Overzicht van AI agents en tool calling
AI agents worden steeds vaker genoemd als de volgende stap na chatbots, maar wat betekent dat precies op technisch niveau en hoe werkt tool calling daar in detail bij? In dit artikel wordt de terminologie ontdaan van hype en teruggebracht tot concrete, begrijpelijke bouwstenen.
Kernpunten in dit artikel:
Definitie van AI agents en het verschil met klassieke chatbots
Uitleg van tool calling, function calling en hoe LLMs acties uitvoeren
Architecturen zoals single agent met meerdere tools en multi agent systemen
Typische use cases in softwareontwikkeling en bedrijfsprocessen
Belangrijke aandachtspunten rond veiligheid, foutafhandeling en observability
Aan het einde kun je:
De belangrijkste begrippen rond AI agents correct plaatsen
Uitleggen hoe tool calling onder water werkt
Beter beoordelen welke architectuur bij een use case past
Gerichte vragen stellen aan ontwikkelaars of leveranciers over agent gebaseerde oplossingen
Wat zijn AI agents precies
De term AI agent wordt op veel manieren gebruikt, maar in kern gaat het om een softwarecomponent die een doel krijgt, zelfstandig beslissingen neemt en acties uitvoert via tools of systemen. Een moderne AI agent combineert meestal een groot taalmodel met logica voor geheugen, planning en toolgebruik.
Een AI agent verschilt van een klassieke chatbot doordat hij niet alleen tekst genereert, maar ook daadwerkelijk stappen kan zetten in een proces. Denk aan het aanmaken van een ticket, het uitvoeren van een zoekopdracht in een externe database of het plannen van een afspraak. De agent interpreteert de gebruikersintentie, kiest welke tool hij nodig heeft en roept die tool vervolgens aan via een gedefinieerde interface.
In technische documentatie wordt vaak onderscheid gemaakt tussen een aantal varianten. Een reactieve agent reageert vooral op input zonder uitgebreide planning. Een reflectieve of planning agent kan meerdere stappen vooruit denken, subdoelen formuleren en zijn eigen tussenresultaten evalueren. In veel moderne oplossingen worden deze concepten gecombineerd, wat leidt tot agent frameworks waar reasoning, geheugen en tool calling strak geïntegreerd zijn.
AI agents worden typisch aangestuurd door een LLM dat de rol van beslissingsmotor vervult. Het model krijgt systeeminstructies, context en een beschrijving van beschikbare tools. Op basis daarvan genereert het model een volgende stap, bijvoorbeeld een tool call of een direct tekstueel antwoord. Dit patroon is terug te zien in diverse platformen voor agent orchestration en in de function calling interfaces van de grote LLM aanbieders.
Tool calling en function calling uitgelegd
Tool calling, ook wel function calling genoemd, is een mechanisme waarbij een LLM niet alleen tekst produceert, maar ook gestructureerde instructies teruggeeft die door een applicatie kunnen worden uitgevoerd. Het model kiest bijvoorbeeld een functie `search_documents` met specifieke parameters en de applicatie voert die functie uit in echte code.
In de praktijk wordt dit ingericht door tools te definiëren als functies met een naam, beschrijving en schema voor parameters. Dit schema is vaak JSON gebaseerd, waarbij duidelijk is welke velden verplicht zijn en welke typen worden verwacht. Het LLM krijgt deze tooldefinities als onderdeel van de prompt. Als de agent besluit dat een tool nodig is, genereert het een gestructureerd object in plaats van gewone tekst. De applicatie herkent dat als tool call, voert de functie uit en geeft het resultaat terug aan het model in een volgende iteratie.
Een vereenvoudigd voorbeeld van een tooldefinitie kan er zo uitzien:
{
"name": "create_support_ticket",
"description": "Maak een nieuw supportticket aan in het systeem",
"parameters": {
"type": "object",
"properties": {
"subject": { "type": "string" },
"priority": { "type": "string", "enum": ["low", "normal", "high"] },
"customer_id": { "type": "string" }
},
"required": ["subject", "customer_id"]
}
}Wanneer de agent besluit deze tool te gebruiken, zal de LLM een gestructureerde call genereren met de juiste velden. De host applicatie voert vervolgens de onderliggende logica uit, bijvoorbeeld een API call naar een ticketsysteem. Het resultaat, bijvoorbeeld het nieuwe ticketnummer, wordt teruggegeven aan het model als observatie. De agent kan dit daarna opnemen in het gesprek met de gebruiker of weer gebruiken als input voor vervolgstappen.
Tool calling ondersteunt vaak meerdere rondes. De agent kan een reeks tools achter elkaar aanroepen, afhankelijk van de complexiteit van de taak. Dit is de basis voor agentic workflows waarin een agent bijvoorbeeld eerst gegevens ophaalt, daarna een berekening uitvoert en ten slotte een rapport opstelt. In veel moderne LLM implementaties is er ondersteuning voor tool use, planning en beperkt geheugen, wat deze scenario's praktisch haalbaar maakt.
Architecturen met AI agents en tools
In de praktijk worden een aantal basisarchitecturen onderscheiden voor AI agents en tool calling. Een veelvoorkomend patroon is de single agent met meerdere tools. In dit model krijgt één agent toegang tot een set tools, bijvoorbeeld een zoekfunctie, een e mailsysteem en een CRM API. De agent kiest per stap welke tool relevant is en blijft verantwoordelijk voor de volledige taak van begin tot eind.
Een andere architectuur is het multi agent systeem, waarbij meerdere gespecialiseerde agents samenwerken. Een planningsagent kan bijvoorbeeld de taak opdelen in subtaken en die doorgeven aan specialistische agents, zoals een research agent, een data transformatie agent en een rapportage agent. Deze agents communiceren onderling via berichten, waarbij een orchestrator of router bepaalt welke agent wanneer aan zet is. Dit patroon wordt vaak ingezet bij complexe workflows met meerdere domeinen of wanneer schaalbaarheid en foutisolatie belangrijk zijn.
De keuze tussen single agent en multi agent is meestal afhankelijk van complexiteit en beheerbaarheid. Voor relatief eenvoudige bedrijfsprocessen is een goed gedefinieerde single agent architectuur vaak voldoende en beter te testen. Bij grotere scenario's, zoals end to end klantprocessen over meerdere systemen, kan een multi agent opzet met duidelijke verantwoordelijkheden per agent transparanter zijn. Het wordt dan ook eenvoudiger om agents afzonderlijk te monitoren, te loggen en te verbeteren.
In softwarearchitectuur zijn observability en controle belangrijke aandachtspunten. Elke tool call vormt een grens tussen het LLM en de echte wereld. Daarom wordt er in productieomgevingen vaak gekozen voor een tussenlaag die alle tool calls logt, valideert en waar nodig verrijkt. Ook worden guardrails toegepast, bijvoorbeeld door permissies per tool te definiëren en door input en output te valideren. Zo blijft inzichtelijk welke acties een agent uitvoert en kunnen ongewenste acties worden voorkomen of teruggedraaid.
Toepassingen, kwaliteitsborging en veiligheidsaspecten
AI agents met tool calling worden in uiteenlopende domeinen toegepast, van klantenservice tot documentverwerking en softwareontwikkeling. In klantenservice scenario's kan een agent bijvoorbeeld klantgegevens ophalen, bestellingen wijzigen of een terugbetaling voorbereiden. In documentgedreven processen kan een agent bestanden analyseren, relevante stukken extraheren en conceptdocumenten genereren, waarbij tools zorgen voor toegang tot documentopslag, OCR en workflow systemen.
Kwaliteitsborging bij agent gebaseerde systemen vraagt om een combinatie van klassieke softwaretestmethoden en nieuwe evaluatietechnieken voor LLM gedrag. Unit tests en integratietests worden aangevuld met scenario gebaseerde evaluaties, waarbij de agent wordt geconfronteerd met realistische dialogen en randgevallen. Daarbij wordt niet alleen gekeken naar de inhoud van de antwoorden, maar ook naar het gebruik van tools, de volgorde van stappen en het naleven van vooraf gedefinieerde policies.
Veiligheid speelt een centrale rol bij tool calling, omdat de agent toegang krijgt tot systemen die wijzigingen kunnen doorvoeren of gevoelige data kunnen lezen. Daarom wordt in productiesystemen gebruikgemaakt van expliciete autorisatiemodellen per tool. Een tool kan bijvoorbeeld alleen leesrechten hebben, of alleen binnen een bepaald klantsegment opereren. Input sanitization, rate limiting en auditing van elke tool call zijn standaardmaatregelen om misbruik of fouten te beperken.
Tot slot is er aandacht nodig voor privacy en data minimalisatie. Agents werken vaak met contextvensters die informatie tijdelijk in het model laden. Door gegevens te pseudonimiseren, velden te maskeren en alleen strikt noodzakelijke gegevens te delen, kan worden voldaan aan wettelijke en organisatorische vereisten. In moderne implementaties worden logs en conversation history daarom zorgvuldig ontworpen, met duidelijke retentiebeleid en mogelijkheden om specifieke interacties terug te trekken of te anonimiseren.
