AI agents die werk uit handen nemen

Chatbot versus agent: het verschil in de praktijk

Een chatbot reageert. Je stelt een vraag, je krijgt een antwoord. De chatbot heeft geen geheugen van vorige berichten, geen toegang tot externe systemen en geen vermogen om iets te doen buiten de conversatie. Dat is nuttig voor klantenservice, FAQ-afhandeling en informatieverstrekking. Maar een chatbot voert geen taken uit.

Een AI agent handelt. Je geeft een opdracht als startpunt. De agent analyseert de opdracht, bepaalt welke stappen nodig zijn, voert die stappen uit via tool-calls en controleert of het resultaat klopt voordat het de volgende stap zet. Als iets mislukt, herstelt de agent zichzelf of vraagt om menselijke input. Het proces stopt pas als de opdracht is afgerond of als de agent aangeeft dat het niet verder kan.

Het onderscheid is architectureel. Een chatbot is een input-output-systeem. Een agent is een lus: plan, actie, observatie, correctie. Die lus kan meerdere cycli doorlopen voor een enkele opdracht. Dat maakt agents geschikt voor taken die te complex zijn voor een script maar te context-afhankelijk voor een vaste automatisering.

Wanneer een agent de goede keuze is

Niet elke taak heeft een agent nodig. Maar voor een specifieke categorie taken is een agent de meest effectieve oplossing:

• ▸Multi-stap taken waarbij elke stap afhangt van het resultaat van de vorige stap. Een script kan dit niet goed verwerken omdat de vertakkingen te complex zijn.
• ▸Taken waarbij context-afhankelijke beslissingen nodig zijn. De agent moet begrijpen wat de juiste actie is op basis van de specifieke situatie, niet op basis van een vaste rule.
• ▸Taken waarbij meerdere tools gecombineerd moeten worden. Bijvoorbeeld: data ophalen uit een systeem, analyseren, verrijken via een externe API en het resultaat wegschrijven.
• ▸Taken waarbij foutafhandeling zelf ook denkvermogen vereist. Als een tool een onverwacht resultaat teruggeeft, moet de agent beslissen of dat acceptabel is of dat het de taak anders moet aanpakken.
• ▸Taken waarbij de output gevalideerd moet worden voordat die gebruikt wordt. De agent kan zijn eigen resultaat beoordelen en opnieuw proberen als het niet voldoet.

Het gemeenschappelijke kenmerk is variabiliteit. Als de taak altijd op precies dezelfde manier verloopt, is een script of n8n-workflow efficienter. Zodra de taak variatie kent die menselijk redeneren vereist, is een agent de betere keuze.

Wanneer je geen agent nodig hebt

Een agent bouwen is duurder dan een script schrijven of een workflow in n8n configureren. Dat is geen probleem als de taak er om vraagt, maar het is wel een reden om kritisch te zijn:

• ▸Volledig deterministische taken: als de stappen altijd identiek zijn en de input gestructureerd is, is een script of workflow sneller, goedkoper en betrouwbaarder dan een agent.
• ▸Enkelvoudige API-calls: als het neerkomt op data ophalen en wegschrijven zonder beslissingen ertussen, bouw ik liever een directe integratie of n8n-node.
• ▸Regelgebaseerde logica: als de beslissingen volledig uitgeschreven kunnen worden in if-then regels zonder AI-redeneren, heeft een agent geen toegevoegde waarde.
• ▸Situaties met nul tolerantie voor variatie: voor financiele transacties of medische data waar elke afwijking onacceptabel is, is een agent niet de juiste keuze. Deterministische code is veiliger.
• ▸Als het budget niet past bij de complexiteit: agents verbruiken meer tokens per taak dan een chatbot. Bij grote volumes moeten de kosten meegewogen worden.

Ik zeg dit in een kennismaking ook als het van toepassing is. Als een simpelere oplossing beter past, stel ik die voor. Dat is uiteindelijk beter voor de samenwerking.

Architectuur: hoe ik een agent bouw

De kern van elke agent die ik bouw bestaat uit drie lagen:

• ▸Reasoning engine: Claude (via de Anthropic API) of OpenAI's nieuwste model (via de OpenAI API) als het model dat plant, beslist en tekst genereert. De keuze hangt af van de taak, het budget en de vereiste context-window.
• ▸Tool layer via MCP servers: de agent heeft toegang tot een set tools die ik expliciet definieer. Een tool kan een database-query zijn, een REST API-call, een bestandsbewerking of een externe dienst. Elke tool heeft een schema met parameters en een beschrijving. De agent beslist zelf welke tool relevant is.
• ▸State-laag in Postgres: de agent slaat zijn huidige taakstatus op in een Postgres-tabel. Elke stap wordt gelogd met timestamp, tool-naam, parameters, resultaat en eventuele fouten. Zo is de volledige uitvoering te reconstrueren.
• ▸Audit log: naast de state-tabel schrijf ik alle tool-calls weg naar een aparte audit-log. Die log is read-only en niet muteerbaar. Bedoeld voor debugging, compliance en post-mortem analyse.
• ▸Orchestrator: de applicatiecode die de lus aanstuurt. Het stuurt de opdracht naar het model, verwerkt de tool-calls, geeft resultaten terug aan het model en bepaalt wanneer de taak klaar is of gestopt moet worden.

De orchestrator is bewust simpel. Complexe orchestratie-frameworks voegen abstracties toe die debugging moeilijker maken. Ik schrijf de orchestrator zelf in TypeScript of Python, afhankelijk van de context.

Guardrails: hoe ik de agent in toom houd

Een agent zonder grenzen is een agent die je niet kunt vertrouwen. Elke agent die ik bouw heeft expliciete beperkingen:

• ▸Max iterations: de agent stopt na een configureerbaar maximum aantal stappen, ook als de taak niet klaar is. Dat voorkomt oneindige loops bij onverwachte input of modelfout.
• ▸Tool whitelist: de agent heeft alleen toegang tot tools die expliciet zijn gedefinieerd. Geen generieke code-uitvoering, geen toegang tot systemen buiten de scope. Elke tool staat in de config.
• ▸Human-approval op kritieke acties: acties met onomkeerbare gevolgen, zoals bestanden overschrijven, data verwijderen of externe berichten sturen, vereisen een goedkeuringsstap van een mens. De agent pauzeert en wacht.
• ▸Rollback transactions: schrijfacties naar een database lopen via transacties. Als de agent halverwege een fout maakt, wordt de hele operatie teruggedraaid. Geen gedeeltelijk gewijzigde data.
• ▸Parameter-validatie per tool: elke tool-call wordt gevalideerd voordat die uitgevoerd wordt. Onjuiste parameters worden geweigerd met een duidelijke foutmelding die de agent kan interpreteren.
• ▸Confidence threshold: voor taken waarbij de agent een beoordeling maakt, configureer ik een minimale zekerheidsdrempel. Onder die drempel vraagt de agent om menselijke input.

Guardrails zijn geen bijzaak. Ze zijn de reden dat je een agent kunt inzetten op echte taken zonder constant toe te kijken.

Wat ik niet doe

Er zijn bewuste grenzen aan wat ik bouw:

• ▸Geen agents zonder logging. Als er geen audit-trail is, is er geen manier om te controleren wat de agent heeft gedaan. Ik lever altijd een volledig gelogd systeem.
• ▸Geen agents met onbeperkte tool-access. Een agent die toegang heeft tot alles is een veiligheidsrisico. De tool-whitelist is altijd expliciet en minimaal.
• ▸Geen agents zonder error-recovery. Een agent die vastloopt en stopt zonder melding is niet productierijp. Foutafhandeling en fallback naar human-in-the-loop zijn standaard.
• ▸Geen agents voor taken waarbij deterministische code beter past. Als een script of workflow de taak afdekt, is dat de betere keuze.
• ▸Geen agents zonder duidelijke stopconditie. Een agent moet weten wanneer hij klaar is. Zonder stopconditie blijft een agent itereren totdat het token-budget op is.

Lees verder