Vad en AI-agent är: fem klassiska typer, två rivaliserande definitioner

Det äldsta exemplet i fältet är en dammsugare i en värld med två rutor, A och B, där varje ruta antingen är ren eller smutsig.¹ Det lever kvar i varje lärobok eftersom det är den minsta värld där en agent kan ha rätt eller fel.

Perceptet är ett par — var jag är och om det är smutsigt här — och handlingarna är SUCK, LEFT och RIGHT. Hela programmet är en rad.

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";   

Kör det mot varje startkonfiguration i tvårutorsvärlden:

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

Det är en simple reflex agent: den agerar enbart på det aktuella perceptet, utan minne av något före det. Inte en leksakskategori — en termostat är en, och det är även ett enda call till en language model utan någon konversation kopplad.

Bryt den nu på samma sätt som verkligheten gör. En riktig dammsugarrobot har en smutssensor och en stötfångare, inte en ruta märkt A under mattan. Ta bort positionen ur perceptet och ändra inget annat:

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

Samma program, två rutor. Från ett starttillstånd blir den klar på tre steg; från ett annat kör den in i högerväggen femhundra gånger och skulle fortsätta tills batteriet dog. Den kan inte uppfatta skillnaden mellan de två situationerna, så den kan inte agera olika i dem. Russell och Norvig anger det allmänna resultatet på en rad: oändliga loopar är ofta oundvikliga för simple reflex agents i delvis observerbara miljöer.¹

Det finns en lösning som kostar en rad och inget minne, värd att mäta innan vi sträcker oss efter något smartare.

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

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

Två tusen körningar av en helt smutsig korridor i tre storlekar, med en och samma seedade generator hela vägen:

Randomisering tar bort loopen helt. Den kostar också: åtta rum kräver femton drag om du vet vad du gör, och denna agent snittar 68,7 och tog en gång 306. Det är hela kapitlet i miniatyr. Varje förmåga vi lägger till köper korrekthet i ett fall som föregående agent inte kunde hantera, och tar betalt för den i en valuta du först måste namnge.

En agent uppfattar sin miljö genom sensorer och agerar genom aktuatorer. Agent-programmet är funktionen från percept till handlingar — varje listning ovan är en sådan. Perceptsekvensen är allt som har uppfattats hittills, och en simple reflex agent ignorerar allt utom det sista objektet.

Rationalitet är ordet som de flesta artiklar får fel, och när man får det rätt blir resten av kapitlet användbart. En agent är inte rationell eller irrationell i sig. Russell och Norvig definierar en rationell agent som en som, för varje möjlig perceptsekvens, väljer den handling som förväntas maximera dess prestationsmått, givet bevisen i den sekvensen och den inbyggda kunskap den har.¹ Prestationsmåttet finns inte inuti agenten: det tillhör designern, och rationalitet definieras bara relativt till det.

Specifikationen skrivs traditionellt som fyra saker, PEAS: performance measure, environment, actuators, sensors.

Lägg märke till vilken rad som sticker ut. Nästan varje team som bygger agents 2026 skriver ner E, A och S — tool-scheman, integrationerna, meddelandeformatet — eftersom koden inte kör utan dem. Nästan ingen skriver ner P. Utan det har ”vår agent gör bra ifrån sig” ingen betydelse som någon kan kontrollera, och ”rationell” kan inte tillämpas på systemet alls, bara på en demonstration. Kapitel 29 handlar om att göra P till ett tal, och det är därför det finns.

    ┌───────────────────────── 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

Uppgiftsmiljöer klassificeras dessutom längs sju axlar, varav fem avgör det mesta av svårigheten här: helt eller delvis observerbar, deterministisk eller inte, episodisk eller sekventiell, statisk eller dynamisk, känd eller okänd.¹ En agent som pratar med riktiga tools över ett riktigt nätverk befinner sig i det svåra hörnet av alla fem — icke-deterministisk även vid temperatur noll (Kapitel 17), och, den underskattade, okänd, eftersom du inte har någon tillförlitlig modell av vad dina egna tools gör med världen. Därför behöver Kapitel 23:s loop felhantering mer än planering.

Riktiga golv är inte endimensionella, så lyft världen till en plan. Fyrkanter är väggar, asterisker är smuts, och roboten startar i mittkammaren:

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

Den uppenbara uppgraderingen är minne. Agenten håller en karta: varje ruta den har stått på och varje ruta där stötfångaren slog till. Dess regel är att gå in i en intilliggande ruta den inte har besökt — höger, sedan ner, sedan vänster, sedan upp — och backa när allt runt den är känt. Det här är en model-based reflex agent: den upprätthåller internt state från percepthistoriken, så att den kan agera utifrån det den inte kan se just nu.

Det är en verklig förbättring, och fortfarande inte tillräckligt:

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

Fem tusen drag, halva golvet aldrig sett. Kartan är korrekt och reglerna är korrekta. Det agenten inte kan göra är att använda kartan för att ta sig någonstans: dess regler svarar bara någonsin på ”vilken av mina fyra grannar ska jag kliva in i”, så när den får slut på obesökta rutor bredvid sig har den inget sätt att uttrycka tanken det finns en obesökt ruta åtta drag bort och jag skulle vilja stå på den. Den vet var den är. Den vet inte var den vill vara.

En goal-based agent håller, ovanpå sin modell av världen, en beskrivning av den situation den vill åstadkomma, och väljer handlingar genom att söka över sekvenser av dem tills den hittar en som slutar där. Mål gör handlingsval från en uppslagning till en sökning.

Målet är ”ingen smutsig ruta återstår”. Sökningen är en bredden-först-vandring till närmaste smutsiga ruta, och vägen den returnerar är planen.

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

Tjugosju drag, rent golv. Men titta på batterikolumnen och planens sista etapp. Kolumn 0 är mattbelagd: att korsa en mattbelagd ruta kostar sex batterienheter, en kaklad ruta en. Agenten gick hem uppför kolumn 0 eftersom det är fyra drag i stället för åtta, och de fyra mattbelagda dragen kostade 24 där omvägen på åtta drag skulle ha kostat 13.

Den kan inte göra annorlunda. Ett mål är ett binärt test: golvet är rent eller inte. Varje plan som slutar med ett rent golv uppfyller det lika mycket, så när flera lyckas har agenten inget att välja mellan. Att föredra en framgång framför en annan kräver ett tal över utfall, och det talet är en nyttofunktion. En agent som maximerar den är en utility-based agent.

Ändringen i koden är en term inne i sökningen. Bredden-först-sökning räknar drag; låt den räkna kostnad i stället och du har Dijkstras algoritm och en annan 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

Fyra extra drag, elva färre batterienheter: tjugoen procent billigare. Samma mål, samma karta, samma kod utom en term. De två agents skiljer sig bara i vad de försöker vara bra på, och de tar olika vägar hem.

Det här är också första punkten där agenten behöver något den inte kan producera. Någon måste bestämma vad en batterienhet är värd relativt ett drag. Nytta är prestationsmåttet skrivet i en form som agenten kan räkna med, och att skriva det är designerns jobb. När folk säger att en agent ”optimerade fel sak” menar de nästan aldrig en bugg. De menar att den här raden skrevs slarvigt.

Låt nu smutsen komma tillbaka. Fyra rum blir smutsiga igen i fyra olika takter, och agenten får aldrig veta dem. Den besöker ett rum per tick och ser bara det rummet. Prestationsmåttet är rums-ticks som spenderats smutsiga över 4 000 ticks — lägre är bättre.

En learning agent, i lärobokens uppdelning, är någon av ovanstående plus tre delar: ett learning element som ändrar agenten, en critic som talar om hur agenten presterar mot en fast prestationsstandard, och en problem generator som föreslår handlingar värda att pröva för vad de skulle lära ut.¹ Tre policys i samma miljö. Den första lär sig inte; den andra och tredje lär sig samma sak och använder det olika.

De dolda takterna var 0,35 för köket, 0,05 för hallen, 0,02 för arbetsrummet och 0,01 för vinden — och learner A hittade dem. Den identifierade korrekt köket som husets smutsigaste rum och gick sedan till köket varje tick resten av simuleringen medan de andra tre stod smutsiga för alltid. Den är fem gånger sämre än att inte lära alls, och den är inte trasig.

Lärdomen är densamma som i nyttoavsnittet. Learner A maximerade ”sannolikheten att rummet jag är på väg att besöka är smutsigt”. Prestationsmåttet var ”rums-ticks spenderade smutsiga”. Olika tal; det andra är vad critic poängsatte, och ingen berättade det för agenten. Learner B multiplicerar samma inlärda takt med tiden sedan senaste besöket — smutsen den förväntar sig att hitta snarare än chansen att hitta någon — och slår patrullen den startade från.

En implementeringsdetalj avgjorde resultatet. I den första versionen av learner B fick ett rum där ingen smuts hade dykt upp på tre besök en takt på exakt noll — och noll gånger vad som helst är noll, så det besöktes aldrig igen och uppskattningen kunde aldrig korrigeras. Att släta ut bråket, lyckade utfall plus ett över försök plus två, gjorde 11 895 till 1 576. ”Inte observerat än” och ”uppmätt och blev noll” är olika påståenden, och ett system som lagrar dem i samma fält fattar beslut det inte kan ångra.

  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

Var och en av de fem finns i produktion i dag under ett annat namn.

Två rader är närmare än en analogi, på ett sätt som kostar pengar.

Chatten är en model-based reflex agent vars modell inte är intern. I läroboken är state en variabel inne i agent-programmet. I en chatt är det transkriptet: det lever på din sida, skickas om i sin helhet vid varje call och byggs om från noll inuti modellen varje gång. Det är Kapitel 16:s kvadratiska räkning, och det är samma objekt som läroboken ritade som en låda märkt ”state”. Här är skillnaden, mätt på en uppföljningsfråga med och utan de två meddelandena före den:

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."

Samma model, samma tre ord av användarinput, och den andra är korridorroboten som kör in i väggen. Det fanns inga tools i den körningen, så 15 är påhittat — men state är det som gör att uppföljningen betyder något alls. Du bygger om det varje gång och betalar 2,3× input token för det på en två-turn-konversation. Kapitel 16 mätte vad den multiplikatorn når vid turn fyrtio.

Reflexion är en learning agent som ändrar sin input snarare än sitt program. I lärobokens uppdelning modifierar learning element performance element. Reflexion lämnar vikterna ifred och skriver reflekterande text till en episodisk buffer som nästa försök läser.³ Learning element är en prompt, minnet en databasrad, performance element en frusen model — och diagrammet är lärobokens, oförändrat.

Och här är den ärliga gränsen för mappningen. De fem typerna klassificerar agent-programmet. År 2026 är det programmet delat på mitten: en del av det är din kod, en del av det finns i vikter du inte tränade. När en model på egen hand bestämmer sig för att anropa ett tool, ligger måltestet i ditt program eller i modellen? Taxonomin har inget svar, för när den skrevs fanns det ingen annanstans för det att vara — och just den frågan är exakt där de två moderna definitionerna går skilda vägar.

Definitionerna är argument om beteende, och mycket lättare att bedöma med en trace framför sig.

Loopen nedan skickar konversationen till en model; om svaret innehåller ett tool call kör den tool, lägger till resultatet och skickar hela saken igen. Den kör mot en lokal Qwen2.5-0.5B-Instruct bakom en OpenAI-formad endpoint på den här maskinen — sömmen från Kapitel 14, så loopen varken vet eller bryr sig om vad som finns bakom porten.

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");                       
}

Två rader bär hela idén, och båda är markerade; resten är bokföring. Alla tre beteenden syns i en körning. Fråga om något den kan göra själv, och modellen svarar. Fråga om något den inte kan, och den anropar:

=== 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

Och den stannar — det tredje beteendet, och det lättaste att missa, eftersom det ser ut som att ingenting händer. Loopen slutar eftersom turn 2 kom tillbaka utan ett tool call. Ingen bestämde det; modellen gjorde det, genom att avge prosa. Termineringsvillkoret för detta program är tecknet på en frånvaro.

Två körningar till är värda utrymmet. När modellen ombeds jämföra två städer utfärdar den båda tool calls i en turn, får tillbaka båda mätningarna och får jämförelsen fel:

  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."

Tools fungerade. Det parallella call fungerade. Loopen fungerade. Svaret är falskt, med båda korrekta siffrorna sittande i transkriptet. Att slå in en model i en loop får den inte att resonera; det ger en model som har fel förmågan att agera på att den har fel — vilket är Kapitel 30 i förväg, och halva Kapitel 29.

Radera nu det markerade return och låt loopen köra till sitt tak i stället. Samma fråga, samma 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

Fyra gånger input token, fyra gånger väggklockan, och ett slut där agenten har glömt vad den blev frågad och förhör användaren om en fråga de svarade på i turn ett. Det korrekta svaret stod på skärmen vid turn 2, och varje turn efter det gjorde transkriptet sämre.

Så en agent är inte en loop. Den är en loop plus en regel för att lämna den, och den här har exakt en sådan regel. Kapitel 23 hittar fem, och visar vad som går sönder när var och en saknas.

Båda citerade snarare än parafraserade, eftersom parafraserna är där förvirringen tillverkas.

Definition ett lägger gränsen vid vem som styr flödet. Anthropics Building effective agents namnger tvetydigheten och avgör den:

”At Anthropic, we categorize all these variations as agentic systems, but draw an important architectural distinction between workflows and agents: Workflows are systems where LLMs and tools are orchestrated through predefined code paths. Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks.”⁴

Testet är en fråga om din källkod: vem valde nästa steg? En switch i ditt program: workflow. Modellen: agent. Samma dokument säger att agents ”are typically just LLMs using tools based on environmental feedback in a loop” — vilket är exakt listningen ovan.

Definition två lägger gränsen vid oberoende från användaren. OpenAI:s A practical guide to building agents öppnar sin definitionssida så här:

”While conventional software enables users to streamline and automate workflows, agents are able to perform the same workflows on the users' behalf with a high degree of independence. Agents are systems that independently accomplish tasks on your behalf.”⁵

Två meningar senare, på samma sida, utesluter den:

”Applications that integrate LLMs but don't use them to control workflow execution—think simple chatbots, single-turn LLMs, or sentiment classifiers—are not agents.”⁵

Läs de citaten i ordning. De inledande meningarna drar linjen vid oberoende: går den här saken iväg och slutför jobbet utan mig? Den fjärde drar den vid kontroll över exekveringen, vilket är exakt Anthropics linje. Olika tester, samma sida, och det finns verkliga system där de säger emot varandra.

Under detta finns en vokabulärkrock, och den orsakar gräl i riktiga möten. I det första dokumentet är ett workflow en arkitektur, och det är det som inte är en agent. I det andra är ett workflow ”a sequence of steps that must be executed to meet the user's goal” — själva jobbet, som varje agent har ett av. ”Vi ersatte workflow med en agent” är sammanhängande enligt den första definitionen och nära meningslöst enligt den andra.

Tre system som finns 2026, under båda definitionerna.

Två av de tre byter sida. Det är inte ett misslyckande för något av dokumenten. Det är en varning om en sorts möte där två personer som är helt överens om vad ett system gör ägnar en timme åt att vara oense om vad det ska kallas.

Definitionerna kolliderar eftersom var och en pressar ihop två oberoende frågor till ett ord. Separera dem och oenigheten blir en tabell, vilket är mer användbart än en dom.

Varje definition ifrågasätter en annan cell, och de andra två är inte omstridda alls. Så när etiketten spelar roll — i ett kontrakt, en riskgranskning, en postmortem — är de två meningarna värda att skriva inte ”är det en agent” utan vem valde nästa steg och vem tittade på. Båda går att besvara genom att läsa kod, ingen kräver någons definition, och tillsammans bär de varje konsekvens som etiketten stod för.

Inget av detta är nytt. Wooldridge och Jennings kartlade de konkurrerande betydelserna av ”agent” 1995;⁶ Franklin och Graesser ställde detta kapitels fråga 1996, samlade de definitioner som cirkulerade och fann att de var oense.⁷ En survey från 2023 definierar fortfarande agents från första principer — ”artificial entities that sense their environment, make decisions, and take actions”⁸ — eftersom det inte fanns någon fastslagen modern definition att citera, och CoALA beskriver delar snarare än att dra en gräns alls.⁹ Trettio år av att avstå från att enas säger att ordet gör mer än ett jobb.

Nu konsekvensen som kommer före filosofin, nämligen räkningen.

Varje mätning här har samma form. Det enskilda call kostade 39 input token; samma fråga med ett tool kostade 420 över två calls; loopen utan sin stoppregel kostade 1 688 över sex. Tillväxten är värre än linjär, eftersom turn n bär med sig varje tidigare turn: prompt-kolumnen i den sex-turn-körningen lyder 187, 238, 261, 302, 327, 373. Kapitel 16 härledde att totalen är $\Theta(n^2)$ och anpassade kurvan på en riktig konversation. En agent gör varje uppgift till den konversationen, oavsett om en människa någonsin ser den.

Om de uppmätta token-antalet hade gått till en kommersiell endpoint till de priser Kapitel 16 läste den 6 september 2026 — $2.00 per miljon input token och $12.00 per miljon output — skulle de fyra körningarna prissättas så här:

Rad två jämfört med rad ett är talet att behålla. Sju och en halv gånger kostnaden, för ett sämre svar på en fråga som modellen redan kunde. Ingenting var felkonfigurerat: ett tool fanns, så modellen använde det — och Kapitel 18:s fynd, att det är priset på en katalog och inte dess träffsäkerhet som gör ont, får sin billigaste demonstration här med en katalog på ett.

Det är därför den användbara halvan av båda dokumenten är halvan om att inte bygga detta. Anthropics är rak: hitta den enklaste möjliga lösningen och lägg bara till komplexitet när det behövs, vilket ”might mean not building agentic systems at all”, eftersom agentic systems ”trade latency and cost for better task performance” och ”for many applications, optimizing single LLM calls with retrieval and in-context examples is usually enough”.⁴ Dess argument för en agent är smalt: öppna problem där du inte kan förutse antalet steg och inte kan hårdkoda en väg, i en miljö du litar på, med acceptans för ”higher costs, and the potential for compounding errors”.⁴ OpenAI:s skärm är spegelbilden — komplex bedömning, regeluppsättningar som inte går att underhålla, ostrukturerad data — och slutar på samma sätt: ”otherwise, a deterministic solution may suffice”.⁵

Så, i detta kapitels taxonomi: ett fast antal steg i en fast ordning är en pipeline, och att kalla den en agent gör den inte snabbare. Om antalet steg beror på vad du hittar på vägen vill du ha en loop — och du köper den flexibiliteten med N calls, ett kvadratiskt transkript och ett system som kan ha fel N gånger i stället för en.

Du har nu taxonomin, båda moderna definitionerna, de två axlarna som gör dem kompatibla, och en kort loop som svarar, anropar och stannar.

Den loopen har ett sätt att sluta: modellen slutar be om tools. Kapitel 23 bryter den med flit, sju gånger, och varje brott lägger till en bit. En omöjlig uppgift, och den tar aldrig slut — ett turn cap. En natts körning, och räkningen kommer — en budget i dollar. Ett tool som misslyckas — ett fel som modellen kan agera på. Samma call två gånger — en idempotency key. En fil den inte borde ha rört — ett human approval. En omstart halvvägs — session persistence. Ett tool som tar tre minuter i tystnad — progress och cancellation. Det som kommer ut är en harness, filen som resten av den här kursen kör på.

Kvar är frågan som detta kapitels omstridda diagonal egentligen handlade om. En loop som bestämmer sitt eget nästa steg måste bestämma när den ska stanna, och vi har just sett vad som händer när den inte kan: sex turns, fyra gånger räkningen, och en agent som förhör användaren om en fråga den redan hade besvarat. Att stanna är inte ett villkor. Hur många finns det, och vilket utlöses först?

Lilian Wengs LLM Powered Autonomous Agents (2023) är den mest kända uppdelningen av en language agent i planning, memory och tool use, och är rätt nästa läsning bredvid de två leverantörsdokumenten; dess tre komponenter är Kapitel 23, 24 och 18 i denna kurs, i den ordningen.

Varje tal i detta kapitel producerades på den här maskinen och inget uppskattades. Korridoren, planlösningen, de fyra agents som går den och de tre patrullpolicys är TypeScript-koden ovan, körd på Node 22; den randomiserade agentens siffror är medelvärden över 2 000 seedade körningar vardera och patrullsiffrorna är enskilda seedade körningar på 4 000 ticks. Modellspåren kommer från Qwen2.5-0.5B-Instruct i float32 på CPU med greedy decoding, serverad över loopback av en liten lokal Python-endpoint som laddar vikterna och talar OpenAI chat-completions-formen — sömmen igen, med tensors på Python-sidan och loopen på TypeScript-sidan — så token-antalet är den modellens tokenizer och latenserna är den maskinens. De enda siffrorna hämtade någon annanstans ifrån är de två priserna i kostnadstabellen, vilka är de priser Kapitel 16 läste från OpenAI:s prissida den 6 september 2026, tillämpade här på lokalt uppmätta token-antal som illustration och inte som en observerad faktura.