🤖 AI uitgelegd

Hoe een AI-agent echt werkt

Iedereen praat over "AI-agents", maar weinig uitleg laat zien wáárom ze werken — en waaróm ze soms ontsporen. Dit is de korte, werkende mentale-modellen-versie: van "een taalmodel is een functie, geen wezen" tot "meerdere agents die samenwerken". Met de bewegende agent-loop, een diagnose voor waarom agents flaken, het geheugen-spectrum, en een kiezer voor het juiste multi-agent-patroon.

Eerlijk vooraf: dit is een oriëntatie, geen cursus transformer-wiskunde. Het doel zijn de mentale modellen die je nodig hebt om met AI te bouwen en scherper te oordelen wat haalbaar is — niet de volledige theorie. Gedestilleerd uit een persoonlijke AI-leergang; 100% client-side, geen account, niets verlaat je toestel.
Module 1

Genoeg model om te bouwen

Het meest contra-intuïtieve idee eerst, want al het andere hangt eraan: een taalmodel is een bevroren functie, geen wezen. Tekst erin, een gok over het volgende stukje tekst eruit. Geen bedoelingen, geen geheugen tussen twee aanroepen, geen besef van "gisteren". Elke keer dat je het aanroept is het exact hetzelfde model in exact dezelfde staat. Alles wat intelligent lijkt, komt uit dat ene trucje — heel vaak en heel goed herhaald.

Zodra je het als "iemand die onthoudt en bijleert tijdens het gesprek" ziet, snap je agents verkeerd. Het model leert niets tijdens je sessie. Alle schijnbare continuïteit heeft de software er telkens opnieuw ingestopt.

Vijf begrippen — meer heb je niet nodig

Token
Het model leest geen woorden maar tokens (~¾ woord). De munteenheid: alle limieten, kosten en snelheid worden per token gerekend. Nederlands kost méér tokens dan Engels.
Next-token-predictie
Het voorspelt steeds het volgende token en plakt dat erachter — een buitengewoon goede autocomplete. Het genereert het plausibelste vervolg, niet het ware. Dáár komt hallucinatie vandaan.
Context window
Alles wat het model nú "weet": de instructie, het gesprek, tool-resultaten. Een bureau met beperkt oppervlak — vol is vol. Wat er niet in staat, bestaat niet voor het model.
Prompt (system / user)
De system-prompt is de staande instructie (rol + regels) en weegt zwaarder; de user-prompt is de taak van nu. Prompt engineering = het venster zó vullen dat het plausibelste vervolg ook het gewenste is.
Temperatuur
De knop voor hoe gretig het minder waarschijnlijke tokens pakt. Laag = voorspelbaar, hoog = creatief maar wisselvallig. Daarom geeft dezelfde vraag soms twee antwoorden: een geregelde dobbelsteen.
Vloeiend ≠ correct
Een model is standaard geoptimaliseerd op vloeiend. Correct moet je afdwingen — met context, met tools die feiten ophalen, en met verificatie. Het heeft geen ingebouwde "dit weet ik niet"-rem.
Je stuurt niet de motor, je stuurt wat de motor ziet.
Module 2

Wat een agent is — de lus

Een model op zichzelf kan maar één ding: praten. Het kan je vertellen hoe je een bestand zou lezen, maar het kan het niet lezen. Een agent is wat er gebeurt als je twee dingen toevoegt: een lus (roep het model steeds opnieuw aan) en tools (geef het handen om iets in de wereld te doen).

Bij een chatbot ben jíj de lus: jij leest het antwoord en stelt de volgende vraag. Bij een agent mag het model zélf acties ondernemen tussen je vraag en het eindantwoord — en op basis van wat het terugkrijgt zijn volgende stap bepalen. De mens stapt uit de lus voor de tussenstappen. Een agent is dus geen slimmer model — het is hetzelfde model in een lus met gereedschap.

Het belangrijkste inzicht van allemaal:

Het model vraagt, de software doet.

Een tool-aanroep is óók maar tekst. Het model schrijft alleen op wélke hand het zou willen gebruiken; het kán niets uitvoeren. De software eromheen — de harnas (zoals Claude Code) — herkent dat verzoek, doet de echte actie, en plakt het resultaat terug in het venster. Dáárom zitten permissions, sandboxing en die netwerk-firewallpopup precies tussen "model vraagt" en "actie gebeurt".

De lus, in beweging

Druk op Stap (of Auto). Let op het venster rechts: elke observatie wordt teruggeplakt. De agent "weet" wat hij twee stappen geleden deed alleen omdat het nog in het venster staat — niet omdat het model iets onthoudt. Dáárom loopt een lange taak het venster onvermijdelijk vol.

1 · Denken volgende stap bepalen 2 · Handelen tool aanroepen 3 · Observeren resultaat terug 4 · Herhalen — tot de taak af is
Context window
18% gevuld
⚠ Venster bijna vol — de aandacht voor het midden zakt in, vroege instructies schuiven naar de rand, de kwaliteit daalt. Dit is geen bug; het is een ingebouwde eigenschap. Precies waarom geheugen bestaat.

Waar de lus ontspoort

Zodra je een model handen geeft, erf je de risico's van handen. Vier manieren, allemaal direct gevolg van module 1 + "het heeft nu handen":

Oneindige lus
Het blijft tools aanroepen zonder te convergeren. Daarom heeft elke serieuze agent een harde max-stappen-limiet.
Verkeerde tool / argument
Een hallucinatie op tool-niveau: een niet-bestaande flag, een verkeerd pad. Plausibel ogend, feitelijk fout.
Prompt injection
Een opgehaalde webpagina of mail bevat een verborgen instructie. Omdat álles in het venster meeweegt, kan die de agent omleiden — een risico dat een chatbot structureel niet heeft.
Resourceverbruik
Autonome tool-calls kosten geld, tijd, API-calls. Zonder harde limiet kan een ontspoorde lus flink doorverbruiken.
Module 1 · de payoff

Waarom agents flaken — diagnose

Geen van de beruchte flake-modi is een teken dat "de AI dom is". Het zijn allemaal voorspelbare eigenschappen van een probabilistisch component. Kies een symptoom — zie de oorzaak, terug te leiden tot één van de vijf begrippen.

Kies hierboven een symptoom om de oorzaak te zien.

Zie je het patroon? Je bouwt rond iets dat per definitie gokt. Je taak is de gok te omkaderen — robuust, met logging, dry-runs, en de bestandsnaam als status. Niet de motor temmen, maar de gok begrenzen.

Module 3

Geheugen, context & betrouwbaarheid

Het venster is eindig, duur en stateless (module 1) en het groeit bij elke stap (module 2). Daaruit volgt alles: geheugen is de kunst om dat venster slim te vullen — wat bewaar je buiten het venster, en hoe haal je op het juiste moment het juiste stukje terug?

Het kernprobleem: bewaren kan maar op twee manieren

Raw — verbatim opgeslagenVerliesloos, maar inert: een berg transcripts is geen begrip. Alles staat er, niets is verbonden of geprioriteerd.
Derived — samenvattingen & feitenCompact en bruikbaar, maar elke her-afleiding drift weg van de bron — als een kopie van een kopie. Je verliest het geleidelijk en kunt niet aanwijzen wanneer het ophield te kloppen.

Elk geheugensysteem kiest een positie op dit spectrum, en geen van beide uitersten werkt. "Lost een groter context window dit niet op?" Nee: je betaalt elke beurt om álles opnieuw te verwerken (kosten), én modellen worden slechter naarmate het venster vol raakt (degradatie). Oneindige context is gewoon de extreme versie van het raw-pad.

RAG — het meest voorkomende patroon

Bij een vraag zoek je éérst in een externe kennisbron de relevante stukjes, plakt die in het venster, en laat het model antwoorden mét die stukjes erbij. Letterlijk module 1 (het venster vullen) toegepast op kennis. Sterk tegen hallucinatie — je geeft de bron mee in plaats van te hopen dat het model het ware vervolg gokt. Het faalt als de retrieval het verkeerde stukje pakt (semantisch dichtbij, qua betekenis fout) of als de bron zelf niet klopt.

Voorbij RAG — de vormen van agent-geheugen

RAG is zoek-en-plak: stateless, en het kent geen veranderende feiten (verhuis je van Mumbai naar Bangalore, dan vindt het vrolijk beide). Het haalt op; het onderhoudt niet. Hieronder vier zwaardere vormen — geen ranglijst met winnaar, maar posities op het raw/derived-spectrum. Tik een vorm aan.

◀ RAW · verliesloos, inertDERIVED · compact, drift ▶
positie = hoeveel afleiding je accepteert in ruil voor compactheid

Betrouwbaarheid: oordeel vs. code

Het kernprincipe rond een probabilistisch model:

Model voor oordeel · code voor determinisme.

Gebruik het model voor classificeren, samenvatten, schrijven, betekenis uit rommelige tekst halen. Gebruik code voor rekenen, routeren, status-codes, transformaties. Elke deterministische beslissing die je door de LLM laat lopen, is een toekomstige flake — een gok waar een garantie hoort. En je kunt een probabilistisch systeem niet bewijzen, alleen meten — met evals: een vaste set testgevallen waar je de agent telkens tegenaan houdt en scoort.

Reasoning-modellen (test-time compute) passen dit principe zélf toe: ze schrijven eerst een "kladblok" vol denk-tokens vóór het antwoord — geen aparte mini-agent, hetzelfde model dat meer tokens aan denken besteedt. Door de tussenstappen in het venster te zetten, conditioneert het zijn eindantwoord op zijn eigen redenering. Op een wiskundeproef ging dat van ~12% naar ~74%. Trager en duurder — zet ze in waar het oordeel echt telt, niet voor bulk.

Module 4

Meerdere agents

Eén agent botst onvermijdelijk tegen de grenzen uit module 1 en 3: het venster loopt vol, één taak duurt lang, en een agent die zichzelf nakijkt is een slechte controleur. Meerdere lussen naast of achter elkaar lossen precies dat op — maar je koopt er coördinatie, cascade-fouten en kosten voor terug. Multi-agent is geen sprong, het is vermenigvuldiging — je erft álle eigenschappen uit module 1-3, nu keer N.

Drie echte redenen om een tweede agent toe te voegen

a · Het venster verdelen
De sterkste reden. Elke agent krijgt een schoon, gefocust venster met alleen zijn deeltaak. Je koopt context-ruimte door werk uit te besteden.
b · Parallelliteit
Onafhankelijke deeltaken tegelijk in plaats van na elkaar. Sneller in tijd, niet goedkoper in tokens — je doet evenveel werk, alleen niet in serie.
c · Specialisatie + verificatie
Een verse agent met de opdracht "weerleg dit" is betrouwbaarder dan een agent die zichzelf nakijkt — die herhaalt z'n eigen blinde vlek (module 1). Onafhankelijke sceptici, geen zelf-applaus.

De drie patronen

1 · Orchestrator / worker

┌─▸ worker A ─┐ taak ─▸ ORCH ─┼─▸ worker B ─┼─▸ ORCH voegt samen ─▸ antwoord └─▸ worker C ─┘

Pak je bij: één taak opsplitsen in deeltaken — schoon venster per stuk. Zwakte: de orchestrator is een bottleneck; al het overzicht loopt door dat ene venster.

2 · Fan-out / parallel — mét barrier

┌─▸ agent 1 ─┐ ├─▸ agent 2 ─┤ ◀ BARRIER: wacht tot ├─▸ agent 3 ─┤ ALLE agents klaar zijn └─▸ agent 4 ─┘ ─▸ één gecombineerd rapport

Pak je bij: een gezamenlijke conclusie nodig (één rapport over alle items). Nadeel: je wacht op de traagste.

3 · Pipeline — een lopende band, geen barrier

item 1 ─▸ [stage A] ─▸ [stage B] ─▸ [stage C] ─▸ klaar item 2 ──────▸ [stage A] ─▸ [stage B] ─▸ ... item 3 ───────────▸ [stage A] ─▸ ... (niemand wacht op niemand)

Pak je bij: losse, onafhankelijke items zonder gezamenlijk eindpunt — hogere doorvoer. Wel gevoeliger voor cascade-fouten: geen barrier = geen natuurlijk controlepunt tussen stages.

Welk patroon? — beslishulp

Wat is je werk?

Mixture-of-Agents vs. model-routing

Beide gebruiken meerdere modellen, maar mikken op tegengestelde doelen — ze worden vaak verward.

Model-routing

→ goedkoper
  • Stuurt elke vraag naar het goedkoopste passende model: simpel → klein model, lastig → zwaar model.
  • Kiest één model per vraag.
  • Maakt je systeem nadrukkelijk niet slimmer dan je beste model — het plafond blijft staan.

Mixture-of-Agents

→ slimmer
  • Meerdere modellen (proposers) beantwoorden dezelfde vraag; een aggregator synthetiseert tot één antwoord.
  • Gebruikt alle modellen per vraag — probeert het plafond te doorbreken.
  • Versloeg in de paper een frontier-model met ~7,5 procentpunt, óók al was elke proposer afzonderlijk zwakker. Kost latency; faalt op complexe multi-step code en lang creatief schrijven (de lasnaden worden zichtbaar).

Beide vereisen dat je model-agnostisch bouwt — je code zit niet vast aan één leverancier. Dat is geen luxe maar een hedge tegen lock-in.

Wanneer méér NIET helpt

Een extra agent is niet gratis. Default naar één agent; voeg pas een tweede toe als één van de drie redenen echt opgaat. De vier kosten: coördinatie-overhead (bij kleine taken duurder dan de taak zelf), cascade-fouten (A geeft z'n fout door aan B aan C, niemand corrigeert), emergent gedrag (agents getest in isolatie gedragen zich anders als ze interacteren), en kosten/latency (een runaway fan-out kan in minuten een groot budget opeten — een gerapporteerd incident verbrandde 1,7 miljoen tokens met nul bruikbare output). "Het kan parallel" is geen reden als de taak in serie even snel klaar is.

Voor naast het toetsenbord

Cheat sheet

Welk multi-agent-patroon?

SituatiePatroonWaarom
Eén taak in deeltakenOrchestrator / workerSchoon venster per stuk; de baas voegt samen.
Gezamenlijke conclusie nodigFan-out + barrierWacht tot alle resultaten binnen zijn vóór de samenvatting.
Losse, onafhankelijke itemsPipelineGeen barrier — hogere doorvoer, niemand wacht.
Kwaliteit boven één modelMixture-of-AgentsProposers + aggregator; accepteer de latency.
Kosten drukkenModel-routingGoedkoopste passende model per vraag.
Kleine taakEén agentCoördinatie-overhead is duurder dan de winst.

De acht vuistregels

1Een model is een functie, geen wezen — het leert niets tijdens je sessie.
2Vloeiend ≠ correct. Correct dwing je af met context, tools en verificatie.
3Wat niet in het venster staat, bestaat niet voor het model.
4Het model vraagt, de software doet.
5Een lange agent-taak loopt het venster onvermijdelijk vol — by design.
6Model voor oordeel, code voor determinisme.
7Een aparte agent verifieert beter dan een agent die zichzelf nakijkt.
8Default naar één agent; voeg er pas een toe als een echte reden opgaat.

Begrippenlijst

Token — het stukje tekst (~¾ woord) dat het model leest/genereert; de munteenheid van kosten en context.
Context window — het eindige venster met alles wat het model op enig moment "weet": instructie, gesprek, tool-resultaten.
Agent-loop — denk → handel (tool) → observeer → herhaal, tot de taak klaar is.
Harnas (harness) — de software-laag rond het kale model die er een agent van maakt: lus, tools, context-management, permissions. "Alles wat niet het model is."
Agent-instructie (system prompt) — de altijd-aan tekst die de harnas in elk venster zet: identiteit, werkwijze, regels.
Tool (function calling) — een afspraak waarmee het model een gestructureerd verzoek schrijft dat de harnas uitvoert.
Skill — een modulair, herbruikbaar pakketje instructies/procedure dat just-in-time laadt; alleen de description is altijd zichtbaar. "Skills zijn RAG voor capabiliteiten."
RAG — zoek relevante stukjes in een kennisbron en plak ze in het venster vóór het model antwoordt.
Reasoning (test-time compute) — het model schrijft eerst een kladblok (denk-tokens) vóór het antwoord; hetzelfde model, meer denk-tokens.
Mixture-of-Agents — meerdere modellen beantwoorden dezelfde vraag, een aggregator synthetiseert; kwaliteit boven één model, tegen latency.
Orchestrator/worker · fan-out · pipeline — de drie multi-agent-patronen.