Multi-Agent-orkestrering: Fem mønstre, og hvornår ét vinder

En portugisisk virksomhed skriver om faktura FT-2026-0918. Mailen siger, at momsen ser forkert ud, og vedhæfter fakturaen: netto EUR 248,00, moms opkrævet med 21 %, EUR 52,08, total EUR 300,08.

De fakta, der skal til for at svare, findes tre steder, og kun ét af dem er i mailen:

Sæt de tre sammen, og fakturaen er forkert: reverse charge gælder, momsen burde have været nul, og der skyldes en kreditnota på EUR 52,08. Kig kun på fakturaen, og den er aritmetisk perfekt — 248,00 plus 52,08 er 300,08 — og det vil du sige.

Mailen siger godt nok "vi er en portugisisk virksomhed". Det er en påstand, ikke en registrering, og intet faktureringssystem udsteder en kreditnota på en påstand. Fælden er ikke et trick: Det er den almindelige form for forretningsarbejde, hvor beslutningen kræver et faktum, ingen tænkte på at hente.

Alt ovenfor kører mod en scripted provider i stil med kapitel 23's, med præcis én regel:

Et svar må kun bruge et faktum, der findes i dets prompt.

"Modellen" beder om hvert værktøj, den har, én gang, i katalogrækkefølge, og anvender derefter en fast regel på den tekst, den kan se. Intet er scriptet per opsætning, så forskellene i åbningstabellen er ikke påstande om modelintelligens: De er informations-routing, målt. En rigtig model lægger sine egne fejl ovenpå; den fjerner ikke disse.

De fem navne nedenfor er Anthropics, fra Building effective agents, hvor dette ordforråd fandt sit leje.¹ Ingen af de fem idéer er ny, og at sige, hvem der navngav hvad — og hvilken idé der er ældre — er halvdelen af værdien ved at kende dem.

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

Det er hele værktøjskassen: fem funktioner, intet framework, og den parallelle er én enkelt linje — hvilket er pointen med at skrive den ud i stedet for at tegne den. Nu tager vi dem én ad gangen, med deres ophav, deres pris og det tilfælde, hvor de tager fejl.

Prompt chaining "decomposes a task into a sequence of steps, where each LLM call processes the output of the previous one".¹ Idéen er ældre end sprogmodeller: Det er en pipeline, med pipelinens byttehandel — klarhed mod et control flow fastlagt, før dataene ankommer.

Fire trin til vores opgave: udtræk fakturafelterne, tjek aritmetikken, beslut hvad der skyldes, skriv svaret. Her fejler den på to forskellige måder, hvilket lærer mere end at fejle én gang.

--- 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-kæden kostede $0.001940 og mistede fakturafelterne mellem trin to og tre, fordi trin tre fik overdraget en sætning om aritmetik og intet andet. Den producerede en afventende besked: ubrugelig, og tydeligt ubrugelig.

Den akkumulerende kæde — rækken i åbningstabellen — kostede $0.003780, hvilket er 95 % mere for fire identiske kald, fordi hvert trin nu bærer alt før sig. Den producerede det farlige output. Flydende, med henvisning til sin aritmetik, korrekt på hvert tal den nævner, og fortæller en kunde, at der ikke skyldes noget, når der skyldes EUR 52,08.

Forskellen mellem de to er én ternary. En kæde, der bærer mindre, producerer svar, der åbenlyst er ufuldstændige; en kæde, der bærer alt, producerer svar, der er selvsikkert forkerte — og kun den anden slags bliver sendt.

Ingen af delene er den egentlige fejl. Den egentlige fejl er, at pipelinen besluttede, før den læste noget som helst, at denne opgave er fire trin over indholdet af en mail. Ingen steder i den struktur er der et sted til at sige "registreringslandet er ikke i denne mail; hent det". Chaining er rigtigt, når nedbrydningen er kendt på forhånd og stabil. Her var det et gæt, og gættet blev sendt.

Routing "classifies an input and directs it to a specialized followup task".¹ Navnet er nyt; mekanismen er dispatcheren, ældre end næsten alt andet i denne bog. Det nye er, at klassifikatoren kan være en model — og det er det, der får den til at fejle på måder, en switch aldrig gjorde.

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

To ting om det sidste argument. Det er ikke fejlhåndtering; det er mønstret. En modelbaseret router har en fejltilstand, en dispatcher ikke har: Den kan returnere en label, der ikke findes, timeoute, eller — den dyre — returnere en plausibel forkert label uden noget signal om, at den er forkert. Alle tre skal lande et sted, og dette sted kan ikke være endnu et modelkald, fordi du allerede er i den gren, hvor modelkald fejlede.

Den anden ting er, at routerens egen prompt ikke er gratis. For at vælge en model har en router brug for et katalog af modeller at vælge imellem, og hver post i det er input, som routeren betaler for, før den har læst brugerens spørgsmål. Ved den inputpris, dette kursus regner med, koster et katalog på omkring 3.800 tokens allerede lige så meget som hele agent-kørslen med fem kald i åbningstabellen. I praksis kører routing-kaldet på en billig model, hvilket er hele grunden til, at routing betaler sig; men aritmetikken er værd at lave den vej i stedet for at antage det. Routing er forkert præcis når den routede opgave er billigere end routing-beslutningen.

Anthropic deler denne i to: sectioning — "breaking a task into independent subtasks run in parallel" — og voting — "running the same task multiple times to get diverse outputs".¹ De deler en figur og næsten intet andet.

Sectioning er den billige gevinst, og det er linjen fra patterns.ts: tre specialister — fakturering, skat, policy — hver med sit eget vindue og sine egne værktøjer, over den samme mail, med ét syntesekald til sidst. Identisk arbejde, ordnet på to måder:

Samme token for token, 1,8 gange hurtigere. Det er derfor mønstret fortjener sit eget navn: Det er det eneste af de fem, der forbedrer noget uden at koste noget. Haken er, at sektionerne skal være reelt uafhængige — giv sektion B et faktum, sektion A producerer, og Promise.all kører dem begge mod en state, der endnu ikke findes. for-loopet skjulte den bug; one-lineren afslører den.

Voting er et andet dyr i samme billede. At køre det samme spørgsmål k gange og tage flertallet er self-consistency, publiceret af Wang et al. i marts 2022 som en decoding-strategi, næsten tre år før nogen kaldte det et orchestration pattern. Abstractet er præcist om mekanismen — "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" — og om gevinsten: +17,9 point på GSM8K.²

Der følger to ting, som billedet skjuler. For det første kræver voting samplingen fra kapitel 17: Ved temperatur nul er alle k samples det samme sample, og flertallet er ét svar betalt k gange. For det andet virker det kun, hvor et flertal giver mening — på fakturasvaret ovenfor er der intet at tælle, fordi fem udkast er fem forskellige sætninger. Voting er til opgaver med et kort, sammenligneligt svar, hvilket er præcis Wangs benchmarks og næsten intet, en kundevendt agent gør.

Målt her på 20 tekstopgaver i tre trin, hvis svar beregnes snarere end vurderes, med den lokale model fra kapitel 23, der ræsonnerer trin for trin:

Fem gange kald, fem gange tokens, præcis fem gange regningen, og ikke ét ekstra korrekt svar. Voting er et væddemål, ikke en forbedring, og denne kørsel tabte det.

To forbehold, før nogen citerer det som en tilbagevisning af Wang. Tyve forsøg kan ikke skelne 45 % fra 60 % — intervallet har samme bredde som påstanden, hvilket er kapitel 4's disciplin vendt mod mit eget resultat. Og de publicerede gevinster kommer fra modeller, der er størrelsesordener større, hvor de diverse reasoning paths, voting marginaliserer over, faktisk er diverse. Det, der overføres, er ikke tallet: Det er, at multiplikatoren er præcis og kendt på forhånd, mens gevinsten ikke er det.

I orchestrator-workers-workflowet "a central LLM dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results", og forskellen fra sectioning er, at "subtasks aren't pre-defined, but determined by the orchestrator".¹ Ophavet her kommer slet ikke fra sprogmodeller: Dette er master-worker, og den version, hvor workers skriver fund ind i et fælles rum, som en controller læser, er blackboard-arkitekturen fra forskning i taleforståelse i 1970'erne. Det nye i 2026 er, at controlleren er en model, og derfor kan nedbrydningen besluttes per input — hvilket er fleksibiliteten og prisen i én sætning.

Det kostede 12 modelkald mod den enkelte agents 5, og det nåede samme konklusion. Så gjorde det noget, der er værd at se nøje på:

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

Begge har ret. Kun én ved hvorfor. Skatte-workeren havde fakturaen, ordren og momstabellen i sit eget vindue, nåede konklusionen og bemærkede også — ingen spurgte — at indkøbsordrenummeret på fakturaen ikke matcher ordrens. Så returnerede den et resume. Orchestrator kan gentage begge udsagn og kontrollere ingen af dem, fordi evidensen blev i et vindue, den aldrig så. Det er kapitel 24's afsluttende spørgsmål, besvaret: parent kan se på det, child valgte at skrive ned.

Rettelsen er et flag, og den har en pris:

Tolv procent flere input tokens, 8,3 % flere penge, og frasen source=worker_unverified forsvinder fra svaret. Det er byttehandlen i ethvert multi-agent-system, og den siges næsten aldrig højt: Childs rene vindue er værd at have, parents mulighed for at auditere det er værd at betale for, og du kan ikke få begge dele gratis.

Så hvornår er orchestrator-workers forkert? Her, på denne opgave. Den købte et korrekt svar, som én agent med de samme fire værktøjer også nåede, for 1,66 gange prisen og 2,3 gange wall clock, og den gjorde svaret sværere at forsvare. Anthropics egen vejledning siger det samme, før mønstrene begynder: Find "the simplest solution possible, and only increasing complexity when needed", fordi "agentic systems often trade latency and cost for better task performance".¹ Tabellerne ovenfor er den sætning med tal under.

Ét kald genererer, et andet evaluerer, og loopet gentages, indtil evalueringen består.¹ De publicerede forfædre er Self-Refine — den samme model som "generator, refiner, and feedback provider", med rapporteret cirka 20 point absolut forbedring i gennemsnit over syv opgaver³ — og Reflexion, som gemmer kritikken i en episodisk buffer på tværs af forsøg og rapporterer 91 % pass@1 på HumanEval, hvor baseline nåede 80 %.⁴

Cost-modellen er den enkleste af de fem: to kald per runde, og antallet af runder er ikke dit. Tre runder refinement på en opgave, der tog ét kald, er seks kald, så mønstrets gulv er 6×, og dets loft er den cap, du sætter — hvilket gør budget-exit fra kapitel 23 obligatorisk snarere end pæn.

Loftet er mere subtilt, og det kan måles. På de samme 20 problemer svarede den lokale model 9 korrekt. Derefter fik den vist hvert af disse svar og blev spurgt, om det var rigtigt — uden at få at vide, at svaret var dens eget, hvilket fjerner smiger-confounden og efterlader capability-delen:

Det er en bedre dommer, end sektionstitlen antyder, og at sige det er pointen med at måle frem for at påstå: Den blokerede intet korrekt og fangede 8 af 11 fejl. Som filter er den sine kald værd.

Som stopping rule, hvilket er det, et evaluator-optimiser-loop faktisk bruger den til, er de tre godkendelser hele historien: De afslutter loopet med et forkert svar i hånden, og intet antal ekstra runder når nogensinde frem til dem. Et refinement-loop kan ikke blive mere korrekt end sin dommer. At købe flere runder køber forsøg på de fejl, dommeren kan se, til fuld pris, og slet ingenting mod dem, den ikke kan.

Derfor reglen: En evaluator fortjener kun sine kald, når den har noget, generatoren ikke har. En compiler, en testsuite, en schema-validator, en anden model, et menneske. Self-Refines egne resultater måles mod menneskelig præference og task metrics, aldrig mod modellens mening om sig selv. Hvis din evaluators eneste fordel er en anden prompt, betaler du dobbelt for enighed. Kapitel 29 bygger versionen med en reel fordel: et golden set med svarene skrevet ned på forhånd.

De fem ovenfor er former for din kode. Under dem ligger en anden familie, som ofte listes sammen med dem og ikke burde være det: ReAct, Reflexion, plan-and-execute og tree of thoughts er reasoning loops, og deres pris ligger i requests.

Kapitel 12 handlede om reasoning inde i modellen, som du betaler for i output tokens på ét kald. Dette er den anden slags. Forskellen betyder noget, når regningen kommer: En længere chain of thought gør ét kald dyrere, og et reasoning loop gør én opgave til mange kald, som hver især sender alt før sig igen — det kvadratiske, kapitel 23 målte i sin runaway-tabel.

Tree-of-thoughts-artiklen publicerer sin egen cost-tabel, hvilket er sjældnere, end det burde være. På Game of 24 med GPT-4: input/output prompting best-of-100 løste 33 % til $0.13 per case, chain of thought best-of-100 løste 49 % til $0.47, og tree of thoughts løste 74 % til $0.74, hvor forfatterne bemærker, at det "could require 5-100 times more generated tokens than CoT".⁷

Næsten seks gange den billige metodes pris for lidt mere end dobbelt succesrate. Om det er et kup, afhænger af hvad en mislykket case koster dig — spørgsmålet, du bør stille, før du adopterer nogen af disse fire.

Dette kursus genimplementerer dem ikke. Alle fire har referenceimplementeringer af deres egne forfattere, i Python, og deres værdi er at være kilden snarere end en oversættelse: ysymyth/ReAct, noahshinn/reflexion, princeton-nlp/tree-of-thought-llm og AGI-Edgerunners/Plan-and-Solve-Prompting. Læs prompts i de repositories; prompts er artiklerne.

Nu egentlig multi-agent, hvor det meste af forvirringen bor. Der er to måder, hvorpå én agent kan involvere en anden, de er ikke varianter, og forskellen er hvem der har kontrollen bagefter.

Agent som værktøj. Parent kalder den, får et svar og fortsætter. Det er kapitel 18's værktøjsgrænseflade med en hel agent bagved, og parent mister aldrig kontrollen. Det er det, orchestrator ovenfor gør.

Overdragelse. Parent overfører samtalen og får den ikke tilbage. OpenAIs guide er den klareste publicerede formulering: handoffs er "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."⁸

En ordforrådsadvarsel, fordi det her konstant spænder ben for folk: "handoff" er ét SDK's ord, ikke en standard. Det er terminologi fra OpenAI Agents SDK og den guide, som også kalder de to opsætninger "manager" og "decentralized" og bemærker, at i manager-mønstret "edges represent tool calls whereas in the decentralized pattern, edges represent handoffs".⁸ Der findes en åben standard på dette område — A2A, i version 1.0.0, under Linux Foundations copyright, med en versioneret release history og en dokumenteret liste over breaking changes, hvis erklærede princip er opaque execution: agents "collaborate based on declared capabilities and exchanged information, without needing to share their internal thoughts, plans, or tool implementations".⁹ Det er ikke en overdragelse, og sammenligningen hører hjemme i kapitel 26. Det vigtige her er, at det ene ord er et biblioteks API, og det andet er en specifikation med governance.

Skellet er en datastruktur, ikke en figur:

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

Tyve linjer, to bugs du ellers ville finde i produktion. reachable finder den agent, ingen kan komme til — konfigureret, betalt for, aldrig kaldt. conflicts afviser den edge, der er begge slags på én gang, hvilket lyder pedantisk, indtil du læser det højt: Parent både beholder kontrollen og giver den væk. Kør det på et system med fem agents med én orphan og én dobbelt edge:

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

Nu den måling, denne sektion findes for, og den eneste i kapitlet, der er taget mod en rigtig model i stedet for en scriptet.

En kunde angiver en begrænsning i sin første besked — vores konto er registreret i Portugal, ikke Spanien; alt skatterelateret skal bruge Portugal — chatter om noget andet og stiller derefter et spørgsmål, som fakturering skal besvare. Casen overføres. Fireogtyve forsøg, et andet land og firma hver gang, fire transfer-payloads, og den modtagende agent får derefter ét spørgsmål: I hvilket land er denne kundes konto registreret?

Tredje række er en kontrol og opfører sig som en: Faktummet er der ikke, så det kan ikke genkaldes. De tre andre er fundet.

Hele transcriptet er 173 tokens og virker 83 % af tiden, hvor de fire fejl er kapitel 24's emne snarere end dette kapitels. Den typed record er 69 tokens — syv mere end resumeet — og virker hver gang, fordi begrænsningen sidder i et navngivet felt i stedet for i en sætning.

Og resumeet er rækken, du skal stirre på. Det fejlede 24 gange ud af 24, og årsagen er ikke, at læseren overså det. Begrænsningen optrådte overhovedet kun i 1 af de 24 resumeer. Den modtagende agent var ikke skødesløs; den fik overdraget en tekst, der ikke indeholdt svaret. Et resume er en komprimering, du ikke skrev, produceret af en model, hvis vindue du ikke kan se, optimeret til at læse som et resume — og "kunden siger, at vores registre har det forkerte land" er præcis den slags ledsætning, en summariser dropper som procedurestøj.

En ærlig grænse for det tal: Summariser-modellen er en model med en halv milliard parameters, og en større ville beholde mere. Det, der ikke forbedres med størrelse, er risikoens form — den afsendende agent beslutter, per overdragelse, per formulering, usynligt, hvilke fakta der overlever. Den typed record afhænger slet ikke af den vurdering, og derfor vinder den ved konstruktion snarere end ved intelligens. Alt, der skal overleve en overførsel, bør være et felt, ikke en sætning.

Samme ræsonnement gælder i den anden retning, for agent-som-værktøj-topologien, og den tidligere tabel har allerede prissat det: Det, der kommer tilbage fra en worker, er også et resume, og at betale 8,3 % mere for at modtage evidensen sammen med det er samme rettelse set fra parents side.

Tre afsluttende fakta, alle fra tabellerne ovenfor.

Et multi-agent-system multiplicerer kald, og kald er kvadratiske i context. Orchestrator lavede 12 modelkald, hvor én agent lavede 5, og hvert bærer sit eget voksende transcript — 3.628 input tokens mod 2.697, et gab der vokser med opgavens længde.

Hver grænse er en tabsgivende kanal. To agents betyder ét resume. Fire agents i en kæde betyder tre, sammensat, hver skrevet af en model, der optimerer for noget andet end din beslutning.

Den enkelte agent fandt noget, ingen havde bedt om. Uoverensstemmelsen i indkøbsordren dukkede op, fordi ét vindue havde fakturaen og ordren på samme tid. At splitte arbejde på tværs af specialister splitter også evnen til at opdage, at to fakta er uenige.

Intet af dette argumenterer imod de publicerede multi-agent-frameworks, som er værd at læse som primærkilder snarere end gennem tutorials.¹⁰ Det argumenterer for at få den anden agent til at gøre sig fortjent til sin plads.

Altså en test snarere end en præference. Tilføj en anden agent, når mindst én af disse er sand: Sub-tasken har brug for et rent vindue, som parent ikke må arve (kapitel 24); sub-tasks er reelt uafhængige, og wall clock betyder noget, hvilket er 1,8× ovenfor; sub-tasken har brug for andre tilladelser eller en anden model, hvilket kapitel 30 gør til et sikkerhedsargument; eller sub-tasken ejes af en anden, hvilket er dér, en rigtig protokol begynder at betyde noget. Hvis svaret er "så hver agent har en klarere prompt", så giv den ene agent en klarere prompt. Det er gratis.

Du kan nu navngive de fem mønstre, prissætte dem mod hinanden på én opgave, skelne en orchestrator fra en sectioner og et værktøjskald fra en overdragelse, og forsvare én agent med en tabel i stedet for en præference.

Hver opsætning her delte én bekvemmelighed, som ikke vil overleve kontakt med noget virkeligt: Alle værktøjerne tilhørte os. Faktura, ordre, momstabel, workerne bag orchestrator — samme repository, samme deploy, samme typer, samme mennesker.

Sæt nu én af dem på den anden side af en virksomhedsgrænse. Momstabellen tilhører en regnskabsleverandør, ordreposten et lagersystem, og ingen af dem har læst din Tool-grænseflade. Du har brug for en måde, hvorpå en model, du ikke har skrevet, kan opdage, beskrive og kalde en capability, som en anden driver — med authentication (som er kapitel 27's halvdel), versionering og garantien for, at en server ikke kan læse resten af din samtale. Det er et protokolproblem, det har en specifikation med et normativt schema, og næsten alt indekseret om det beskriver en revision, der ikke længere findes.

Kapitel 26 læser den specifikation i stedet for at opsummere den, og starter med at skrive JSON-RPC i en terminal i hånden.

Alle cost- og token-tal ovenfor kom fra den scripted provider beskrevet i den anden sektion, på Node 22 over en loopback-grænseflade, talt med o200k_base-encoding og prissat efter de satser, kapitel 16 aflæste den 6. september 2026 — $2.00 per million input tokens og $12.00 per million output. Wall-clock-tal er fra de samme kørsler med providerens latency sat til 400 ms per kald og værktøjer til 50 ms, så de måler opsætningen snarere end nogen provider. De to real-model-målinger — overdragelsestabellen og voting-and-judging-tabellen — brugte Qwen/Qwen2.5-0.5B-Instruct i float32 på CPU'en bag et endpoint af samme form, greedy bortset fra hvor en temperatur er angivet, med intervaller beregnet med Wilsons metode fra kapitel 4. Ingen request i dette kapitel gik til et betalt endpoint, og intet tal i det blev estimeret.