Wat een AI-agent is: vijf klassieke types, twee rivaliserende definities

Het oudste voorbeeld in het vakgebied is een stofzuiger in een wereld van twee vakken, A en B, elk schoon of vies.¹ Het overleeft in elk tekstboek omdat het de kleinste wereld is waarin een agent gelijk of ongelijk kan hebben.

De percept is een paar — waar ik ben, en of het hier vies is — en de acties zijn SUCK, LEFT en RIGHT. Het hele programma is één regel.

type Percept = { dirty: boolean; where?: "A" | "B" };
type Action = "SUCK" | "LEFT" | "RIGHT";

const textbook = (p: Percept): Action =>
  p.dirty ? "SUCK" : p.where === "A" ? "RIGHT" : "LEFT";   

Draai het tegen elke startconfiguratie van de wereld met twee vakken:

A dirty, B dirty, start A    -> steps=3 clean=true
A clean, B dirty, start A    -> steps=2 clean=true
A dirty, B clean, start B    -> steps=2 clean=true

Dat is een simple reflex agent: hij handelt alleen op basis van de huidige percept, zonder herinnering aan wat eraan voorafging. Geen speelgoedcategorie — een thermostaat is er één, en een enkele call naar een taalmodel zonder gesprek eraan vast ook.

Breek hem nu zoals de werkelijkheid dat doet. Een echte stofzuigrobot heeft een vuilsensor en een bumper, geen vak met label A onder het tapijt. Haal de locatie uit de percept en verander verder niets:

const dirtOnly = (p: Percept): Action => (p.dirty ? "SUCK" : "RIGHT");

A dirty, B dirty, start A    -> steps=3   clean=true   still dirty=0
      t=0 at=A percept={dirty:true}  -> SUCK
      t=1 at=A percept={dirty:false} -> RIGHT
      t=2 at=B percept={dirty:true}  -> SUCK

A dirty, B clean, start B    -> steps=500 clean=false  still dirty=1
      t=0 at=B percept={dirty:false} -> RIGHT
      t=1 at=B percept={dirty:false} -> RIGHT
      t=2 at=B percept={dirty:false} -> RIGHT
      t=3 at=B percept={dirty:false} -> RIGHT

Hetzelfde programma, twee vakken. Vanuit één starttoestand is het in drie stappen klaar; vanuit een andere rijdt het vijfhonderd keer tegen de rechtermuur en zou het doorgaan tot de batterij leeg was. Het kan het verschil tussen de twee situaties niet waarnemen, dus het kan er niet anders in handelen. Russell en Norvig formuleren het algemene resultaat in één regel: oneindige loops zijn vaak onvermijdelijk voor simple reflex agents in gedeeltelijk observeerbare omgevingen.¹

Er is een fix die één regel kost en geen geheugen, de moeite waard om te meten voordat we naar iets slimmers grijpen.

let seed = 12345;
const rnd = () => ((seed = (seed * 1103515245 + 12345) & 0x7fffffff) / 0x7fffffff);

const coin = (p: Percept): Action => (p.dirty ? "SUCK" : rnd() < 0.5 ? "LEFT" : "RIGHT");  

Tweeduizend runs van een volledig vieze gang in drie groottes, met één seeded generator voor alles:

Randomisatie verwijdert de loop volledig. Het kost ook iets: acht kamers vragen vijftien zetten als je weet wat je doet, en deze agent haalt gemiddeld 68,7 en deed er één keer 306 over. Dat is het hele hoofdstuk in het klein. Elke capability die we toevoegen koopt correctness in een geval dat de vorige agent niet aankon, en rekent daarvoor af in een valuta die je eerst een naam moet geven.

Een agent neemt zijn omgeving waar via sensors en handelt via actuators. Het agent program is de functie van percepts naar acties — elke listing hierboven is er één. De percept sequence is alles wat tot nu toe is waargenomen, en een simple reflex agent negeert alles behalve het laatste item.

Rationaliteit is het woord dat de meeste artikelen verkeerd gebruiken, en als je het goed gebruikt wordt de rest van dit hoofdstuk bruikbaar. Een agent is op zichzelf niet rationeel of irrationeel. Russell en Norvig definiëren een rationele agent als één die, voor elke mogelijke percept sequence, de actie selecteert waarvan wordt verwacht dat die zijn performance measure maximaliseert, gegeven het bewijs uit die sequence en alle ingebouwde kennis die hij heeft.¹ De performance measure zit niet in de agent: die hoort bij de ontwerper, en rationaliteit wordt alleen relatief daaraan gedefinieerd.

De specificatie wordt traditioneel geschreven als vier dingen, PEAS: performance measure, environment, actuators, sensors.

Let op welke rij uit de toon valt. Bijna elk team dat in 2026 agents bouwt, schrijft E, A en S op — de toolschema’s, de integrations, het berichtformaat — omdat de code zonder die dingen niet draait. Bijna niemand schrijft P op. Zonder P betekent „onze agent doet het goed” niets wat iemand kan controleren, en „rationeel” kan helemaal niet op het systeem worden toegepast, alleen op een demo. Hoofdstuk 29 gaat over P in een getal veranderen, en dit is waarom het bestaat.

    ┌───────────────────────── the environment ─────────────────────────┐
    │                                                                   │
    │   ┌──────────────────────── the agent ─────────────────────┐      │
    │   │                                                        │      │
 ───┼──►│  sensors  ──►  the agent program  ──►  actuators  ─────┼──────┼──►
percept │                                                        │    action
    │   └────────────────────────────────────────────────────────┘      │
    └───────────────────────────────────────────────────────────────────┘
                                   ▲
              the performance measure lives out here, in the head of
              whoever built the thing, and the agent cannot change it

Taakomgevingen worden verder geclassificeerd langs zeven assen, waarvan er vijf hier het grootste deel van de moeilijkheid bepalen: volledig of gedeeltelijk observeerbaar, deterministisch of niet, episodisch of sequentieel, statisch of dynamisch, bekend of onbekend.¹ Een agent die met echte tools over een echt netwerk praat zit in de moeilijke hoek van alle vijf — niet-deterministisch zelfs bij temperature zero (Hoofdstuk 17), en, de onderschatte, onbekend, omdat je geen betrouwbaar model hebt van wat je eigen tools met de wereld doen. Daarom heeft de loop van Hoofdstuk 23 meer error handling nodig dan planning.

Echte vloeren zijn niet eendimensionaal, dus promoveer de wereld naar een plattegrond. Hekjes zijn muren, sterretjes zijn vuil, en de robot begint in de middelste kamer:

        col  0 1 2 3 4 5 6
      row 0  * . . # . . *
      row 1  . # . # . # .
      row 2  . # . S . # .        S = the robot starts here
      row 3  . # . # . # .
      row 4  * . . # . . *

De voor de hand liggende upgrade is geheugen. De agent houdt een kaart bij: elk vak waar hij heeft gestaan en elk vak waar de bumper afging. Zijn regel is een aangrenzend vak inlopen waar hij nog niet is geweest — rechts, dan omlaag, dan links, dan omhoog — en terugdeinzen wanneer alles om hem heen bekend is. Dit is een model-based reflex agent: hij onderhoudt interne state uit de percept history, zodat hij kan handelen op basis van wat hij op dit moment niet kan zien.

Het is een echte verbetering, en nog steeds niet genoeg:

5,000 steps allowed -> steps=5,000  distinct squares visited=13/25  still dirty=2/4

Vijfduizend zetten, de helft van de vloer nooit gezien. De kaart klopt en de regels kloppen. Wat de agent niet kan, is de kaart gebruiken om ergens naartoe te gaan: zijn regels beantwoorden alleen ooit „naar welke van mijn vier buren moet ik stappen”, dus zodra er naast hem geen onbezochte vakken meer zijn, heeft hij geen manier om de gedachte uit te drukken er is een onbezocht vak acht zetten verderop en ik zou daar graag staan. Hij weet waar hij is. Hij weet niet waar hij wil zijn.

Een goal-based agent houdt, boven op zijn model van de wereld, een beschrijving bij van de situatie die hij wil laten ontstaan, en kiest acties door reeksen ervan te doorzoeken totdat hij er één vindt die daar eindigt. Doelen veranderen actieselectie van een lookup in een search.

Het doel is „er blijft geen vies vak over”. De search is een breadth-first wandeling naar het dichtstbijzijnde vieze vak, en het pad dat die oplevert is het plan.

goal-based (fewest moves)      -> moves=27  battery=52  still dirty=0
      from 2,3 -> 4,6 via 5 moves:  2,3 2,4 3,4 4,4 4,5 4,6
      from 4,6 -> 0,6 via 4 moves:  4,6 3,6 2,6 1,6 0,6
      from 0,6 -> 4,0 via 10 moves: 0,6 0,5 0,4 1,4 2,4 2,3 2,2 3,2 4,2 4,1 4,0
      from 4,0 -> 0,0 via 4 moves:  4,0 3,0 2,0 1,0 0,0

Zevenentwintig zetten, vloer schoon. Maar kijk naar de batterijkolom en het laatste been van het plan. Kolom 0 heeft tapijt: een vak met tapijt oversteken kost zes batterijeenheden, een betegeld vak één. De agent ging via kolom 0 naar huis omdat dat vier zetten zijn in plaats van acht, en die vier tapijtzetten kostten 24 waar de omweg van acht zetten 13 had gekost.

Hij kan niet anders. Een doel is een binaire test: de vloer is schoon of niet. Elk plan dat eindigt met een schone vloer voldoet er even goed aan, dus wanneer meerdere plannen slagen heeft de agent niets om ertussen te kiezen. De ene succesvolle uitkomst boven de andere verkiezen vraagt om een getal over outcomes, en dat getal is een utility function. Een agent die die maximaliseert is een utility-based agent.

De wijziging in de code is één term binnen de search. Breadth-first search telt zetten; laat hem in plaats daarvan kosten tellen en je hebt Dijkstra’s algoritme en een andere agent:

const nd = dist.get(k)! + (byCost ? cell.cost : 1);   // <- the entire difference

goal-based    (fewest moves)   -> moves=27  battery=52  still dirty=0
utility-based (cheapest route) -> moves=31  battery=41  still dirty=0
      from 4,0 -> 0,0 via 8 moves: 4,0 4,1 4,2 3,2 2,2 1,2 0,2 0,1 0,0

Vier extra zetten, elf batterijeenheden minder: eenentwintig procent goedkoper. Zelfde doel, zelfde kaart, zelfde code op één term na. De twee agents verschillen alleen in waar ze goed in proberen te zijn, en ze nemen verschillende routes naar huis.

Dit is ook het eerste punt waarop de agent iets nodig heeft dat hij niet kan produceren. Iemand moet beslissen wat een batterijeenheid waard is ten opzichte van een zet. Utility is de performance measure geschreven in een vorm waarmee de agent kan rekenen, en het schrijven ervan is de taak van de ontwerper. Wanneer mensen zeggen dat een agent „het verkeerde optimaliseerde”, bedoelen ze bijna nooit een bug. Ze bedoelen dat deze regel slordig is geschreven.

Laat vuil nu terugkomen. Vier kamers worden opnieuw vies met vier verschillende snelheden, en de agent krijgt die nooit te horen. Hij bezoekt één kamer per tick en ziet alleen die kamer. De performance measure is room-ticks die vies worden doorgebracht over 4.000 ticks — lager is beter.

Een learning agent is, in de ontleding van het tekstboek, een van de bovenstaande plus drie onderdelen: een learning element dat de agent verandert, een critic die vertelt hoe de agent het doet ten opzichte van een vaste prestatienorm, en een problem generator die acties voorstelt die het proberen waard zijn vanwege wat ze zouden leren.¹ Drie policies in dezelfde omgeving. De eerste leert niet; de tweede en derde leren hetzelfde en gebruiken het anders.

De verborgen snelheden waren 0,35 voor de keuken, 0,05 voor de hal, 0,02 voor de werkkamer en 0,01 voor de zolder — en learner A vond ze. Hij identificeerde de keuken correct als de vieste kamer in het huis, ging daarna elke tick voor de rest van de simulatie naar de keuken terwijl de andere drie voor altijd vies bleven. Hij is vijf keer slechter dan helemaal niet leren, en hij is niet stuk.

De les is die van de sectie over utility. Learner A maximaliseerde „kans dat de kamer die ik ga bezoeken vies is”. De performance measure was „room-ticks die vies worden doorgebracht”. Verschillende getallen; het tweede is wat de critic beoordeelde, en niemand vertelde het de agent. Learner B vermenigvuldigt dezelfde geleerde snelheid met de tijd sinds het laatste bezoek — het vuil dat hij verwacht te vinden in plaats van de kans om überhaupt iets te vinden — en verslaat de patrouille waar hij mee begon.

Eén implementatiedetail bepaalde het resultaat. In de eerste versie van learner B kreeg een kamer waar in drie bezoeken geen vuil was opgedoken een snelheid van precies nul — en nul keer wat dan ook is nul, dus die werd nooit meer bezocht en de schatting kon nooit worden gecorrigeerd. De fractie smoothen, successen plus één gedeeld door pogingen plus twee, veranderde 11.895 in 1.576. „Nog niet waargenomen” en „gemeten en kwam uit op nul” zijn verschillende claims, en een systeem dat ze in hetzelfde veld opslaat neemt beslissingen die het niet ongedaan kan maken.

  1  simple reflex    percept ────────────────────────────────► rules ────► action
  2  model-based      percept ──► [state] ──────────────────► rules ────► action
  3  goal-based       percept ──► [state] ──► [goal] ──────► search ───► action
  4  utility-based    percept ──► [state] ──► [goal] ──► [U] ──► argmax ► action
  5  learning         all of the above, plus [critic] ──► changes the parts above

Elk van de vijf staat vandaag in productie onder een andere naam.

Twee rijen zijn meer dan een analogie, op een manier die geld kost.

De chat is een model-based reflex agent waarvan het model niet intern is. In het tekstboek is de state een variabele binnen het agent program. In een chat is het het transcript: het leeft aan jouw kant, wordt bij elke call volledig opnieuw meegestuurd en wordt elke keer vanaf nul opnieuw opgebouwd binnen het model. Dat is de kwadratische rekening van Hoofdstuk 16, en het is hetzelfde object dat het tekstboek tekende als een box met label „state”. Hier is het verschil, gemeten op één follow-upvraag met en zonder de twee berichten ervoor:

with the transcript      prompt=67  "The current temperature in Lisbon, Portugal is 15°C."
without the transcript   prompt=29  "Lisbon is the capital of Portugal, not a city in Portugal."

Hetzelfde model, dezelfde drie woorden user input, en de tweede is de gangrobot die tegen de muur rijdt. Er waren geen tools in die run, dus de 15 is verzonnen — maar de state is wat de follow-up überhaupt iets laat betekenen. Je bouwt die elke keer opnieuw op en betaalt er 2,3× de input tokens voor op een gesprek van twee beurten. Hoofdstuk 16 mat waar die multiplier bij beurt veertig uitkomt.

Reflexion is een learning agent die zijn input verandert in plaats van zijn programma. In de ontleding van het tekstboek past het learning element het performance element aan. Reflexion laat de weights met rust en schrijft reflectieve tekst naar een episodic buffer die de volgende poging leest.³ Het learning element is een prompt, het geheugen een databaserij, het performance element een frozen model — en het diagram is dat van het tekstboek, onveranderd.

En hier is de eerlijke grens van de mapping. De vijf types classificeren het agent program. In 2026 is dat programma doormidden gesplitst: een deel zit in jouw code, een deel zit in weights die jij niet hebt getraind. Wanneer een model uit zichzelf besluit een tool aan te roepen, zit de goal test dan in jouw programma of in het model? De taxonomie heeft geen antwoord, omdat er toen ze werd geschreven nergens anders plaats voor was — en precies die vraag is waar de twee moderne definities uit elkaar gaan.

De definities zijn discussies over gedrag, en veel makkelijker te beoordelen met een trace voor je.

De loop hieronder stuurt het gesprek naar een model; als het antwoord een tool call bevat, voert hij de tool uit, voegt het resultaat toe en stuurt het geheel opnieuw. Hij draait tegen een lokale Qwen2.5-0.5B-Instruct achter een OpenAI-vormig endpoint op deze machine — de naad uit Hoofdstuk 14, dus de loop weet niet en geeft er niet om wat er achter de poort zit.

const BASE = process.env.LLM_BASE_URL ?? "http://127.0.0.1:8799/v1";

async function loop(question: string, maxTurns = 6) {
  const messages: Msg[] = [
    { role: "system", content: SYSTEM },
    { role: "user", content: question },
  ];

  for (let turn = 1; turn <= maxTurns; turn++) {
    const reply = await call(messages, TOOLS);
    const calls = reply.choices[0].message.tool_calls ?? [];
    messages.push(reply.choices[0].message);

    if (!calls.length) return messages;                      

    for (const c of calls) {
      const out = runTool(c.function.name, JSON.parse(c.function.arguments));
      messages.push({ role: "tool", name: c.function.name, content: out });
    }
  }
  throw new Error("turn cap reached");                       
}

Twee regels dragen het hele idee, en beide zijn gemarkeerd; de rest is boekhouding. Alle drie gedragingen zijn zichtbaar in één run. Vraag je iets wat het zelf kan doen, dan antwoordt het model. Vraag je iets wat het niet kan, dan roept het aan:

=== a question the model cannot answer, one tool available
  turn 1  prompt= 187  out= 21  finish=tool_calls  CALL get_temperature({"city": "Oslo"})
          tool  get_temperature -> {"city":"Oslo","celsius":4}
  turn 2  prompt= 238  out= 12  finish=stop        TEXT "The current temperature in Oslo is 4
                                                        degrees Celsius."
  => model calls=2  prompt tokens=425  output=33  wall=6,257 ms
  => stopped by: the model produced text instead of a call

En het stopt — het derde gedrag, en het makkelijkst te missen, omdat het eruitziet alsof er niets gebeurt. De loop eindigt omdat beurt 2 terugkwam zonder tool call. Niemand besloot dat; het model deed dat, door proza uit te stoten. De termination condition van dit programma is het teken van een afwezigheid.

Nog twee runs zijn de ruimte waard. Gevraagd om twee steden te vergelijken, doet het model beide tool calls in één beurt, krijgt beide metingen terug, en heeft de vergelijking fout:

  turn 1  prompt= 188  out= 43  finish=tool_calls  CALL get_temperature({"city": "Oslo"}),
                                                        get_temperature({"city": "Lisbon"})
          tool  get_temperature -> {"city":"Oslo","celsius":4}
          tool  get_temperature -> {"city":"Lisbon","celsius":19}
  turn 2  prompt= 284  out= 13  finish=stop        TEXT "Oslo is currently warmer than Lisbon
                                                        at 4°C."

De tools werkten. De parallelle call werkte. De loop werkte. Het antwoord is onwaar, met beide juiste getallen in het transcript. Een model in een loop wikkelen laat het niet redeneren; het geeft een model dat fout zit het vermogen te handelen op basis van fout zitten — dat is Hoofdstuk 30 vooruitgeschoven, en de helft van Hoofdstuk 29.

Verwijder nu de gemarkeerde return en laat de loop in plaats daarvan tot zijn limiet draaien. Zelfde vraag, zelfde model:

  turn 1  prompt= 187  out= 21  CALL get_temperature({"city": "Oslo"})
  turn 2  prompt= 238  out= 12  TEXT "The current temperature in Oslo is 4 degrees Celsius."
  turn 3  prompt= 261  out= 30  TEXT "Could you please specify the exact location you're..."
  turn 4  prompt= 302  out= 14  TEXT "Sure! Could you tell me which city you're interested in?"
  turn 5  prompt= 327  out= 35  TEXT "I'm sorry, but I need more details to provide an..."
  turn 6  prompt= 373  out= 12  TEXT "Which city would you like to know the temperature for?"
  => model calls=6  prompt tokens=1,688  output=124  wall=25,261 ms  stopped by: turn cap

Vier keer zoveel input tokens, vier keer zoveel wall clock, en een einde waarin de agent is vergeten wat hem werd gevraagd en de gebruiker ondervraagt over een vraag die die op beurt één al had beantwoord. Het juiste antwoord stond bij beurt 2 op het scherm, en elke beurt daarna maakte het transcript slechter.

Een agent is dus geen loop. Het is een loop plus een regel om die te verlaten, en deze heeft precies één zo’n regel. Hoofdstuk 23 vindt er vijf, en laat zien wat breekt wanneer elk ontbreekt.

Beide geciteerd in plaats van geparafraseerd, omdat de parafrases de verwarring produceren.

Definitie één legt de grens bij wie de flow controleert. Anthropic’s Building effective agents benoemt de ambiguïteit en doet er uitspraak over:

„Bij Anthropic categoriseren we al deze variaties als agentic systems, maar trekken we een belangrijk architectonisch onderscheid tussen workflows en agents: workflows zijn systemen waarin LLMs en tools worden georkestreerd via vooraf gedefinieerde codepaden. Agents daarentegen zijn systemen waarin LLMs dynamisch hun eigen processen en toolgebruik aansturen, waarbij ze controle houden over hoe ze taken uitvoeren.”⁴

De test is een vraag over je source code: wie koos de volgende stap? Een switch in je programma: workflow. Het model: agent. Hetzelfde document zegt dat agents „typically just LLMs using tools based on environmental feedback in a loop” zijn — wat precies de listing hierboven is.

Definitie twee legt de grens bij onafhankelijkheid van de gebruiker. OpenAI’s A practical guide to building agents opent zijn definitiepagina zo:

„Terwijl conventionele software gebruikers helpt workflows te stroomlijnen en te automatiseren, kunnen agents dezelfde workflows namens gebruikers uitvoeren met een hoge mate van onafhankelijkheid. Agents zijn systemen die zelfstandig taken namens je volbrengen.”⁵

Twee zinnen later, op dezelfde pagina, sluit het uit:

„Applicaties die LLMs integreren maar ze niet gebruiken om workflow execution te controleren — denk aan eenvoudige chatbots, single-turn LLMs of sentiment classifiers — zijn geen agents.”⁵

Lees die citaten op volgorde. De openingszinnen trekken de lijn bij onafhankelijkheid: gaat dit ding ervandoor en maakt het de klus af zonder mij? De vierde trekt hem bij controle over execution, wat exact de lijn van Anthropic is. Verschillende tests, dezelfde pagina, en er zijn echte systemen waarover ze het oneens zijn.

Daaronder zit een botsing van vocabulaire, en die veroorzaakt discussies in echte meetings. In het eerste document is een workflow een architectuur, en het is het ding dat geen agent is. In het tweede is een workflow „een sequence of steps die moet worden uitgevoerd om het doel van de gebruiker te bereiken” — de taak zelf, waarvan elke agent er één heeft. „We hebben de workflow vervangen door een agent” is coherent onder de eerste definitie en bijna betekenisloos onder de tweede.

Drie systemen die in 2026 bestaan, onder beide definities.

Twee van de drie wisselen van kant. Dat is geen falen van een van beide documenten. Het is een waarschuwing voor een soort meeting waarin twee mensen die het volledig eens zijn over wat een systeem doet een uur besteden aan onenigheid over hoe je het moet noemen.

De definities botsen omdat elk twee onafhankelijke vragen samenperst in één woord. Haal ze uit elkaar en de onenigheid wordt een tabel, wat nuttiger is dan een oordeel.

Elke definitie betwist een andere cel, en de andere twee staan niet ter discussie. Dus wanneer het label ertoe doet — in een contract, een risk review, een postmortem — zijn de twee zinnen die het waard zijn om op te schrijven niet „is het een agent”, maar wie koos de volgende stap en wie keek mee. Beide zijn te beantwoorden door code te lezen, geen van beide heeft iemands definitie nodig, en samen dragen ze elke consequentie waarvoor het label inviel.

Niets hiervan is nieuw. Wooldridge en Jennings onderzochten de concurrerende betekenissen van „agent” in 1995;⁶ Franklin en Graesser stelden de vraag van dit hoofdstuk in 1996, verzamelden de definities die in omloop waren en ontdekten dat ze elkaar tegenspraken.⁷ Een survey uit 2023 definieert agents nog steeds vanaf de eerste principes — „artificial entities that sense their environment, make decisions, and take actions”⁸ — omdat er niets gevestigds bestond om te citeren, en CoALA beschrijft onderdelen in plaats van überhaupt een grens te trekken.⁹ Dertig jaar weigering om het eens te worden zegt dat het woord meer dan één taak uitvoert.

Nu de consequentie die vóór de filosofie arriveert: de rekening.

Elke meting hier heeft dezelfde vorm. De single call kostte 39 input tokens; dezelfde vraag met één tool kostte 420 over twee calls; de loop zonder stopregel kostte 1.688 over zes. De groei is erger dan lineair, omdat beurt n elke vorige beurt meedraagt: de prompt-kolom van die run met zes beurten leest 187, 238, 261, 302, 327, 373. Hoofdstuk 16 leidde af dat het totaal $\Theta(n^2)$ is en fit de curve op een echt gesprek. Een agent verandert elke taak in dat gesprek, of een mens het nu ooit ziet of niet.

Als die gemeten token counts naar een commercieel endpoint waren gegaan tegen de tarieven die Hoofdstuk 16 op 6 september 2026 las — $2.00 per miljoen input tokens en $12.00 per miljoen output — dan komen de vier runs zo uit:

Rij twee tegenover rij één is het getal om te onthouden. Zeven en een half keer de kosten, voor een slechter antwoord op een vraag die het model al wist. Niets was verkeerd geconfigureerd: er bestond een tool, dus het model gebruikte die — en de bevinding van Hoofdstuk 18, dat de prijs van een catalogus en niet de nauwkeurigheid ervan pijn doet, heeft hier zijn goedkoopste demonstratie met een catalogus van één.

Daarom is de nuttige helft van beide documenten de helft over dit niet bouwen. Anthropic is bot: zoek de eenvoudigst mogelijke oplossing en voeg complexiteit alleen toe wanneer dat nodig is, wat „might mean not building agentic systems at all”, omdat agentic systems „trade latency and cost for better task performance” en „for many applications, optimizing single LLM calls with retrieval and in-context examples is usually enough”.⁴ Zijn case voor een agent is smal: open problemen waarbij je het aantal stappen niet kunt voorspellen en geen pad kunt hardcoden, in een environment die je vertrouwt, waarbij je „higher costs, and the potential for compounding errors” accepteert.⁴ OpenAI’s scherm is het spiegelbeeld — complex judgement, ononderhoudbare regelsets, ongestructureerde data — en eindigt hetzelfde: „otherwise, a deterministic solution may suffice”.⁵

Dus, in de taxonomie van dit hoofdstuk: een vast aantal stappen in een vaste volgorde is een pipeline, en die een agent noemen maakt hem niet sneller. Als het aantal stappen afhangt van wat je onderweg vindt, wil je een loop — en die flexibiliteit koop je met N calls, een kwadratisch transcript en een systeem dat N keer fout kan zijn in plaats van één keer.

Je hebt nu de taxonomie, beide moderne definities, de twee assen die ze compatibel maken, en een korte loop die antwoordt, aanroept en stopt.

Die loop heeft één manier om te eindigen: het model stopt met om tools vragen. Hoofdstuk 23 breekt hem expres, zeven keer, en elke breuk voegt een stuk toe. Een onmogelijke taak, en hij eindigt nooit — een turn cap. Een nacht draaien, en de rekening komt — een budget in dollars. Een tool die faalt — een error waarop het model kan handelen. Dezelfde call twee keer — een idempotency key. Een bestand dat het niet had mogen aanraken — menselijke goedkeuring. Een restart halverwege — session persistence. Een tool die drie minuten stil is — voortgang en annulering. Wat eruit komt is een harness, het bestand waarop de rest van deze cursus draait.

Daarmee blijft de vraag over waar de betwiste diagonaal van dit hoofdstuk echt over ging. Een loop die zijn eigen volgende stap beslist moet beslissen wanneer hij stopt, en we hebben net gezien wat er gebeurt wanneer hij dat niet kan: zes beurten, vier keer de rekening, en een agent die de gebruiker ondervraagt over een vraag die hij al had beantwoord. Stoppen is niet één voorwaarde. Hoeveel zijn er, en welke gaat als eerste af?

Lilian Wengs LLM Powered Autonomous Agents (2023) is de bekendste ontleding van een language agent in planning, memory en tool use, en is de juiste volgende tekst naast de twee vendordocumenten; de drie componenten zijn Hoofdstuk 23, 24 en 18 van deze cursus, in die volgorde.

Elk getal in dit hoofdstuk is op deze machine geproduceerd en niets is geschat. De gang, de plattegrond, de vier agents die erop lopen en de drie patrol policies zijn de TypeScript hierboven, gedraaid op Node 22; de cijfers van de gerandomiseerde agent zijn gemiddelden over 2.000 seeded runs elk en de patrol figures zijn enkele seeded runs van 4.000 ticks. De model traces komen van Qwen2.5-0.5B-Instruct in float32 op CPU met greedy decoding, geserveerd over loopback door een klein lokaal Python-endpoint dat de weights laadt en de OpenAI chat-completions-vorm spreekt — opnieuw de naad, met de tensors aan de Python-kant en de loop aan de TypeScript-kant — dus de token counts zijn die van de tokenizer van dat model en de latencies die van die machine. De enige cijfers die elders vandaan komen zijn de twee prijzen in de kostentabel, de tarieven die Hoofdstuk 16 op 6 september 2026 las van OpenAI’s pricing page, hier toegepast op lokaal gemeten token counts als illustratie en niet als waargenomen factuur.