Wat is een AI-agent? Een taalmodel in een lus met gereedschap

Je denkt waarschijnlijk dat een AI-agent een slimmere, zelfstandige AI is die zelf nadenkt en handelt, zoals een robot met een eigen wil, of op zijn minst iets heel anders dan de chatbot die je kent. Geen van beide klopt. Een agent is precies hetzelfde taalmodel, alleen in een lus gezet met gereedschap.

Kijk wat er gebeurt bij één opdracht. Je typt: boek morgen om 10 uur een vergaderruimte en stuur de uitnodiging. Een gewone chatbot schrijft daar tekst over terug, meer kan hij niet. Een agent doet dit:

• hij leest het doel en kiest de tool check-beschikbaarheid;
• hij ziet dat ruimte 3 vrij is en kiest boek-ruimte;
• hij ziet de bevestiging en kiest stuur-uitnodiging;
• hij ziet dat die verstuurd is en meldt: klaar.

Vier keer opnieuw keek het model naar alles wat er tot dan toe stond, het doel plus de tool-resultaten, en koos het de volgende zet. Dat heen-en-weer is geen truc bovenop het model. Het is het hele idee.

Nu pas de definitie, want nu heb je hem al zien draaien. Een AI-agent is geen apart, autonoom brein. Het is hetzelfde taalmodel dat je uit een chatbot kent, in een lus gezet met gereedschap: je geeft het een doel, het model kiest een actie (een tool aanroepen, of stoppen), de runtime voert die uit, het resultaat gaat terug in de context, en het model kiest de volgende zet, net zolang tot het doel gehaald is of een limiet bereikt. Die observeer-beslis-handel-lus heeft een naam in het onderzoek: reason-and-act, kortweg ReAct, het model dat redeneren en handelen afwisselt in plaats van alles in één keer te bedenken.

Loop die drie lagen na in gewone taal, want daar zit alles in.

Wie voert die tool eigenlijk uit?

Niet het model. Dit is het stukje dat bijna iedereen verkeerd heeft. Kiest het model een tool, dan produceert het geen actie maar een verzoek: een gestructureerde aanroep met de naam van de tool en de argumenten. OpenAI beschrijft de volgorde in vijf stappen: je stuurt het model een vraag met de tools die het mág gebruiken, je krijgt een tool-aanroep terug, jouw eigen code voert die uit, je stuurt het resultaat terug naar het model, en dan komt het antwoord (of de volgende aanroep). Het model draait je code dus nooit zelf. Het vraagt erom; de runtime doet het. En elke keuze die het onderweg maakt is dezelfde next-token-voorspelling als in een gewone chat, alleen nu op een context die na elke stap groeit.

Dat verklaart meteen waar MCP past en waar niet. MCP is de standaard die de tools beschrijft en verbindt, de USB-C-poort waarlangs elke app bij dezelfde tool kan. Maar kiezen wélke tool, met welke argumenten, dat doet het model, niet MCP. Verwar de poort niet met het brein. Een handige tool is trouwens opzoeken in je eigen documenten, precies wat RAG doet: dat grondt het antwoord in echte bronnen in plaats van in wat het model denkt te weten.

Waarom lopen lange agent-runs zo op?

Omdat de agent geen apart geheugen heeft. Alles wat hij binnen een run onthoudt staat in de context, het werkgeheugen dat hij elke stap opnieuw helemaal leest. Elke observatie en elk tool-resultaat wordt er onderaan bijgeplakt, en bij de volgende stap gaat dat hele, groeiende geheel opnieuw mee naar het model. Vijf stappen ver stuur je de eerste vier resultaten dus vier keer opnieuw mee.

Daarom tikken de tokenkosten van een agent zo aan. Microsoft mat bij agentische taken dat het tokenverbruik tot twaalf keer kan oplopen, en een agent-run kan tot 136 keer meer energie kosten dan één chatbotvraag. Op een gegeven moment loopt die groeiende context bovendien tegen de bovengrens van het venster aan, waarna de agent de oudste stappen kwijtraakt.

Waar gaat het mis, en wat houd je ertegen?

Bij elke stap opnieuw. Omdat elke beslissing een kansige voorspelling is, kan een agent net zo goed iets verzinnen als een chatbot, alleen handelt hij er nu naar. Hij kan de verkeerde tool kiezen, een resultaat verkeerd lezen, in een lus blijven hangen of langzaam van het doel afdwalen. Over veel stappen stapelt dat op: bij 95 procent betrouwbaarheid per stap is een run van twintig stappen nog maar in ongeveer 36 procent van de gevallen foutloos.

Daarom hoort er een hek omheen. Anthropic beschrijft onder meer een harde limiet op het aantal stappen zodat een lus niet oneindig doorloopt, menselijke goedkeuring voor risicovolle acties zoals een factuur versturen of een record overschrijven, en het toetsen van de uitkomst aan de echte omgeving in plaats van aan wat het model erover zegt. Guardrails halen het risico omlaag; ze halen het niet weg. Dat verschil is precies waarom een agent die alleen mág lezen ongevaarlijker is dan een die mág schrijven.

Chatbot, vaste workflow of agent?

Drie dingen die op elkaar lijken, met één verschil dat telt: wie de stappen kiest. Een chatbot antwoordt één keer en klaar. Een vaste workflow doet altijd dezelfde stappen in dezelfde volgorde, als-dit-dan-dat, volkomen voorspelbaar. Een agent kiest zijn stappen zélf, onderweg naar een doel, en dat maakt hem flexibel maar minder voorspelbaar. De praktische regel is kort: liggen de stappen vooraf vast, neem een workflow; liggen ze niet vast, dan pas heb je een agent nodig. Zulke agents zijn geen theorie meer, ze draaien als product dat uren kantoorwerk zelfstandig afmaakt.

Zodra je een agent ziet als een model in een lus, valt de mystiek weg. De vraag verschuift van of deze AI slim genoeg is om te vertrouwen naar iets veel nuchterder: welke stappen laat ik hem zelf kiezen, welke tools geef ik hem in handen, en waar zet ik het hek. Dat is geen vraag over hoe geniaal het model is. Het is een ontwerpvraag, en die kun je zelf beantwoorden, voor elke taak die je overweegt uit handen te geven.