De meeste AI-teams die betere prestaties van agenten nastreven, grijpen naar dezelfde middelen: grotere contextvensters, meer documenten en slimmere prompts. Dit artikel betoogt dat dit precies de verkeerde reflex is. Het ontbrekende ingrediënt is niet meer informatie. Het is controle. Een goed ontworpen controlelaag maakt het verschil tussen een agent die in een demo werkt en een agent die in productie werkt.
Een AI-agent wordt niet slimmer van een groter geheugen, meer documenten of een langer contextvenster, maar alleen langzamer en duurder. De echte winst ontstaat wanneer je de agent leert te kiezen wat hij nodig heeft en wanneer, in plaats van alles tegelijk te verwerken.
Betrouwbaarheid komt uit de lus, niet uit het model. Het verschil tussen een agent die indruk maakt in een demo en een agent die standhoudt in productie, is niet de kwaliteit van de AI, maar of het systeem zijn eigen werk controleert. Agenten die bij elke stap plannen, handelen, observeren en verifiëren, ontdekken hun eigen fouten in plaats van vol zelfvertrouwen de mist in te gaan.
De meeste AI-agenten zijn tegenwoordig in wezen chatbots met extra stappen: ze hebben geen mechanisme om te weten of ze op koers liggen, wanneer ze moeten stoppen of wanneer ze een andere aanpak moeten proberen. Een goede controlelaag met duidelijke succescriteria, een gestructureerde status en validatiecontroles verandert iets wat alleen op een agent lijkt in iets wat je echt kunt vertrouwen.
Wat heb je gisteren als lunch gegeten?
Waarschijnlijk speelde je niet elke herinnering uit je leven opnieuw af totdat je bij "gisteren + lunch" kwam. Je ging meteen naar het deel van je ervaring waarin die concepten thuishoren. Dat is een nuttig denkmodel voor het bouwen van agenten:
Een enorm contextvenster is geen geheugen.
Een stapel opgehaalde documenten is geen begrip.
Een lange chain-of-thought is geen betrouwbaarheid.
Dat zijn ingrediënten. Maar wat een agent als een agent laat aanvoelen, is hetzelfde wat voorkomt dat je brein je hele levensgeschiedenis brute-force doorzoekt: controle.
Een recent onderzoek, Agentic Reasoning for Large Language Models, vat de verschuiving die velen van ons tijdens het bouwen ervaren uitstekend samen en geeft die een naam: van redenering binnen het model naar redenering via interactie. Dit artikel is geen samenvatting van die paper. Het is een poging om deze verschuiving te vertalen naar praktisch systeemontwerp:
Als je agenten bouwt als chatbots met tools, blijf je dezelfde fouten krijgen als bij chatbots, maar dan met duurdere gevolgen.
Lange tijd bestond ons standaardrecept om "het model slimmer te maken" uit betere prompts, chain-of-thought, zelfconsistentie of verbeteringen op basis van sampling, en misschien wat zoekwerk.
ReAct was een kantelpunt, omdat het "gedachte → actie → observatie" natuurlijk liet aanvoelen. Maar let op de impliciete beperking: veel hiervan komt nog steeds neer op "one-shot inferentie, maar met meer tokens". De formulering van het onderzoek is scherper: agentgestuurde redenering benadrukt het opschalen van interactie tijdens de testfase. Inferentie wordt zo een iteratief proces waarin het model, het geheugen en de omgeving allemaal in de lus blijven.
Als je agenten hebt gebouwd of gebruikt die indrukwekkend zijn in demo's maar kwetsbaar in echte workflows, is dit voor jou.
Ik beschrijf een patroon dat ik vaak heb gezien en waarvan ik zelf zeker ook versies heb gebouwd:
Neem een goed chatmodel
Voeg enkele tools toe (zoeken, databasequery's en eventueel code-uitvoering)
Voeg RAG toe
Voeg een systeemprompt toe met "je bent een autonome agent"
Zet alles in een while-lus totdat het stopt of de time-out wordt bereikt
Gefeliciteerd, je hebt iets dat op een agent lijkt. Maar het gaat vaak op voorspelbare manieren mis:
Opgeblazen context: elke observatie wordt toegevoegd en prompts veranderen in archeologische aardlagen.
Doelloos toolgebruik: "zelfverzekerd de verkeerde tool gebruiken" wordt de standaardfout.
Geen stopvoorwaarden: het gaat door omdat het kan, niet omdat het moet.
Geen discipline bij verankering: het merkt niet dat het fout zit, tenzij je het daartoe dwingt.
Geheugen = chatgeschiedenis: dat komt neer op logboeken schrijven en dat leren noemen.
Daarom voelen "agenten" in demo's vaak magisch en zijn ze in productie rommelig. Onze ervaring met het in productie nemen van agentgestuurde systemen bevestigt dit: zodra je geen model maar een systeem evalueert, omvatten de foutmodi ook navigatie, zorgvuldig toolgebruik, contextopschoning en het ontwerp van evaluaties, en niet alleen de vraag of het model correct antwoordde.
De vraag wordt dus: hoe ziet de doelbewust ontworpen agent eruit?
Om dit concreter te maken, volgt hier een eenvoudig voorbeeld van een workflow die de meeste mensen zich kunnen voorstellen: "Book me a flight from London to New York next Tuesday. Arrive before 6pm. Keep it under £900. Aisle seat."
Een veelvoorkomende implementatie die op een agent lijkt, werkt zo:
Haalt direct allerlei documenten over luchtvaartmaatschappijen en reisbeleid op, ook als die nog niet nodig zijn.
Roept een zoektool aan, plakt een lange lijst met resultaten in de prompt en "kiest er één".
Boekt te vroeg, zonder beperkingen te controleren zoals aankomsttijd, bagage, stoel en beleid.
Als dat mislukt, probeert het systeem het op een iets andere manier opnieuw, maar zonder duidelijk beeld van wat er veranderde of wat het leerde.
Het probleem is niet dat het model niet kan redeneren, maar dat het systeem geen controle over de workflow heeft.
Een meer agentgestuurde versie behandelt de taak als een interactief proces met een expliciete status en controles:
PLANNEN: herhaal de beperkingen en noem ontbrekende informatie (bijv. "welk vliegveld heeft je voorkeur?" / "is één overstap acceptabel?").
HANDELEN: roep de vluchtzoekfunctie aan met een gestructureerde query (datumbereik, uiterste aankomsttijd en budget).
OBSERVEREN: sla de resultaten op in een compact statusobject (de vijf beste opties met prijs, aankomsttijd en overstappen), niet als een enorme geplakte tekstmassa.
BIJWERKEN: verfijn de query als niet aan de beperkingen wordt voldaan (bijv. "aankomst vóór 18.00 uur is te strikt: het tijdvenster verruimen of het budget verhogen?").
VERIFIËREN: voer validators uit ("aankomst < 18.00 uur", "prijs ≤ £ 900", "voldoet aan beleid", "stoelkeuze beschikbaar").
STOPPEN: pas wanneer de boekings-API een bevestiging teruggeeft en alle validators slagen.
De verandering is subtiel, maar doorslaggevend. Informatie wordt voorwaardelijk opgehaald (niet uit reflex), context wordt beheerd (de status is gestructureerd en stapelt zich niet op) en verificatie maakt deel uit van de lus (en wordt niet aan de gebruiker overgelaten). Vervang "een vlucht boeken" door "een inkooporder maken", "een terugbetaling uitvoeren", "een productieconfiguratie wijzigen" of "een PR opleveren" en hetzelfde geldt: zodra de agent kan handelen, is de lus belangrijker dan de prompt.
Het bovengenoemde onderzoek verdeelt agentgestuurde redenering in drie lagen: fundamenteel (planning, toolgebruik en zoeken), zelfontwikkelend (feedback en geheugen) en collectief (coördinatie tussen meerdere agenten).
Maar het diepere idee is dat redenering het organiserende principe wordt voor planning, besluitvorming en verificatie, en niet alleen voor het genereren van een aannemelijke chain-of-thought. Dat klinkt abstract totdat je het koppelt aan de veranderingen in je architectuur. Er zijn drie kernpunten om te onthouden:
Een goede agent moet informatie niet standaard altijd ophalen. Dat is een beslissing, geen reflex.
Een praktische vuistregel:
Als je systeem bij elke beurt informatie ophaalt, heb je geen goede retrieval gebouwd maar een contextbelasting.
Dit zie je voortdurend in de praktijk. Bij het debuggen van een productie-incident stort je niet alle logboeken in de context; op basis van je huidige hypothese bepaal je welke meetgegevens en logboeken je vervolgens ophaalt. Dat is "agentgestuurde retrieval". Een concreter patroon ziet er zo uit:
Bepaal of je informatie moet ophalen
Zo ja: stel een query op, haal informatie op, scan die en extraheer wat relevant is
Als bewijs tegenstrijdig is: haal opnieuw informatie op
Maak pas daarna een synthese
Hier begint "agentgestuurde RAG" ook af te wijken van traditionele RAG: informatie ophalen wordt een bewuste redeneerstap in plaats van een standaardfase in de pipeline.
Zodra je niet langer "een model" maar "een systeem" evalueert, worden statustracking en tracing belangrijk.
De sector is inmiddels explicieter geworden over observability voor agentworkflows. De Agents SDK van OpenAI heeft bijvoorbeeld ingebouwde tracing en een Traces-dashboard dat uitvoeringen van agenten vastlegt (generaties, toolaanroepen, overdrachten, guardrails en aangepaste gebeurtenissen), zodat je stap voor stap kunt debuggen en controleren wat er is gebeurd.
Dat is niet alleen "mooi meegenomen". Het maakt het verschil tussen een systeem dat je kunt debuggen en een systeem dat je alleen op gevoel kunt beoordelen.
Het praktischst aan het onderzoek vind ik hoe duidelijk het over feedback is. Het verdeelt feedback in drie regimes: reflectieve feedback (genereren → bekritiseren → herzien), parametrische aanpassing (leren via finetuning/RL) en validatiegestuurde feedback (opnieuw proberen totdat een validator slaagt).
De meeste teams kunnen het beste beginnen met validatiegestuurde feedback, omdat die saai maar doeltreffend is. Als je ook maar één validator kunt schrijven die unittests uitvoert, het schema controleert, bedrijfsregels of beperkingen afdwingt ("geen terugbetalingen boven X zonder escalatie") of feitelijkheid waarborgt ("bronvermeldingen verplicht"), kun je niet-deterministische modeluitvoer omzetten in iets wat je echt kunt vertrouwen.
Een van de onverwachte verschuivingen is eenvoudig: bij agenten komt betrouwbaarheid vaak eerder uit de lus dan uit het model.
Dit is de eenvoudigste gedisciplineerde lus die volgens mij zonder training betrouwbaar tot beter gedrag leidt:
Werk in stappen: Plannen → Handelen → Observeren → Bijwerken,
Vat na elke handeling de observatie samen in 1–3 punten,
Stop zodra aan de succescriteria is voldaan of het budget is bereikt; geef het beste bekende resultaat en de resterende onzekerheden terug.
Het gaat er niet om het model breedsprakig te maken. Het gaat erom het systeem inzichtelijk te maken en bij elke stap "contact met de werkelijkheid" af te dwingen. Een voor engineers herkenbaar voorbeeld is verankering in een gesloten lus, zoals bij CI:
Plannen: een lijst met wijzigingen voorstellen
Handelen: tests/linting uitvoeren
Observeren: fouten verwerken
Bijwerken: patchen en opnieuw proberen
Enkele vragen die onbedoelde agentontwerpen vaak blootleggen:
"Kiest mijn agent wat er moet worden opgehaald, of haal ik altijd informatie op?"
Als informatie onvoorwaardelijk wordt opgehaald, betaal je daarvoor met vertraging, kosten, verwatering van de context en een groter risico op garbage in, garbage out.
"Kan mijn agent merken dat hij het mis heeft?"
Als het enige feedbacksignaal van je agent is dat de gebruiker geïrriteerd raakt, pas je RL toe met menselijk leed. Een validatiegestuurde lus voor nieuwe pogingen is de duidelijkste manier om de agent met de werkelijkheid te confronteren.
"Is het geheugen beschrijfbaar en wordt het na verloop van tijd beter?"
Als je "geheugen" alleen chatgeschiedenis toevoegt, schrijf je in feite logboeken. De kijk van het onderzoek op geheugen is belangrijk: geheugen wordt een dynamisch groeiende context die agenten na verloop van tijd verfijnen, niet slechts een transcript.
Logboeken vertellen wat er is gebeurd; geheugen vertelt wat je de volgende keer moet doen. Chatgeschiedenis is een transcript. Geheugen is een zich ontwikkelend beleid voor wat de moeite waard is om te bewaren.
Een praktisch begin is een kleine tabel met "geleerde lessen", geordend op taaktype, tool en foutmodus, met als waarde wat werkte en wat je beter kunt vermijden. Het doel is niet om een perfecte kennisgraaf te bouwen. Het doel is cumulatief beter gedrag: geheugen en feedback veranderen agenten van "toestandsloze helpers" in systemen die na verloop van tijd verbeteren.
Het is verleidelijk om meer agenten op het probleem af te sturen, maar daardoor neemt de coördinatielast vaak sterk toe. Een goed patroon voor een "minimaal werkbaar team":
Coördinator: splitst op en wijst toe
Uitvoerder: doet toolaanroepen en brengt wijzigingen aan
Criticus/evaluator: controleert juistheid en risico's
Geheugenbeheerder: legt lessen vast en beheert ze
Als je niet kunt uitleggen waar elke agent verantwoordelijk voor is, heb je waarschijnlijk nog geen meerdere agenten nodig.
Als we deze paradigmaverschuiving echt omarmen, stoppen we waarschijnlijk met alles in prompts te proppen, mislukkingen als definitieve uitvoer te behandelen en agenten als chatbots te evalueren. In plaats daarvan behandelen we agenten als wat ze zijn: softwaresystemen waarin taal het besturingsvlak vormt en betrouwbaarheid uit de lus komt.
Voeg vóór een extra model eerst een extra evaluatielus toe. Maak het ophalen voorwaardelijk voordat je alles ophaalt. Lever eerst één validator op voordat je er tien oplevert. Behandel geheugen als beleidskeuzes, niet als een database. En als je voor multi-agent kiest, begin dan met twee agenten, niet met twintig. Dit zijn geen regels, maar patronen die zich in productie hebben bewezen.