Was ein AI Agent ist: fünf klassische Typen, zwei rivalisierende Definitionen

Das älteste Beispiel des Feldes ist ein Staubsauger in einer Welt aus zwei Feldern, A und B, jeweils entweder sauber oder schmutzig.¹ Es überlebt in jedem Lehrbuch, weil es die kleinste Welt ist, in der ein agent richtig oder falsch liegen kann.

Der Percept ist ein Paar — wo ich bin und ob es hier schmutzig ist — und die Aktionen sind SUCK, LEFT und RIGHT. Das ganze Programm ist eine Zeile.

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

Lass es gegen jede Startkonfiguration der Zwei-Felder-Welt laufen:

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

Das ist ein simple reflex agent: Er handelt allein auf Basis des aktuellen Percepts, ohne Erinnerung an irgendetwas davor. Keine Spielzeugkategorie — ein Thermostat ist einer, und ein einzelner Call an ein Sprachmodell ohne angehängte Conversation ebenso.

Jetzt zerbrich ihn so, wie die Realität es tut. Ein echter Staubsaugerroboter hat einen Schmutzsensor und einen Stoßfänger, kein unter dem Teppich beschriftetes Feld A. Nimm den Standort aus dem Percept heraus und ändere sonst nichts:

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

Dasselbe Programm, zwei Felder. Aus einem Startzustand ist es nach drei Schritten fertig; aus einem anderen fährt es fünfhundertmal gegen die rechte Wand und würde weiterfahren, bis der Akku leer ist. Es kann den Unterschied zwischen den beiden Situationen nicht wahrnehmen, also kann es in ihnen nicht unterschiedlich handeln. Russell und Norvig formulieren das allgemeine Ergebnis in einer Zeile: Endlosschleifen sind für simple reflex agents in teilweise beobachtbaren Umgebungen oft unvermeidbar.¹

Es gibt einen Fix, der eine Zeile und keinen Speicher kostet; es lohnt sich, ihn zu messen, bevor wir nach etwas Klügerem greifen.

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

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

Zweitausend Läufe eines komplett schmutzigen Korridors in drei Größen, durchgehend mit einem seeded Generator:

Randomisierung entfernt die Schleife vollständig. Sie kostet aber auch: Acht Räume brauchen fünfzehn Züge, wenn du weißt, was du tust, und dieser agent braucht im Schnitt 68,7 und einmal 306. Das ist das ganze Kapitel im Miniaturformat. Jede Fähigkeit, die wir hinzufügen, kauft Korrektheit in einem Fall, mit dem der vorherige agent nicht umgehen konnte, und berechnet sie in einer Währung, die du zuerst benennen musst.

Ein agent nimmt seine Umgebung durch Sensoren wahr und handelt durch Aktuatoren. Das agent program ist die Funktion von Percepts zu Aktionen — jedes Listing oben ist eines. Die Percept-Sequenz ist alles, was bisher wahrgenommen wurde, und ein simple reflex agent ignoriert alles davon außer dem letzten Element.

Rationalität ist das Wort, das die meisten Artikel falsch verstehen, und wenn du es richtig verstehst, wird der Rest dieses Kapitels nutzbar. Ein agent ist nicht an sich rational oder irrational. Russell und Norvig definieren einen rationalen agent als einen, der für jede mögliche Percept-Sequenz die Aktion auswählt, von der erwartet wird, dass sie sein Performance-Maß maximiert, gegeben die Evidenz dieser Sequenz und das eingebaute Wissen, das er hat.¹ Das Performance-Maß steckt nicht im agent: Es gehört dem Designer, und Rationalität ist nur relativ dazu definiert.

Die Spezifikation wird üblicherweise als vier Dinge geschrieben, PEAS: performance measure, environment, actuators, sensors.

Beachte, welche Zeile aus der Reihe fällt. Fast jedes Team, das 2026 agents baut, schreibt E, A und S auf — die tool-Schemas, die Integrationen, das Nachrichtenformat —, weil der Code ohne sie nicht läuft. Fast niemand schreibt P auf. Ohne P hat „unser agent macht das gut“ keine Bedeutung, die irgendjemand prüfen kann, und „rational“ lässt sich auf das System überhaupt nicht anwenden, nur auf eine Demonstration. In Kapitel 29 geht es darum, P in eine Zahl zu verwandeln, und genau deshalb existiert es.

    ┌───────────────────────── 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-Umgebungen werden weiter entlang sieben Achsen klassifiziert, von denen fünf den größten Teil der Schwierigkeit hier bestimmen: vollständig oder teilweise beobachtbar, deterministisch oder nicht, episodisch oder sequenziell, statisch oder dynamisch, bekannt oder unbekannt.¹ Ein agent, der mit echten tools über ein echtes Netzwerk spricht, sitzt in der harten Ecke aller fünf — nicht-deterministisch selbst bei temperature zero (Kapitel 17), und, der unterschätzte Punkt, unbekannt, weil du kein verlässliches Modell davon hast, was deine eigenen tools mit der Welt machen. Deshalb braucht die Schleife aus Kapitel 23 error handling mehr als Planung.

Echte Böden sind nicht eindimensional, also befördern wir die Welt zu einem Plan. Rauten sind Wände, Sternchen sind Schmutz, und der Roboter startet in der mittleren Kammer:

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

Das naheliegende Upgrade ist Speicher. Der agent führt eine Karte: jedes Feld, auf dem er gestanden hat, und jedes Feld, auf dem der Stoßfänger ausgelöst hat. Seine Regel ist, in ein benachbartes Feld zu gehen, das er noch nicht besucht hat — rechts, dann runter, dann links, dann hoch — und zurückzugehen, wenn alles um ihn herum bekannt ist. Das ist ein model-based reflex agent: Er hält internen Zustand aus der Percept-Historie vor und kann deshalb auf das reagieren, was er gerade nicht sehen kann.

Es ist eine echte Verbesserung, und immer noch nicht genug:

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

Fünftausend Züge, die Hälfte des Bodens nie gesehen. Die Karte ist korrekt und die Regeln sind korrekt. Was der agent nicht kann, ist, die Karte zu benutzen, um irgendwohin zu gehen: Seine Regeln beantworten immer nur „in welchen meiner vier Nachbarn soll ich treten“, also hat er, sobald ihm direkt neben sich die unbesuchten Felder ausgehen, keine Möglichkeit, den Gedanken auszudrücken: Es gibt ein unbesuchtes Feld acht Züge entfernt und ich möchte dort stehen. Er weiß, wo er ist. Er weiß nicht, wo er sein will.

Ein goal-based agent hält zusätzlich zu seinem Modell der Welt eine Beschreibung der Situation vor, die er herbeiführen will, und wählt Aktionen, indem er über Sequenzen davon sucht, bis er eine findet, die dort endet. Ziele machen aus Aktionsauswahl eine Suche statt eines Lookups.

Das Ziel ist „kein schmutziges Feld bleibt übrig“. Die Suche ist ein breadth-first Lauf zum nächsten schmutzigen Feld, und der Pfad, den sie zurückgibt, ist der 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

Siebenundzwanzig Züge, Boden sauber. Aber sieh dir die Akku-Spalte und das letzte Teilstück des Plans an. Spalte 0 ist mit Teppich belegt: Ein Teppichfeld zu queren kostet sechs Akku-Einheiten, ein Fliesenfeld eine. Der agent ging über Spalte 0 nach Hause, weil das vier Züge statt acht sind, und diese vier Teppichzüge kosteten 24, während der Umweg mit acht Zügen 13 gekostet hätte.

Er kann nicht anders. Ein Ziel ist ein binärer Test: Der Boden ist sauber oder nicht. Jeder Plan, der mit sauberem Boden endet, erfüllt es gleichermaßen, also hat der agent, wenn mehrere erfolgreich sind, nichts, woran er zwischen ihnen wählen könnte. Einen Erfolg einem anderen vorzuziehen, braucht eine Zahl über Outcomes, und diese Zahl ist eine utility function. Ein agent, der sie maximiert, ist ein utility-based agent.

Die Code-Änderung ist ein Term innerhalb der Suche. Breadth-first search zählt Züge; lass sie stattdessen Kosten zählen, und du hast Dijkstra's algorithm und einen anderen 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 zusätzliche Züge, elf Akku-Einheiten weniger: einundzwanzig Prozent günstiger. Dasselbe Ziel, dieselbe Karte, derselbe Code bis auf einen Term. Die beiden agents unterscheiden sich nur darin, worin sie gut sein wollen, und nehmen unterschiedliche Routen nach Hause.

Das ist auch der erste Punkt, an dem der agent etwas braucht, das er nicht selbst erzeugen kann. Jemand muss entscheiden, was eine Akku-Einheit im Verhältnis zu einem Zug wert ist. Utility ist das Performance-Maß in einer Form, mit der der agent rechnen kann, und es zu schreiben ist Aufgabe des Designers. Wenn Leute sagen, ein agent habe „das Falsche optimiert“, meinen sie fast nie einen Bug. Sie meinen, diese Zeile wurde nachlässig geschrieben.

Jetzt kommt Schmutz zurück. Vier Räume werden mit vier unterschiedlichen Raten wieder schmutzig, und der agent erfährt sie nie. Er besucht pro Tick einen Raum und sieht nur diesen Raum. Das Performance-Maß sind Raum-Ticks, die über 4.000 Ticks schmutzig verbracht wurden — weniger ist besser.

Ein learning agent ist in der Lehrbuchzerlegung jeder der obigen plus drei Teile: ein learning element, das den agent verändert, ein critic, der ihm sagt, wie gut der agent gegen einen festen Performance-Standard abschneidet, und ein problem generator, der Aktionen vorschlägt, die sich wegen dessen lohnen, was sie lehren würden.¹ Drei Policies in derselben Umgebung. Die erste lernt nicht; die zweite und dritte lernen dasselbe und nutzen es unterschiedlich.

Die versteckten Raten waren 0,35 für die Küche, 0,05 für den Flur, 0,02 für das Arbeitszimmer und 0,01 für den Dachboden — und Learner A fand sie. Er identifizierte korrekt die Küche als schmutzigsten Raum im Haus und ging dann für den Rest der Simulation in jedem Tick in die Küche, während die anderen drei für immer schmutzig blieben. Er ist fünfmal schlechter, als gar nicht zu lernen, und er ist nicht kaputt.

Die Lektion ist dieselbe wie im Utility-Abschnitt. Learner A maximierte „Wahrscheinlichkeit, dass der Raum, den ich gleich besuche, schmutzig ist“. Das Performance-Maß war „Raum-Ticks, die schmutzig verbracht wurden“. Unterschiedliche Zahlen; die zweite war die, die der critic bewertete, und niemand sagte es dem agent. Learner B multipliziert dieselbe gelernte Rate mit der Zeit seit dem letzten Besuch — den Schmutz, den er zu finden erwartet, statt die Chance, überhaupt welchen zu finden — und schlägt die Patrouille, von der er gestartet war.

Ein Implementierungsdetail entschied das Ergebnis. In der ersten Version von Learner B bekam ein Raum, in dem bei drei Besuchen kein Schmutz aufgetaucht war, eine Rate von exakt null — und null mal irgendetwas ist null, also wurde er nie wieder besucht und die Schätzung konnte nie korrigiert werden. Das Glätten des Bruchs, Erfolge plus eins über Versuche plus zwei, machte aus 11.895 eine 1.576. „Noch nicht beobachtet“ und „gemessen und als null herausgekommen“ sind unterschiedliche Behauptungen, und ein System, das sie im selben Feld speichert, trifft Entscheidungen, die es nicht rückgängig machen kann.

  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

Jeder der fünf läuft heute in Produktion unter einem anderen Namen.

Zwei Zeilen sind mehr als nur analog, und zwar auf eine Weise, die Geld kostet.

Der Chat ist ein model-based reflex agent, dessen Modell nicht intern ist. Im Lehrbuch ist der Zustand eine Variable innerhalb des agent program. In einem Chat ist es das Transcript: Es lebt auf deiner Seite, wird bei jedem Call vollständig erneut gesendet und jedes Mal im model von Grund auf neu aufgebaut. Das ist die quadratische Rechnung aus Kapitel 16, und es ist dasselbe Objekt, das das Lehrbuch als Kasten mit der Beschriftung „state“ gezeichnet hat. Hier ist der Unterschied, gemessen an einer Follow-up-Frage mit und ohne die zwei Nachrichten davor:

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

Dasselbe model, dieselben drei Wörter user input, und die zweite Variante ist der Korridorroboter, der gegen die Wand fährt. In diesem Lauf gab es keine tools, also ist die 15 erfunden — aber der Zustand ist das, was das Follow-up überhaupt sinnvoll macht. Du baust ihn jedes Mal neu auf und bezahlst dafür 2,3× die input Tokens bei einer Conversation mit zwei Turns. Kapitel 16 hat gemessen, wohin dieser Multiplikator bei Turn vierzig kommt.

Reflexion ist ein learning agent, der seinen input verändert statt sein Programm. In der Lehrbuchzerlegung modifiziert das learning element das performance element. Reflexion lässt die weights in Ruhe und schreibt reflektierenden Text in einen episodic buffer, den der nächste Versuch liest.³ Das learning element ist ein prompt, der Speicher eine Datenbankzeile, das performance element ein eingefrorenes model — und das Diagramm ist unverändert das aus dem Lehrbuch.

Und hier ist die ehrliche Grenze des Mappings. Die fünf Typen klassifizieren das agent program. 2026 ist dieses Programm in der Mitte geteilt: Ein Teil ist dein Code, ein Teil steckt in weights, die du nicht trainiert hast. Wenn ein model von sich aus entscheidet, ein tool aufzurufen, liegt der Zieltest dann in deinem Programm oder im model? Die Taxonomie hat keine Antwort, weil es, als sie geschrieben wurde, keinen anderen Ort dafür gab — und genau an dieser Frage trennen sich die beiden modernen Definitionen.

Die Definitionen sind Argumente über Verhalten, und sie lassen sich viel leichter beurteilen, wenn ein Trace vor dir liegt.

Die Schleife unten sendet die Conversation an ein model; wenn die Antwort einen tool call enthält, führt sie das tool aus, hängt das Ergebnis an und sendet das Ganze erneut. Sie läuft gegen ein lokales Qwen2.5-0.5B-Instruct hinter einem OpenAI-förmigen Endpoint auf dieser Maschine — die Naht aus Kapitel 14, also weiß die Schleife weder, was hinter dem Port liegt, noch kümmert es sie.

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

Zwei Zeilen tragen die ganze Idee, und beide sind markiert; der Rest ist Buchhaltung. Alle drei Verhaltensweisen sind in einem Lauf sichtbar. Wird das model etwas gefragt, das es selbst kann, antwortet es. Wird es etwas gefragt, das es nicht kann, ruft es auf:

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

Und es stoppt — das dritte Verhalten und das am leichtesten zu übersehende, weil es aussieht, als passiere nichts. Die Schleife endet, weil Turn 2 ohne tool call zurückkam. Niemand entschied das; das model tat es, indem es Prosa ausgab. Die Terminierungsbedingung dieses Programms ist das Zeichen einer Abwesenheit.

Zwei weitere Läufe sind den Platz wert. Gebeten, zwei Städte zu vergleichen, gibt das model beide tool calls in einem Turn aus, bekommt beide Messwerte zurück und macht den Vergleich falsch:

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

Die tools funktionierten. Der parallele Call funktionierte. Die Schleife funktionierte. Die Antwort ist falsch, mit beiden korrekten Zahlen im Transcript. Ein model in eine Schleife zu wickeln, lässt es nicht denken; es gibt einem falschen model die Fähigkeit, aufgrund seines Falschliegens zu handeln — das ist Kapitel 30 vorweggenommen und die Hälfte von Kapitel 29.

Lösche jetzt das markierte return und lass die Schleife stattdessen bis zu ihrer Obergrenze laufen. Dieselbe Frage, dasselbe 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

Viermal so viele input Tokens, viermal so viel Wanduhrzeit und ein Ende, in dem der agent vergessen hat, was er gefragt wurde, und den Nutzer zu einer Frage verhört, die dieser in Turn eins beantwortet hatte. Die richtige Antwort stand in Turn 2 auf dem Bildschirm, und jeder Turn danach machte das Transcript schlechter.

Ein agent ist also keine Schleife. Er ist eine Schleife plus eine Regel, sie zu verlassen, und diese hier hat genau eine solche Regel. Kapitel 23 findet fünf und zeigt, was kaputtgeht, wenn jede einzelne fehlt.

Beide zitiert statt paraphrasiert, weil die Verwirrung in den Paraphrasen hergestellt wird.

Definition eins setzt die Grenze dort, wo entschieden wird, wer den Ablauf kontrolliert. Anthropics Building effective agents benennt die Mehrdeutigkeit und entscheidet darüber:

„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.“⁴

Der Test ist eine Frage an deinen Quellcode: Wer hat den nächsten Schritt gewählt? Ein switch in deinem Programm: Workflow. Das model: agent. Dasselbe Dokument sagt, agents seien „typically just LLMs using tools based on environmental feedback in a loop“ — also exakt das Listing oben.

Definition zwei setzt die Grenze bei der Unabhängigkeit vom Nutzer. OpenAIs A practical guide to building agents eröffnet seine Definitionsseite so:

„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.“⁵

Zwei Sätze später, auf derselben Seite, schließt es aus:

„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.“⁵

Lies diese Zitate der Reihe nach. Die einleitenden Sätze ziehen die Linie bei Unabhängigkeit: Geht dieses Ding los und erledigt den Job ohne mich? Der vierte zieht sie bei Kontrolle der Ausführung, also exakt bei Anthropics Linie. Unterschiedliche Tests, dieselbe Seite, und es gibt echte Systeme, bei denen sie uneins sind.

Darunter liegt eine Kollision im Vokabular, und sie verursacht Streit in echten Meetings. Im ersten Dokument ist ein Workflow eine Architektur, und er ist das, was kein agent ist. Im zweiten ist ein Workflow „a sequence of steps that must be executed to meet the user's goal“ — die Aufgabe selbst, von der jeder agent eine hat. „Wir haben den Workflow durch einen agent ersetzt“ ist unter der ersten Definition kohärent und unter der zweiten fast bedeutungslos.

Drei Systeme, die 2026 existieren, unter beiden Definitionen.

Zwei der drei wechseln die Seite. Das ist kein Scheitern eines der beiden Dokumente. Es ist eine Warnung vor einer Art Meeting, in dem zwei Menschen, die vollständig darin übereinstimmen, was ein System tut, eine Stunde damit verbringen, sich darüber zu streiten, wie man es nennt.

Die Definitionen kollidieren, weil jede zwei unabhängige Fragen in ein Wort presst. Trenn sie, und die Uneinigkeit wird zu einer Tabelle, die nützlicher ist als ein Urteil.

Jede Definition bestreitet eine andere Zelle, und die anderen beiden sind überhaupt nicht strittig. Wenn das Label also wichtig ist — in einem Vertrag, einem Risk Review, einem Postmortem — lauten die zwei Sätze, die sich zu schreiben lohnen, nicht „ist es ein agent“, sondern wer hat den nächsten Schritt gewählt und wer hat zugesehen. Beide lassen sich durch Lesen des Codes beantworten, keine braucht irgendeine Definition, und zusammen tragen sie jede Konsequenz, für die das Label stand.

Nichts davon ist neu. Wooldridge und Jennings untersuchten 1995 die konkurrierenden Bedeutungen von „agent“;⁶ Franklin und Graesser stellten 1996 die Frage dieses Kapitels, sammelten die damals kursierenden Definitionen und stellten fest, dass sie sich widersprachen.⁷ Eine Survey von 2023 definiert agents immer noch von ersten Prinzipien her — „artificial entities that sense their environment, make decisions, and take actions“⁸ —, weil es nichts Festgelegtes gab, auf das man hätte verweisen können, und CoALA beschreibt Teile, statt überhaupt eine Grenze zu ziehen.⁹ Dreißig Jahre Nicht-Einigung sagen, dass das Wort mehr als eine Aufgabe erfüllt.

Jetzt die Konsequenz, die vor der Philosophie ankommt: die Rechnung.

Jede Messung hier hat dieselbe Form. Der einzelne Call kostete 39 input Tokens; dieselbe Frage mit einem tool kostete 420 über zwei Calls; die Schleife ohne Stoppregel kostete 1.688 über sechs. Das Wachstum ist schlechter als linear, weil Turn n jeden vorherigen Turn mitträgt: Die prompt-Spalte dieses Sechs-Turn-Laufs lautet 187, 238, 261, 302, 327, 373. Kapitel 16 leitete her, dass die Summe $\Theta(n^2)$ ist, und fitete die Kurve auf einer echten Conversation. Ein agent verwandelt jede Aufgabe in diese Conversation, ob ein Mensch sie je sieht oder nicht.

Wenn diese gemessenen token-Zahlen zu einem kommerziellen Endpoint zu den Raten gegangen wären, die Kapitel 16 am 6. September 2026 las — $2,00 pro Million input Tokens und $12,00 pro Million output —, sähen die vier Läufe preislich so aus:

Zeile zwei gegen Zeile eins ist die Zahl, die du behalten solltest. Siebeneinhalbfache Kosten für eine schlechtere Antwort auf eine Frage, die das model bereits wusste. Nichts war falsch konfiguriert: Ein tool existierte, also nutzte das model es — und die Feststellung aus Kapitel 18, dass der Preis eines Katalogs und nicht seine Genauigkeit weh tut, hat hier ihre günstigste Demonstration mit einem Katalog von eins.

Deshalb ist die nützliche Hälfte beider Dokumente die Hälfte darüber, das nicht zu bauen. Anthropic ist direkt: Finde die einfachste mögliche Lösung und füge Komplexität nur hinzu, wenn nötig, was „might mean not building agentic systems at all“ bedeuten könne, weil agentic systems „trade latency and cost for better task performance“ und „for many applications, optimizing single LLM calls with retrieval and in-context examples is usually enough“.⁴ Der Fall für einen agent ist eng: offene Probleme, bei denen du die Zahl der Schritte nicht vorhersagen und keinen Pfad hardcoden kannst, in einer Umgebung, der du vertraust, unter Akzeptanz von „higher costs, and the potential for compounding errors“.⁴ OpenAIs Screen ist das Spiegelbild — komplexes Urteilsvermögen, nicht wartbare Regelsätze, unstrukturierte Daten — und endet genauso: „otherwise, a deterministic solution may suffice“.⁵

Also, in der Taxonomie dieses Kapitels: Eine feste Anzahl von Schritten in fester Reihenfolge ist eine Pipeline, und sie agent zu nennen, macht sie nicht schneller. Wenn die Anzahl der Schritte davon abhängt, was du unterwegs findest, willst du eine Schleife — und du kaufst diese Flexibilität mit N Calls, einem quadratischen Transcript und einem System, das N-mal falsch liegen kann statt einmal.

Du hast jetzt die Taxonomie, beide modernen Definitionen, die zwei Achsen, die sie kompatibel machen, und eine kurze Schleife, die antwortet, aufruft und stoppt.

Diese Schleife hat eine Art zu enden: Das model hört auf, nach tools zu fragen. Kapitel 23 zerbricht sie absichtlich siebenmal, und jeder Bruch fügt ein Stück hinzu. Eine unmögliche Aufgabe, und sie endet nie — eine Turn-Obergrenze. Eine Nacht Laufzeit, und die Rechnung kommt — ein Dollar-Budget. Ein tool, das fehlschlägt — ein Fehler, auf den das model reagieren kann. Derselbe Call zweimal — ein Idempotency Key. Eine Datei, die es nicht hätte anfassen sollen — eine human approval. Ein Neustart in der Mitte — Session-Persistenz. Ein tool, das drei Minuten lang schweigend läuft — Fortschritt und Abbruch. Heraus kommt ein harness, die Datei, auf der der Rest dieses Kurses läuft.

Damit bleibt die Frage, um die es in der umstrittenen Diagonale dieses Kapitels wirklich ging. Eine Schleife, die ihren eigenen nächsten Schritt entscheidet, muss entscheiden, wann sie stoppt, und wir haben gerade gesehen, was passiert, wenn sie es nicht kann: sechs Turns, viermal die Rechnung und ein agent, der den Nutzer zu einer Frage verhört, die er bereits beantwortet hatte. Stoppen ist nicht eine Bedingung. Wie viele gibt es, und welche feuert zuerst?

Lilian Wengs LLM Powered Autonomous Agents (2023) ist die bekannteste Zerlegung eines language agent in Planung, Speicher und tool-Nutzung und ist die richtige nächste Lektüre neben den beiden Vendor-Dokumenten; ihre drei Komponenten sind Kapitel 23, 24 und 18 dieses Kurses, in dieser Reihenfolge.

Jede Zahl in diesem Kapitel wurde auf dieser Maschine erzeugt, und nichts wurde geschätzt. Der Korridor, der Grundriss, die vier agents, die ihn begehen, und die drei Patrouillen-Policies sind das TypeScript oben, ausgeführt auf Node 22; die Zahlen des randomisierten agent sind Mittelwerte über je 2.000 seeded Läufe, und die Patrouillen-Zahlen sind einzelne seeded Läufe über 4.000 Ticks. Die model Traces stammen aus Qwen2.5-0.5B-Instruct in float32 auf CPU mit greedy decoding, bereitgestellt über loopback durch einen kleinen lokalen Python-Endpoint, der die weights lädt und die OpenAI chat-completions-Form spricht — wieder die Naht, mit den Tensoren auf der Python-Seite und der Schleife auf der TypeScript-Seite —, also sind die token-Zahlen die des Tokenizers dieses model und die Latenzen die dieser Maschine. Die einzigen Zahlen von anderswo sind die zwei Preise in der Kostentabelle, nämlich die Raten, die Kapitel 16 am 6. September 2026 von OpenAIs Pricing-Seite gelesen hat, hier angewendet auf lokal gemessene token-Zahlen als Illustration und nicht als beobachtete Rechnung.