Je zet een AI-agent op je Google Ads-account. Hij analyseert, komt met voorstellen, en een deel daarvan is best goed. Maanden later stelt hij precies dat ene ding voor dat je in maart hebt geprobeerd en na drie weken hebt teruggedraaid.
Hij weet dat niet, en hij kán het niet weten: elke sessie begint blanco.
Dit is geen modelprobleem, en een groter contextvenster lost het niet op. Je plakt dan alleen meer geschiedenis in een sessie die straks alsnog wordt afgesloten. Het probleem is dat er geen geheugenlaag zit tussen jouw kennis van het account en de agent die erop werkt.
Ik bouw die laag inmiddels voor de accounts die ik beheer. Hieronder wat werkt, wat kapotgaat, en waarom het belangrijkste ontwerpbesluit contra-intuïtief is: er mogen geen cijfers in.
Wat je vastlegt en wat je live ophaalt
Google Ads-data verandert dagelijks. Erger nog: met terugwerkende kracht. Conversies komen dagen na de klik binnen, dus de ROAS van vorige week is vandaag een ander getal dan gisteren.
Zet je "ROAS Shopping NL: 4,2" vast in het geheugen van je agent, dan leg je een momentopname vast die de volgende dag alweer achterhaald is. Je agent redeneert er vervolgens op verder, waardoor die verouderde waarde doorwerkt in elke aanbeveling die daarna komt.
De splitsing die wél werkt:
- Het geheugen bepaalt wélke vraag je stelt.
- De API geeft het antwoord, live, op het moment van de vraag, met het juiste tijdvenster.
Alles wat in het geheugen staat heeft een houdbaarheid van maanden tot jaren. Alles wat per dag verandert wordt opgehaald.
Dat betekent in de praktijk ook dat je met twee vensters werkt. Een realtime venster voor spend, budget en biedingen, dat is direct correct. En een vertraagd venster voor ROAS, CPA en conversievolume, dat is pas compleet als de lag voorbij is. Een agent die de twee door elkaar haalt, trekt zelfverzekerd verkeerde conclusies over de afgelopen week.
Wat er dan wél in gaat
1. Het beslislog, mét uitkomst
Dit is verreweg het waardevolste onderdeel, en het onderdeel dat vrijwel nergens wordt bijgehouden.
Niet: "tROAS 400% ingesteld op 14 maart."
Wel: de hypothese, wat je verwachtte, wanneer je zou beoordelen, wat er daadwerkelijk gebeurde, en of het is teruggedraaid.
De verzameling mislukte experimenten is waardevoller dan de lijst met successen. Successen herhaal je toch wel. Het zijn de mislukkingen die je elk jaar opnieuw uitvoert, omdat niemand zich nog herinnert dat je ze al eens hebt gedaan.
---
id: 2026-03-14-shopping-troas-400
type: decision
account: klant-x
campagne: shopping-nl-hoofd
datum: 2026-03-14
hypothese: >
Shopping NL draait op Maximaliseer klikken en koopt te veel laagwaardig
verkeer. tROAS 400% duwt de mix richting hogere ordermarge, met maximaal
20% volumeverlies als acceptabele prijs.
wijziging: biedstrategie Maximaliseer klikken -> tROAS 400%
evaluate_at: 2026-04-25 # datum + conversie-lag (11d) + leerperiode (14d)
status: geëvalueerd
uitkomst: >
ROAS van 3,1 naar 4,4. Maar omzet -38%, ruim buiten de 20% die we
hadden afgesproken. Campagne had ~22 conversies/maand: te weinig
signaal om de strategie te laten sturen.
conclusie: teruggedraaid op 2026-04-28
regel: >
Onder ~30 conversies/maand per campagne geen tROAS. Eerst consolideren,
daarna pas waardegericht bieden.
bron: human
---Twee dingen aan dit voorbeeld doen het werk. De evaluate_at, daar kom ik zo op. En de regel onderaan: dat is de destillatie. Dát is wat een agent over zes maanden leest en toepast, zonder het hele verhaal door te hoeven ploegen.
2. Invarianten
Dingen die waar blijven. Marges per productgroep. Welke conversieactie écht telt en welke ruis is. De attributie-instelling. De conversie-lag zoals je die in dít account hebt gemeten, dus geen vuistregel uit een blog. En afspraken met de klant die nergens in de interface staan.
---
id: attributie-en-conversieacties
type: invariant
account: klant-x
review_at: 2026-10-01
---
- Enige conversieactie die meetelt in bieden: `Aankoop (web)`.
`Nieuwsbrief` en `Contactformulier` staan bewust op secundair.
(bron: human, 2026-01-12)
- Attributie: datagedreven, 30 dagen click-through.
- Gemeten conversie-lag: 80% binnen 4 dagen, 95% binnen 11 dagen.
Gemeten over Q4 2025. Beoordeel ROAS nooit over de laatste 11 dagen.
(bron: api, 2026-01-08)
- Merkcampagne nooit pauzeren zonder overleg. Reden: een distributeur bood
in 2024 op ons merk; afspraak is dat wij zichtbaar blijven.
(bron: human, 2026-02-03)Dit is de laag die agents structureel missen. Een agent die niet weet dat Nieuwsbrief bewust op secundair staat, gaat je vertellen dat het conversievolume tegenvalt.
3. Entiteiten en vergelijkingen
Campagnes, biedstrategieën, feeds, conversieacties, doelgroepen: elk met een eigen pagina die beschrijft wat het ding is en waarom het zo is opgezet. Plus de vergelijkingen daartussen: hoe verhoudt Shopping NL zich tot Shopping BE, en waarom lopen ze uiteen?
4. Open vragen
Wat weet je niet? "Kannibaliseert PMax onze merkcampagne?" Het staat er, met datum, en het staat er over drie maanden nog steeds als niemand het heeft beantwoord. Een to-dolijst die niet verdwijnt zodra je het tabblad sluit.
De feedbackloop duurt weken, geen seconden
In een codebase weet je binnen een minuut of een wijziging werkt: de test slaagt of niet. In Google Ads duurt dat weken. Conversie-lag plus leerperiode, en dan wil je ook nog genoeg volume voor een eerlijke uitspraak.
Je geheugen heeft dus een wachtrij nodig. Elke beslissing krijgt bij het wegschrijven een evaluatiedatum:
evaluate_at = beslisdatum + conversie-lag + leerperiodeEn dan moet er iets zijn dat op die datum terugkomt en de uitkomst invult. Zonder die stap krijg je een log vol beslissingen zonder afloop, en daar strandt vrijwel elk beslislog. Het wordt pas waardevol als de uitkomst erin staat, en de uitkomst kost geduld.
Houd het klein en leesbaar
De onvermijdelijke vraag: vectordatabase? Knowledge graph? Nee. Niet hiervoor.
Op accountniveau praat je over tientallen tot een paar honderd bestanden. Te weinig om infrastructuur voor op te tuigen. En de grootste winst van platte markdown-bestanden is dat jíj ze kunt lezen. En corrigeren. Als een agent iets verkeerd heeft opgeschreven, wil je het kunnen doorstrepen zonder in een embedding te gaan graven.
Scope is wat het klein houdt:
- MCC is het archief. Read-only. Alles staat erin, niemand schrijft erin.
- Account is de langlopende laag. Invarianten en beslislog leven hier jaren.
- Opdracht is wegwerpbaar. Een audit, een migratie, een kwartaaloptimalisatie. Per opdracht scope je omlaag naar wat je nodig hebt.
Één globaal geheugen over alle klanten heen is de opzet waarin dit omvalt: te groot, te traag, en je lekt context van de ene klant naar de andere.
De patroonlaag over klanten heen
Beheer je meerdere accounts, dan ontstaat er iets dat je in één account nooit vindt: patronen die overal gelden. "Onder ongeveer 30 conversies per maand per campagne stuurt tROAS niet." Dat haal je niet uit één account; je ziet het pas als het je vijf keer is misgegaan.
Dit is meteen de gevaarlijkste laag. Drie regels:
- Alleen geanonimiseerd. Nooit iets dat herleidbaar is naar een klant.
- Alleen met een drempel. Gezien bij n accounts, consistente richting, meetbare effectgrootte.
- Behandel het als aanname. Elk account mag hem weerleggen.
Twee dingen die het slopen
Herkomst per claim. Een agent leidt uit een vage klantmail af: "wil geen merkcampagne pauzeren". Dat wordt een notitie. Zes maanden later behandelt een andere agent het als harde afspraak, en niemand weet meer waar het vandaan kwam. Een gehallucineerde regel in het geheugen is erger dan geen geheugen, want elke volgende sessie leest hem opnieuw en bevestigt hem.
Dus: elke claim krijgt een herkomst (api, human, inferred), een datum en een betrouwbaarheid. Harde afspraken schrijft een mens. Daar mag de agent alleen lezen.
Verrotting. Google Ads-kennis veroudert sneller dan bijna elk ander domein. Elk kwartaal verdwijnt een instelling of verandert een biedstrategie van gedrag. Je hebt iets nodig dat periodiek langsloopt en markeert: welke entries zijn over hun reviewdatum, welke worden tegengesproken door verse data, welke verwijzen naar een campagne die niet meer bestaat.
Een geheugenlaag zonder onderhoud is over een jaar een verzameling verkeerde aannames met een gezaghebbende toon.
Waar je morgen kunt beginnen
Niet met terugwerkende kracht. Dat valt namelijk tegen: change_event in de Google Ads API geeft je maximaal 30 dagen historie (en maximaal 10.000 rijen per query). change_status reikt 90 dagen terug, maar geeft alleen welke velden zijn gewijzigd, zonder de oude en de nieuwe waarde erbij. Je échte historie zit in je eigen spullen: audits die je hebt verstuurd, mailwisselingen met de klant, rapportages.
Het goedkoopste startpunt ligt dus vooruit:
- Kies één account. Eentje met genoeg historie en genoeg beslissingen om binnen een kwartaal iets te zien.
- Schrijf de invarianten op. Een uur werk. Marges, conversieacties, attributie, gemeten lag, klantafspraken. Direct waardevol, ook zonder agents, ook voor je collega die het account overneemt.
- Log vanaf nu elke wijziging als beslissing. Hypothese, wijziging, evaluatiedatum. Dertig seconden per wijziging.
- Zet een herinnering op die evaluatiedatum. En vul de uitkomst in. Dit is de stap die iedereen overslaat en de enige die het geheel waardevol maakt.
Na één kwartaal heb je iets wat geen enkel model uit zichzelf heeft: de geschiedenis van dít account, inclusief wat er níet werkte.
Dit is dezelfde beweging die ik beschreef in Google Ads als redeneerprobleem: de winst zit in wat de agent tussen sessies door onthoudt. Het sluit ook aan op AI-agents zijn belangrijker dan AI-modellen, waar ik beschrijf dat het model wisselbaar is en de opgebouwde kennis het bezit blijft.
Tot slot
De verleiding bij AI-agents is om aan het model te sleutelen. Beter prompten, groter venster, nieuwer model. In de praktijk beslist dat zelden of een voorstel aardig is of bruikbaar. Dat verschil zit in wat de agent weet over jouw account en nergens in de interface terugkomt.
Uiteindelijk is dit een documentatieprobleem. Documentatie, alleen dan geschreven voor een lezer die geen geheugen heeft en alles letterlijk neemt.