Multi-agent orchestráció: öt minta, és mikor győz az egyik

Egy portugál cég ír a FT-2026-0918 számláról. Az email szerint az áfa hibásnak tűnik, és csatolja a számlát: nettó 248,00 EUR, 21 % áfa felszámítva, 52,08 EUR, összesen 300,08 EUR.

A válaszhoz szükséges tények három helyen élnek, és ezek közül csak egy van benne az emailben:

Rakd össze a hármat, és a számla hibás: reverse charge alkalmazandó, az áfának nullának kellett volna lennie, 52,08 EUR jóváíró számla jár. Ha csak a számlát nézed, aritmetikailag tökéletes — 248,00 plusz 52,08 az 300,08 —, és ezt fogod mondani.

Az email valóban állítja, hogy „portugál cég vagyunk”. Ez állítás, nem rekord, és egyetlen számlázórendszer sem állít ki jóváíró számlát puszta állítás alapján. A csapda nem trükk: ez az üzleti munka hétköznapi alakja, ahol a döntéshez olyan tény kell, amelynek lekérésére senki sem gondolt.

A fentiek mind a 23. fejezet stílusában szkriptelt szolgáltatóval futnak, pontosan egy szabállyal:

Egy válasz csak olyan tényt használhat, amely benne van a promptjában.

A „modell” minden nála lévő eszközt egyszer kér le, katalógussorrendben, majd rögzített szabályt alkalmaz arra a szövegre, amelyet lát. Semmi sincs elrendezésenként szkriptelve, ezért a nyitó táblázat különbségei nem a modellintelligenciáról szóló állítások: ezek információ-útvonalak, megmérve. Egy valódi modell ehhez hozzáadja a saját hibáit; nem tünteti el ezeket.

Az alábbi öt név Anthropicé, a Building effective agents cikkből; ott állapodott meg ez a szókészlet.¹ Az öt ötlet közül egyik sem új, és annak kimondása, melyik ház mit nevezett el — és melyik ötlet régebbi — a megértés értékének fele.

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

Ez a teljes eszközkészlet: öt függvény, nincs framework, és a párhuzamos egyetlen sor — éppen ezért érdemes kiírni, nem lerajzolni. Most egyenként, az eredetükkel, az árukkal és azzal az esettel, ahol hibáznak.

A prompt chaining „egy feladatot lépések sorozatára bont, ahol minden LLM-hívás az előző kimenetét dolgozza fel”.¹ Az ötlet régebbi a nyelvi modelleknél: ez pipeline, a pipeline alkújával — átláthatóságért cserébe olyan kontrollfolyam, amely rögzített, mielőtt az adat megérkezik.

Négy lépés a feladatunkhoz: a számlamezők kinyerése, az aritmetika ellenőrzése, annak eldöntése, mi jár, a válasz megírása. Itt két különböző módon bukik el, ami többet tanít, mintha csak egyszer bukna.

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

A relay lánc $0,001940-ba került, és elvesztette a számlamezőket a második és harmadik lépés között, mert a harmadik lépés csak egy aritmetikáról szóló mondatot kapott, semmi mást. Tartóüzenetet adott: haszontalant, és láthatóan haszontalant.

Az akkumuláló lánc — a nyitó táblázat sora — $0,003780-ba került, ami 95 %-kal több négy azonos hívásért, mert most minden lépés visz magával mindent, ami előtte volt. Ez adta a veszélyes kimenetet. Folyékony, az aritmetikájára hivatkozik, minden említett számában helyes, és azt mondja az ügyfélnek, hogy semmi nem jár, miközben 52,08 EUR jár.

A kettő közti különbség egy ternary. Az a lánc, amely kevesebbet visz tovább, nyilvánvalóan hiányos válaszokat ad; az a lánc, amely mindent visz tovább, magabiztosan hibás válaszokat ad — és csak a második fajtát küldik el.

De egyik sem a valódi hiba. A valódi hiba az, hogy a pipeline még olvasás előtt eldöntötte: ez a feladat négy lépés egy email tartalma fölött. Ebben a struktúrában sehol sincs hely azt mondani: „a regisztrációs ország nincs ebben az emailben; menj, szerezd meg”. A chaining akkor helyes, ha a bontás előre ismert és stabil. Itt találgatás volt, és a találgatást élesítették.

A routing „bemenetet osztályoz, és egy specializált follow-up feladathoz irányítja”.¹ A név új; a mechanizmus a dispatcher, amely régebbi szinte minden másnál ebben a könyvben. Az az új, hogy az osztályozó lehet modell — ettől bukik el olyan módokon, ahogy egy switch soha.

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

Két dolog az utolsó argumentumról. Ez nem error handling; ez maga a minta. Egy modellalapú routernek van olyan hibamódja, amely egy dispatchernek nincs: visszaadhat nem létező címkét, timeoutolhat, vagy — ez a drága — visszaadhat hihető, de rossz címkét úgy, hogy semmi nem jelzi a hibát. Mindháromnak valahol landolnia kell, és ez a valahol nem lehet újabb modellhívás, mert már abban az ágban vagy, ahol a modellhívások megbuktak.

A második dolog: a router saját promptja sem ingyenes. Ahhoz, hogy modellt válasszon, a routernek kell egy választható modellkatalógus, és ennek minden bejegyzése olyan input, amelyért a router fizet, mielőtt elolvasta volna a felhasználó kérdését. Azon az input áron, amellyel ez a kurzus számol, egy nagyjából 3 800 tokenes katalógus már annyiba kerül, mint a nyitó táblázat teljes öthívásos agent futása. A gyakorlatban a routing hívás olcsó modellen fut, pontosan ezért térül meg a routing; de az aritmetikát ebbe az irányba érdemes elvégezni, nem feltételezni. A routing pontosan akkor hibás, amikor a routolt feladat olcsóbb, mint maga a routing döntés.

Anthropic ezt kettébontja: sectioning — „egy feladat felbontása független részfeladatokra, amelyek párhuzamosan futnak” — és voting — „ugyanannak a feladatnak többszöri futtatása változatos kimenetekért”.¹ Közös rajzuk van, és szinte semmi másuk nem közös.

A sectioning az olcsó győzelem, és ez a patterns.ts sora: három specialista — számlázás, adó, policy — mindegyik saját context window-val és eszközökkel, ugyanazon az emailen, a végén egy szintézishívással. Azonos munka, kétféle sorrendben:

Tokenről tokenre ugyanaz, 1,8-szor gyorsabban. Ezért érdemel saját nevet a minta: az öt közül ez az egyetlen, amely valamit úgy javít, hogy nem kerül semmibe. A bökkenő az, hogy a szekcióknak valóban függetlennek kell lenniük — adj B szekciónak egy tényt, amelyet A szekció állít elő, és a Promise.all mindkettőt olyan állapoton futtatja, amely még nem létezik. A for loop elrejtette ezt a hibát; az egysoros felfedi.

A voting más állat ugyanabban a képben. Ugyanazt a kérdést k alkalommal futtatni és többséget venni: ez self-consistency, amelyet Wang és társai 2022 márciusában decoding stratégiaként publikáltak, majdnem három évvel azelőtt, hogy bárki orchestrációs mintának nevezte volna. Az absztraktja pontos a mechanizmusról — „először változatos reasoning útvonalakat mintavételez ahelyett, hogy csak a greedy választ venné, majd a mintavételezett reasoning útvonalakat marginalizálva kiválasztja a legkonzisztensebb választ” — és a nyereségről is: +17,9 pont GSM8K-n.²

Ebből két dolog következik, amelyet a kép elrejt. Először: a voting igényli a 17. fejezet mintavételezését: nulla temperature mellett mind a k minta ugyanaz a minta, a többség pedig egy válasz, k-szor kifizetve. Másodszor: csak ott működik, ahol a többség értelmes — a fenti számlaválasznál nincs mit megszámolni, mert öt piszkozat öt különböző mondat. A voting olyan feladatokra való, ahol rövid, összehasonlítható válasz van; pontosan ilyenek Wang benchmarkjai, és szinte semmi, amit egy ügyféloldali agent csinál.

Itt 20 háromlépéses szöveges feladaton mérve, amelyeknek válaszai számítottak, nem megítéltek, a 23. fejezet helyi modelljével lépésről lépésre reasoningelve:

Ötször annyi hívás, ötször annyi token, pontosan ötször akkora számla, és egyetlen plusz helyes válasz sem. A voting fogadás, nem javítás, és ez a futás elveszítette.

Két fenntartás, mielőtt bárki Wang cáfolataként idézné. Húsz próba nem tudja megkülönböztetni a 45 %-ot a 60 %-tól — az intervallum a claim szélessége, ami a 4. fejezet fegyelme a saját eredményem ellen fordítva. A publikált nyereségek pedig nagyságrendekkel nagyobb modellekből jönnek, ahol a voting által marginalizált változatos reasoning útvonalak valóban változatosak. Nem a szám vihető át, hanem az, hogy a szorzó pontos és előre ismert, a nyereség viszont nem.

Az orchestrator-workers workflow-ban „egy központi LLM dinamikusan bontja le a feladatokat, worker LLM-ekre delegálja őket, és szintetizálja az eredményeiket”, a sectioningtől pedig az különbözteti meg, hogy „a részfeladatok nincsenek előre definiálva, hanem az orchestrator határozza meg őket”.¹ Az eredet itt egyáltalán nem nyelvi modellekből jön: ez master-worker, az a változata pedig, ahol a workerek leleteket írnak egy közös térbe, amelyet egy controller olvas, a blackboard architektúra, az 1970-es évek beszédértési kutatásaiból. Ami 2026-ban új, az az, hogy a controller modell, ezért a bontás bemenetenként eldönthető — ez a rugalmasság és a költség egy mondatban.

12 modellhívásba került az egyetlen agent 5 hívásával szemben, és ugyanarra a verdictre jutott. Aztán tett valamit, amit érdemes közelről nézni:

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

Mindkettő helyes. Csak az egyik tudja, miért. Az adó workernek a saját context window-jában ott volt a számla, a rendelés és az adótábla, levonta a következtetést, és azt is észrevette — senki sem kérdezte —, hogy a számlán lévő beszerzési rendelési szám nem egyezik a rendelésével. Aztán visszaadott egy összefoglalót. Az orchestrator mindkét állítást meg tudja ismételni, de egyiket sem tudja ellenőrizni, mert a bizonyíték abban a context window-ban maradt, amelyet soha nem látott. Ez a 24. fejezet zárókérdésének válasza: a szülő azt láthatja, amit a gyerek úgy döntött, leír.

A javítás egy flag, és ára van:

Tizenkét százalékkal több input token, 8,3 %-kal több pénz, és a source=worker_unverified kifejezés eltűnik a válaszból. Ez az alku minden multi-agent rendszerben, és szinte soha nem mondják ki: a gyerek tiszta context window-ja értékes, a szülő auditálási képességéért érdemes fizetni, és a kettőt nem kaphatod meg ingyen.

Mikor hibás tehát az orchestrator-workers? Itt, ezen a feladaton. Olyan helyes választ vett meg, amelyet egy agent ugyanazzal a négy eszközzel szintén elért, 1,66-szoros költségért és 2,3-szoros falióra-időért, ráadásul nehezebben védhetővé tette a választ. Anthropic saját iránymutatása ezt már a minták előtt kimondja: találd meg „a lehető legegyszerűbb megoldást, és csak akkor növeld a komplexitást, amikor szükséges”, mert „az agentic rendszerek gyakran latencyt és költséget cserélnek jobb feladatteljesítményre”.¹ A fenti táblák ennek a mondatnak a számai.

Az egyik hívás generál, a másik értékel, a loop pedig addig ismétlődik, amíg az értékelés át nem megy.¹ A publikált elődök a Self-Refine — ugyanaz a modell „generator, refiner, and feedback provider” szerepben, hét feladaton átlagosan körülbelül 20 pont abszolút javulást jelentve³ — és a Reflexion, amely a kritikát epizodikus bufferben tárolja a próbálkozások között, és 91 % pass@1-et jelent HumanEvalon, ahol a baseline 80 %-ot ért el.⁴

Az öt közül ennek a legegyszerűbb a költségmodellje: két hívás körönként, és a körök száma nem a tiéd. Három finomítási kör egy egyhívásos feladaton hat hívás, tehát a minta padlója 6×, a plafonja pedig az a cap, amelyet beállítasz — ezért a 23. fejezet budget exitje kötelező, nem csinos extra.

A plafon finomabb, és mérhető. Ugyanazon a 20 feladaton a helyi modell 9-re válaszolt helyesen. Ezután megmutattuk neki mindegyik saját válaszát, és megkérdeztük, helyes-e — anélkül, hogy megmondtuk volna, hogy a sajátja, ami eltávolítja a hízelgési konfúziót, és meghagyja a képességbelit:

Ez jobb bíró, mint amit a szekciócím sugall, és éppen ez a mérés, nem az állítás lényege: semmi helyeset nem blokkolt, és 11 hibából 8-at elkapott. Szűrőként megéri a hívásait.

Megállási szabályként viszont, márpedig egy evaluator-optimiser loop ténylegesen erre használja, az a három jóváhagyás az egész történet: hibás válasszal a kézben zárják le a loopot, és semennyi extra kör nem jut el hozzájuk. Egy finomítási loop nem lehet helyesebb, mint a bírája. Több kör vásárlása próbálkozásokat vesz azokhoz a hibákhoz, amelyeket a bíró lát, teljes áron, és semmit azok ellen, amelyeket nem lát.

Ezért a szabály: egy evaluator csak akkor érdemli ki a hívásait, ha van valamije, ami a generatornak nincs. Compiler, test suite, schema validator, másik modell, ember. A Self-Refine saját eredményeit emberi preferenciával és feladatmetrikákkal mérték, soha nem a modell önmagáról alkotott véleményével. Ha az evaluator egyetlen előnye egy másik prompt, akkor kétszer fizetsz az egyetértésért. A 29. fejezet azt a változatot építi fel, amelynek valódi előnye van: golden setet, előre leírt válaszokkal.

A fenti öt alakzat a te kódodhoz. Alattuk ül egy második család, amelyet gyakran melléjük sorolnak, pedig nem kellene: a ReAct, a Reflexion, a plan-and-execute és a tree of thoughts reasoning loopok, és a költségük requestekben van.

A 12. fejezet a modellen belüli reasoningről szólt, amelyért egy hívás output tokenjeiben fizetsz. Ez a másik fajta. A különbség akkor számít, amikor megérkezik a számla: egy hosszabb chain of thought egy hívást drágít, egy reasoning loop pedig egy feladatból sok hívást csinál, amelyek mindegyike újraküld mindent, ami előtte volt — azt a kvadratikust, amelyet a 23. fejezet a runaway táblájában mért.

A tree-of-thoughts tanulmány saját költségtáblát közöl, ami ritkább, mint kellene. Game of 24-en GPT-4-gyel: az input/output prompting best-of-100 33 %-ot oldott meg esetenként $0,13-ért, a chain of thought best-of-100 49 %-ot $0,47-ért, a tree of thoughts pedig 74 %-ot $0,74-ért, miközben a szerzők megjegyzik, hogy „5–100-szor több generált tokent igényelhet, mint a CoT”.⁷

Majdnem hatszorosa az olcsó módszer árának, valamivel több mint kétszeres sikerarányért. Hogy ez jó üzlet-e, attól függ, mennyibe kerül neked egy sikertelen eset — ezt a kérdést kell feltenni, mielőtt a négy bármelyikét bevezeted.

Ez a kurzus nem implementálja újra őket. Mind a négynek van referenciaimplementációja a saját szerzőitől, Pythonban, és az értékük az, hogy források, nem fordítások: ysymyth/ReAct, noahshinn/reflexion, princeton-nlp/tree-of-thought-llm és AGI-Edgerunners/Plan-and-Solve-Prompting. Olvasd el a promptokat ezekben a repositorykban; a promptok maguk a tanulmányok.

Most jön a valódi multi-agent rész, ahol a legtöbb zavar él. Két módja van annak, hogy egy agent bevonjon egy másikat; ezek nem variánsok, és a különbség az, ki irányít utána.

Agent mint eszköz. A szülő meghívja, választ kap, és folytatja. Ez a 18. fejezet eszközinterfésze, mögötte egy teljes agenttel, és a szülő soha nem veszíti el az irányítást. Ezt csinálja a fenti orchestrator.

Handoff. A szülő átadja a beszélgetést, és nem kapja vissza. OpenAI útmutatója a legtisztább publikált megfogalmazás: a handoff „egyirányú átadás, amely lehetővé teszi, hogy egy agent másik agentre delegáljon... Ha egy agent handoff függvényt hív, azonnal elindítjuk a végrehajtást azon az új agenten, amelynek átadták, miközben a legfrissebb beszélgetésállapotot is átvisszük.”⁸

Szókészleti figyelmeztetés, mert ez állandóan megbotlatja az embereket: a „handoff” egy SDK szava, nem szabvány. Az OpenAI Agents SDK és az útmutató terminológiája; az útmutató a két elrendezést „manager” és „decentralized” néven is említi, és megjegyzi, hogy a manager mintában „az élek tool callokat jelentenek, míg a decentralized mintában az élek handoffokat jelentenek”.⁸ Van nyílt szabvány ezen a területen — az A2A, 1.0.0 verziónál, a Linux Foundation copyrightja alatt, verziózott release historyval és dokumentált breaking changes listával, amelynek kimondott elve az opaque execution: az agentek „deklarált képességek és kicserélt információ alapján működnek együtt, anélkül, hogy meg kellene osztaniuk belső gondolataikat, terveiket vagy eszközimplementációikat”.⁹ Ez nem handoff, és az összehasonlítás a 26. fejezetbe tartozik. Itt az számít, hogy a két szó közül az egyik egy könyvtár API-ja, a másik pedig kormányzással rendelkező specifikáció.

A különbség adatstruktúra, nem 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;
}

Húsz sor, két bug, amelyet különben productionben találnál meg. reachable megtalálja azt az agentet, amelyhez senki sem tud eljutni — konfigurálva, kifizetve, soha meg nem hívva. conflicts visszautasítja azt az élt, amely egyszerre mindkét fajta; ez pedánsnak hangzik, amíg hangosan ki nem mondod: a szülő egyszerre tartja meg az irányítást és adja is át. Futtasd egy öt agentből álló rendszeren, egy orphan-nel és egy dupla éllel:

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

Most az a mérés, amelyért ez a szekció létezik, és az egyetlen ebben a fejezetben, amely valódi modell ellen futott, nem szkriptelt ellen.

Egy ügyfél már az első üzenetében megad egy korlátozást — a fiókunk Portugáliában van regisztrálva, nem Spanyolországban; minden adózással kapcsolatos dolgot Portugáliával kell kezelni —, beszélget valami másról, majd olyan kérdést tesz fel, amelyre a számlázásnak kell válaszolnia. Az ügy átadásra kerül. Huszonnégy próba, minden alkalommal más ország és cég, négy átadási payload, majd a fogadó agent egyetlen kérdést kap: melyik országban van regisztrálva ennek az ügyfélnek a fiókja?

A harmadik sor kontroll, és úgy is viselkedik: a tény nincs ott, tehát nem lehet felidézni. A másik három a finding.

A teljes transcript 173 token, és az esetek 83 %-ában működik; a négy hiba inkább a 24. fejezet tárgya, nem ezé. A tipizált rekord 69 token — héttel több, mint az összefoglaló — és minden alkalommal működik, mert a korlátozás névvel ellátott mezőben ül, nem mondatban.

Az összefoglaló sora az, amelyet nézni kell. 24-ből 24-szer megbukott, és nem azért, mert az olvasó elszalasztotta. A korlátozás a 24 összefoglalóból összesen 1-ben jelent meg. A fogadó agent nem volt figyelmetlen; olyan szöveget kapott, amely nem tartalmazta a választ. Az összefoglaló olyan tömörítés, amelyet nem te írtál, egy modell állítja elő, amelynek context window-ját nem látod, és arra optimalizál, hogy összefoglalónak hasson — márpedig „az ügyfél szerint a rekordjainkban rossz ország szerepel” pontosan az a mellékmondat, amelyet egy summariser eljárási zajként dob el.

Őszinte korlát ehhez a számhoz: a summariser félmilliárd paraméteres modell, és egy nagyobb többet megtartana. Ami mérettel sem javul, az a kockázat alakja — a küldő agent handoffonként, megfogalmazásonként, megfigyelhetetlenül dönt arról, mely tények maradnak életben. A tipizált rekord egyáltalán nem függ ettől az ítélettől, ezért konstrukcióból győz, nem intelligenciából. Ami túl kell éljen egy átadást, mező legyen, ne mondat.

Ugyanez az érvelés a másik irányban is érvényes, az agent-as-tool topológiára, és a korábbi tábla már beárazta: ami egy workertől visszajön, az is összefoglaló, és 8,3 %-kal többet fizetni azért, hogy a bizonyíték is visszajöjjön vele, ugyanaz a javítás a szülő oldaláról nézve.

Három záró tény, mind a fenti táblákból.

Egy multi-agent rendszer szorozza a hívásokat, a hívások pedig kvadratikusak a contextben. Az orchestrator 12 modellhívást tett ott, ahol egy agent 5-öt, és mindegyik viszi a saját növekvő transcriptjét — 3 628 input token a 2 697-tel szemben, és ez a rés a feladat hosszával nő.

Minden határ veszteséges csatorna. Két agent egy összefoglalót jelent. Négy agent láncban hármat, egymásra épülve, mindegyiket egy modell írja, amely valami másra optimalizál, mint a te döntésed.

Az egyetlen agent olyasmit talált, amit senki sem kért. A beszerzési rendelés eltérése azért került felszínre, mert egy context window-ban egyszerre volt ott a számla és a rendelés. A specialisták közötti felosztás azt a képességet is felosztja, hogy észrevegyük: két tény ellentmond egymásnak.

Mindez nem a publikált multi-agent frameworkök ellen szól; ezeket elsődleges forrásként érdemes olvasni, nem tutorialokon keresztül.¹⁰ Amellett érvel, hogy a második agent érdemelje ki a helyét.

Tehát teszt, nem preferencia. Akkor adj hozzá második agentet, ha ezek közül legalább egy igaz: a részfeladatnak tiszta context window kell, amelyet a szülő nem örökölhet (24. fejezet); a részfeladatok valóban függetlenek, és számít a falióra-idő — ez a fenti 1,8×; a részfeladatnak eltérő jogosultságok vagy másik modell kell, amit a 30. fejezet security érvvé alakít; vagy a részfeladatot valaki más birtokolja, ahol egy valódi protocol kezd számítani. Ha a válasz az, hogy „így minden agentnek tisztább promptja van”, adj az egyetlen agentnek tisztább promptot. Ingyen van.

Most már meg tudod nevezni az öt mintát, be tudod árazni őket egymáshoz képest egy feladaton, meg tudod különböztetni az orchestratort a sectionertől és a tool callt a handofftól, és egyetlen agentet táblával tudsz védeni, nem preferenciával.

Itt minden elrendezés osztozott egy kényelmen, amely semmi valódival találkozva nem marad életben: minden eszköz a miénk volt. Számla, rendelés, adótábla, az orchestrator mögötti workerek — ugyanaz a repository, ugyanaz a deploy, ugyanazok a típusok, ugyanazok az emberek.

Most tedd az egyiket egy céghatár túloldalára. Az adótábla egy könyvelési vendoré, a rendelési rekord egy raktári rendszeré, és egyik sem olvasta a te Tool interfészedet. Kell egy mód arra, hogy egy modell, amelyet nem te írtál, felfedezzen, leírjon és meghívjon egy képességet, amelyet valaki más üzemeltet — authenticationnel (ez a 27. fejezet fele), versioninggel, és azzal a garanciával, hogy egy server nem olvashatja a beszélgetésed többi részét. Ez protocol probléma, van hozzá normatív schemával rendelkező specifikáció, és szinte minden, amit indexeltek róla, olyan revisiont ír le, amely már nem létezik.

A 26. fejezet összefoglalás helyett ezt a specifikációt olvassa, és azzal kezd, hogy kézzel beírja a JSON-RPC-t egy terminalba.

A fenti minden költség és token count a második szekcióban leírt szkriptelt szolgáltatótól jött, Node 22-n, loopback interfészen, o200k_base encodinggal számolva, és azokkal az árakkal árazva, amelyeket a 16. fejezet 2026. szeptember 6-án olvasott — $2,00 millió input tokenenként és $12,00 millió outputonként. A falióra-adatok ugyanazokból a futásokból származnak, a provider latencyje hívásonként 400 ms-ra, az eszközöké 50 ms-ra állítva, tehát az elrendezést mérik, nem valamelyik providert. A két valódi modellen végzett mérés — a handoff tábla és a voting-and-judging tábla — Qwen/Qwen2.5-0.5B-Instruct-t használt float32-ben, CPU-n, azonos alakú endpoint mögött, greedy módon, kivéve ahol temperature szerepel, az intervallumokat pedig a 4. fejezet Wilson-módszerével számítva. Ebben a fejezetben egyetlen request sem ment fizetős endpointnak, és egyetlen szám sem becslés.