Multi-Agent Orchestration: پانچ patterns، اور کب ایک ہی جیتتا ہے

ایک Portuguese company invoice FT-2026-0918 کے بارے میں لکھتی ہے۔ email کہتی ہے کہ VAT غلط لگ رہا ہے، اور invoice attach کرتی ہے: net EUR 248.00، VAT 21 % پر charged، 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 کی ordinary shape ہے، جہاں decision کو ایک ایسا fact چاہیے جسے fetch کرنے کا کسی نے سوچا ہی نہیں۔

اوپر کا سب کچھ Chapter 23 جیسے scripted provider کے خلاف چلتا ہے، صرف ایک rule کے ساتھ:

ایک answer صرف وہ fact use کر سکتا ہے جو اس کے prompt میں ہو۔

”model“ اپنے پاس موجود ہر tool کو catalogue order میں ایک بار مانگتا ہے، پھر جو text وہ دیکھ سکتا ہے اس پر fixed rule apply کرتا ہے۔ کسی arrangement کے لیے کچھ separately scripted نہیں، اس لیے opening table کے differences model intelligence کے claims نہیں: یہ information routing ہے، measured۔ ایک real model اپنی failures اوپر add کرتا ہے؛ انہیں remove نہیں کرتا۔

نیچے کے پانچ names Anthropic کے ہیں، Building effective agents سے، جہاں یہ vocabulary settle ہوئی۔¹ پانچوں ideas میں سے کوئی نئی نہیں، اور یہ کہنا کہ کس گھر نے کیا name دیا — اور کون سی idea older ہے — انہیں جاننے کی آدھی 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 ہے — point بھی یہی ہے کہ اسے draw کرنے کے بجائے لکھا جائے۔ اب ہر ایک باری باری، اس کی ancestry، price، اور وہ case جہاں یہ غلط ہے۔

Prompt chaining ”ایک task کو steps کی sequence میں decompose کرتا ہے، جہاں ہر LLM call پچھلے one کے output کو process کرتی ہے“۔¹ idea language models سے پرانی ہے: یہ pipeline ہے، pipeline کا trade — data آنے سے پہلے fixed control flow کے بدلے clarity۔

ہمارے task کے لیے چار steps: invoice fields extract کریں، arithmetic check کریں، decide کریں کیا owed ہے، reply لکھیں۔ یہاں یہ دو مختلف ways میں 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 ہوئی اور steps two اور three کے بیچ invoice fields کھو گئے، کیونکہ step three کو arithmetic کے بارے میں ایک sentence ملا اور کچھ نہیں۔ اس نے holding message بنایا: useless، اور visibly useless۔

accumulating chain — opening table والی row — کی cost $0.003780 ہوئی، جو چار identical calls کے لیے 95 % زیادہ ہے، کیونکہ اب ہر step اپنے سے پہلے کی ہر چیز carry کرتا ہے۔ اس نے dangerous output بنایا۔ Fluent، اپنی arithmetic cite کرتا ہوا، جس ہر number کا ذکر کیا اس پر correct، اور customer کو بتاتا ہوا کہ کچھ owed نہیں جبکہ EUR 52.08 owed ہے۔

دونوں کے بیچ فرق ایک ternary ہے۔ جو chain کم carry کرتی ہے وہ answers بناتی ہے جو obviously incomplete ہوتے ہیں؛ جو chain سب کچھ carry کرتی ہے وہ answers بناتی ہے جو confidently wrong ہوتے ہیں — اور صرف دوسری قسم send ہوتی ہے۔

اصل failure ان میں سے کوئی نہیں۔ اصل failure یہ ہے کہ pipeline نے کچھ پڑھنے سے پہلے decide کر لیا کہ یہ task email contents پر چار steps ہے۔ اس structure میں کہیں جگہ نہیں کہ کہا جائے ”registration country اس email میں نہیں؛ جا کر لاؤ“۔ Chaining تب درست ہے جب decomposition پہلے سے known اور stable ہو۔ یہاں یہ guess تھا، اور guess ship ہو گیا۔

Routing ”input کو classify کرتا ہے اور اسے specialized followup task کی طرف direct کرتا ہے“۔¹ name نیا ہے؛ mechanism dispatcher ہے، اس book کی تقریباً ہر چیز سے older۔ نئی بات یہ ہے کہ classifier model ہو سکتا ہے — اور یہی اسے ان ways میں fail کراتا ہے جن میں switch کبھی fail نہیں ہوا۔

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 کے بارے میں دو things۔ یہ error handling نہیں؛ یہی pattern ہے۔ model-based router کا failure mode dispatcher کے پاس نہیں: یہ ایسا label return کر سکتا ہے جو exist نہیں کرتا، time out کر سکتا ہے، یا — expensive one — plausible wrong label return کر سکتا ہے جس میں کوئی signal نہیں کہ وہ wrong ہے۔ تینوں کو کہیں land کرنا ہے، اور وہ somewhere ایک اور model call نہیں ہو سکتا، کیونکہ آپ پہلے ہی اس branch میں ہیں جہاں model calls failed۔

دوسری بات یہ ہے کہ router کا اپنا prompt free نہیں۔ model choose کرنے کے لیے router کو models کا catalogue چاہیے جس میں سے choose کرے، اور اس کی ہر entry ایسا input ہے جس کی قیمت router user کا question پڑھنے سے پہلے ادا کرتا ہے۔ جس input rate سے یہ course prices لگاتا ہے، اس پر تقریباً 3,800 tokens کا catalogue پہلے ہی opening table کے پورے five-call agent run جتنا cost کرتا ہے۔ عملی طور پر routing call ایک cheap model پر چلتی ہے، اور یہی پوری وجہ ہے کہ routing اپنی قیمت خود پوری کرتی ہے؛ لیکن assume کرنے کے بجائے arithmetic اسی سمت میں کر کے دیکھنا worth it ہے۔ Routing ٹھیک اس وقت wrong ہے جب routed task خود routing decision سے cheaper ہو۔

Anthropic اسے دو میں split کرتا ہے: sectioning — ”task کو independent subtasks میں break کرنا جو parallel run ہوں“ — اور voting — ”diverse outputs حاصل کرنے کے لیے same task کو multiple times run کرنا“۔¹ دونوں diagram share کرتے ہیں اور تقریباً کچھ اور share نہیں کرتے۔

Sectioning cheap win ہے، اور یہ patterns.ts کی line ہے: تین specialists — billing، tax، policy — ہر ایک اپنی window اور tools کے ساتھ، same email پر، end میں ایک synthesis call۔ identical work، دو ways سے ordered:

Token for token same، 1.8 times faster۔ اسی لیے pattern اپنا name earn کرتا ہے: یہ پانچوں میں واحد ہے جو کچھ improve کرتا ہے بغیر کچھ cost کیے۔ catch یہ ہے کہ sections genuinely independent ہونے چاہئیں — section B کو وہ fact دیں جو section A produce کرتا ہے اور Promise.all دونوں کو ایک ایسی state کے خلاف run کرتا ہے جو ابھی exist نہیں کرتی۔ for loop نے bug چھپا دیا؛ one-liner اسے expose کرتا ہے۔

Voting اسی picture پہنا ہوا ایک different animal ہے۔ same question کو k times run کرنا اور 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۔²

اس سے دو things follow کرتی ہیں جو picture hide کرتی ہے۔ First، voting کو Chapter 17 کی sampling require ہے: temperature zero پر تمام k samples same sample ہیں، اور majority ایک answer ہے جس کے لیے k times pay کیا گیا۔ Second، یہ صرف وہاں کام کرتی ہے جہاں majority meaningful ہو — اوپر والے invoice reply میں count کرنے کو کچھ نہیں، کیونکہ پانچ drafts پانچ different sentences ہیں۔ Voting short، comparable answer والے tasks کے لیے ہے، جو Wang کے benchmarks exactly ہیں اور customer-facing agent کے تقریباً کسی کام کے نہیں۔

یہاں 20 three-step word problems پر measured، جن کے answers judged نہیں بلکہ computed ہیں، Chapter 23 کے local model کے ساتھ step by step reasoning کرتے ہوئے:

پانچ times calls، پانچ times tokens، exactly پانچ times bill، اور ایک بھی additional correct answer نہیں۔ Voting ایک bet ہے، improvement نہیں، اور اس run نے اسے ہار دیا۔

دو caveats، اس سے پہلے کہ کوئی اسے Wang کی refutation کے طور پر quote کرے۔ Twenty trials 45 % کو 60 % سے distinguish نہیں کر سکتے — interval claim کی width ہے، جو Chapter 4 کی discipline میرے اپنے result پر turn کی ہوئی ہے۔ اور published gains orders of magnitude larger models سے آتے ہیں، جہاں diverse reasoning paths جن پر voting marginalise کرتی ہے واقعی diverse ہوتے ہیں۔ جو transfer ہوتا ہے وہ number نہیں: یہ ہے کہ multiplier exact اور پہلے سے known ہے جبکہ gain نہیں۔

orchestrator-workers workflow میں ”ایک central LLM dynamically tasks کو break down کرتا ہے، انہیں worker LLMs کو delegate کرتا ہے، اور ان کے results synthesize کرتا ہے“، اور sectioning سے difference یہ ہے کہ ”subtasks pre-defined نہیں ہوتے، بلکہ orchestrator کے ذریعے determined ہوتے ہیں“۔¹ ancestry یہاں language models سے بالکل نہیں: یہ master-worker ہے، اور وہ version جہاں workers findings کو shared space میں لکھتے ہیں جسے controller پڑھتا ہے blackboard architecture ہے، 1970s کی speech understanding research سے۔ 2026 میں نئی بات یہ ہے کہ controller model ہے اور اس لیے decomposition per input decide ہو سکتی ہے — flexibility اور cost، ایک ہی sentence میں۔

اس کی cost single agent کی 5 calls کے مقابلے 12 model calls ہوئی، اور وہی verdict ملا۔ پھر اس نے ایک ایسا کام کیا جسے غور سے دیکھنا worth ہے:

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 کے number سے match نہیں کرتا۔ پھر اس نے summary return کی۔ orchestrator دونوں statements repeat کر سکتا ہے اور check neither، کیونکہ evidence اسی window میں رہ گئی جو اس نے کبھی نہیں دیکھی۔ یہ Chapter 24 کا closing question answered ہے: parent وہی دیکھ سکتا ہے جو child نے لکھنے کا انتخاب کیا۔

fix ایک flag ہے، اور اس کی price ہے:

بارہ per cent زیادہ input tokens، 8.3 % زیادہ money، اور phrase source=worker_unverified answer سے غائب ہو جاتا ہے۔ ہر multi-agent system میں trade یہی ہے اور تقریباً کبھی stated نہیں ہوتا: child کی clean window worth having ہے، parent کی audit کرنے کی ability worth paying for ہے، اور دونوں free نہیں ملتے۔

تو orchestrator-workers کب wrong ہے؟ یہاں، اس task پر۔ اس نے ایک correct answer خریدا جو same four tools کے ساتھ ایک agent نے بھی حاصل کر لیا، 1.66 times cost اور 2.3 times wall clock پر، اور اس answer کو defend کرنا harder بنا دیا۔ 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 پر average تقریباً 20 points absolute improvement report کرتے ہوئے³ — اور Reflexion، جو attempts کے across critique کو episodic buffer میں store کرتا ہے اور HumanEval پر 91 % pass@1 report کرتا ہے جہاں baseline 80 % تک پہنچا۔⁴

cost model پانچوں میں سب سے simple ہے: ہر round میں دو calls، اور round count آپ کا نہیں۔ ایک ایسے task پر refinement کے three rounds جسے ایک call لگی، six calls ہیں، اس لیے pattern کا floor 6× ہے اور ceiling وہ cap ہے جو آپ set کریں — جس سے Chapter 23 کا budget exit tidy کے بجائے mandatory ہو جاتا ہے۔

ceiling subtler ہے، اور measurable ہے۔ same 20 problems پر local model نے 9 correct answer کیے۔ پھر اسے ان میں سے ہر answer دکھایا گیا اور پوچھا گیا کہ آیا یہ right ہے — یہ بتائے بغیر کہ answer اسی کا اپنا تھا، جس سے flattery confound remove ہوتا ہے اور capability والی بات رہ جاتی ہے:

یہ section title کے imply کرنے سے بہتر judge ہے، اور یہی measuring کا point ہے asserting کے بجائے: اس نے کچھ correct block نہیں کیا اور 11 mistakes میں سے 8 catch کیں۔ filter کے طور پر یہ اپنی calls کے worth ہے۔

بطور stopping rule، جو evaluator-optimiser loop actually use کرتا ہے، وہ تین approvals پوری story ہیں: وہ loop کو ہاتھ میں wrong answer کے ساتھ end کر دیتے ہیں، اور extra rounds کی کوئی تعداد کبھی ان تک نہیں پہنچتی۔ refinement loop اپنے judge سے زیادہ correct نہیں ہو سکتا۔ مزید rounds خریدنا ان errors پر attempts خریدتا ہے جنہیں judge دیکھ سکتا ہے، full price پر، اور ان کے خلاف کچھ بھی نہیں جنہیں وہ نہیں دیکھ سکتا۔

لہٰذا rule: evaluator اپنی calls تبھی earn کرتا ہے جب اس کے پاس generator کے پاس نہ ہونے والی کوئی چیز ہو۔ compiler، test suite، schema validator، different model، human۔ Self-Refine کے own results human preference اور task metrics کے against measured ہیں، model کی اپنے بارے میں opinion کے against کبھی نہیں۔ اگر آپ کے evaluator کا واحد advantage different prompt ہے، آپ agreement کے لیے double pay کر رہے ہیں۔ Chapter 29 وہ version build کرتا ہے جس کے پاس real advantage ہے: golden set جس میں answers پہلے سے written down ہیں۔

اوپر کے پانچ آپ کے code کی shapes ہیں۔ ان کے نیچے ایک second family ہے جو اکثر ساتھ list کی جاتی ہے اور نہیں کی جانی چاہیے: ReAct، Reflexion، plan-and-execute اور tree of thoughts reasoning loops ہیں، اور ان کی cost requests میں ہے۔

Chapter 12 model کے اندر reasoning کے بارے میں تھا، جس کے لیے آپ ایک call کے output tokens میں pay کرتے ہیں۔ یہ دوسری kind ہے۔ bill آنے پر فرق matter کرتا ہے: longer chain of thought ایک call کو expensive بناتی ہے، اور reasoning loop ایک task کو many calls بناتا ہے، جن میں سے ہر ایک اپنے سے پہلے کی ہر چیز دوبارہ send کرتا ہے — وہ quadratic جسے Chapter 23 نے اپنی runaway table میں measure کیا۔

tree-of-thoughts paper اپنی cost table publish کرتا ہے، جو ہونا چاہیے اس سے rare ہے۔ GPT-4 کے ساتھ Game of 24 پر: 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 کے ساتھ کہ یہ ”CoT سے 5-100 times more generated tokens require کر سکتا ہے“۔⁷

cheap method کی price سے تقریباً six times، success rate کے double سے کچھ زیادہ کے لیے۔ یہ bargain ہے یا نہیں، اس پر depend کرتا ہے کہ failed case آپ کو کیا cost کرتا ہے — ان چاروں میں سے کسی کو adopt کرنے سے پہلے پوچھنے والا question۔

یہ course انہیں reimplement نہیں کرتا۔ چاروں کے reference implementations ان کے own 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 ہیں۔

اب multi-agent proper، جہاں زیادہ تر confusion رہتی ہے۔ ایک agent کے دوسرے کو involve کرنے کے دو ways ہیں، یہ variants نہیں، اور فرق یہ ہے کہ بعد میں in charge کون ہے۔

Agent as a tool۔ parent اسے call کرتا ہے، answer حاصل کرتا ہے، اور continue کرتا ہے۔ یہ Chapter 18 tool interface ہے جس کے پیچھے پورا agent ہے، اور parent control کبھی lose نہیں کرتا۔ اوپر 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، کیونکہ یہ لوگوں کو مسلسل trip کرتا ہے: ”handoff“ ایک SDK کا word ہے، standard نہیں۔ یہ OpenAI Agents SDK اور اس guide کی terminology ہے، جو دونوں arrangements کو ”manager“ اور ”decentralized“ بھی name کرتی ہے اور 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 اور documented list of breaking changes کے ساتھ، جس کا 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 میں belong کرتا ہے۔ یہاں important یہ ہے کہ دو 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 ڈھونڈتا ہے جس تک کوئی پہنچ نہیں سکتا — configured، paid for، کبھی called نہیں۔ conflicts اس edge کو refuse کرتا ہے جو دونوں kinds at once ہے، جو pedantic لگتا ہے جب تک آپ اسے aloud نہ پڑھیں: parent control رکھتا بھی ہے اور دے بھی دیتا ہے۔ اسے پانچ-agent system پر run کریں جس میں one orphan اور one double edge ہو:

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

اب وہ measurement جس کے لیے یہ section exists ہے، اور chapter میں واحد measurement جو scripted کے بجائے real model کے خلاف لیا گیا۔

Customer اپنی first message میں constraint state کرتا ہے — 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 کا account کس country میں registered ہے؟

تیسری row control ہے اور control کی طرح behave کرتی ہے: fact وہاں نہیں، سو recall نہیں ہو سکتا۔ باقی تین finding ہیں۔

full transcript 173 tokens ہے اور 83 % times کام کرتا ہے، اس کی four failures Chapter 24 کا subject ہیں، اس کا نہیں۔ typed record 69 tokens — summary سے سات زیادہ — اور ہر بار کام کرتا ہے، کیونکہ constraint sentence کے بجائے named field میں بیٹھا ہے۔

اور summary وہ row ہے جسے stare کرنا چاہیے۔ یہ 24 میں سے 24 times failed، اور reason یہ نہیں کہ reader نے miss کیا۔ constraint 24 summaries میں سے صرف 1 میں appear ہوا۔ receiving agent careless نہیں تھا؛ اسے ایسا text دیا گیا جس میں answer تھا ہی نہیں۔ summary ایسی compaction ہے جسے آپ نے نہیں لکھا، ایک model نے produce کی جس کی window آپ نہیں دیکھ سکتے، reading like a summary کے لیے optimised — اور ”customer says our records have the wrong country“ exactly اس kind کی 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 سے wins کرتا ہے۔ جو بھی transfer survive کرنا must ہے وہ field ہونا چاہیے، sentence نہیں۔

یہی reasoning دوسری direction میں بھی apply ہوتی ہے، agent-as-tool topology پر، اور earlier table اسے 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 کیں جہاں ایک agent نے 5 کیں، اور ہر ایک اپنی growing transcript carry کرتی ہے — 3,628 input tokens against 2,697، ایک gap جو task کی length کے ساتھ widen ہوتا ہے۔

ہر boundary lossy channel ہے۔ دو agents کا مطلب ایک summary۔ chain میں چار agents کا مطلب تین summaries، composed، ہر ایک model کے ذریعے لکھی گئی جو آپ کے decision کے علاوہ کسی چیز کے لیے optimising ہے۔

single agent نے وہ چیز find کی جو کسی نے نہیں پوچھی۔ purchase-order mismatch اس لیے surface ہوا کہ ایک window نے invoice اور order کو at once hold کیا۔ specialists کے across work split کرنا اس ability کو بھی split کرتا ہے کہ دو facts disagree کر رہے ہیں۔

یہ published multi-agent frameworks کے خلاف argument نہیں، جنہیں tutorials کے بجائے primary sources کے طور پر پڑھنا worth ہے۔¹⁰ یہ argument ہے کہ 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 کی ownership میں ہے، جہاں real protocol matter کرنا شروع کرتا ہے۔ اگر answer ہے ”تاکہ ہر agent کا prompt clearer ہو“، تو ایک agent کو clearer prompt دیں۔ یہ free ہے۔

اب آپ پانچ patterns کو name کر سکتے ہیں، ایک task پر ان کی قیمت compare کر سکتے ہیں، orchestrator کو sectioner سے اور tool call کو handoff سے الگ بتا سکتے ہیں، اور single agent کا دفاع preference کے بجائے table سے کر سکتے ہیں۔

یہاں ہر arrangement نے ایک convenience share کی جو کسی real چیز سے contact میں survive نہیں کرے گی: تمام tools ہمارے تھے۔ Invoice، order، tax table، orchestrator کے پیچھے workers — same repository، same deploy، same types، same people۔

اب ان میں سے ایک کو company boundary کے دوسری طرف رکھیں۔ tax table accounting vendor کی ہے، order record warehouse system کا، اور neither نے آپ کا Tool interface پڑھا ہے۔ آپ کو ایک way چاہیے کہ وہ 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 سے count کرتے ہوئے اور ان rates پر priced جو Chapter 16 نے 6 September 2026 کو read کیے — $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 تھے، اس لیے وہ arrangement کو measure کرتے ہیں، کسی provider کو نہیں۔ دو 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 method سے computed۔ اس chapter کی کوئی request paid endpoint پر نہیں گئی، اور اس میں کوئی number estimated نہیں تھا۔