Wat een AI-agent echt is (en de vier onderdelen die hem laten werken)

Het woord agent is inmiddels opgerekt tot alles tussen een chatbot met een systeemprompt en een volledig autonoom engineeringsysteem. Die vaagheid kost geld: teams kopen een "agentplatform" en verwachten autonomie, maar krijgen een formulier met een taalmodel erachter. Of ze bouwen een autonome lus voor een taak die met één API-aanroep klaar was.

Dit is de definitie die wij in productie hanteren, en de vier onderdelen die je daadwerkelijk moet bouwen.

De definitie

Een AI-agent is een systeem waarin een taalmodel bepaalt wat er vervolgens gebeurt, en waarin die beslissingen effect hebben in de echte wereld.

Twee zinsdelen, allebei dragend.

Het model beslist — dat onderscheidt een agent van een workflow. In een workflow heb jij de besturing geschreven: stap één roept de classifier aan, stap twee vertakt op het label, stap drie stuurt de e-mail. Het model vult de gaten in. In een agent kiest het model de volgorde. Je wist vooraf niet of hij eerst de kennisbank zou doorzoeken of eerst de orderstatus zou opvragen.

Beslissingen hebben effect — dat onderscheidt een agent van een chatbot. Een chatbot produceert tekst die een mens leest en waarnaar die mens handelt. Een agent verwerkt de terugbetaling zelf.

Als geen van beide waar is, heb je geen agent — en dat is meestal goed nieuws. Agents kosten meer, zijn trager en falen op vreemdere manieren dan de alternatieven.

Moet dit überhaupt een agent zijn?

Voordat we naar architectuur kijken, doen we een triage op vier punten:

• Complexiteit. Is de taak echt lastig vooraf te specificeren? "Haal het factuurtotaal uit deze pdf" niet. "Zoek uit waarom deze klant ontevreden is en los het op" wel.
• Waarde. Wegen de hogere latency en het hogere tokenverbruik op tegen de uitkomst? Eén agent-beurt kan 20× zoveel kosten als één classificatie-aanroep.
• Haalbaarheid. Is het model vandaag daadwerkelijk goed in dit soort taken? Wees eerlijk — meet het, ga er niet van uit.
• Kosten van een fout. Kan een fout worden opgemerkt en teruggedraaid? Agents die naar een staging-branch schrijven: prima. Agents die geld overmaken: ander ontwerp.

Is een antwoord "nee", ga dan een niveau lager. Het meeste werk dat het label "agentic" krijgt, is beter af als workflow: jij houdt de besturing, het model doet de taalstappen, en je kunt het debuggen.

De vier onderdelen

1. Het model

De redeneerkern. Twee beslissingen zijn hier belangrijk en worden vaak door elkaar gehaald.

Welk model. Routeer per stap, niet per systeem. Een snel, goedkoop model classificeert de intentie; een topmodel behandelt alles wat klantgericht of oordeelsgevoelig is. Dat is geen compromis — het is meestal én nauwkeuriger én goedkoper, omdat het kleine model duizend keer per dag dezelfde smalle taak draait en je het fatsoenlijk kunt evalueren.

Hoeveel redeneren. Moderne modellen bieden een knop voor redeneerdiepte. Meer diepte betekent meer deliberatie, meer tool-aanroepen, meer tokens; minder diepte betekent sneller, korter, letterlijker. Dat is een knop die je op je eigen evaluatieset uitprobeert, niet een waarde die je uit een blog overneemt. In onze implementaties ligt het optimum voor routinematig operationeel werk meestal één stand onder de standaardwaarde; de hoogste standen bewaren we voor lange autonome runs.

2. Tools

Tools zijn de handen van de agent. De ontwerpvraag is niet welke tools er zijn — maar op welk niveau je ze blootstelt.

Eén enkele bash-tool geeft het model enorm bereik. Maar hij geeft jouw harnas ook één ondoorzichtige string voor élke mogelijke actie, wat betekent dat je er niets van kunt afschermen, controleren, weergeven of parallelliseren.

Promoveer een actie tot een eigen tool wanneer je:

• Hem wilt afschermen. Moeilijk omkeerbare acties — een e-mail sturen, een record verwijderen, geld terugstorten — hoor je afzonderlijk te kunnen goedkeuren. verwerk_retour(order_id, bedrag) is makkelijk af te schermen. bash -c "curl -X POST ..." niet.
• Een invariant wilt afdwingen. Een aparte bewerk_bestand-tool kan een schrijfactie weigeren als het bestand is gewijzigd sinds de agent het las. Een shell-commando kan dat niet.
• Hem wilt weergeven. Sommige acties verdienen eigen UI. Een vraag_gebruiker-tool kan een dialoog openen met opties.
• Hem wilt parallelliseren. Jouw harnas kan een alleen-lezen zoektool markeren als veilig om gelijktijdig te draaien. Het kan een veilige grep niet onderscheiden van een onveilige git push als beide als shell-string binnenkomen.

Vuistregel: begin breed, promoveer naarmate je leert. En wees voorschrijvend in je tool-omschrijvingen — zeg wanneer de tool aangeroepen moet worden, niet alleen wat hij doet. "Roep dit aan als de klant vraagt naar bezorgtijd of een vermist pakket" presteert ruim beter dan "Haalt tracking-informatie op", omdat de omschrijving het enige is wat het model leest bij het beslissen.

3. Context

Het werkgeheugen van de agent. Hier gaan de meeste productie-agents daadwerkelijk mis. Het verdient een eigen artikel, maar kort samengevat:

• Retrieval zet de juiste feiten op het juiste moment voor het model. Een agent die antwoordt uit modelgeheugen in plaats van uit je live orderdata, zit er met veel zelfvertrouwen naast.
• Compactie en snoeien voorkomen dat lange runs verzuipen. Naarmate een sessie tool-resultaten opstapelt, verdient oude output zijn plek in het venster niet meer. Vat de historie samen of gooi verouderde tool-resultaten er gewoon uit.
• Persistent geheugen neemt lessen mee tussen sessies. Zelfs een simpel Markdown-bestand dat de agent leest en schrijft, verbetert langlopende agents meetbaar — één les per bestand, een samenvatting van één regel bovenaan, en de expliciete instructie om het te raadplegen.

4. De controlelus

Het deel dat van jou is. Minimaal:

zolang niet klaar:
    antwoord = model(context, tools)
    als antwoord.wil_tool:
        resultaat = voer_uit(antwoord.tool_aanroep)   # hier zit jouw poortwachter
        context.voeg_toe(resultaat)
    anders:
        klaar = waar

Elke SDK levert hier een versie van. Gebruik die van hen — de hooks per beurt geven je goedkeuringspoorten, foutafhandeling, retries en aanpassing van resultaten zonder dat je de lus met de hand schrijft. Schrijf je eigen versie alleen als je controle nodig hebt die het harnas echt niet biedt.

Wat telt, is wat je er in stopt:

• Een stopconditie die niet alleen "het model hield op" is. Begrens het aantal iteraties. Begrens het totale tokenverbruik per taak. Detecteer lussen waarin de agent dezelfde tool drie keer met dezelfde argumenten aanroept.
• Een escalatiepad. Een betrouwbaarheidsdrempel die overdraagt aan een mens, mét geschreven samenvatting, is meer waard dan welke hoeveelheid prompt-tuning ook. De agent die weet wat hij niet weet, is de agent die je kunt uitrollen.
• Een volledig audittrail. Elke tool-aanroep, elke input, elk resultaat, elke beslissing. Je gaat het nodig hebben — om te debuggen, voor compliance, en voor de evaluatieset die je opbouwt uit echte fouten.

Hoe dit er in de praktijk uitziet

Een support-agent die "waar blijft mijn bestelling" afhandelt:

1. Model — een middenklassemodel op lage redeneerdiepte. De taak is smal en de evaluatieset is groot.
2. Tools — zoek_order(email_of_nummer), haal_tracking(order_id), escaleer_naar_mens(samenvatting, reden). Drie tools, elk met een voorschrijvende omschrijving. Geen shell.
3. Context — het orderrecord, de live respons van de vervoerder, het verzendbeleid van het merk voor die markt, en de laatste drie berichten uit het gesprek. Verder niets.
4. Lus — maximaal vier iteraties. Levert tracking niets op, of gebruikt de klant taal die matcht met onze escalatieset, dan meteen overdragen met een samenvatting.

Meer is het niet. Het lost de overgrote meerderheid van een echte ticketwachtrij op, en elk onderdeel is inspecteerbaar. Het is niet indrukwekkend op een demopodium. Het werkt op een dinsdag.

De valkuil die je moet vermijden

De meest voorkomende fout die we zien, is dat mensen met de lus beginnen. Iemand zet een autonome agent op, geeft hem brede tools, schrijft een ambitieuze systeemprompt, en spendeert daarna drie maanden aan het bijschaven van proza om gedrag te repareren dat met een aparte tool en een beslisgrens in één dag opgelost was.

Bouw eerst de tools. Bouw eerst de retrieval. Krijg de context goed. De lus is het laatste en kleinste onderdeel — en als je de andere drie goed hebt gedaan, blijkt vaak dat je helemaal geen agent nodig had.

---

AIMAGENTIC bouwt AI-agents die in productie draaien — support, content, retentie en rapportage, binnen jouw stack en met jouw sleutels. Wil je de gerangschikte kaart van wat automatiseerbaar is in jouw operatie? Plan een auditgesprek.