Hoe AI‑agenten werken: het model, tools, geheugen en de controlelus

Een AI‑agent werkt door een model te combineren met instructies, tools, geheugen en een controlelus die herhaaldelijk beslist wat de volgende stap is. Het model levert oordeel‑ en taalvaardigheden, terwijl de omringende software die mogelijkheden omzet in een stateful proces dat kan handelen, resultaten kan inspecteren, fouten kan herstellen en kan stoppen.

Het begrijpen van deze architectuur is nuttiger dan een agent te beschouwen als één enkel intelligent object. De meeste successen en mislukkingen ontstaan door de manier waarop de componenten samenwerken: een uitstekend model kan ondermijnd worden door vage tools, verouderd geheugen, te ruime permissies, of een controlelus zonder een betrouwbare definitie van voltooiing.

De vijf kernonderdelen van een AI‑agent

1. het model

Het model interpreteert het doel, redeneert over de beschikbare context en kiest een actie. In veel huidige agenten is dit een groot taalmodel dat instructies kan opvolgen en zowel gestructureerde tool‑oproepen als natuurlijke taal kan produceren.

Het meest capabele model is niet automatisch de beste keuze voor elke stap. Een systeem kan moeilijke planning naar een sterker model sturen, een sneller model gebruiken voor classificatie, en deterministische code inzetten voor validatie. Deze mix kan snelheid, kosten en betrouwbaarheid verbeteren.

2. Instructies

Instructies definiëren de rol, grenzen, prioriteiten en outputvereisten van de agent. Ze kunnen een system‑prompt, taak‑specifieke context, beleidsregels, voorbeelden, tool‑beschrijvingen en stopcriteria omvatten.

Goede instructies zijn operationeel. Ze vertellen de agent welk bewijs vereist is, wanneer om goedkeuring te vragen, welke bronnen acceptabel zijn en hoe voltooiing te herkennen. Vage of tegenstrijdige regels dwingen het model te gokken, wat leidt tot inconsistentie bij vergelijkbare taken.

3. Tools

Tools verbinden het model met mogelijkheden buiten de huidige context. Een tool kan het web doorzoeken, een klantrecord ophalen, code uitvoeren, een database bevragen, een browser besturen of een agenda‑item aanmaken.

Het model voert de functie normaal gesproken niet zelf uit. Het kiest een benoemde tool en stelt gestructureerde argumenten voor. De agent‑runtime valideert dat verzoek, controleert permissies, voert de bewerking uit en retourneert het resultaat. Deze scheiding is essentieel: software krijgt de kans om misvormde of onveilige acties af te wijzen voordat ze de buitenwereld beïnvloeden.

4. Staat en geheugen

De staat is de informatie die de agent nodig heeft tijdens de huidige uitvoering: het doel, het gesprek, het plan, observaties, tool‑uitvoer en voltooide stappen. Geheugen breidt dat concept uit door nuttige informatie buiten de directe context te behouden, zoals eerdere voorkeuren, terugkerende feiten of lessen uit eerdere taken.

Meer geheugen is niet altijd beter. Irrelevante records verbruiken context en kunnen het model naar verouderde aannames sturen. Effectieve geheugensystemen bepalen wat opgeslagen moet worden, hoe het georganiseerd wordt, wanneer het opgehaald moet worden en hoe conflicterende of verouderde informatie wordt afgehandeld.

5. de controlelus

De controlelus is de orkestratielaag die het proces in beweging houdt. Hij stuurt de huidige staat naar het model, ontvangt een voorgestelde actie, voert goedgekeurde tools uit, registreert de observatie en roept het model opnieuw op.

Anthropic beschrijft een agent als een uitgebreid taalmodel dat in een lus opereert met mogelijkheden zoals retrieval, tools en geheugen in hun gids voor effectieve agenten bouwen. OpenAI schetst agent‑executie op vergelijkbare wijze als een voortdurende interactie tussen het model, zijn tools en een omgeving in Van model naar agent.

De interfaces zijn net zo belangrijk als de componenten

Een architectuurdiagram kan elke component er netjes gescheiden laten uitzien, maar echte betrouwbaarheid hangt af van de contracten ertussen. Het model heeft duidelijke tool‑beschrijvingen nodig die vergelijkbare mogelijkheden onderscheiden. De runtime heeft getypte argumenten en expliciete foutstatussen nodig. Geheugen‑retrieval heeft herkomst‑ en versheidsinformatie nodig. De voltooiingscontrole heeft testbare criteria nodig in plaats van een vaag gevoel dat het antwoord “goed genoeg” is.

Beschouw een zoek‑tool die een lege lijst teruggeeft. Dat resultaat kan betekenen dat er geen relevante records bestaan, dat de query verkeerd was, dat de gebruiker geen permissie heeft, of dat de service is verlopen. Als de tool al deze vier situaties in dezelfde output samenvat, kan het model niet betrouwbaar redeneren over wat er is gebeurd. Een goed ontworpen interface levert gestructureerd bewijs: status, bron, tijdstempel, query, aantal resultaten en een machine‑leesbare fout wanneer van toepassing.

Hetzelfde principe geldt voor context. Instructies, gezaghebbende records, opgehaalde passages, door het model gemaakte notities en onbetrouwbare externe inhoud moeten niet als gelijkwaardige tekst worden behandeld. Het labelen van hun bron en autoriteit helpt de runtime beleid af te dwingen en helpt het model het bewijs correct te wegen. Dit is een praktische vorm van context‑engineering: niet alleen bepalen welke informatie het model ziet, maar ook hoe die informatie is georganiseerd en wat het systeem mag laten controleren.

Een stapsgewijs voorbeeld

Stel je een agent voor die drie potentiële leveranciers moet vergelijken en een aanbeveling moet voorbereiden.

1. Ontvang het doel: de agent leest de beslissingscriteria, deadline, budget en vereiste output.
2. Inspecteer de beschikbare context: hij controleert of de namen van leveranciers, interne eisen en bron‑documenten aanwezig zijn.
3. Stel een plan op: hij besluit prijsinformatie, beveiligingsdetails, servicevoorwaarden en klant‑bewijs voor elke leverancier te verzamelen.
4. Selecteer een tool: hij doorzoekt een goedgekeurde documentopslag of roept een extern onderzoekstool aan.
5. Observeer: de runtime retourneert resultaten, inclusief mogelijke fouten of ontbrekende velden.
6. Werk de status bij: de agent registreert wat hij heeft geleerd en markeert onopgeloste vragen.
7. Pas aan: hij wijzigt queries, raadpleegt een andere bron, of vraagt een persoon om een ontbrekend document.
8. Verifieer: hij controleert of elke aanbeveling onderbouwd is en of vergelijkingen dezelfde criteria gebruiken.
9. Stop of vraag goedkeuring aan: hij produceert een concept‑aanbeveling, maar laat de uiteindelijke aankoopbeslissing over aan de bevoegde persoon.

Het belangrijke punt is dat de volgorde niet volledig hard‑gecodeerd was. Het systeem selecteerde stappen op basis van wat het vond, maar opereerde nog steeds binnen de ontworpen grenzen.

Planning is niet altijd een aparte fase

Sommige agenten maken een volledig plan voordat ze handelen. Andere beslissen één stap tegelijk. Veel gebruiken een hybride aanpak: een ruwe schets maken, de volgende actie uitvoeren en het resterende plan bijstellen naarmate observaties binnenkomen.

Lange, starre plannen kunnen achterhaald raken na het eerste onverwachte resultaat. Zuiver reactieve agenten kunnen afdwalen of werk herhalen. Een praktische ontwerpkeuze houdt voldoende planning aan om richting te behouden, terwijl herplanning mogelijk blijft wanneer de omgeving verandert.

Het ReAct‑framework is een fundamenteel voorbeeld van het afwisselen van redeneren met acties en observaties. De kerninzichten zijn dat een extern resultaat een redeneringsstap kan corrigeren, verfijnen of heroriënteren.

Hoe agenten weten wanneer ze moeten stoppen

Stoppen is een ontwerpprobleem. Een model kan te vroeg succes declareren, blijven polijsten nadat het doel bereikt is, of blijven loopen wanneer een tool herhaaldelijk faalt.

Betrouwbare agenten combineren verschillende stopmechanismen:

• Voltooiingscriteria: expliciete voorwaarden zoals vereiste velden, geslaagde tests of geverifieerde citaten.
• Budgetten: limieten op stappen, tijd, model‑tokens, tool‑oproepen of kosten.
• Foutdrempels: escalatie na herhaalde fouten of observaties met lage zekerheid.
• Goedkeuringspoorten: een pauze vóór acties met grote impact of onomkeerbare gevolgen.
• Externe beoordelaars: deterministische controles of aparte modellen die beoordelen of de output aan de taak voldoet.

Veelvoorkomende agentarchitecturen

Een enkele‑agentlus is het eenvoudigste ontwerp: één model gebruikt herhaaldelijk tools totdat het klaar is. Het is makkelijker te debuggen en vaak voldoende.

Een router classificeert het verzoek en stuurt het door naar een gespecialiseerde prompt, toolset of model. Routing vermindert irrelevante keuzes en kan verschillende beleidsregels toepassen op verschillende werkzaamheden.

Een orchestrator‑worker‑architectuur laat een leidende agent subtaken creëren en deze delegeren aan workers, waarna de resultaten worden samengevoegd. Dit is nuttig wanneer werk parallel kan worden uitgevoerd of verschillende specialisaties vereist, maar het verhoogt het token‑verbruik en de kans op coördinatiefouten.

Een evaluator‑optimizer‑lus scheidt generatie van kritiek. Eén component produceert een antwoord; een andere controleert het aan de gedefinieerde criteria; de eerste herziet het. Dit werkt goed wanneer kwaliteit meetbaar is en iteratieve verbetering de extra kosten waard is.

Wat er meestal misgaat

• Slechte toolbeschrijvingen: het model kiest de verkeerde mogelijkheid of levert ongeldige argumenten.
• Onbegrensde context: lange transcripties vullen zich met irrelevante details en verbergen beslissende informatie.
• Stille toolfouten: een leeg of gedeeltelijk resultaat wordt ten onrechte gezien als een geldige observatie.
• Zwakke onderbouwing: de agent handelt op een aanname in plaats van het systeem‑record te controleren.
• Overmatige autonomie: de agent kan ingrijpende acties ondernemen zonder passende beoordelingsgrens.
• Geen trajectevaluatie: teams beoordelen het eindantwoord maar inspecteren niet hoe de agent tot dat resultaat is gekomen.

Ontwerpprincipes voor betrouwbare agenten

Begin met de kleinste architectuur die de taak kan oplossen. Een deterministische workflow moet bekende stappen afhandelen; reserveer modeldiscretie voor beslissingen die echt interpretatie vereisen. Geef elke tool een smal doel, getypte invoer, expliciete foutstatussen en minimaal benodigde rechten.

Maak de status zichtbaar. Log elke tool‑oproep, resultaat, herpoging, goedkeuring en model‑beslissing die nodig is voor diagnose. Comprimeer oude context in plaats van deze eindeloos toe te voegen, en bewaar gezaghebbende data apart van door het model gegenereerde samenvattingen.

Ontwerp de runtime zodat fouten expliciet zijn. Een tool moet onderscheid maken tussen “geen records gevonden” en “verzoek mislukt”, en de status‑store moet geverifieerde feiten scheiden van model‑gegenereerde samenvattingen. Anders kan het model een time‑out interpreteren als bewijs dat iets niet bestaat.

Tot slot, evalueer het volledige systeem. Voer dezelfde taak meerdere keren uit, meet succes en resource‑gebruik, en inspecteer trajecten op beleids­schendingen of fragiele shortcuts. Anthropic’s gids voor agent‑evaluaties benadrukt dat agenten taken, herhaalbare proeven, transcripties en beoordelaars nodig hebben — niet slechts een handvol indrukwekkende demo’s.

Wat te onthouden over hoe AI‑agenten werken

Een AI‑agent is een ontworpen lus, niet alleen een slim model. Het model beslist; tools handelen; geheugen draagt de status; de omgeving levert bewijs; en de controlelus bepaalt wat er vervolgens gebeurt.

Wanneer die onderdelen duidelijke interfaces en grenzen hebben, kan een agent open‑ended werk aan die conventionele automatisering niet kan voorzien. Wanneer dat niet zo is, vergroot autonomie de ambiguïteit. De kwaliteit van een agent hangt daarom evenveel af van systeemontwerp, permissies en evaluatie als van het onderliggende model.