Multi-agent orchestration: vijf patronen, en wanneer één wint

Een Portugees bedrijf schrijft over factuur FT-2026-0918. De e-mail zegt dat de btw verkeerd lijkt, en voegt de factuur toe: netto EUR 248,00, btw berekend tegen 21%, EUR 52,08, totaal EUR 300,08.

De feiten die nodig zijn om te antwoorden staan op drie plekken, en slechts één daarvan staat in de e-mail:

Zet de drie bij elkaar en de factuur is fout: de verleggingsregeling geldt, de btw had nul moeten zijn, er is een creditnota voor EUR 52,08 verschuldigd. Kijk alleen naar de factuur en hij klopt rekenkundig perfect — 248,00 plus 52,08 is 300,08 — en dat zul je dan ook zeggen.

De e-mail vermeldt wel „wij zijn een Portugees bedrijf”. Dat is een bewering, geen registratie, en geen enkel facturatiesysteem geeft een creditnota uit op basis van een bewering. De val is geen truc: het is de normale vorm van zakelijk werk, waarin de beslissing een feit nodig heeft dat niemand eraan dacht op te halen.

Alles hierboven draait tegen een gescripte provider in de stijl van die uit Hoofdstuk 23, met precies één regel:

Een antwoord mag alleen een feit gebruiken dat in zijn prompt staat.

Het „model” vraagt elke tool die het heeft één keer op, in catalogusvolgorde, en past daarna een vaste regel toe op de tekst die het kan zien. Niets is per opstelling gescript, dus de verschillen in de begintabel zijn geen claims over modelintelligentie: ze zijn gemeten information routing. Een echt model voegt daar zijn eigen fouten bovenop toe; het haalt deze niet weg.

De vijf namen hieronder zijn die van Anthropic, uit Building effective agents, waar deze woordenschat is geland.¹ Geen van de vijf ideeën is nieuw, en zeggen welk huis wat heeft benoemd — en welk idee ouder is — is de helft van de waarde van ze kennen.

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

Dat is de hele toolkit: vijf functies, geen framework, en de parallelle is één regel — wat precies het punt is van uitschrijven in plaats van tekenen. Nu elk op zijn beurt, met zijn afkomst, zijn prijs en het geval waarin het fout zit.

Prompt chaining „ontleedt een taak in een reeks stappen, waarbij elke LLM-aanroep de output van de vorige verwerkt”.¹ Het idee is ouder dan taalmodellen: het is een pipeline, met de trade van de pipeline — helderheid in ruil voor een control flow die vastligt voordat de data arriveert.

Vier stappen voor onze taak: haal de factuurvelden eruit, controleer de berekening, beslis wat verschuldigd is, schrijf het antwoord. Hier faalt het op twee verschillende manieren, wat meer leert dan één keer falen.

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

De relay chain kostte $0.001940 en verloor de factuurvelden tussen stap twee en drie, omdat stap drie een zin over rekenkunde kreeg en niets anders. Hij produceerde een wachtbericht: nutteloos, en zichtbaar nutteloos.

De accumulerende chain — de rij in de begintabel — kostte $0.003780, 95% meer voor vier identieke aanroepen, omdat elke stap nu alles meedraagt wat eraan voorafging. Hij produceerde de gevaarlijke output. Vloeiend, met verwijzing naar zijn berekening, correct op elk getal dat hij noemt, en hij vertelt een klant dat er niets verschuldigd is terwijl EUR 52,08 verschuldigd is.

Het verschil tussen de twee is één ternary. Een chain die minder meedraagt produceert antwoorden die duidelijk incompleet zijn; een chain die alles meedraagt produceert antwoorden die zelfverzekerd fout zijn — en alleen de tweede soort wordt verzonden.

Geen van beide is de echte fout. De echte fout is dat de pipeline vóór het lezen al besliste dat deze taak vier stappen over de inhoud van een e-mail is. Nergens in die structuur is er een plek om te zeggen: „het registratieland staat niet in deze e-mail; ga het halen”. Chaining is juist wanneer de ontleding vooraf bekend en stabiel is. Hier was het een gok, en de gok ging de deur uit.

Routing „classificeert een input en stuurt die naar een gespecialiseerde vervolgtaak”.¹ De naam is nieuw; het mechanisme is de dispatcher, ouder dan bijna alles in dit boek. Wat nieuw is, is dat de classifier een model kan zijn — en daardoor faalt hij op manieren waarop een switch dat nooit deed.

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

Twee dingen over dat laatste argument. Het is geen error handling; het is het patroon. Een model-based router heeft een faalmodus die een dispatcher niet heeft: hij kan een label teruggeven dat niet bestaat, time-outen, of — de dure — een plausibel verkeerd label teruggeven zonder signaal dat het verkeerd is. Alle drie moeten ergens landen, en dat ergens kan niet nog een modelaanroep zijn, want je zit al in de branch waar modelaanroepen faalden.

Het tweede is dat de eigen prompt van de router niet gratis is. Om een model te kiezen heeft een router een catalogus van modellen nodig om uit te kiezen, en elk item daarin is input waarvoor de router betaalt voordat hij de vraag van de gebruiker heeft gelezen. Tegen het inputtarief waarmee deze cursus rekent, kost een catalogus van ongeveer 3.800 tokens al evenveel als de volledige agent-run met vijf aanroepen uit de openingstabel. In de praktijk draait de routingaanroep op een goedkoop model, en dat is precies waarom routing zichzelf terugverdient; maar het loont om de rekensom in die richting te maken in plaats van het aan te nemen. Routing is verkeerd precies wanneer de gerouteerde taak goedkoper is dan de routingbeslissing.

Anthropic splitst deze in tweeën: sectioning — „een taak opdelen in onafhankelijke subtaken die parallel worden uitgevoerd” — en voting — „dezelfde taak meerdere keren uitvoeren om diverse outputs te krijgen”.¹ Ze delen een diagram en bijna niets anders.

Sectioning is de goedkope winst, en het is de regel uit patterns.ts: drie specialisten — facturatie, belasting, policy — elk met zijn eigen window en tools, over dezelfde e-mail, met één synthese-aanroep aan het einde. Identiek werk, op twee manieren geordend:

Token voor token hetzelfde, 1,8 keer sneller. Daarom verdient het patroon zijn eigen naam: het is de enige van de vijf die iets verbetert zonder iets te kosten. De adder is dat de secties echt onafhankelijk moeten zijn — geef sectie B een feit dat sectie A produceert en Promise.all draait ze allebei tegen een state die nog niet bestaat. De for loop verborg die bug; de one-liner legt hem bloot.

Voting is een ander dier met hetzelfde plaatje aan. Dezelfde vraag k keer uitvoeren en de meerderheid nemen is self-consistency, in maart 2022 gepubliceerd door Wang et al. als decoding-strategie, bijna drie jaar voordat iemand het een orchestration pattern noemde. Het abstract is precies over het mechanisme — „samplet eerst een diverse set reasoning paths in plaats van alleen de greedy te nemen, en selecteert daarna het meest consistente antwoord door de gesamplede reasoning paths weg te marginaliseren” — en over de winst: +17,9 punten op GSM8K.²

Daaruit volgen twee dingen die het plaatje verbergt. Ten eerste vereist voting de sampling uit Hoofdstuk 17: bij temperature nul zijn alle k samples dezelfde sample, en is de meerderheid één antwoord waarvoor k keer is betaald. Ten tweede werkt het alleen waar een meerderheid betekenisvol is — bij het factuurantwoord hierboven is er niets te tellen, want vijf concepten zijn vijf verschillende zinnen. Voting is voor taken met een kort, vergelijkbaar antwoord, wat precies Wangs benchmarks zijn en bijna niets wat een customer-facing agent doet.

Hier gemeten op 20 driestaps woordproblemen waarvan de antwoorden worden berekend in plaats van beoordeeld, met het lokale model uit Hoofdstuk 23 dat stap voor stap redeneert:

Vijf keer de aanroepen, vijf keer de tokens, exact vijf keer de rekening, en niet één extra correct antwoord. Voting is een weddenschap, geen verbetering, en deze run verloor hem.

Twee kanttekeningen, voordat iemand dat citeert als weerlegging van Wang. Twintig trials kunnen 45% niet onderscheiden van 60% — het interval is de breedte van de claim, wat de discipline uit Hoofdstuk 4 op mijn eigen resultaat toegepast is. En de gepubliceerde winsten komen van modellen die orden van grootte groter zijn, waar de diverse reasoning paths waar voting over marginaliseert ook echt divers zijn. Wat overdraagt is niet het getal: het is dat de multiplier exact is en vooraf bekend, terwijl de winst dat niet is.

In de orchestrator-workers workflow „breekt een centrale LLM taken dynamisch op, delegeert ze aan worker LLMs en synthetiseert hun resultaten”, en het verschil met sectioning is dat „subtaken niet vooraf gedefinieerd zijn, maar door de orchestrator worden bepaald”.¹ De afkomst hier komt helemaal niet uit taalmodellen: dit is master-worker, en de versie waarin workers bevindingen in een gedeelde ruimte schrijven die een controller leest, is de blackboard-architectuur, uit spraakverstaansonderzoek in de jaren 70. Wat in 2026 nieuw is, is dat de controller een model is en de ontleding dus per input kan worden beslist — de flexibiliteit en de kosten in één zin.

Het kostte 12 modelaanroepen tegenover 5 voor de single agent, en het kwam tot hetzelfde oordeel. Daarna deed het iets dat het bekijken waard is:

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 hebben gelijk. Slechts één weet waarom. De tax worker had de factuur, de order en de belastingtabel in zijn eigen window, kwam tot de conclusie, en merkte ook op — niemand vroeg erom — dat het inkoopordernummer op de factuur niet overeenkomt met dat van de order. Daarna gaf hij een samenvatting terug. De orchestrator kan beide uitspraken herhalen en geen van beide controleren, omdat het bewijs in een window bleef dat hij nooit zag. Dat is de slotvraag van Hoofdstuk 24, beantwoord: de parent krijgt te zien wat het child ervoor koos op te schrijven.

De fix is een flag, en die heeft een prijs:

Twaalf procent meer input-tokens, 8,3% meer geld, en de frase source=worker_unverified verdwijnt uit het antwoord. Dat is de trade in elk multi-agent system en hij wordt bijna nooit uitgesproken: het schone window van het child is waardevol, het vermogen van de parent om het te auditen is het betalen waard, en je kunt niet allebei gratis hebben.

Wanneer is orchestrator-workers dus verkeerd? Hier, op deze taak. Het kocht een correct antwoord dat één agent met dezelfde vier tools ook bereikte, voor 1,66 keer de kosten en 2,3 keer de wall clock, en het maakte dat antwoord moeilijker te verdedigen. Anthropic's eigen richtlijn zegt hetzelfde voordat de patronen beginnen: vind „de eenvoudigst mogelijke oplossing, en verhoog complexiteit alleen wanneer nodig”, omdat „agentic systems vaak latency en kosten inruilen voor betere taakprestaties”.¹ De tabellen hierboven zijn die zin met cijfers eronder.

Eén aanroep genereert, een andere evalueert, en de loop herhaalt tot de evaluatie slaagt.¹ De gepubliceerde voorouders zijn Self-Refine — hetzelfde model als „generator, refiner, and feedback provider”, met ongeveer 20 punten absolute verbetering gemiddeld over zeven taken³ — en Reflexion, dat de kritiek in een episodische buffer over pogingen heen bewaart en 91% pass@1 op HumanEval rapporteert waar de baseline 80% haalde.⁴

Het kostenmodel is de eenvoudigste van de vijf: twee aanroepen per ronde, en het aantal rondes is niet van jou. Drie verfijningsrondes op een taak die één aanroep kostte, is zes aanroepen, dus de bodem van het patroon is 6× en het plafond is welke cap jij instelt — waardoor de budget-exit uit Hoofdstuk 23 verplicht wordt in plaats van netjes.

Het plafond is subtieler, en meetbaar. Op dezelfde 20 problemen beantwoordde het lokale model er 9 correct. Daarna kreeg het elk van die antwoorden te zien en werd gevraagd of het klopte — zonder te vertellen dat het antwoord van hemzelf was, wat de vleierij-confound weghaalt en de capability overlaat:

Dat is een betere rechter dan de sectietitel suggereert, en dat zeggen is het punt van meten in plaats van beweren: hij blokkeerde niets corrects en ving 8 van de 11 fouten. Als filter is hij zijn aanroepen waard.

Als stopregel, wat een evaluator-optimiser loop er daadwerkelijk voor gebruikt, zijn die drie goedkeuringen het hele verhaal: ze beëindigen de loop met een fout antwoord in handen, en geen aantal extra rondes bereikt ze ooit. Een refinement loop kan niet correcter worden dan zijn rechter. Meer rondes kopen pogingen op de fouten die de rechter kan zien, tegen volle prijs, en helemaal niets tegen de fouten die hij niet kan zien.

Dus de regel: een evaluator verdient zijn aanroepen alleen wanneer hij iets heeft dat de generator niet heeft. Een compiler, een test suite, een schema validator, een ander model, een mens. Self-Refine's eigen resultaten zijn gemeten tegen menselijke voorkeur en taakmetrics, nooit tegen de mening van het model over zichzelf. Als het enige voordeel van je evaluator een andere prompt is, betaal je dubbel voor overeenstemming. Hoofdstuk 29 bouwt de versie met een echt voordeel: een golden set met de antwoorden vooraf opgeschreven.

De vijf hierboven zijn vormen voor jouw code. Daaronder zit een tweede familie die er vaak naast wordt gezet en dat niet zou moeten worden: ReAct, Reflexion, plan-and-execute en tree of thoughts zijn reasoning loops, en hun kosten zitten in requests.

Hoofdstuk 12 ging over reasoning binnen het model, waarvoor je betaalt in output-tokens op één aanroep. Dit is de andere soort. Het verschil doet ertoe als de rekening komt: een langere chain of thought maakt één aanroep duurder, en een reasoning loop maakt van één taak veel aanroepen, die elk alles ervoor opnieuw meesturen — het kwadratische dat Hoofdstuk 23 in zijn runaway-tabel mat.

De tree-of-thoughts-paper publiceert zijn eigen kostentabel, wat zeldzamer is dan het zou moeten zijn. Op Game of 24 met GPT-4: input/output prompting best-of-100 loste 33% op voor $0.13 per case, chain of thought best-of-100 loste 49% op voor $0.47, en tree of thoughts loste 74% op voor $0.74, waarbij de auteurs opmerken dat het „5–100 keer meer gegenereerde tokens dan CoT zou kunnen vereisen”.⁷

Bijna zes keer de prijs van de goedkope methode voor iets meer dan het dubbele succespercentage. Of dat een koopje is, hangt af van wat een mislukte case je kost — de vraag die je moet stellen voordat je een van deze vier adopteert.

Deze cursus implementeert ze niet opnieuw. Alle vier hebben referentie-implementaties van hun eigen auteurs, in Python, en hun waarde is dat ze de bron zijn in plaats van een vertaling: ysymyth/ReAct, noahshinn/reflexion, princeton-nlp/tree-of-thought-llm en AGI-Edgerunners/Plan-and-Solve-Prompting. Lees de prompts in die repositories; de prompts zijn de papers.

Nu multi-agent zelf, waar de meeste verwarring zit. Er zijn twee manieren waarop één agent een andere kan betrekken, het zijn geen varianten, en het verschil is wie daarna de leiding heeft.

Agent als tool. De parent roept hem aan, krijgt een antwoord en gaat door. Het is de tool-interface uit Hoofdstuk 18 met een volledige agent erachter, en de parent verliest nooit de controle. Dit is wat de orchestrator hierboven doet.

Handoff. De parent draagt het gesprek over en krijgt het niet terug. OpenAI's guide is de helderste gepubliceerde formulering: handoffs zijn „een eenrichtingsoverdracht waarmee een agent aan een andere agent kan delegeren... Als een agent een handoff function aanroept, starten we onmiddellijk de uitvoering op die nieuwe agent waaraan is overgedragen, terwijl we ook de nieuwste conversation state overdragen.”⁸

Een vocabulairewaarschuwing, want dit laat mensen voortdurend struikelen: „handoff” is het woord van één SDK, geen standaard. Het is terminologie uit de OpenAI Agents SDK en die guide, die de twee opstellingen ook „manager” en „decentralized” noemt en opmerkt dat in het manager pattern „edges tool calls voorstellen, terwijl edges in het decentralized pattern handoffs voorstellen”.⁸ Er is een open standaard in deze ruimte — A2A, op versie 1.0.0, onder copyright van de Linux Foundation, met een versiegeschiedenis en een gedocumenteerde lijst met breaking changes, waarvan het verklaarde principe opaque execution is: agents „collaborate based on declared capabilities and exchanged information, without needing to share their internal thoughts, plans, or tool implementations”.⁹ Dat is geen handoff, en de vergelijking hoort thuis in Hoofdstuk 26. Wat hier telt is dat een van de twee woorden de API van een library is en het andere een specificatie met governance.

Het onderscheid is een datastructuur, geen 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;
}

Twintig regels, twee bugs die je anders in productie zou vinden. reachable vindt de agent waar niemand bij kan — geconfigureerd, betaald, nooit aangeroepen. conflicts weigert de edge die beide soorten tegelijk is, wat pietluttig klinkt tot je het hardop leest: de parent behoudt de controle én geeft die weg. Draai het op een vijf-agent system met één orphan en één dubbele edge:

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

Nu de meting waar deze sectie voor bestaat, en de enige in het hoofdstuk tegen een echt model in plaats van een gescript model.

Een klant noemt in zijn eerste bericht een constraint — onze account is geregistreerd in Portugal, niet Spanje; alles wat met belasting te maken heeft moet Portugal gebruiken — chat over iets anders, en stelt daarna een vraag die billing moet beantwoorden. De case wordt overgedragen. Vierentwintig trials, telkens een ander land en bedrijf, vier transfer-payloads, en de ontvangende agent krijgt daarna één vraag: in welk land is deze klantaccount geregistreerd?

De derde rij is een controle en gedraagt zich zo: het feit staat er niet in, dus kan het niet worden herinnerd. De andere drie zijn de bevinding.

Het volledige transcript is 173 tokens en werkt 83% van de tijd, waarbij de vier mislukkingen het onderwerp van Hoofdstuk 24 zijn in plaats van dat van dit hoofdstuk. Het typed record is 69 tokens — zeven meer dan de samenvatting — en werkt elke keer, omdat de constraint in een benoemd veld zit in plaats van in een zin.

En de samenvatting is de rij om naar te blijven kijken. Hij faalde 24 van de 24 keer, en de reden is niet dat de lezer het miste. De constraint verscheen überhaupt in slechts 1 van de 24 samenvattingen. De ontvangende agent was niet slordig; hij kreeg een tekst waarin het antwoord niet stond. Een samenvatting is een compaction die jij niet hebt geschreven, geproduceerd door een model waarvan je het window niet kunt zien, geoptimaliseerd om als samenvatting te lezen — en „de klant zegt dat onze records het verkeerde land hebben” is precies het soort bijzin dat een summariser als procedurele ruis laat vallen.

Een eerlijke beperking op dat getal: de summariser is een half-billion-parameter model en een groter model zou meer bewaren. Wat niet verbetert met grootte is de vorm van het risico — de zendende agent beslist, per handoff, per formulering, onobserveerbaar, welke feiten overleven. Het typed record hangt helemaal niet van dat oordeel af, en daarom wint het door constructie in plaats van door intelligentie. Wat een transfer moet overleven, moet een veld zijn, geen zin.

Dezelfde redenering geldt de andere kant op, voor de agent-as-tool-topologie, en de eerdere tabel heeft hem al geprijsd: wat terugkomt van een worker is ook een samenvatting, en 8,3% meer betalen om het bewijs erbij te ontvangen is dezelfde fix gezien vanaf de kant van de parent.

Drie slotfeiten, allemaal uit tabellen hierboven.

Een multi-agent system vermenigvuldigt aanroepen, en aanroepen zijn kwadratisch in context. De orchestrator deed 12 modelaanroepen waar één agent er 5 deed, en elk draagt zijn eigen groeiende transcript mee — 3.628 input-tokens tegenover 2.697, een kloof die groter wordt met de lengte van de taak.

Elke grens is een lossy channel. Twee agents betekent één samenvatting. Vier agents in een chain betekent drie, samengesteld, elk geschreven door een model dat voor iets anders optimaliseert dan jouw beslissing.

De single agent vond iets waar niemand om vroeg. De mismatch in het inkoopordernummer kwam boven omdat één window de factuur en de order tegelijk bevatte. Werk opsplitsen over specialisten splitst ook het vermogen om te merken dat twee feiten elkaar tegenspreken.

Niets daarvan pleit tegen de gepubliceerde multi-agent frameworks, die het waard zijn om als primaire bronnen te lezen in plaats van via tutorials.¹⁰ Het pleit ervoor de tweede agent zijn plek te laten verdienen.

Dus een test in plaats van een voorkeur. Voeg een tweede agent toe wanneer minstens één hiervan waar is: de subtaak heeft een clean window nodig dat de parent niet mag erven (Hoofdstuk 24); de subtaken zijn echt onafhankelijk en de wall clock doet ertoe, wat de 1,8× hierboven is; de subtaak heeft andere rechten of een ander model nodig, wat Hoofdstuk 30 in een security-argument omzet; of de subtaak is eigendom van iemand anders, waar een echt protocol belangrijk begint te worden. Als het antwoord is „zodat elke agent een duidelijkere prompt heeft”, geef de ene agent dan een duidelijkere prompt. Dat is gratis.

Je kunt nu de vijf patronen benoemen, ze op één taak tegen elkaar prijzen, een orchestrator onderscheiden van een sectioner en een tool call van een handoff, en een single agent verdedigen met een tabel in plaats van een voorkeur.

Elke opstelling hier deelde één gemak dat contact met iets echts niet zal overleven: alle tools waren van ons. Factuur, order, belastingtabel, de workers achter de orchestrator — dezelfde repository, dezelfde deploy, dezelfde types, dezelfde mensen.

Zet er nu één aan de andere kant van een bedrijfsgrens. De belastingtabel is van een boekhoudleverancier, de orderregistratie van een warehousesysteem, en geen van beide heeft jouw Tool interface gelezen. Je hebt een manier nodig waarop een model dat jij niet schreef een capability die iemand anders runt kan ontdekken, beschrijven en aanroepen — met authenticatie (wat de helft van Hoofdstuk 27 is), versioning, en de garantie dat een server de rest van je gesprek niet kan lezen. Dat is een protocolprobleem, het heeft een specificatie met een normatief schema, en bijna alles wat erover is geïndexeerd beschrijft een revisie die niet meer bestaat.

Hoofdstuk 26 leest die specificatie in plaats van haar samen te vatten, en begint door JSON-RPC met de hand in een terminal te typen.

Elke cost en elk token count hierboven kwam van de gescripte provider die in de tweede sectie is beschreven, op Node 22 over een loopback-interface, geteld met de o200k_base encoding en geprijsd tegen de tarieven die Hoofdstuk 16 op 6 september 2026 las — $2.00 per miljoen input-tokens en $12.00 per miljoen output. Wall-clock-cijfers komen uit dezelfde runs met de latency van de provider ingesteld op 400 ms per aanroep en tools op 50 ms, zodat ze de opstelling meten in plaats van een provider. De twee real-model-metingen — de handoff-tabel en de voting-and-judging-tabel — gebruikten Qwen/Qwen2.5-0.5B-Instruct in float32 op de CPU achter een endpoint met dezelfde vorm, greedy behalve waar een temperature wordt genoemd, met intervallen berekend volgens Wilsons methode uit Hoofdstuk 4. Geen enkele request in dit hoofdstuk ging naar een betaald endpoint, en geen enkel getal erin is geschat.