Multi-Agent समन्वयन: पाँच पैटर्न, और कब एक ही जीतता है

एक Portuguese company invoice FT-2026-0918 के बारे में लिखती है। Email कहता है कि VAT गलत लग रहा है, और invoice attach करता है: net EUR 248.00, VAT 21 % पर charge, EUR 52.08, total EUR 300.08।

Answer देने के लिए जिन facts की जरूरत है वे तीन जगहों पर हैं, और उनमें से सिर्फ एक email में है:

तीनों को साथ रखिए और invoice गलत है: reverse charge applied, VAT zero होना चाहिए था, EUR 52.08 का credit note देना है। सिर्फ invoice देखें तो वह arithmetic में perfect है — 248.00 plus 52.08 is 300.08 — और आप वही कहेंगे।

Email सचमुच कहता है "we are a Portuguese company"। वह claim है, record नहीं, और कोई billing system claim पर credit note issue नहीं करता। Trap कोई चाल नहीं है: यह business work का साधारण shape है, जहाँ decision को एक ऐसा fact चाहिए जिसे fetch करने के बारे में किसी ने सोचा ही नहीं।

ऊपर की हर चीज Chapter 23 की style के scripted provider के खिलाफ चलती है, सिर्फ एक rule के साथ:

An answer may only use a fact that is in its prompt.

"model" अपने पास मौजूद हर tool के लिए एक-एक बार, catalogue order में पूछता है, फिर दिख रहे text पर fixed rule apply करता है। किसी arrangement के लिए कुछ अलग से script नहीं है, इसलिए opening table में differences model intelligence के claims नहीं हैं: वे information routing हैं, measured. Real model इसके ऊपर अपनी failures जोड़ता है; इन्हें हटाता नहीं।

नीचे के पाँच नाम Anthropic के हैं, Building effective agents से, जहाँ यह vocabulary settle हुई।¹ पाँचों ideas में से कोई नया नहीं है, और किस house ने किस चीज को क्या नाम दिया — और कौन-सा idea पुराना है — यह जानना आधी value है।

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

यही पूरा toolkit है: पाँच functions, कोई framework नहीं, और parallel वाला single line है — इसी बात को समझाने के लिए इसे draw करने के बजाय लिखना जरूरी है। अब हर एक, उसकी ancestry, price, और वह case जहाँ वह गलत होता है।

Prompt chaining "decomposes a task into a sequence of steps, where each LLM call processes the output of the previous one".¹ यह idea language models से पुराना है: यह pipeline है, और pipeline का trade है — data आने से पहले fixed control flow के बदले clarity।

हमारे task के लिए चार steps: invoice fields extract करना, arithmetic check करना, क्या owed है तय करना, reply लिखना। यहाँ यह दो अलग तरीकों से fail करता है, जो एक बार fail होने से अधिक सिखाता है।

--- 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 की cost $0.001940 रही और step two और three के बीच invoice fields खो गए, क्योंकि step three को arithmetic के बारे में एक sentence दिया गया था और कुछ नहीं। इसने holding message बनाया: बेकार, और साफ तौर पर बेकार।

Accumulating chain — opening table वाली row — की cost $0.003780 रही, यानी चार identical calls के लिए 95 % ज्यादा, क्योंकि अब हर step अपने से पहले की हर चीज लेकर चलता है। इसने dangerous output बनाया। Fluent, अपने arithmetic को cite करता हुआ, जिन numbers का उल्लेख करता है उन पर correct, और customer को बताता हुआ कि कुछ owed नहीं है जबकि EUR 52.08 owed है।

दोनों के बीच difference एक ternary है। जो chain कम carry करती है वह obviously incomplete answers बनाती है; जो chain सब कुछ carry करती है वह confidently wrong answers बनाती है — और भेजा सिर्फ दूसरा वाला जाता है।

असल failure इनमें से कोई नहीं है। असल failure यह है कि pipeline ने कुछ भी पढ़ने से पहले तय कर लिया कि यह task email contents पर चार steps का है। उस structure में कहीं यह कहने की जगह नहीं है कि "registration country इस email में नहीं है; जाओ और उसे लाओ"। Chaining तब सही है जब decomposition पहले से known और stable हो। यहाँ वह guess था, और guess ship हो गया।

Routing "classifies an input and directs it to a specialized followup task".¹ नाम नया है; mechanism dispatcher है, इस book की लगभग हर चीज से पुराना। नया यह है कि classifier model हो सकता है — और इसी से यह उन तरीकों से fail करता है जिनसे switch कभी नहीं करता था।

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

उस last argument के बारे में दो बातें। यह error handling नहीं है; यही pattern है। Model-based router में dispatcher से अलग failure mode होता है: वह ऐसा label return कर सकता है जो exist नहीं करता, time out कर सकता है, या — महँगा वाला — बिना किसी signal के plausible wrong label return कर सकता है। तीनों को कहीं land करना होगा, और वह जगह एक और model call नहीं हो सकती, क्योंकि आप already उस branch में हैं जहाँ model calls fail हुए।

दूसरी बात यह है कि router का अपना prompt free नहीं है। Model चुनने के लिए router को चुनने के लिए models का catalogue चाहिए, और उसकी हर entry ऐसा input है जिसके लिए router user का question पढ़ने से पहले ही pay करता है। जिस input rate से यह course price करता है, उस पर लगभग 3,800 tokens का catalogue already उतना cost करता है जितना opening table का पूरा five-call agent run। Practice में routing call सस्ते model पर चलता है, और यही पूरी वजह है कि routing अपनी कीमत खुद वसूल लेता है; लेकिन assume करने के बजाय arithmetic उस direction में करना worth है। Routing ठीक तब wrong है जब routed task routing decision से सस्ता हो।

Anthropic इसे दो हिस्सों में बाँटता है: sectioning — "breaking a task into independent subtasks run in parallel" — और voting — "running the same task multiple times to get diverse outputs".¹ दोनों diagram share करते हैं और इसके अलावा लगभग कुछ भी नहीं।

Sectioning cheap win है, और यह patterns.ts की line है: तीन specialists — billing, tax, policy — हर एक अपनी window और tools के साथ, same email पर, अंत में एक synthesis call। Identical work, दो order में:

Same token for token, 1.8 times faster. इसी से pattern अपना नाम कमाता है: पाँचों में यही अकेला है जो कुछ improve करता है बिना कुछ cost किए। Catch यह है कि sections सचमुच independent होने चाहिए — section B को ऐसा fact दीजिए जो section A produce करता है और Promise.all दोनों को ऐसी state के खिलाफ चलाता है जो अभी exist ही नहीं करती। for loop ने वह bug छिपा दिया; one-liner उसे expose करता है।

Voting उसी picture को पहने एक अलग जीव है। Same question को k times चलाकर majority लेना self-consistency है, जिसे Wang et al. ने March 2022 में decoding strategy के रूप में publish किया था, लगभग तीन साल पहले कि किसी ने इसे orchestration pattern कहा। उसका abstract mechanism के बारे में precise है — "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" — और gain के बारे में भी: GSM8K पर +17.9 points।²

इससे दो बातें निकलती हैं जिन्हें picture छिपा देता है। पहली, voting को Chapter 17 की sampling चाहिए: temperature zero पर सभी k samples वही same sample हैं, और majority एक answer है जिसके लिए k times pay किया गया। दूसरी, यह सिर्फ वहाँ काम करता है जहाँ majority meaningful हो — ऊपर की invoice reply पर count करने को कुछ नहीं है, क्योंकि पाँच drafts पाँच अलग sentences हैं। Voting उन tasks के लिए है जिनका answer छोटा और comparable हो, जो Wang के benchmarks बिल्कुल हैं और customer-facing agent जो करता है उसमें लगभग कुछ भी नहीं।

यहाँ 20 three-step word problems पर measured, जिनके answers judged नहीं बल्कि computed हैं, Chapter 23 के local model के साथ step by step reasoning करते हुए:

Calls पाँच गुना, tokens पाँच गुना, bill ठीक पाँच गुना, और एक भी additional correct answer नहीं। Voting एक bet है, improvement नहीं, और यह run वह bet हार गया।

दो caveats, इससे पहले कि कोई इसे Wang का refutation quote करे। Twenty trials 45 % और 60 % में distinguish नहीं कर सकते — interval claim की width ही है, यानी Chapter 4 की discipline मेरे अपने result पर लागू। और published gains orders of magnitude larger models से आते हैं, जहाँ diverse reasoning paths जिन्हें voting marginalise करता है, सचमुच diverse होते हैं। Transfer होने वाली चीज number नहीं है: यह है कि multiplier exact और advance में known है, जबकि gain neither.

Orchestrator-workers workflow में "a central LLM dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results", और sectioning से difference यह है कि "subtasks aren't pre-defined, but determined by the orchestrator".¹ इसकी ancestry language models से बिल्कुल नहीं आती: यह master-worker है, और वह version जहाँ workers findings को shared space में लिखते हैं जिसे controller पढ़ता है, blackboard architecture है, 1970s की speech understanding research से। 2026 में नया यह है कि controller model है और इसलिए decomposition हर input पर decide हो सकती है — flexibility और cost, एक ही sentence में।

Single agent के 5 calls के मुकाबले इसकी cost 12 model calls रही, और वही verdict मिला। फिर इसने कुछ ऐसा किया जिसे ध्यान से देखना चाहिए:

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

दोनों सही हैं। सिर्फ एक जानता है क्यों। Tax worker के पास अपनी window में invoice, order और tax table थे, उसने conclusion निकाला, और यह भी notice किया — किसी ने पूछा नहीं था — कि invoice पर purchase order number order से match नहीं करता। फिर उसने summary return की। Orchestrator दोनों statements repeat कर सकता है और किसी को check नहीं कर सकता, क्योंकि evidence उस window में रह गया जिसे उसने कभी देखा ही नहीं। यह Chapter 24 का closing question है, answered: parent वही देखता है जो child ने लिखना चुना।

Fix एक flag है, और उसकी price है:

बारह per cent more input tokens, 8.3 % ज्यादा money, और phrase source=worker_unverified answer से गायब हो जाता है। हर multi-agent system में यही trade है और इसे लगभग कभी stated नहीं किया जाता: child की clean window valuable है, parent की उसे audit करने की ability paying for है, और दोनों free में नहीं मिलते।

तो orchestrator-workers कब wrong है? यहाँ, इस task पर। इसने एक correct answer खरीदा जो same चार tools वाले एक agent ने भी पाया, 1.66 times cost और 2.3 times wall clock पर, और उस answer को defend करना कठिन बना दिया। Anthropic की अपनी guidance patterns शुरू होने से पहले ही यह कहती है: "the simplest solution possible, and only increasing complexity when needed" खोजिए, क्योंकि "agentic systems often trade latency and cost for better task performance".¹ ऊपर की tables वही sentence हैं, numbers के साथ।

एक call generate करता है, दूसरा evaluate करता है, और loop तब तक repeat होता है जब तक evaluation pass नहीं होती।¹ Published ancestors हैं Self-Refine — वही model "generator, refiner, and feedback provider" के रूप में, सात tasks पर averaged लगभग 20 points absolute improvement report करते हुए³ — और Reflexion, जो critique को attempts के across episodic buffer में store करता है और HumanEval पर 91 % pass@1 report करता है जहाँ baseline 80 % पहुँचा।⁴

Cost model पाँचों में सबसे simple है: हर round में दो calls, और round count आपका नहीं है। एक task पर refinement के तीन rounds, जिसमें one call लगता, six calls हैं, इसलिए pattern का floor 6× है और ceiling वह cap है जो आप set करें — जिससे Chapter 23 का budget exit tidy नहीं बल्कि mandatory हो जाता है।

Ceiling अधिक subtle है, और measurable है। उन्हीं 20 problems पर local model ने 9 सही answer दिए। फिर उसे उसके हर answer दिखाए गए और पूछा गया कि क्या यह सही है — बिना बताए कि answer उसका अपना है, जिससे flattery confound हटता है और capability वाला बचता है:

यह section title जितना imply करता है उससे better judge है, और यही measuring instead of asserting का point है: इसने कोई correct block नहीं किया और 11 mistakes में से 8 पकड़ीं। Filter के रूप में, यह अपने calls के लायक है।

Stopping rule के रूप में, जो evaluator-optimiser loop असल में इसे बनाता है, वे तीन approvals पूरी story हैं: वे loop को wrong answer हाथ में लिए end कर देते हैं, और कितने भी extra rounds कभी उन तक नहीं पहुँचते। Refinement loop अपने judge से ज्यादा correct नहीं हो सकता। More rounds खरीदना उन errors पर attempts खरीदना है जिन्हें judge देख सकता है, full price पर, और जिन्हें वह नहीं देख सकता उनके खिलाफ कुछ भी नहीं।

इसलिए rule: evaluator अपने calls तभी कमाता है जब उसके पास generator से अलग कुछ हो। Compiler, test suite, schema validator, different model, human. Self-Refine के अपने results human preference और task metrics के against measured हैं, model की अपने बारे में राय के against कभी नहीं। अगर आपके evaluator का only advantage अलग prompt है, तो आप agreement के लिए double pay कर रहे हैं। Chapter 29 real advantage वाला version बनाता है: एक golden set जिसमें answers advance में लिखे होते हैं।

ऊपर के पाँच आपके code के shapes हैं। उनके नीचे एक second family बैठती है जिसे अक्सर उनके साथ list किया जाता है और नहीं किया जाना चाहिए: ReAct, Reflexion, plan-and-execute और tree of thoughts reasoning loops हैं, और उनकी cost requests में है।

Chapter 12 model के भीतर reasoning के बारे में था, जिसके लिए आप one call पर output tokens में pay करते हैं। यह दूसरा kind है। Bill आने पर difference matter करता है: longer chain of thought one call को expensive बनाती है, और reasoning loop one task को many calls में बदल देता है, जिनमें से हर एक अपने पहले की हर चीज फिर भेजता है — वही quadratic जिसे Chapter 23 ने runaway table में measured किया।

Tree-of-thoughts paper अपनी cost table publish करता है, जो जितना rare होना चाहिए उससे अधिक rare है। Game of 24 पर GPT-4 के साथ: input/output prompting best-of-100 ने 33 % solve किया $0.13 per case पर, chain of thought best-of-100 ने 49 % solve किया $0.47 पर, और tree of thoughts ने 74 % solve किया $0.74 पर, authors ने note किया कि यह "could require 5-100 times more generated tokens than CoT".⁷

Cheap method की price से लगभग six times, success rate से कुछ ज्यादा than double। यह bargain है या नहीं, यह depend करता है कि failed case आपको कितना cost करता है — इन चारों में से किसी को adopt करने से पहले यही question पूछना चाहिए।

यह course इन्हें reimplement नहीं करता। चारों के reference implementations उनके authors द्वारा, Python में हैं, और उनकी value source होना है, translation नहीं: ysymyth/ReAct, noahshinn/reflexion, princeton-nlp/tree-of-thought-llm और AGI-Edgerunners/Plan-and-Solve-Prompting। उन repositories में prompts पढ़िए; prompts ही papers हैं।

अब proper multi-agent, जहाँ सबसे ज्यादा confusion रहती है। एक agent दूसरे को involve करने के दो तरीके हैं, वे variants नहीं हैं, और difference यह है कि बाद में charge किसके पास है।

Agent as a tool. Parent उसे call करता है, answer पाता है, और continue करता है। यह Chapter 18 tool interface है जिसके पीछे पूरा agent है, और parent कभी control नहीं खोता। ऊपर वाला orchestrator यही करता है।

Handoff. Parent conversation transfer करता है और उसे वापस नहीं पाता। OpenAI की guide सबसे clear published statement है: handoffs "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."⁸

Vocabulary warning, क्योंकि यह लोगों को लगातार अटका देता है: "handoff" एक SDK का word है, standard नहीं। यह OpenAI Agents SDK और उस guide की terminology है, जो दो arrangements को "manager" और "decentralized" भी नाम देती है और note करती है कि manager pattern में "edges represent tool calls whereas in the decentralized pattern, edges represent handoffs".⁸ इस space में एक open standard है — A2A, version 1.0.0 पर, Linux Foundation के copyright के तहत, versioned release history और breaking changes की documented list के साथ, जिसका stated principle opaque execution है: agents "collaborate based on declared capabilities and exchanged information, without needing to share their internal thoughts, plans, or tool implementations".⁹ यह handoff नहीं है, और comparison Chapter 26 में आता है। यहाँ matter यह करता है कि दो words में से एक library की API है और दूसरा governance वाली specification।

Distinction diagram नहीं, data structure है:

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

Twenty lines, दो bugs जो वरना production में मिलते। reachable उस agent को find करता है जहाँ कोई पहुँच नहीं सकता — configured, paid for, never called. conflicts उस edge को refuse करता है जो दोनों kinds एक साथ है, जो pedantic लगता है जब तक आप उसे aloud नहीं पढ़ते: parent control रखता भी है और दे भी देता है। इसे एक five-agent system पर चलाइए जिसमें one orphan और one double edge हो:

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

अब वह measurement जिसके लिए यह section मौजूद है, और chapter में अकेला जो scripted के बजाय real model के खिलाफ लिया गया।

Customer अपनी first message में एक constraint बताता है — our account is registered in Portugal, not Spain; everything tax-related has to use Portugal — फिर किसी और बात पर chat करता है, फिर billing को answer देने वाला question पूछता है। Case transfer किया जाता है। Twenty-four trials, हर बार different country और company, four transfer payloads, और receiving agent से फिर एक question पूछा जाता है: इस customer's account किस country में registered है?

तीसरी row control है और control जैसी behave करती है: fact वहाँ है ही नहीं, इसलिए recall नहीं हो सकता। बाकी तीन finding हैं।

Full transcript 173 tokens है और 83 % time काम करता है, इसकी चार failures Chapter 24 का subject हैं, इस chapter का नहीं। Typed record 69 tokens — summary से seven more — और हर बार काम करता है, क्योंकि constraint sentence के बजाय named field में बैठता है।

और summary वह row है जिसे घूरना चाहिए। यह 24 में 24 बार fail हुई, और reason यह नहीं कि reader ने miss किया। Constraint 24 summaries में केवल 1 में आया ही था। Receiving agent careless नहीं था; उसे ऐसा text दिया गया था जिसमें answer था ही नहीं। Summary एक compaction है जिसे आपने नहीं लिखा, ऐसे model द्वारा produced जिसकी window आप नहीं देख सकते, summary जैसा पढ़ने के लिए optimised — और "customer says our records have the wrong country" ठीक वही clause है जिसे summariser procedural noise समझकर drop करता है।

उस number पर honest limit: summariser half-billion-parameter model है और larger one अधिक keep करेगा। Size के साथ जो improve नहीं होता वह risk का shape है — sending agent, हर handoff पर, हर phrasing पर, unobservably decide करता है कि कौन-से facts survive करते हैं। Typed record उस judgement पर depend नहीं करता, इसलिए वह intelligence से नहीं बल्कि construction से जीतता है। जो भी transfer में survive करना must है वह field होना चाहिए, sentence नहीं।

Same reasoning दूसरी direction में, agent-as-tool topology पर भी apply होती है, और earlier table ने already इसे price किया: worker से जो वापस आता है वह भी summary है, और उसके साथ evidence receive करने के लिए 8.3 % अधिक pay करना parent की side से देखा वही fix है।

तीन closing facts, सब ऊपर की tables से।

Multi-agent system calls को multiply करता है, और calls context में quadratic हैं। Orchestrator ने वहाँ 12 model calls किए जहाँ one agent ने 5 किए, और हर call अपनी बढ़ती transcript carry करता है — 2,697 के against 3,628 input tokens, एक gap जो task की length के साथ widen होता है।

हर boundary lossy channel है। Two agents मतलब one summary. Chain में four agents मतलब three summaries, composed, हर एक ऐसे model द्वारा written जो आपकी decision के अलावा किसी और चीज के लिए optimise कर रहा है।

Single agent ने वह चीज ढूँढी जिसे किसी ने नहीं पूछा। Purchase-order mismatch surfaced हुआ क्योंकि one window में invoice और order साथ थे। Specialists में काम बाँटना यह notice करने की ability भी बाँट देता है कि दो facts disagree करते हैं।

इनमें से कोई भी published multi-agent frameworks के खिलाफ argument नहीं है, जिन्हें tutorials के बजाय primary sources की तरह पढ़ना चाहिए।¹⁰ यह argue करता है कि second agent अपनी जगह earn करे।

तो preference नहीं, test. Second agent तब add करें जब इनमें से कम से कम एक true हो: sub-task को ऐसी clean window चाहिए जिसे parent inherit न करे (Chapter 24); sub-tasks genuinely independent हैं और wall clock matter करता है, यानी ऊपर का 1.8×; sub-task को different permissions या different model चाहिए, जिसे Chapter 30 security argument में बदलता है; या sub-task someone else owned है, जहाँ real protocol matter करना शुरू करता है। अगर answer है "ताकि हर agent का prompt clearer हो", तो one agent को clearer prompt दीजिए। यह free है।

अब आप पाँच patterns के नाम बता सकते हैं, एक task पर उन्हें एक-दूसरे के against price कर सकते हैं, orchestrator और sectioner, tool call और handoff में फर्क बता सकते हैं, और preference के बजाय table से single agent defend कर सकते हैं।

यहाँ हर arrangement ने एक convenience share की जो किसी real चीज से contact के बाद survive नहीं करेगी: सभी tools हमारे थे। Invoice, order, tax table, orchestrator के पीछे workers — same repository, same deploy, same types, same people.

अब इनमें से एक को company boundary के दूसरी side रखिए। Tax table किसी accounting vendor की है, order record warehouse system का, और दोनों में से किसी ने आपकी Tool interface नहीं पढ़ी। आपको ऐसे model के लिए जिसे आपने नहीं लिखा, किसी और द्वारा operated capability discover, describe और call करने का तरीका चाहिए — authentication (जो Chapter 27 का half है), versioning, और यह guarantee कि server आपकी बाकी conversation नहीं पढ़ सकता। यह protocol problem है, इसकी normative schema वाली specification है, और इसके बारे में indexed लगभग हर चीज ऐसी revision describe करती है जो अब exist नहीं करती।

Chapter 26 उस specification को summarise करने के बजाय पढ़ता है, और terminal में हाथ से JSON-RPC type करने से शुरू करता है।

ऊपर की हर cost और token count second section में described scripted provider से आया, Node 22 पर loopback interface के ऊपर, o200k_base encoding से counting करके और उन rates पर priced जिन्हें Chapter 16 ने 6 September 2026 को पढ़ा था — $2.00 per million input tokens और $12.00 per million output. Wall-clock figures same runs से हैं जिनमें provider की latency 400 ms per call और tools 50 ms set थे, इसलिए वे किसी provider के बजाय arrangement measure करते हैं। दो real-model measurements — handoff table और voting-and-judging table — ने same shape के endpoint के पीछे CPU पर float32 में Qwen/Qwen2.5-0.5B-Instruct use किया, greedy except जहाँ temperature stated है, intervals Chapter 4 की Wilson's method से computed. इस chapter की कोई request paid endpoint पर नहीं गई, और इसमें कोई number estimate नहीं किया गया।