Hvad en AI-agent er: fem klassiske typer, to rivaliserende definitioner

Det ældste eksempel på området er en støvsuger i en verden med to felter, A og B, som hver især enten er rene eller beskidte.¹ Det overlever i alle lærebøger, fordi det er den mindste verden, hvor en agent kan have ret eller tage fejl.

Perceptet er et par — hvor jeg er, og om der er beskidt her — og handlingerne er SUCK, LEFT og RIGHT. Hele programmet er én linje.

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 mod alle startkonfigurationer i verdenen med to felter:

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 er en simple reflex agent: den handler kun ud fra det aktuelle percept, uden memory om noget før det. Ikke en legetøjskategori — en termostat er én, og det samme er et enkelt call til en sprogmodel uden tilknyttet samtale.

Knæk den nu på den måde, virkeligheden gør. En rigtig støvsugerrobot har en snavssensor og en kofanger, ikke et felt mærket A under gulvtæppet. Fjern placeringen fra perceptet, og lad alt andet være uændret:

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

Samme program, to felter. Fra én starttilstand bliver den færdig på tre trin; fra en anden kører den ind i højre væg fem hundrede gange og ville blive ved, indtil batteriet døde. Den kan ikke sanse forskellen på de to situationer, så den kan ikke handle forskelligt i dem. Russell og Norvig formulerer det generelle resultat på én linje: uendelige loops er ofte uundgåelige for simple reflex agents i delvist observerbare environments.¹

Der findes en løsning, der koster én linje og ingen memory, og som er værd at måle, før vi griber efter noget smartere.

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

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

To tusind kørsler af en helt beskidt korridor i tre størrelser, med én seeded generator hele vejen igennem:

Randomisering fjerner loopet helt. Det koster også: otte rum kræver femten træk, hvis du ved, hvad du laver, og denne agent ligger i gennemsnit på 68,7 og brugte en enkelt gang 306. Det er hele kapitlet i miniature. Hver capability, vi tilføjer, køber korrekthed i en case, den forrige agent ikke kunne håndtere, og opkræver betaling for det i en valuta, du først er nødt til at navngive.

En agent sanser sit environment gennem sensorer og handler gennem aktuatorer. agent-programmet er funktionen fra percepts til handlinger — hver listing ovenfor er ét. percept-sekvensen er alt, der er sanset indtil nu, og en simple reflex agent ignorerer det hele bortset fra det sidste element.

Rationalitet er det ord, de fleste artikler får galt fat i, og når man får det rigtigt, bliver resten af kapitlet brugbart. En agent er ikke rationel eller irrationel i sig selv. Russell og Norvig definerer en rationel agent som en, der for hver mulig percept-sekvens vælger den handling, der forventes at maksimere dens performance measure, givet evidensen i sekvensen og den indbyggede viden, den måtte have.¹ Performance measure ligger ikke inde i agenten: den tilhører designeren, og rationalitet er kun defineret relativt til den.

Specifikationen skrives traditionelt som fire ting, PEAS: performance measure, environment, actuators, sensors.

Læg mærke til, hvilken række der skiller sig ud. Næsten alle teams, der bygger agents i 2026, skriver E, A og S ned — tool-schemas, integrationerne, beskedformatet — fordi koden ikke kører uden dem. Næsten ingen skriver P ned. Uden den har „vores agent klarer sig godt” ingen betydning, nogen kan tjekke, og „rationel” kan slet ikke anvendes på systemet, kun på en demonstration. Kapitel 29 handler om at gøre P til et tal, og det er derfor, det findes.

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

Task environments klassificeres yderligere langs syv akser, hvoraf fem afgør det meste af sværhedsgraden her: fuldt eller delvist observerbare, deterministiske eller ej, episodiske eller sekventielle, statiske eller dynamiske, kendte eller ukendte.¹ En agent, der taler med rigtige tools over et rigtigt netværk, befinder sig i det svære hjørne af alle fem — ikke-deterministisk selv ved temperature zero (Kapitel 17), og den undervurderede: ukendt, fordi du ikke har en pålidelig model af, hvad dine egne tools gør ved verden. Derfor har Kapitel 23’s loop mere brug for fejlhåndtering end planlægning.

Rigtige gulve er ikke endimensionelle, så løft verden til en plan. Hash-tegn er vægge, stjerner er snavs, og robotten starter i kammeret i midten:

        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 oplagte opgradering er memory. Agenten holder et kort: hvert felt, den har stået på, og hvert felt, hvor kofangeren blev udløst. Dens regel er at gå ind i et nabofelt, den ikke har besøgt — højre, så ned, så venstre, så op — og bakke ud, når alt omkring den er kendt. Det er en model-based reflex agent: den opretholder intern tilstand fra percept history, så den kan handle på det, den ikke aktuelt kan se.

Det er en reel forbedring, og stadig ikke nok:

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

Fem tusind træk, halvdelen af gulvet aldrig set. Kortet er korrekt, og reglerne er korrekte. Det agenten ikke kan, er at bruge kortet til at komme et sted hen: dens regler svarer kun nogensinde på „hvilken af mine fire naboer skal jeg træde ind i”, så når den løber tør for ubesøgte felter ved siden af sig, har den ingen måde at udtrykke tanken der er et ubesøgt felt otte træk væk, og jeg vil gerne stå på det. Den ved, hvor den er. Den ved ikke, hvor den vil hen.

En goal-based agent har, oven på sin model af verden, en beskrivelse af den situation, den vil frembringe, og vælger handlinger ved at søge gennem sekvenser af dem, indtil den finder en, der ender der. Goals gør handlingsvalg fra et opslag til en søgning.

Goalet er „intet beskidt felt er tilbage”. Søgningen er en bredde-først-gang til det nærmeste beskidte felt, og den sti, den returnerer, er 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

Syvogtyve træk, gulvet rent. Men se på batterikolonnen og planens sidste etape. Kolonne 0 er tæppebelagt: at krydse et tæppebelagt felt koster seks batterienheder, et flisefelt én. Agenten gik hjem op gennem kolonne 0, fordi det er fire træk i stedet for otte, og de fire tæppetræk kostede 24, hvor omvejen på otte træk ville have kostet 13.

Den kan ikke gøre andet. Et goal er en binær test: gulvet er rent, eller også er det ikke. Hver plan, der ender med et rent gulv, opfylder det lige godt, så når flere lykkes, har agenten intet at vælge mellem. At foretrække én succes frem for en anden kræver et tal over udfald, og det tal er en utility function. En agent, der maksimerer den, er en utility-based agent.

Ændringen i koden er ét led inde i søgningen. Breadth-first search tæller træk; få den til at tælle omkostning i stedet, og du har Dijkstras algoritme og en anden 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

Fire ekstra træk, elleve færre batterienheder: enogtyve procent billigere. Samme goal, samme kort, samme kode bortset fra ét led. De to agents adskiller sig kun i, hvad de prøver at være gode til, og de tager forskellige ruter hjem.

Det er også første punkt, hvor agenten har brug for noget, den ikke selv kan producere. Nogen skal beslutte, hvad en batterienhed er værd i forhold til et træk. Utility er performance measure skrevet i en form, agenten kan regne med, og at skrive den er designerens arbejde. Når folk siger, at en agent „optimerede den forkerte ting”, mener de næsten aldrig en bug. De mener, at denne linje blev skrevet sjusket.

Lad nu snavset komme tilbage. Fire rum bliver beskidte igen med fire forskellige hastigheder, og agenten får dem aldrig at vide. Den besøger ét rum pr. tick og ser kun det rum. Performance measure er room-ticks brugt beskidte over 4.000 ticks — lavere er bedre.

En learning agent er i lærebogens opdeling enhver af de ovenstående plus tre dele: et learning element, der ændrer agenten, en critic, der fortæller den, hvordan agenten klarer sig mod en fast performance standard, og en problem generator, der foreslår handlinger, som er værd at prøve på grund af det, de ville lære den.¹ Tre policies i det samme environment. Den første lærer ikke; den anden og tredje lærer det samme og bruger det forskelligt.

De skjulte rater var 0,35 for køkkenet, 0,05 for gangen, 0,02 for arbejdsværelset og 0,01 for loftet — og learner A fandt dem. Den identificerede korrekt køkkenet som husets mest beskidte rum og gik derefter til køkkenet ved hvert tick resten af simuleringen, mens de tre andre stod beskidte for evigt. Den er fem gange værre end slet ikke at lære, og den er ikke i stykker.

Læren er den samme som i utility-afsnittet. Learner A maksimerede „sandsynligheden for, at det rum, jeg er ved at besøge, er beskidt”. Performance measure var „room-ticks brugt beskidte”. Forskellige tal; det andet var det, critic’en scorede, og ingen fortalte agenten det. Learner B ganger den samme lærte rate med tiden siden sidste besøg — det snavs, den forventer at finde, snarere end chancen for at finde noget — og slår den patrulje, den startede fra.

Én implementeringsdetalje afgjorde resultatet. I den første version af learner B fik et rum, hvor der ikke var dukket snavs op i tre besøg, en rate på præcis nul — og nul gange hvad som helst er nul, så det blev aldrig besøgt igen, og estimatet kunne aldrig korrigeres. Smoothing af brøken, succeser plus én over forsøg plus to, gjorde 11.895 til 1.576. „Ikke observeret endnu” og „målt og endte på nul” er forskellige påstande, og et system, der gemmer dem i samme felt, træffer beslutninger, det ikke kan fortryde.

  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

Hver eneste af de fem er i produktion i dag under et andet navn.

To rækker er tættere end en analogi, på en måde der koster penge.

Chatten er en model-based reflex agent, hvis model ikke er intern. I lærebogen er tilstanden en variabel inde i agent-programmet. I en chat er den transcriptet: den bor på din side, sendes igen i fuld længde ved hvert call og genopbygges fra bunden inde i modellen hver gang. Det er Kapitel 16’s kvadratiske regning, og det er det samme objekt, lærebogen tegnede som en kasse mærket „state”. Her er forskellen, målt på ét opfølgende spørgsmål med og uden de to beskeder før det:

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

Samme model, de samme tre ord brugerinput, og den anden er korridorrobotten, der kører ind i væggen. Der var ingen tools i den kørsel, så de 15 er opfundet — men tilstanden er det, der får opfølgningen til overhovedet at betyde noget. Du genopbygger den hver gang og betaler 2,3× input tokens for den i en samtale med to turns. Kapitel 16 målte, hvad den multiplikator når ved turn fyrre.

Reflexion er en learning agent, der ændrer sit input i stedet for sit program. I lærebogens opdeling ændrer learning element performance element. Reflexion lader weights være og skriver reflekterende tekst ind i en episodisk buffer, som næste forsøg læser.³ Learning element er en prompt, memory er en databaserække, performance element er en frossen model — og diagrammet er lærebogens, uændret.

Og her er den ærlige grænse for mappingen. De fem typer klassificerer agent-programmet. I 2026 er det program delt lige over: noget af det er din kode, noget af det er inde i weights, du ikke har trænet. Når en model på egen hånd beslutter at kalde en tool, ligger goal-testen så i dit program eller i modellen? Taksonomien har intet svar, for da den blev skrevet, var der intet andet sted, den kunne være — og præcis det spørgsmål er stedet, hvor de to moderne definitioner går hver sin vej.

Definitionerne er argumenter om adfærd og meget lettere at bedømme med et trace foran sig.

Loopet nedenfor sender samtalen til en model; hvis svaret indeholder et tool call, udfører det tool’en, tilføjer resultatet og sender det hele igen. Det kører mod en lokal Qwen2.5-0.5B-Instruct bag et OpenAI-formet endpoint på denne maskine — sømmen fra Kapitel 14, så loopet hverken ved eller bekymrer sig om, hvad der er bag 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");                       
}

To linjer bærer hele idéen, og begge er markeret; resten er bookkeeping. Alle tre adfærdstyper er synlige i én kørsel. Spørg om noget, modellen selv kan klare, og den svarer. Spørg om noget, den ikke kan, og den kalder:

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

Og den stopper — den tredje adfærd, og den letteste at overse, fordi den ligner, at der ikke sker noget. Loopet slutter, fordi turn 2 kom tilbage uden et tool call. Ingen besluttede det; modellen gjorde, ved at udsende prosa. Termineringstilstanden for dette program er tegnet på et fravær.

To kørsler mere er pladsen værd. Bedt om at sammenligne to byer udsteder modellen begge tool calls i én turn, får begge målinger tilbage og får sammenligningen forkert:

  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 fungerede. Det parallelle call fungerede. Loopet fungerede. Svaret er falsk, med begge korrekte tal liggende i transcriptet. At pakke en model ind i et loop får den ikke til at reason; det giver en model, der tager fejl, evnen til at handle på at tage fejl — hvilket er Kapitel 30 på forhånd og halvdelen af Kapitel 29.

Slet nu det markerede return, og lad loopet køre til sin cap i stedet. Samme spørgsmål, samme 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

Fire gange så mange input tokens, fire gange vægurtiden og en slutning, hvor agenten har glemt, hvad den blev spurgt om, og forhører brugeren om et spørgsmål, de besvarede på turn ét. Det korrekte svar stod på skærmen ved turn 2, og hvert turn efter det gjorde transcriptet værre.

Så en agent er ikke et loop. Det er et loop plus en regel for at forlade det, og denne har præcis én sådan regel. Kapitel 23 finder fem og viser, hvad der går i stykker, når hver af dem mangler.

Begge citeret frem for parafraseret, fordi det er parafraserne, der producerer forvirringen.

Definition ét lægger grænsen ved, hvem der kontrollerer flowet. Anthropics Building effective agents navngiver tvetydigheden og afgør den:

„Hos Anthropic kategoriserer vi alle disse variationer som agentic systems, men trækker en vigtig arkitektonisk skelnen mellem workflows og agents: Workflows er systemer, hvor LLMs og tools orkestreres gennem foruddefinerede kodeveje. Agents er derimod systemer, hvor LLMs dynamisk styrer deres egne processer og tool-brug og bevarer kontrollen over, hvordan de løser opgaver.”⁴

Testen er et spørgsmål om din kildekode: hvem valgte næste trin? En switch i dit program: workflow. Modellen: agent. Det samme dokument siger, at agents „typisk bare er LLMs, der bruger tools baseret på environmental feedback i et loop” — hvilket er præcis listingen ovenfor.

Definition to lægger grænsen ved uafhængighed fra brugeren. OpenAIs A practical guide to building agents åbner sin definitionsside sådan:

„Mens konventionel software gør det muligt for brugere at strømline og automatisere workflows, kan agents udføre de samme workflows på brugernes vegne med en høj grad af uafhængighed. Agents er systemer, der selvstændigt udfører opgaver på dine vegne.”⁵

To sætninger senere, på samme side, udelukker den:

„Applikationer, der integrerer LLMs, men ikke bruger dem til at kontrollere workflow-udførelse — tænk simple chatbots, single-turn LLMs eller sentiment classifiers — er ikke agents.”⁵

Læs citaterne i rækkefølge. Åbningssætningerne trækker linjen ved uafhængighed: går denne ting væk og gør jobbet færdigt uden mig? Den fjerde trækker den ved kontrol over udførelse, hvilket er præcis Anthropics linje. Forskellige tests, samme side, og der findes virkelige systemer, hvor de er uenige.

Der ligger et ordsammenstød under det, og det skaber diskussioner i rigtige møder. I det første dokument er et workflow en arkitektur, og det er det, der ikke er en agent. I det andet er et workflow „en sekvens af trin, der skal udføres for at opfylde brugerens goal” — selve jobbet, som hver agent har et af. „Vi erstattede workflowet med en agent” er sammenhængende under den første definition og tæt på meningsløst under den anden.

Tre systemer, der findes i 2026, under begge definitioner.

To af de tre skifter side. Det er ikke en fejl ved nogen af dokumenterne. Det er en advarsel om en type møde, hvor to mennesker, der er helt enige om, hvad et system gør, bruger en time på at være uenige om, hvad man skal kalde det.

Definitionerne kolliderer, fordi hver af dem presser to uafhængige spørgsmål sammen i ét ord. Adskil dem, og uenigheden bliver til en tabel, som er mere nyttig end en dom.

Hver definition bestrider en anden celle, og de to andre er slet ikke til diskussion. Så når labelen betyder noget — i en kontrakt, en risikovurdering, en postmortem — er de to sætninger, der er værd at skrive, ikke „er det en agent”, men hvem valgte næste trin og hvem så med. Begge kan besvares ved at læse kode, ingen af dem kræver nogens definition, og tilsammen bærer de alle de konsekvenser, labelen stod i stedet for.

Intet af dette er nyt. Wooldridge og Jennings kortlagde de konkurrerende betydninger af „agent” i 1995;⁶ Franklin og Graesser stillede dette kapitels spørgsmål i 1996, samlede de definitioner, der var i omløb, og fandt, at de var uenige.⁷ En survey fra 2023 definerer stadig agents fra første principper — „kunstige entiteter, der sanser deres environment, træffer beslutninger og handler”⁸ — fordi der ikke fandtes noget afklaret at citere, og CoALA beskriver dele i stedet for overhovedet at trække en grænse.⁹ Tredive års afvisning af at blive enige siger, at ordet udfører mere end ét job.

Nu konsekvensen, der ankommer før filosofien: regningen.

Hver måling her har samme form. Det enkelte call kostede 39 input tokens; det samme spørgsmål med én tool kostede 420 på tværs af to calls; loopet uden sin stopping rule kostede 1.688 på tværs af seks. Væksten er værre end lineær, fordi turn n bærer hvert tidligere turn med sig: prompt-kolonnen i den seks-turn-kørsel lyder 187, 238, 261, 302, 327, 373. Kapitel 16 udledte, at totalen er $\Theta(n^2)$ og fit’ede kurven på en rigtig samtale. En agent gør hver opgave til den samtale, uanset om et menneske nogensinde ser den.

Hvis de målte token-tal var sendt til et kommercielt endpoint til de priser, Kapitel 16 aflæste 6. september 2026 — $2.00 pr. million input tokens og $12.00 pr. million output — ville de fire kørsler koste sådan:

Række to mod række ét er tallet, du skal beholde. Syv en halv gange omkostningen, for et dårligere svar på et spørgsmål, modellen allerede kendte svaret på. Intet var miskonfigureret: en tool fandtes, så modellen brugte den — og Kapitel 18’s fund, at det er prisen på et katalog og ikke dets accuracy, der gør ondt, får sin billigste demonstration her med et katalog på én.

Derfor er den nyttige halvdel af begge dokumenter halvparten om ikke at bygge dette. Anthropics er direkte: find den simpleste mulige løsning, og tilføj kun kompleksitet, når det er nødvendigt, hvilket „kan betyde slet ikke at bygge agentic systems”, eftersom agentic systems „bytter latency og cost for bedre task performance”, og „for mange applikationer er det som regel nok at optimere enkelte LLM-calls med retrieval og in-context examples”.⁴ Dens argument for en agent er snævert: open-ended problemer, hvor du ikke kan forudsige antallet af trin og ikke kan hardcode en vej, i et environment du stoler på, mens du accepterer „højere omkostninger og potentialet for compounded errors”.⁴ OpenAIs skærm er spejlbilledet — kompleks judgement, rule sets der ikke kan vedligeholdes, unstructured data — og slutter samme sted: „ellers kan en deterministisk løsning være nok”.⁵

Så i dette kapitels taksonomi: et fast antal trin i en fast rækkefølge er en pipeline, og at kalde den en agent gør den ikke hurtigere. Hvis antallet af trin afhænger af, hvad du finder på vejen, vil du have et loop — og du køber den fleksibilitet med N calls, et kvadratisk transcript og et system, der kan tage fejl N gange i stedet for én.

Du har nu taksonomien, begge moderne definitioner, de to akser, der gør dem kompatible, og et kort loop, der svarer, kalder og stopper.

Det loop har én måde at ende på: modellen holder op med at bede om tools. Kapitel 23 knækker det med vilje syv gange, og hvert brud tilføjer en del. En umulig opgave, og det ender aldrig — en turn cap. En nat med kørsel, og regningen kommer — et budget i dollars. En tool, der fejler — en fejl, modellen kan handle på. Det samme call to gange — en idempotency key. En fil, den ikke burde have rørt — en human approval. En genstart halvvejs — session persistence. En tool, der tager tre minutter i stilhed — progress og cancellation. Det, der kommer ud, er et harness, den fil resten af dette kursus kører på.

Det efterlader spørgsmålet, som dette kapitels omstridte diagonal egentlig handlede om. Et loop, der beslutter sit eget næste trin, skal beslutte, hvornår det stopper, og vi har lige set, hvad der sker, når det ikke kan: seks turns, fire gange regningen og en agent, der forhører brugeren om et spørgsmål, den allerede havde besvaret. Stopping er ikke én betingelse. Hvor mange er der, og hvilken fyrer først?

Lilian Wengs LLM Powered Autonomous Agents (2023) er den mest kendte opdeling af en language agent i planning, memory og tool use og er den rigtige næste læsning ved siden af de to vendor-dokumenter; dens tre komponenter er Kapitel 23, 24 og 18 i dette kursus i den rækkefølge.

Hvert tal i dette kapitel blev produceret på denne maskine, og intet blev estimeret. Korridoren, gulvplanen, de fire agents der går den, og de tre patrol policies er TypeScript ovenfor, kørt på Node 22; den randomiserede agents tal er gennemsnit over 2.000 seeded kørsler hver, og patrol-tallene er enkelte seeded kørsler på 4.000 ticks. Model-traces kommer fra Qwen2.5-0.5B-Instruct i float32 på CPU med greedy decoding, serveret over loopback af et lille lokalt Python-endpoint, der loader weights og taler OpenAI chat-completions-formen — sømmen igen, med tensors på Python-siden og loopet på TypeScript-siden — så token-tallene er den models tokenizer, og latencies er den maskines. De eneste tal taget andetsteds fra er de to priser i cost-tabellen, som er de rates, Kapitel 16 læste fra OpenAIs pricing page 6. september 2026, anvendt her på lokalt målte token-tal som en illustration og ikke som en observeret invoice.