Multi-agent-Orchestrierung: fünf Muster – und wann eines gewinnt

Ein portugiesisches Unternehmen schreibt wegen Rechnung FT-2026-0918. Die E-Mail sagt, die Mehrwertsteuer sehe falsch aus, und hängt die Rechnung an: netto 248,00 EUR, MwSt. mit 21 % berechnet, 52,08 EUR, Gesamtbetrag 300,08 EUR.

Die Fakten für die Antwort liegen an drei Stellen, und nur eine davon steht in der E-Mail:

Setzt man die drei zusammen, ist die Rechnung falsch: reverse charge gilt, die MwSt. hätte null sein müssen, und eine Gutschrift über 52,08 EUR ist fällig. Sieht man nur auf die Rechnung, ist sie rechnerisch perfekt — 248,00 plus 52,08 sind 300,08 — und genau das wird man sagen.

Die E-Mail sagt zwar: „Wir sind ein portugiesisches Unternehmen“. Das ist eine Behauptung, kein Datensatz, und kein Abrechnungssystem stellt auf Basis einer Behauptung eine Gutschrift aus. Die Falle ist kein Trick: Sie ist die gewöhnliche Form von Geschäftsarbeit, bei der die Entscheidung einen Fakt braucht, den niemand abzurufen gedacht hat.

Alles oben läuft gegen einen geskripteten Provider im Stil von Kapitel 23, mit genau einer Regel:

Eine Antwort darf nur einen Fakt verwenden, der in ihrem prompt steht.

Das „Modell“ fragt jedes Tool, das es hat, einmal ab — in Katalogreihenfolge — und wendet dann eine feste Regel auf den Text an, den es sehen kann. Nichts ist pro Arrangement geskriptet, deshalb sind die Unterschiede in der Eingangstabelle keine Behauptungen über Modellintelligenz: Sie sind gemessenes Informationsrouting. Ein echtes Modell legt eigene Fehler obendrauf; es entfernt diese nicht.

Die fünf Namen unten stammen von Anthropic aus Building effective agents; dort hat sich dieses Vokabular eingependelt.¹ Keine der fünf Ideen ist neu, und zu wissen, welche Schule was benannt hat — und welche Idee älter ist — macht die Hälfte ihres Werts aus.

/* 1. Prompt chaining: a fixed pipeline. The control flow is yours. */
export async function chain(steps: Step[], first: string) {
  let carry = first, all = first;
  for (const s of steps) {
    const r = await step(s.role, s.system, s.accumulate ? all : carry);   
    carry = r.text;
    all = `${all}\n${r.text}`;
  }
  return carry;
}

/* 2. Routing: one cheap call picks the branch. The fallback is not a model. */
export async function route<T>(input: string, classify: Classifier,
                               routes: Record<string, Branch<T>>, fallback: Branch<T>) {
  let label: string | undefined;
  try { label = await classify(input); } catch { label = undefined; }
  return ((label && routes[label]) || fallback)(input);                    
}

/* 3. Parallelisation. The pattern IS this line. */
export const parallel = <T>(workers: Branch<T>[], input: string) =>
  Promise.all(workers.map((w) => w(input)));                              

/* 4. Orchestrator-workers: an agent behind a tool. Chapter 18's interface, unchanged. */
export function agentTool(o: WorkerSpec): Tool {
  return {
    name: o.name, description: o.description, readOnly: true,
    parameters: { type: "object", properties: { question: { type: "string" } } },
    async run(args: { question: string }) {
      const child = newRun(o.system, args.question);          // its own window
      await runTracked(child, o.tools, o.usage);              // its own limits
      const conclusion = child.output ?? "no result";
      if (!o.carryFindings) return conclusion;                             
      return `${conclusion}\nFINDINGS ${evidence(child)}`;                 
    },
  };
}

/* 5. Evaluator-optimiser: make, judge, remake. Rounds are calls. */
export async function refine(make: Make, judge: Judge, maxRounds: number) {
  let draft = "", feedback: string | undefined;
  for (let r = 1; r <= maxRounds; r++) {
    draft = (await make(feedback)).text;
    const j = await judge(draft);
    if (j.ok) return { draft, rounds: r };
    feedback = j.note;
  }
  return { draft, rounds: maxRounds };
}

Das ist das ganze Toolkit: fünf Funktionen, kein Framework, und die parallele ist eine einzige Zeile — genau deshalb lohnt es sich, sie auszuschreiben, statt sie zu zeichnen. Jetzt der Reihe nach: mit Herkunft, Preis und dem Fall, in dem sie falschliegt.

Prompt chaining „zerlegt eine Aufgabe in eine Sequenz von Schritten, bei der jeder LLM-Aufruf die Ausgabe des vorherigen verarbeitet“.¹ Die Idee ist älter als Sprachmodelle: Es ist eine Pipeline, mit dem Tauschgeschäft jeder Pipeline — Klarheit gegen einen Kontrollfluss, der feststeht, bevor die Daten eintreffen.

Vier Schritte für unsere Aufgabe: Rechnungsfelder extrahieren, Arithmetik prüfen, entscheiden, was geschuldet ist, Antwort schreiben. Hier scheitert es auf zwei verschiedene Arten, was mehr lehrt als ein einzelnes Scheitern.

--- relay: each step sees only the previous step's output
extract: FIELDS invoice_id=FT-2026-0918 net=248.00 vat_rate_applied=21 vat_amount=52.08 ...
check:   ARITHMETIC ok 248.00+52.08=300.08
decide:  VERDICT=unknown reason=no_invoice_in_context
draft:   "we are looking into invoice FT-2026-0918 and will come back to you."

--- accumulating: each step sees the email and everything produced so far
extract: FIELDS invoice_id=FT-2026-0918 net=248.00 vat_rate_applied=21 ...
check:   ARITHMETIC ok 248.00+52.08=300.08
decide:  VERDICT=invoice_correct reason=net_248.00_plus_21pct_vat_52.08_equals_300.08
draft:   "we have checked FT-2026-0918 and it is correct... Nothing is owed back."

Die Relay-Kette kostete $0.001940 und verlor die Rechnungsfelder zwischen Schritt zwei und drei, weil Schritt drei nur einen Satz über Arithmetik bekam und sonst nichts. Sie erzeugte eine Zwischenantwort: nutzlos, und sichtbar nutzlos.

Die akkumulierende Kette — die Zeile in der Eingangstabelle — kostete $0.003780, also 95 % mehr für vier identische Aufrufe, weil jeder Schritt nun alles Vorherige mitträgt. Sie erzeugte die gefährliche Ausgabe. Flüssig, mit Verweis auf die eigene Arithmetik, korrekt bei jeder Zahl, die sie erwähnt, und mit der Aussage an den Kunden, dass nichts geschuldet sei, obwohl 52,08 EUR geschuldet sind.

Der Unterschied zwischen beiden ist ein ternärer Operator. Eine Kette, die weniger mitträgt, erzeugt offensichtlich unvollständige Antworten; eine Kette, die alles mitträgt, erzeugt selbstsicher falsche Antworten — und nur die zweite Sorte wird verschickt.

Keines davon ist der eigentliche Fehler. Der eigentliche Fehler ist, dass die Pipeline vor dem Lesen entschieden hat, diese Aufgabe bestehe aus vier Schritten über den Inhalt einer E-Mail. In dieser Struktur gibt es nirgends einen Ort, an dem sie sagen kann: „Das Registrierungsland steht nicht in dieser E-Mail; hol es.“ Chaining ist richtig, wenn die Zerlegung im Voraus bekannt und stabil ist. Hier war sie eine Vermutung, und die Vermutung wurde ausgeliefert.

Routing „klassifiziert eine Eingabe und leitet sie an eine spezialisierte Folgeaufgabe weiter“.¹ Der Name ist neu; der Mechanismus ist der Dispatcher, älter als fast alles andere in diesem Buch. Neu ist, dass der Klassifizierer ein Modell sein kann — und genau dadurch scheitert er auf Arten, wie es ein switch nie tat.

const answer = await route(email,
  (q) => classifyWithSmallModel(q),          // cheap model, one call
  { billing: billingAgent, tax: taxAgent, dunning: dunningAgent },
  taxAgent,                                  // deterministic, chosen in advance
);

Zwei Dinge zu diesem letzten Argument. Es ist kein Error Handling; es ist das Muster. Ein modellbasierter Router hat einen Fehlermodus, den ein Dispatcher nicht hat: Er kann ein Label zurückgeben, das nicht existiert, einen Timeout haben oder — der teure Fall — ein plausibles falsches Label ohne Signal zurückgeben, dass es falsch ist. Alle drei müssen irgendwo landen, und dieses Irgendwo kann kein weiterer Modellaufruf sein, weil du bereits in dem Branch bist, in dem Modellaufrufe fehlgeschlagen sind.

Das Zweite: Der prompt des Routers selbst ist nicht kostenlos. Um ein Modell auszuwählen, braucht ein Router einen Katalog von Modellen, aus denen er wählen kann, und jeder Eintrag darin ist input, den der Router bezahlt, bevor er die Frage des Nutzers gelesen hat. Beim input-Preis, mit dem dieser Kurs rechnet, kostet ein Katalog von etwa 3.800 tokens bereits so viel wie der komplette Fünf-Aufruf-agent-Run in der Eingangstabelle. In der Praxis läuft der Routing-Aufruf auf einem billigen Modell, genau deshalb lohnt sich Routing überhaupt; aber die Rechnung sollte man in diese Richtung machen, statt sie anzunehmen. Routing ist genau dann falsch, wenn die geroutete Aufgabe billiger ist als die Routing-Entscheidung.

Anthropic teilt dieses Muster in zwei: Sectioning — „eine Aufgabe in unabhängige Teilaufgaben zerlegen, die parallel laufen“ — und Voting — „dieselbe Aufgabe mehrfach ausführen, um verschiedene Ausgaben zu erhalten“.¹ Beide teilen sich ein Diagramm und sonst fast nichts.

Sectioning ist der günstige Gewinn, und es ist die Zeile aus patterns.ts: drei Spezialisten — Billing, Tax, Policy — jeder mit eigenem Fenster und eigenen Tools, über derselben E-Mail, am Ende ein Syntheseaufruf. Identische Arbeit, auf zwei Arten geordnet:

Token für token gleich, 1,8-mal schneller. Deshalb verdient das Muster seinen eigenen Namen: Es ist das einzige der fünf, das etwas verbessert, ohne etwas zu kosten. Der Haken ist, dass die Abschnitte wirklich unabhängig sein müssen — gib Abschnitt B einen Fakt, den Abschnitt A erzeugt, und Promise.all lässt beide gegen einen Zustand laufen, den es noch nicht gibt. Die for-Schleife versteckte diesen Bug; der Einzeiler legt ihn offen.

Voting ist ein anderes Tier, das dasselbe Bild trägt. Dieselbe Frage k-mal auszuführen und die Mehrheit zu nehmen, ist self-consistency, veröffentlicht von Wang et al. im März 2022 als Decoding-Strategie, fast drei Jahre bevor es jemand ein Orchestrierungsmuster nannte. Das Abstract ist präzise über den Mechanismus — „zuerst eine diverse Menge von Reasoning-Pfaden samplen, statt nur den greedy Pfad zu nehmen, und dann die konsistenteste Antwort auswählen, indem die gesampelten Reasoning-Pfade marginalisiert werden“ — und über den Gewinn: +17,9 Punkte auf GSM8K.²

Daraus folgen zwei Dinge, die das Bild verbirgt. Erstens erfordert Voting das Sampling aus Kapitel 17: Bei Temperatur null sind alle k Samples dasselbe Sample, und die Mehrheit ist eine Antwort, für die k-mal bezahlt wurde. Zweitens funktioniert es nur dort, wo eine Mehrheit sinnvoll ist — bei der Rechnungsantwort oben gibt es nichts zu zählen, weil fünf Entwürfe fünf verschiedene Sätze sind. Voting ist für Aufgaben mit kurzer, vergleichbarer Antwort; das sind genau Wangs Benchmarks und fast nichts, was ein kundenorientierter agent tut.

Hier gemessen an 20 dreischrittigen Textaufgaben, deren Antworten berechnet statt beurteilt werden, mit dem lokalen Modell aus Kapitel 23, das Schritt für Schritt schließt:

Fünfmal so viele Aufrufe, fünfmal so viele tokens, exakt fünfmal die Rechnung und keine einzige zusätzliche richtige Antwort. Voting ist eine Wette, keine Verbesserung, und dieser Lauf hat sie verloren.

Zwei Einschränkungen, bevor jemand das als Widerlegung von Wang zitiert. Zwanzig Versuche können 45 % nicht von 60 % unterscheiden — das Intervall ist so breit wie die Behauptung, also Kapitel 4s Disziplin auf mein eigenes Ergebnis angewendet. Und die veröffentlichten Gewinne stammen von um Größenordnungen größeren Modellen, bei denen die diversen Reasoning-Pfade, über die Voting marginalisiert, tatsächlich divers sind. Übertragbar ist nicht die Zahl, sondern: Der Multiplikator ist exakt und im Voraus bekannt, der Gewinn ist es nicht.

Im orchestrator-workers-Workflow „zerlegt ein zentrales LLM Aufgaben dynamisch, delegiert sie an Worker-LLMs und synthetisiert ihre Ergebnisse“, und der Unterschied zu Sectioning ist, dass „Teilaufgaben nicht vordefiniert sind, sondern vom Orchestrator bestimmt werden“.¹ Die Herkunft liegt hier überhaupt nicht bei Sprachmodellen: Das ist Master-Worker, und die Variante, in der Worker Findings in einen gemeinsamen Raum schreiben, den ein Controller liest, ist die Blackboard-Architektur aus der Forschung zur Spracherkennung der 1970er. Neu im Jahr 2026 ist, dass der Controller ein Modell ist und die Zerlegung deshalb pro Eingabe entschieden werden kann — Flexibilität und Kosten in einem Satz.

Es kostete 12 Modellaufrufe gegenüber 5 beim einzelnen agent, und erreichte dasselbe Urteil. Dann tat es etwas, das einen genauen Blick verdient:

orchestrator final: VERDICT=credit_note_due amount=52.08 source=worker_unverified
                  | PO_MISMATCH=yes source=worker_unverified
single agent:       VERDICT=credit_note_due amount=52.08 reason=reverse_charge_should_have_applied
                  | PO_MISMATCH=yes invoice_says=PO-4417 order_says=PO-4471

Beide haben recht. Nur eines weiß warum. Der Tax-Worker hatte Rechnung, Bestellung und Steuertabelle im eigenen Fenster, kam zur Schlussfolgerung und bemerkte außerdem — niemand hatte gefragt —, dass die Bestellnummer auf der Rechnung nicht zur Bestellung passt. Dann gab er eine Zusammenfassung zurück. Der Orchestrator kann beide Aussagen wiederholen und keine prüfen, weil die Belege in einem Fenster geblieben sind, das er nie gesehen hat. Das ist die Schlussfrage aus Kapitel 24, beantwortet: Der Parent darf ansehen, was das Child aufzuschreiben entschieden hat.

Die Lösung ist ein Flag, und es hat einen Preis:

Zwölf Prozent mehr input tokens, 8,3 % mehr Geld, und die Formulierung source=worker_unverified verschwindet aus der Antwort. Das ist der Tausch in jedem multi-agent system und er wird fast nie ausgesprochen: Das saubere Fenster des Child ist wertvoll, die Audit-Fähigkeit des Parent ist bezahlenswert, und beides gibt es nicht kostenlos.

Wann ist orchestrator-workers also falsch? Hier, bei dieser Aufgabe. Es kaufte eine richtige Antwort, die ein agent mit denselben vier Tools ebenfalls erreicht hat — für 1,66-mal die Kosten und 2,3-mal die Wanduhrzeit — und machte diese Antwort schwerer verteidigbar. Anthropics eigene Empfehlung sagt das schon vor den Mustern: Finde „die einfachste mögliche Lösung und erhöhe Komplexität nur, wenn nötig“, weil „agentic systems häufig Latenz und Kosten gegen bessere Aufgabenleistung tauschen“.¹ Die Tabellen oben sind dieser Satz mit Zahlen darunter.

Ein Aufruf generiert, ein anderer bewertet, und die Schleife wiederholt sich, bis die Bewertung besteht.¹ Die veröffentlichten Vorfahren sind Self-Refine — dasselbe Modell als „Generator, Refiner und Feedback Provider“, mit etwa 20 Punkten absoluter Verbesserung im Durchschnitt über sieben Aufgaben³ — und Reflexion, das die Kritik über Versuche hinweg in einem episodischen Puffer speichert und 91 % pass@1 auf HumanEval berichtet, wo die Baseline 80 % erreichte.⁴

Das Kostenmodell ist das einfachste der fünf: zwei Aufrufe pro Runde, und die Rundenzahl gehört nicht dir. Drei Verfeinerungsrunden bei einer Aufgabe, die einen Aufruf gebraucht hätte, sind sechs Aufrufe; der Boden des Musters ist also 6× und die Decke ist jedes Cap, das du setzt — damit wird der Budget-Exit aus Kapitel 23 Pflicht statt Aufräumarbeit.

Die Decke ist subtiler, und sie ist messbar. Bei denselben 20 Aufgaben beantwortete das lokale Modell 9 korrekt. Dann bekam es jede dieser Antworten gezeigt und wurde gefragt, ob sie richtig sei — ohne den Hinweis, dass es die eigene Antwort war; das entfernt den Schmeichel-Confound und lässt den Capability-Confound übrig:

Das ist ein besserer Richter, als der Abschnittstitel nahelegt, und genau deshalb misst man, statt zu behaupten: Er blockierte nichts Korrektes und fing 8 von 11 Fehlern. Als Filter ist er seine Aufrufe wert.

Als Stoppregel, wofür eine evaluator-optimiser-Schleife ihn tatsächlich nutzt, erzählen diese drei Freigaben die ganze Geschichte: Sie beenden die Schleife mit einer falschen Antwort in der Hand, und keine Zahl zusätzlicher Runden erreicht sie je. Eine Verfeinerungsschleife kann nicht korrekter werden als ihr Richter. Mehr Runden kaufen Versuche gegen die Fehler, die der Richter sehen kann, zum vollen Preis — und gar nichts gegen die, die er nicht sehen kann.

Daher die Regel: Ein Evaluator verdient seine Aufrufe nur, wenn er etwas hat, das der Generator nicht hat. Einen Compiler, eine Testsuite, einen Schema-Validator, ein anderes Modell, einen Menschen. Self-Refines eigene Ergebnisse werden gegen menschliche Präferenz und Aufgabenmetriken gemessen, nie gegen die Meinung des Modells über sich selbst. Wenn der einzige Vorteil deines Evaluators ein anderer prompt ist, zahlst du doppelt für Zustimmung. Kapitel 29 baut die Version mit echtem Vorteil: ein Golden Set mit vorab niedergeschriebenen Antworten.

Die fünf oben sind Formen für deinen Code. Darunter sitzt eine zweite Familie, die oft daneben gelistet wird und es nicht sollte: ReAct, Reflexion, plan-and-execute und tree of thoughts sind Reasoning-Schleifen, und ihre Kosten liegen in Requests.

Kapitel 12 handelte von Reasoning innerhalb des Modells, das du in output tokens eines Aufrufs bezahlst. Das hier ist die andere Art. Der Unterschied zählt, wenn die Rechnung kommt: Eine längere chain of thought macht einen Aufruf teurer, und eine Reasoning-Schleife macht aus einer Aufgabe viele Aufrufe, von denen jeder alles Vorherige erneut sendet — die quadratische Form, die Kapitel 23 in seiner Runaway-Tabelle gemessen hat.

Das tree-of-thoughts-Paper veröffentlicht seine eigene Kostentabelle, was seltener ist, als es sein sollte. Bei Game of 24 mit GPT-4: input/output prompting best-of-100 löste 33 % zu $0.13 pro Fall, chain of thought best-of-100 löste 49 % zu $0.47, und tree of thoughts löste 74 % zu $0.74; die Autoren merken an, es „könnte 5-100 times more generated tokens than CoT“ benötigen.⁷

Fast sechsmal der Preis der billigen Methode für etwas mehr als die doppelte Erfolgsrate. Ob das ein Schnäppchen ist, hängt davon ab, was ein fehlgeschlagener Fall dich kostet — die Frage, die du stellen solltest, bevor du eines dieser vier übernimmst.

Dieser Kurs implementiert sie nicht neu. Alle vier haben Referenzimplementierungen ihrer eigenen Autoren in Python, und ihr Wert liegt darin, Quelle zu sein statt Übersetzung: ysymyth/ReAct, noahshinn/reflexion, princeton-nlp/tree-of-thought-llm und AGI-Edgerunners/Plan-and-Solve-Prompting. Lies die prompts in diesen Repositories; die prompts sind die Papers.

Jetzt multi-agent im eigentlichen Sinn, wo der größte Teil der Verwirrung lebt. Es gibt zwei Wege, wie ein agent einen anderen einbezieht; sie sind keine Varianten, und der Unterschied ist, wer danach das Sagen hat.

Agent as a tool. Der Parent ruft ihn auf, bekommt eine Antwort und macht weiter. Es ist die Tool-Schnittstelle aus Kapitel 18 mit einem ganzen agent dahinter, und der Parent verliert nie die Kontrolle. Das macht der Orchestrator oben.

Handoff. Der Parent überträgt die Konversation und bekommt sie nicht zurück. OpenAIs Guide ist die klarste veröffentlichte Formulierung: Handoffs sind „eine einseitige Übergabe, die einem agent erlaubt, an einen anderen agent zu delegieren ... Wenn ein agent eine handoff function aufruft, starten wir sofort die Ausführung auf dem neuen agent, an den übergeben wurde, und übertragen zugleich den neuesten conversation state.“⁸

Eine Vokabelwarnung, weil Menschen hier ständig stolpern: „handoff“ ist das Wort eines SDK, kein Standard. Es ist Terminologie aus dem OpenAI Agents SDK und diesem Guide, der die zwei Arrangements außerdem „manager“ und „decentralized“ nennt und anmerkt, dass im Manager-Muster „Kanten tool calls repräsentieren, während Kanten im dezentralisierten Muster handoffs repräsentieren“.⁸ Es gibt einen offenen Standard in diesem Raum — A2A, in Version 1.0.0, unter Copyright der Linux Foundation, mit versionierter Release-Historie und dokumentierter Liste von Breaking Changes; sein erklärtes Prinzip ist opaque execution: agents „arbeiten auf Basis deklarierter Fähigkeiten und ausgetauschter Informationen zusammen, ohne ihre internen Gedanken, Pläne oder Tool-Implementierungen teilen zu müssen“.⁹ Das ist kein handoff, und der Vergleich gehört in Kapitel 26. Wichtig hier ist: Eines der beiden Wörter ist die API einer Library, das andere eine Spezifikation mit Governance.

Die Unterscheidung ist eine Datenstruktur, kein Diagramm:

export type EdgeKind = "tool" | "handoff";
export interface AgentEdge { from: string; to: string; kind: EdgeKind }
export interface AgentGraph { root: string; agents: Record<string, AgentSpec>; edges: AgentEdge[] }

/** One agent may not be both a tool of X and a handoff target of X. */
export function conflicts(g: AgentGraph): AgentEdge[] {
  const seen = new Map<string, EdgeKind>();
  const bad: AgentEdge[] = [];
  for (const e of g.edges) {
    const key = `${e.from}->${e.to}`;
    const other = seen.get(key);
    if (other && other !== e.kind) bad.push(e);                            
    else seen.set(key, e.kind);
  }
  return bad;
}

/** Every agent reachable from the root, and at what depth. */
export function reachable(g: AgentGraph): Map<string, number> {
  const depth = new Map([[g.root, 0]]);
  const queue = [g.root];
  while (queue.length) {
    const id = queue.shift()!;
    for (const e of g.edges.filter((x) => x.from === id)) {
      if (depth.has(e.to)) continue;
      depth.set(e.to, depth.get(id)! + 1);
      queue.push(e.to);
    }
  }
  return depth;
}

Zwanzig Zeilen, zwei Bugs, die du sonst in Produktion finden würdest. reachable findet den agent, den niemand erreichen kann — konfiguriert, bezahlt, nie aufgerufen. conflicts verweigert die Kante, die beides zugleich ist; das klingt pedantisch, bis du es laut liest: Der Parent behält zugleich die Kontrolle und gibt sie ab. Auf einem Fünf-agent-System mit einem Orphan und einer Doppelkante ausgeführt:

reachable: lead@0 billing@1 tax@1 dunning@1
orphans:   ghost
conflicts: lead->tax

Jetzt die Messung, für die dieser Abschnitt existiert, und die einzige in diesem Kapitel, die gegen ein echtes Modell statt ein geskriptetes läuft.

Ein Kunde nennt in seiner ersten Nachricht eine Einschränkung — unser Konto ist in Portugal registriert, nicht in Spanien; alles Steuerliche muss Portugal verwenden — chattet über etwas anderes und stellt dann eine Frage, die Billing beantworten muss. Der Fall wird übertragen. Vierundzwanzig Versuche, jedes Mal ein anderes Land und Unternehmen, vier Transfer-Payloads, und der empfangende agent bekommt danach eine Frage: In welchem Land ist das Konto dieses Kunden registriert?

Die dritte Zeile ist eine Kontrolle und verhält sich auch so: Der Fakt ist nicht da, also kann er nicht erinnert werden. Die anderen drei sind der Befund.

Das vollständige Transcript hat 173 tokens und funktioniert in 83 % der Fälle; seine vier Fehler sind Thema von Kapitel 24, nicht von diesem. Der typisierte Datensatz hat 69 tokens — sieben mehr als die Zusammenfassung — und funktioniert jedes Mal, weil die Einschränkung in einem benannten Feld sitzt statt in einem Satz.

Und die Zusammenfassung ist die Zeile, auf die man starren sollte. Sie scheiterte 24 von 24 Mal, und der Grund ist nicht, dass der Leser sie übersehen hätte. Die Einschränkung erschien überhaupt nur in 1 der 24 Zusammenfassungen. Der empfangende agent war nicht nachlässig; ihm wurde ein Text gereicht, der die Antwort nicht enthielt. Eine Zusammenfassung ist eine Verdichtung, die du nicht geschrieben hast, erzeugt von einem Modell, dessen Fenster du nicht sehen kannst, optimiert darauf, wie eine Zusammenfassung zu lesen — und „der Kunde sagt, unsere Datensätze hätten das falsche Land“ ist genau die Art Nebensatz, die ein Zusammenfasser als prozedurales Rauschen fallen lässt.

Eine ehrliche Grenze dieser Zahl: Der Zusammenfasser ist ein Modell mit einer halben Milliarde Parametern, und ein größeres würde mehr behalten. Was mit Größe nicht besser wird, ist die Form des Risikos — der sendende agent entscheidet pro handoff, pro Formulierung, unsichtbar, welche Fakten überleben. Der typisierte Datensatz hängt überhaupt nicht von diesem Urteil ab, deshalb gewinnt er konstruktionsbedingt und nicht durch Intelligenz. Alles, was einen Transfer überleben muss, sollte ein Feld sein, kein Satz.

Dieselbe Logik gilt in die andere Richtung, für die Agent-as-tool-Topologie, und die frühere Tabelle hat sie bereits bepreist: Was von einem Worker zurückkommt, ist ebenfalls eine Zusammenfassung, und 8,3 % mehr zu zahlen, um die Belege mitzubekommen, ist dieselbe Lösung von der Seite des Parent aus gesehen.

Drei Schlussfakten, alle aus den Tabellen oben.

Ein multi-agent system multipliziert Aufrufe, und Aufrufe sind quadratisch im Kontext. Der Orchestrator machte 12 Modellaufrufe, wo ein agent 5 machte, und jeder trägt sein eigenes wachsendes Transcript — 3.628 input tokens gegenüber 2.697, eine Lücke, die mit der Aufgabenlänge wächst.

Jede Grenze ist ein verlustbehafteter Kanal. Zwei agents bedeuten eine Zusammenfassung. Vier agents in einer Kette bedeuten drei, zusammengesetzt, jede geschrieben von einem Modell, das auf etwas anderes optimiert als auf deine Entscheidung.

Der einzelne agent fand etwas, wonach niemand gefragt hatte. Die Abweichung bei der Bestellnummer tauchte auf, weil ein Fenster Rechnung und Bestellung zugleich hielt. Arbeit auf Spezialisten aufzuteilen, teilt auch die Fähigkeit auf, zu bemerken, dass zwei Fakten einander widersprechen.

Nichts davon spricht gegen die veröffentlichten multi-agent Frameworks, die man als Primärquellen lesen sollte statt über Tutorials.¹⁰ Es spricht dafür, dass der zweite agent seinen Platz verdienen muss.

Also ein Test statt einer Präferenz. Füge einen zweiten agent hinzu, wenn mindestens eines davon wahr ist: Die Teilaufgabe braucht ein sauberes Fenster, das der Parent nicht erben darf (Kapitel 24); die Teilaufgaben sind wirklich unabhängig und die Wanduhrzeit zählt — das sind die 1,8× oben; die Teilaufgabe braucht andere Berechtigungen oder ein anderes Modell, was Kapitel 30 in ein Sicherheitsargument verwandelt; oder die Teilaufgabe gehört jemand anderem, wo ein echtes Protokoll relevant wird. Wenn die Antwort lautet „damit jeder agent einen klareren prompt hat“, gib dem einen agent einen klareren prompt. Das ist kostenlos.

Du kannst jetzt die fünf Muster benennen, sie bei einer Aufgabe gegeneinander bepreisen, einen Orchestrator von einem Sectioner und einen tool call von einem handoff unterscheiden, und einen einzelnen agent mit einer Tabelle verteidigen statt mit einer Präferenz.

Alle Arrangements hier teilten eine Bequemlichkeit, die den Kontakt mit der Realität nicht überlebt: Alle Tools gehörten uns. Rechnung, Bestellung, Steuertabelle, die Worker hinter dem Orchestrator — dasselbe Repository, derselbe deploy, dieselben Typen, dieselben Menschen.

Jetzt setz eines davon auf die andere Seite einer Unternehmensgrenze. Die Steuertabelle gehört einem Buchhaltungsanbieter, der Bestelldatensatz einem Lagersystem, und keines von beiden hat deine Tool-Schnittstelle gelesen. Du brauchst einen Weg, damit ein Modell, das du nicht geschrieben hast, eine Fähigkeit, die jemand anderes betreibt, entdecken, beschreiben und aufrufen kann — mit Authentifizierung (das ist die Hälfte von Kapitel 27), Versionierung und der Garantie, dass ein Server nicht den Rest deiner Konversation lesen kann. Das ist ein Protokollproblem, es hat eine Spezifikation mit normativem Schema, und fast alles, was dazu indexiert ist, beschreibt eine Revision, die nicht mehr existiert.

Kapitel 26 liest diese Spezifikation, statt sie zusammenzufassen, und beginnt damit, JSON-RPC von Hand in ein Terminal zu tippen.

Jede Kosten- und token-Zählung oben stammt vom geskripteten Provider aus dem zweiten Abschnitt, auf Node 22 über ein Loopback-Interface, gezählt mit dem o200k_base encoding und bepreist zu den Raten, die Kapitel 16 am 6. September 2026 gelesen hat — $2.00 pro Million input tokens und $12.00 pro Million output. Wanduhrzeiten stammen aus denselben Läufen mit der Latenz des Providers auf 400 ms pro Aufruf und Tools auf 50 ms gesetzt; sie messen also das Arrangement statt irgendeinen Provider. Die zwei Messungen mit echtem Modell — die handoff-Tabelle und die Voting-und-Judging-Tabelle — verwendeten Qwen/Qwen2.5-0.5B-Instruct in float32 auf der CPU hinter einem Endpoint gleicher Form, greedy außer dort, wo eine Temperatur angegeben ist, mit Intervallen nach Wilsons Methode aus Kapitel 4. Keine Anfrage in diesem Kapitel ging an einen bezahlten Endpoint, und keine Zahl darin wurde geschätzt.