Wat is een AI-agent precies?
Definitie: AI-agent
Een AI-agent is een taalmodel dat niet alleen antwoordt, maar ook handelt. Hij krijgt een opdracht, bepaalt zelf welke stappen nodig zijn, roept daarvoor tools aan — een database, een API, een documentzoeker — en gebruikt de resultaten om verder te werken, net zo lang tot de taak af is.
Het verschil met een chatbot is dat eerste woord: handelen. Een chatbot praat over je factuuradministratie; een agent kan hem daadwerkelijk bevragen. Dat onderscheid klinkt klein maar verandert alles aan wat je ermee kunt, en aan wat er mis kan gaan.
Belangrijk om meteen te zeggen: "agent" is geen synoniem voor "autonoom". De nuttigste agents die we in de praktijk zien, doen het voorwerk en leggen het resultaat bij een mens neer. Daarover verderop meer.
Waarom de meeste AI-agents stranden
Een demo bouwen die indruk maakt, lukt in een middag. Een agent die over drie maanden nog gebruikt wordt, is een ander verhaal. De patronen die we terugzien zijn opvallend consistent, en het ligt vrijwel nooit aan het model:
- De taak was te vaag. "Help ons met offertes" is geen opdracht die je kunt beoordelen. "Haal uit een binnengekomen aanvraag de klantgegevens en de gevraagde leverdatum" wel.
- De data was niet op orde. De agent put uit bronnen die elkaar tegenspreken, verouderd zijn of waar niemand eigenaar van is. Het resultaat is rommel, maar dan met veel zelfvertrouwen gebracht.
- Er was geen controlemoment. Collega's vertrouwen een systeem niet dat zonder tussenkomst dingen de deur uit doet — en terecht.
- Niemand wist waarom de agent iets deed. Zonder vastlegging van welke bron tot welk antwoord leidde, is een fout niet te herleiden en dus niet te repareren.
- De kosten liepen stilletjes op. Een agent die in een lus hangt, roept het model honderd keer aan voor één taak. Zonder bovengrens merk je dat pas op de rekening.
Kort samengevat: het bouwen is het makkelijke deel. De keuze van de taak, de kwaliteit van de data eronder en de rol van de mens bepalen of het iets wordt.
De vier bouwstenen van een AI-agent
Elke agent, hoe eenvoudig of complex ook, bestaat uit dezelfde vier onderdelen. Wie die uit elkaar houdt, houdt ook overzicht over waar een fout vandaan komt.
- Het model. De motor die redeneert en beslist welke stap volgt. Dit is het onderdeel waar je het minst aan hoeft te sleutelen: elk modern model kan tools aanroepen. Kies een kleiner, goedkoper model voor eenvoudige taken en schaal pas op als dat aantoonbaar nodig is.
- De tools. Wat de agent kan dóén: een tabel bevragen, een document ophalen, een berekening uitvoeren, een systeem aanroepen. Hier zit het echte werk, en hier zit ook de begrenzing: een agent kan alleen wat je hem geeft.
- Het geheugen. Wat de agent onthoudt binnen een taak (de tussenresultaten) en daarbuiten (eerdere gesprekken, vastgelegde voorkeuren). Begin klein: voor veel taken is "geen geheugen tussen taken" de juiste keuze, omdat het gedrag dan voorspelbaar blijft.
- De orkestratie. De lus die alles aan elkaar knoopt, plus de grenzen: hoeveel stappen mag de agent zetten, wat gebeurt er bij een fout, wanneer stopt hij en legt hij het bij een mens neer.
De kern: een agent is een lus
Hier zit de grootste misvatting rond agents. Het klinkt als iets ingewikkelds, maar in de kern is het dit: stuur de vraag naar het model, kijk of het een tool wil gebruiken, voer die uit, stuur het resultaat terug, herhaal. Meer niet.
Onderstaand voorbeeld is een complete, werkende agent met één tool. Hij gebruikt de Anthropic-SDK, maar het patroon is bij elke aanbieder hetzelfde.
import anthropic
client = anthropic.Anthropic() # leest ANTHROPIC_API_KEY uit de omgeving
# 1. De tool: wat de agent kan doen. De beschrijving is belangrijker dan je denkt --
# het model kiest hierop of hij de tool gebruikt, en met welke waarden.
TOOLS = [{
"name": "zoek_order",
"description": (
"Zoek een order op in het ordersysteem aan de hand van het ordernummer. "
"Geeft klant, status en leverdatum terug. Gebruik dit altijd voordat je "
"iets over een order beweert; gok nooit."
),
"input_schema": {
"type": "object",
"properties": {
"ordernummer": {"type": "string", "description": "Bijvoorbeeld ORD-2026-0041"}
},
"required": ["ordernummer"],
},
}]
def zoek_order(ordernummer: str) -> dict:
"""De echte uitvoering. Hier praat je met je eigen database of API."""
# In productie: een query op je datamart, met een alleen-lezen account.
rij = database.haal_order(ordernummer)
if rij is None:
# Expliciet 'niet gevonden' teruggeven is beter dan een lege dict:
# het model weet dan dat het niets moet verzinnen.
return {"gevonden": False, "reden": "ordernummer bestaat niet"}
return {
"gevonden": True,
"klant": rij.klant,
"status": rij.status,
"leverdatum": rij.leverdatum.isoformat(),
}
SYSTEM = (
"Je helpt medewerkers met vragen over orders. Gebruik altijd de tool om "
"gegevens op te zoeken en baseer je antwoord uitsluitend daarop. Weet je iets "
"niet of geeft de tool niets terug, zeg dat dan. Verzin nooit gegevens."
)
MAX_STAPPEN = 6 # harde bovengrens: zonder dit kan een agent blijven rondlopen
def vraag(tekst: str) -> str:
berichten = [{"role": "user", "content": tekst}]
for _ in range(MAX_STAPPEN):
antwoord = client.messages.create(
model="claude-sonnet-5-5",
max_tokens=1024,
system=SYSTEM,
tools=TOOLS,
messages=berichten,
)
# Klaar: het model wil geen tool meer gebruiken.
if antwoord.stop_reason != "tool_use":
return "".join(b.text for b in antwoord.content if b.type == "text")
# Het model wil een tool aanroepen. Uitvoeren en het resultaat terugsturen.
berichten.append({"role": "assistant", "content": antwoord.content})
resultaten = []
for blok in antwoord.content:
if blok.type != "tool_use":
continue
uitkomst = zoek_order(**blok.input)
resultaten.append({
"type": "tool_result",
"tool_use_id": blok.id,
"content": str(uitkomst),
})
berichten.append({"role": "user", "content": resultaten})
return "Ik kom er niet uit binnen het toegestane aantal stappen."Dat is het. Geen framework, geen abstractielagen. Drie dingen in deze code verdienen aandacht omdat ze het verschil maken tussen een demo en iets bruikbaars:
MAX_STAPPEN. Zonder bovengrens kan een agent eindeloos doorgaan, met een rekening tot gevolg. Begin laag en verhoog alleen als je ziet dat het nodig is.- De toolbeschrijving. Het model kiest op basis van die tekst. "Gebruik dit altijd voordat je iets beweert; gok nooit" is geen beleefdheidsfrase maar stuurt gedrag.
- Expliciet "niet gevonden". Een lege uitkomst nodigt uit tot invullen. Een duidelijk nee geeft het model iets om op terug te vallen.
Waar het echt om draait: de data eronder
In de code hierboven staat één onopvallende regel: database.haal_order(ordernummer). Daar zit in de praktijk het leeuwendeel van het werk, en daar lopen de meeste trajecten vast.
Een agent is namelijk precies zo goed als wat hij kan opzoeken. Als "status" in het ene systeem iets anders betekent dan in het andere, als de leverdatum in drie bronnen verschilt, of als niemand weet welke tabel de juiste is — dan geeft de agent antwoorden die klinken alsof ze kloppen. Dat is erger dan geen antwoord.
Dit is ook waarom wij als data-engineeringbureau juist met AI bezig zijn: het is grotendeels hetzelfde werk. Bronnen ontsluiten, definities eenmaal vastleggen, historie bijhouden, rechten regelen. Wie dat op orde heeft, kan er een agent op zetten. Wie dat niet heeft, bouwt een demo.
Praktische volgorde
Je hoeft niet te wachten op een compleet dataplatform. Kijk welke bronnen je agent concreet nodig heeft voor één taak, en zorg dat díe bereikbaar en betrouwbaar zijn. Vaak blijkt tijdens het bouwen welk stuk data aandacht nodig heeft — dat is dan een concreet vervolg in plaats van een aanname vooraf. Meer hierover in onze gids over ERP-data naar een modern dataplatform.
De laatste stap is een mens
De verleiding is groot om een agent volledig zelfstandig te laten werken. In de praktijk is dat zelden de beste keuze, en niet alleen om risico's te beperken.
Een agent die een conceptantwoord klaarzet dat een medewerker nakijkt, wordt sneller geaccepteerd dan een agent die zelf verstuurt. Collega's zien wat hij doet voordat het gevolgen heeft, en bouwen daardoor vertrouwen op. Bovendien levert elk goedgekeurd of gecorrigeerd concept informatie op over waar de agent nog niet goed genoeg is.
Een bruikbare vuistregel: alles met gevolgen naar buiten gaat langs een mens. Verzenden, toezeggen, vastleggen, betalen. Opzoeken, samenvatten, voorbereiden en klaarzetten mag de agent zelf.
Leg daarnaast vast wat er gebeurde: welke tool is aangeroepen, met welke invoer, wat kwam eruit. Zonder dat spoor is een fout niet te herleiden, en kun je ook niet uitleggen waarom de agent tot een bepaald antwoord kwam.
Veelgemaakte fouten bij het bouwen van een AI-agent
- Beginnen met de moeilijkste taak. Het meest indrukwekkende idee is zelden het beste startpunt. Kies een taak die vaak terugkomt en duidelijke spelregels heeft; die is ook het makkelijkst te beoordelen.
- Te veel tools tegelijk. Hoe meer tools, hoe vaker het model de verkeerde kiest. Begin met één of twee en breid uit als dat aantoonbaar nodig is.
- Geen bovengrens op stappen of kosten. Zonder harde limiet ontdek je een lus pas achteraf.
- Een framework kiezen voordat je het probleem kent. Een agent is een lus. Bouw die eerst zelf, dan weet je wat een framework voor je oplost — en of je het nodig hebt.
- De agent laten raden. Als een opzoeking niets oplevert, moet dat expliciet terugkomen. Lege resultaten nodigen uit tot invullen.
- Succes niet vooraf definiëren. Spreek af wanneer het resultaat goed genoeg is, vóór je begint. Anders blijft "het werkt wel een beetje" eindeloos hangen.
Zelf een AI-agent laten bouwen?
Onder de naam AIpartner365 bouwen we AI-agents en automatiseringen die aansluiten op je bestaande processen, systemen en data. We kijken eerst samen wat haalbaar is met wat er nu al ligt — en zeggen het ook als AI niet de beste route is.
Conclusie
Een AI-agent maken is technisch goed te doen: de lus uit deze gids is veertig regels code en werkt. Het moeilijke zit elders. Kies een taak die vaak terugkomt en duidelijke spelregels heeft. Zorg dat de agent bij betrouwbare gegevens kan, want hij is niet beter dan wat hij kan opzoeken. Bouw harde grenzen in op stappen en kosten. En laat de laatste stap bij een mens liggen, zolang er gevolgen aan vastzitten.
Begin klein, laat het werken, en breid pas uit als je ziet dat het oplevert wat je hoopte. Dat is minder spectaculair dan een volledig autonome agent, maar het is wel wat er over een half jaar nog draait.
Benieuwd wat er voor jouw organisatie haalbaar is? Bekijk ons AI-aanbod onder AIpartner365, of lees hoe we dataplatformen inrichten als fundament daaronder.
Veelgestelde vragen
Wat is het verschil tussen een AI-agent en een chatbot?
Een chatbot praat, een agent doet. Een chatbot geeft antwoord op basis van wat het model weet of wat er in het gesprek staat. Een agent kan tools aanroepen: een database bevragen, een API aanroepen, een document ophalen. Daardoor kan hij werken met gegevens die het model niet kent, en taken uitvoeren in plaats van alleen beschrijven.
Welke programmeertaal gebruik je om een AI-agent te maken?
Python is de meest gebruikte taal, omdat vrijwel elke LLM-aanbieder een Python-SDK heeft en de meeste databibliotheken erin beschikbaar zijn. TypeScript is een goed alternatief wanneer de agent in een webomgeving draait. De taal is zelden de bepalende keuze: de koppelingen naar je eigen systemen zijn het echte werk.
Heb je een framework zoals LangChain nodig om een agent te bouwen?
Nee. Een agent is in de kern een lus: vraag het model wat het wil doen, voer dat uit, geef het resultaat terug. Dat zijn ongeveer veertig regels code, zoals het voorbeeld hierboven laat zien. Een framework kan helpen bij grotere systemen, maar voor een eerste werkende agent voegt het vooral abstractie toe die het lastiger maakt om te zien waar iets misgaat.
Hoeveel kost het draaien van een AI-agent?
De kosten zitten in tokens: je betaalt per verwerkte tekst. Een agent die per taak een paar keer een model aanroept, kost doorgaans enkele centen per taak. Wat de rekening laat oplopen is niet de prijs per aanroep maar het aantal: een agent die in een lus blijft hangen of telkens de hele context meestuurt. Bouw daarom vanaf het begin een harde bovengrens in op het aantal aanroepen en een maandbudget.
Moet mijn dataplatform klaar zijn voordat ik een AI-agent kan bouwen?
Niet helemaal. Voor een eerste toepassing is meestal genoeg dat de bronnen die de agent nodig heeft bereikbaar en betrouwbaar zijn. Vaak blijkt tijdens het bouwen juist welk stuk data aandacht nodig heeft; dat is dan een concreet vervolg in plaats van een aanname vooraf. Wel geldt: een agent die put uit rommelige data geeft rommelige antwoorden, alleen dan met meer zelfvertrouwen.
Hoe voorkom je dat een AI-agent dingen verzint?
Door hem niet te laten raden. Geef de agent tools waarmee hij feiten kan opzoeken, laat hem bij elk antwoord vermelden waar het vandaan komt, en laat hem expliciet "weet ik niet" zeggen als een opzoeking niets oplevert. Verzinnen is meestal geen modelprobleem maar een ontwerpprobleem: het model kreeg geen manier om het echte antwoord te vinden.
Mag een AI-agent zelfstandig e-mails versturen of betalingen doen?
Technisch kan het, maar het is zelden verstandig. Alles met gevolgen naar buiten of voor een klant hoort langs een mens: verzenden, toezeggen, vastleggen, betalen. De agent bereidt voor, een medewerker keurt goed. Dat scheelt niet alleen risico, het maakt ook de invoering makkelijker omdat collega's zien wat de agent doet voordat het echt gebeurt.