Orchestrace multi-agentů: pět vzorců a kdy jeden vítězí

Portugalská společnost píše kvůli faktuře FT-2026-0918. E-mail říká, že DPH vypadá špatně, a přikládá fakturu: základ EUR 248.00, DPH účtovaná sazbou 21 %, EUR 52.08, celkem EUR 300.08.

Fakta potřebná k odpovědi žijí na třech místech a jen jedno z nich je v e-mailu:

Dejte ty tři věci dohromady a faktura je špatně: měl se použít reverse charge, DPH měla být nulová, dluží se dobropis na EUR 52.08. Podívejte se jen na fakturu a aritmeticky je dokonalá — 248.00 plus 52.08 je 300.08 — a řeknete to.

E-mail skutečně uvádí „jsme portugalská společnost“. To je tvrzení, ne záznam, a žádný fakturační systém nevystaví dobropis na základě tvrzení. Past není trik: je to běžný tvar obchodní práce, kde rozhodnutí potřebuje fakt, který nikoho nenapadlo načíst.

Všechno výše běží proti skriptovanému providerovi ve stylu toho z kapitoly 23, přesně s jedním pravidlem:

Odpověď smí použít jen fakt, který je v jejím prompt.

„Model“ požádá o každý nástroj, který má, jednou, v katalogovém pořadí, a potom použije pevné pravidlo na text, který vidí. Nic není skriptováno pro konkrétní uspořádání, takže rozdíly v úvodní tabulce nejsou tvrzení o inteligenci modelu: jsou to změřené rozdíly v information routing. Skutečný model navrch přidá vlastní selhání; tato neodstraní.

Pět názvů níže je od Anthropic, z Building effective agents, kde se tato slovní zásoba ustálila.¹ Žádná z pěti myšlenek není nová a říct, který dům co pojmenoval — a která myšlenka je starší — je polovina hodnoty toho, že je znáte.

/* 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 };
}

To je celá sada nástrojů: pět funkcí, žádný framework a ta paralelní je jediný řádek — což je důvod, proč ji vypsat místo kreslení. Teď postupně ke každé, s jejím původem, cenou a případem, kdy je špatně.

Prompt chaining „decomposes a task into a sequence of steps, where each LLM call processes the output of the previous one“.¹ Myšlenka předchází jazykovým modelům: je to pipeline, s typickým obchodem pipeline — jasnost výměnou za control flow pevně daný ještě před příchodem dat.

Čtyři kroky pro náš úkol: extrahovat pole faktury, zkontrolovat aritmetiku, rozhodnout, co se dluží, napsat odpověď. Tady selže dvěma různými způsoby, což naučí víc než jedno selhání.

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

Relay chain stál $0.001940 a ztratil pole faktury mezi kroky dva a tři, protože třetí krok dostal větu o aritmetice a nic dalšího. Vytvořil zadržovací zprávu: zbytečnou a viditelně zbytečnou.

Akumulační chain — řádek v úvodní tabulce — stál $0.003780, tedy o 95 % víc za čtyři identická volání, protože každý krok teď nese všechno před ním. Vytvořil nebezpečný výstup. Plynulý, citující svou aritmetiku, správný u každého čísla, které zmiňuje, a říkající zákazníkovi, že se nic nedluží, když se dluží EUR 52.08.

Rozdíl mezi těmi dvěma je jeden ternární operátor. Chain, který nese méně, produkuje odpovědi, které jsou zjevně neúplné; chain, který nese všechno, produkuje odpovědi, které jsou sebejistě špatně — a odesílá se jen druhý druh.

Ani jedno není skutečné selhání. Skutečné selhání je, že pipeline rozhodla ještě před čtením čehokoli, že tento úkol jsou čtyři kroky nad obsahem e-mailu. Nikde v té struktuře není místo říct „registrační země v tomto e-mailu není; běž ji získat“. Chaining je správně, když je dekompozice známá předem a stabilní. Tady to byl odhad a odhad odešel zákazníkovi.

Routing „classifies an input and directs it to a specialized followup task“.¹ Název je nový; mechanismus je dispatcher, starší než skoro všechno ostatní v této knize. Nové je, že classifier může být model — a právě tím selhává způsoby, jakými switch nikdy neselhával.

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

Dvě věci k tomu poslednímu argumentu. Není to error handling; je to vzorec. Model-based router má režim selhání, který dispatcher nemá: může vrátit label, který neexistuje, vypršet, nebo — drahá varianta — vrátit věrohodný špatný label bez signálu, že je špatný. Všechny tři musí někam dopadnout a to „někam“ nemůže být další volání modelu, protože už jste ve větvi, kde modelová volání selhala.

Druhá věc je, že vlastní prompt routeru není zdarma. Aby router vybral model, potřebuje katalog modelů, ze kterého může vybírat, a každá položka v něm je vstup, za který router platí dřív, než přečte otázku uživatele. Při vstupní sazbě, se kterou tento kurz počítá ceny, stojí katalog o zhruba 3 800 tokenech už tolik jako celý běh agenta s pěti voláními v úvodní tabulce. V praxi běží routovací volání na levném modelu, a právě proto se routing vyplatí; ale tu aritmetiku stojí za to udělat tímto směrem, místo abychom ji předpokládali. Routing je špatně přesně tehdy, když je routovaný úkol levnější než rozhodnutí o routingu.

Anthropic tuto položku dělí na dvě: sectioning — „breaking a task into independent subtasks run in parallel“ — a voting — „running the same task multiple times to get diverse outputs“.¹ Sdílejí diagram a nesdílejí skoro nic dalšího.

Sectioning je levné vítězství a je to řádek z patterns.ts: tři specialisté — billing, tax, policy — každý se svým oknem a nástroji, nad stejným e-mailem, s jedním syntetizačním voláním na konci. Identická práce, seřazená dvěma způsoby:

Stejné token za tokenem, 1,8× rychlejší. Proto si tento vzorec zaslouží vlastní jméno: je jediný z pěti, který něco zlepší, aniž by cokoli stál. Háček je, že sekce musí být skutečně nezávislé — dejte sekci B fakt, který produkuje sekce A, a Promise.all spustí obě proti stavu, který ještě neexistuje. Loop for tu chybu skryl; jednořádková verze ji odhalí.

Voting je jiné zvíře ve stejném obrázku. Spustit stejnou otázku kkrát a vzít většinu je self-consistency, publikovaná Wangem a kol. v březnu 2022 jako decoding strategy, skoro tři roky předtím, než ji kdokoli nazval orchestration pattern. Abstrakt přesně popisuje mechanismus — „first samples a diverse set of reasoning paths instead of only taking the greedy one, and then selects the most consistent answer by marginalizing out the sampled reasoning paths“ — i zisk: +17,9 bodu na GSM8K.²

Z toho plynou dvě věci, které obrázek skrývá. Zaprvé, voting vyžaduje sampling z kapitoly 17: při temperature nula je všech k vzorků stejný vzorek a většina je jedna odpověď zaplacená kkrát. Zadruhé funguje jen tam, kde má většina smysl — u fakturační odpovědi výše není co počítat, protože pět návrhů je pět různých vět. Voting je pro úlohy s krátkou, porovnatelnou odpovědí, což přesně odpovídá Wangovým benchmarkům a skoro ničemu, co dělá customer-facing agent.

Změřeno zde na 20 tříkrokových slovních úlohách, jejichž odpovědi se počítají, ne posuzují, s lokálním modelem z kapitoly 23 uvažujícím krok za krokem:

Pětkrát více volání, pětkrát více tokens, přesně pětkrát vyšší účet a ani jedna správná odpověď navíc. Voting je sázka, ne zlepšení, a tento běh ji prohrál.

Dvě výhrady, než to někdo ocituje jako vyvrácení Wanga. Dvacet pokusů nedokáže rozlišit 45 % od 60 % — interval je široký jako tvrzení, což je disciplína kapitoly 4 obrácená na můj vlastní výsledek. A publikované zisky pocházejí z modelů o řády větších, kde jsou diverse reasoning paths, přes které voting marginalizuje, skutečně rozmanité. Nepřenáší se číslo: přenáší se to, že násobitel je přesný a známý předem, zatímco zisk ani jedno.

V orchestrator-workers workflow „a central LLM dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results“ a rozdíl proti sectioning je, že „subtasks aren't pre-defined, but determined by the orchestrator“.¹ Původ tady vůbec není v jazykových modelech: je to master-worker a verze, kde workeři zapisují zjištění do sdíleného prostoru, který čte controller, je blackboard architecture z výzkumu porozumění řeči v 70. letech. Nové v roce 2026 je, že controller je model, a dekompozice se proto může rozhodovat pro každý input zvlášť — flexibilita i cena v jedné větě.

Stálo to 12 volání modelu proti 5 u jediného agent a došlo to ke stejnému verdiktu. Pak to udělalo něco, co stojí za bližší pohled:

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

Obojí je správně. Jen jedno ví proč. Tax worker měl ve svém vlastním okně fakturu, objednávku i daňovou tabulku, došel k závěru a také si všiml — nikdo se neptal — že číslo objednávky na faktuře neodpovídá objednávce. Pak vrátil shrnutí. Orchestrator může obě tvrzení zopakovat a nemůže zkontrolovat ani jedno, protože důkazy zůstaly v okně, které nikdy neviděl. To je závěrečná otázka kapitoly 24, zodpovězená: rodič se může podívat na cokoli, co se dítě rozhodlo zapsat.

Oprava je flag a má cenu:

O dvanáct procent víc input tokens, o 8,3 % víc peněz a fráze source=worker_unverified z odpovědi zmizí. To je trade v každém multi-agent systému a skoro nikdy se neříká nahlas: čisté okno dítěte má hodnotu, rodičova schopnost ho auditovat má hodnotu a obojí nemůžete mít zdarma.

Kdy je tedy orchestrator-workers špatně? Tady, na tomto úkolu. Koupilo správnou odpověď, ke které došel i jeden agent se stejnými čtyřmi nástroji, za 1,66× ceny a 2,3× wall clock, a učinilo tu odpověď hůře obhajitelnou. Vlastní doporučení Anthropic říká totéž ještě před vzorci: najít „the simplest solution possible, and only increasing complexity when needed“, protože „agentic systems often trade latency and cost for better task performance“.¹ Tabulky výše jsou tatáž věta s čísly pod ní.

Jedno volání generuje, druhé vyhodnocuje a loop se opakuje, dokud evaluation neprojde.¹ Publikovaní předchůdci jsou Self-Refine — tentýž model jako „generator, refiner, and feedback provider“, hlásící asi 20 bodů absolutního zlepšení v průměru přes sedm úloh³ — a Reflexion, který ukládá kritiku do episodic buffer napříč pokusy a hlásí 91 % pass@1 na HumanEval tam, kde baseline dosáhl 80 %.⁴

Cost model je nejjednodušší z pěti: dvě volání na kolo a počet kol není váš. Tři kola refinement na úloze, která zabrala jedno volání, jsou šest volání, takže spodní hranice vzorce je 6× a strop je jakýkoli cap, který nastavíte — což z budget exit z kapitoly 23 dělá nutnost, ne úhlednost.

Strop je jemnější a dá se měřit. Na stejných 20 úlohách lokální model odpověděl správně na 9. Potom mu byla každá z těch odpovědí ukázána a byl dotázán, zda je správná — aniž by mu bylo řečeno, že je jeho vlastní, což odstraňuje confound lichocení a nechává ten schopnostní:

Je to lepší soudce, než naznačuje nadpis sekce, a říct to je smysl měření místo tvrzení: nezablokoval nic správného a zachytil 8 z 11 chyb. Jako filtr si svá volání zaslouží.

Jako stopping rule, což je to, k čemu ho evaluator-optimiser loop ve skutečnosti používá, jsou ta tři schválení celý příběh: ukončí loop se špatnou odpovědí v ruce a žádný počet dalších kol se k nim nikdy nedostane. Refinement loop nemůže být správnější než jeho soudce. Kupování dalších kol kupuje pokusy o chyby, které soudce vidí, za plnou cenu, a vůbec nic proti těm, které nevidí.

Pravidlo tedy zní: evaluator si svá volání zaslouží jen tehdy, když má něco, co generator nemá. Compiler, test suite, schema validator, jiný model, člověka. Vlastní výsledky Self-Refine jsou měřené proti lidské preferenci a metrikám úloh, nikdy proti názoru modelu na sebe samého. Pokud je jedinou výhodou vašeho evaluator jiný prompt, platíte dvojnásob za souhlas. Kapitola 29 staví verzi se skutečnou výhodou: golden set s odpověďmi napsanými předem.

Pět výše jsou tvary pro váš kód. Pod nimi sedí druhá rodina, která se často uvádí vedle nich a neměla by: ReAct, Reflexion, plan-and-execute a tree of thoughts jsou reasoning loops a jejich cena je v requestech.

Kapitola 12 byla o reasoning uvnitř modelu, za které platíte output tokens v jednom volání. Tohle je druhý druh. Rozdíl je důležitý, když dorazí účet: delší chain of thought zdraží jedno volání a reasoning loop udělá z jednoho úkolu mnoho volání, z nichž každé znovu posílá všechno před ním — kvadratika, kterou kapitola 23 změřila ve své tabulce runaway.

Článek tree-of-thoughts publikuje vlastní cost table, což je vzácnější, než by mělo být. Na Game of 24 s GPT-4: input/output prompting best-of-100 vyřešil 33 % za $0.13 na případ, chain of thought best-of-100 vyřešil 49 % za $0.47 a tree of thoughts vyřešil 74 % za $0.74, přičemž autoři poznamenávají, že „could require 5-100 times more generated tokens than CoT“.⁷

Skoro šestkrát vyšší cena než u levné metody za trochu víc než dvojnásobnou úspěšnost. Zda je to výhodná koupě, závisí na tom, co vás stojí neúspěšný případ — otázka, kterou je třeba položit před přijetím kterékoli z těchto čtyř.

Tento kurz je znovu neimplementuje. Všechny čtyři mají referenční implementace od vlastních autorů, v Pythonu, a jejich hodnota je v tom, že jsou zdroj, ne překlad: ysymyth/ReAct, noahshinn/reflexion, princeton-nlp/tree-of-thought-llm a AGI-Edgerunners/Plan-and-Solve-Prompting. Čtěte prompty v těch repozitářích; prompty jsou články.

Teď skutečné multi-agent, kde žije většina zmatku. Existují dva způsoby, jak může jeden agent zapojit jiného, nejsou to varianty a rozdíl je v tom, kdo potom velí.

Agent jako nástroj. Rodič ho zavolá, dostane odpověď a pokračuje. Je to rozhraní nástroje z kapitoly 18 s celým agentem za ním a rodič nikdy neztratí kontrolu. To dělá orchestrator výše.

Handoff. Rodič předá konverzaci a nedostane ji zpět. Průvodce OpenAI to říká nejjasněji: handoffs jsou „a one way transfer that allow an agent to delegate to another agent... If an agent calls a handoff function, we immediately start execution on that new agent that was handed off to while also transferring the latest conversation state.“⁸

Upozornění ke slovní zásobě, protože to lidi neustále plete: „handoff“ je slovo jednoho SDK, ne standard. Je to terminologie z OpenAI Agents SDK a tohoto průvodce, který také pojmenovává dvě uspořádání „manager“ a „decentralized“ a poznamenává, že v manager pattern „edges represent tool calls whereas in the decentralized pattern, edges represent handoffs“.⁸ V tomto prostoru existuje otevřený standard — A2A, ve verzi 1.0.0, pod copyrightem Linux Foundation, s verzovanou release history a dokumentovaným seznamem breaking changes, jehož deklarovaný princip je opaque execution: agents „collaborate based on declared capabilities and exchanged information, without needing to share their internal thoughts, plans, or tool implementations“.⁹ To není handoff a srovnání patří do kapitoly 26. Tady je důležité, že jedno z těch dvou slov je API knihovny a druhé je specifikace s governance.

Rozlišení je datová struktura, ne diagram:

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

Dvacet řádků, dvě chyby, které byste jinak našli v produkci. reachable najde agent, ke kterému se nikdo nedostane — nakonfigurovaný, zaplacený, nikdy nevolaný. conflicts odmítne hranu, která je obojí najednou, což zní pedantsky, dokud si to nepřečtete nahlas: rodič si zároveň kontrolu nechává i ji odevzdává. Spusťte to na pět agent systému s jedním sirotkem a jednou dvojitou hranou:

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

Teď měření, kvůli kterému tato sekce existuje, a jediné v kapitole provedené proti skutečnému modelu místo skriptovaného.

Zákazník uvede omezení v první zprávě — náš účet je registrován v Portugalsku, ne ve Španělsku; všechno daňové musí používat Portugalsko — povídá si o něčem jiném a potom položí otázku, na kterou musí odpovědět billing. Případ je předán. Dvacet čtyři pokusů, pokaždé jiná země a společnost, čtyři transfer payloads, a přijímající agent potom dostane jednu otázku: ve které zemi je registrován účet tohoto zákazníka?

Třetí řádek je kontrola a chová se jako kontrola: fakt tam není, takže si ho nelze vybavit. Ostatní tři jsou zjištění.

Úplný přepis má 173 tokens a funguje v 83 % případů, přičemž čtyři selhání jsou téma kapitoly 24, ne této. Typovaný záznam má 69 tokens — o sedm víc než shrnutí — a funguje pokaždé, protože omezení sedí v pojmenovaném poli místo ve větě.

A shrnutí je řádek, na který je třeba zírat. Selhalo 24krát z 24 a důvod není, že by ho čtenář přehlédl. Omezení se vůbec objevilo jen v 1 z 24 shrnutí. Přijímající agent nebyl nedbalý; dostal text, který neobsahoval odpověď. Shrnutí je kompakce, kterou jste nenapsali, vyprodukovaná modelem, jehož okno nevidíte, optimalizovaná tak, aby se četla jako shrnutí — a „zákazník říká, že naše záznamy mají špatnou zemi“ je přesně typ klauzule, kterou summarizer zahodí jako procedurální šum.

Poctivý limit toho čísla: summarizer je model s půl miliardou parametrů a větší by udržel víc. Co se velikostí nezlepší, je tvar rizika — odesílající agent rozhoduje při každém handoff, pro každé phrasing, nepozorovatelně, která fakta přežijí. Typovaný záznam na tomto úsudku vůbec nezávisí, a proto vítězí konstrukcí, ne inteligencí. Cokoli, co musí přežít transfer, má být pole, ne věta.

Stejné uvažování platí i opačným směrem, pro topologii agent-as-tool, a dřívější tabulka ji už nacenila: to, co se vrací od workera, je také shrnutí, a zaplatit o 8,3 % víc za přijetí důkazů spolu s ním je stejná oprava viděná z rodičovy strany.

Tři závěrečná fakta, všechna z tabulek výše.

Multi-agent systém násobí volání a volání jsou kvadratická v context. Orchestrator udělal 12 volání modelu tam, kde jeden agent udělal 5, a každé nese vlastní rostoucí přepis — 3,628 input tokens proti 2,697, mezera, která se s délkou úkolu rozšiřuje.

Každá hranice je ztrátový kanál. Dva agents znamenají jedno shrnutí. Čtyři agents v chain znamenají tři, složená, každé napsané modelem optimalizujícím něco jiného než vaše rozhodnutí.

Jediný agent našel něco, na co se nikdo neptal. Nesoulad čísla objednávky se objevil, protože jedno okno drželo fakturu a objednávku najednou. Rozdělení práce mezi specialisty také rozděluje schopnost všimnout si, že si dvě fakta odporují.

Nic z toho neargumentuje proti publikovaným multi-agent frameworkům, které stojí za čtení jako primární zdroje, ne přes tutoriály.¹⁰ Argumentuje to pro to, aby si druhý agent zasloužil své místo.

Takže test, ne preference. Přidejte druhý agent, když platí alespoň jedno z toho: sub-task potřebuje čisté okno, které rodič nesmí zdědit (kapitola 24); sub-tasks jsou skutečně nezávislé a wall clock matters, což je těch 1,8× výše; sub-task potřebuje jiná oprávnění nebo jiný model, z čehož kapitola 30 dělá bezpečnostní argument; nebo sub-task vlastní někdo jiný, což je místo, kde začíná záležet na skutečném protokolu. Pokud odpověď zní „aby měl každý agent jasnější prompt“, dejte jasnější prompt tomu jednomu agent. Je to zdarma.

Teď umíte pojmenovat pět vzorců, nacenit je proti sobě na jednom úkolu, odlišit orchestrator od sectioner a tool call od handoff a obhájit jediný agent tabulkou místo preference.

Každé uspořádání tady sdílelo jednu výhodu, která nepřežije kontakt s čímkoli skutečným: všechny nástroje patřily nám. Faktura, objednávka, daňová tabulka, workeři za orchestratorem — stejný repozitář, stejný deploy, stejné typy, stejní lidé.

Teď jeden z nich dejte na druhou stranu hranice firmy. Daňová tabulka patří účetnímu vendorovi, záznam objednávky skladovému systému a ani jeden nečetl vaše rozhraní Tool. Potřebujete způsob, jak model, který jste nenapsali, objeví, popíše a zavolá capability, kterou provozuje někdo jiný — s authentication (což je polovina kapitoly 27), versioning a zárukou, že server nemůže číst zbytek vaší konverzace. To je problém protokolu, má specifikaci s normative schema a skoro všechno, co je o něm indexované, popisuje revizi, která už neexistuje.

Kapitola 26 čte tu specifikaci místo toho, aby ji shrnovala, a začíná ručním psaním JSON-RPC do terminálu.

Každá cena a každý token count výše pocházely ze skriptovaného provideru popsaného ve druhé sekci, na Node 22 přes loopback interface, počítáno encoding o200k_base a naceněno sazbami, které kapitola 16 četla 6. září 2026 — $2.00 za milion input tokens a $12.00 za milion output. Wall-clock údaje jsou ze stejných běhů s latencí provideru nastavenou na 400 ms na volání a nástroji na 50 ms, takže měří uspořádání, ne žádného providera. Dvě měření se skutečným modelem — tabulka handoff a tabulka voting-and-judging — použila Qwen/Qwen2.5-0.5B-Instruct ve float32 na CPU za endpointem stejného tvaru, greedy kromě míst, kde je uvedena temperature, s intervaly vypočtenými Wilsonovou metodou z kapitoly 4. Žádný request v této kapitole nešel na placený endpoint a žádné číslo v ní nebylo odhadnuto.