هماهنگ‌سازی multi-agent: پنج الگو و زمان برنده‌شدن یکی از آن‌ها

یک شرکت پرتغالی درباره فاکتور FT-2026-0918 ایمیل می‌زند. ایمیل می‌گوید VAT اشتباه به نظر می‌رسد، و فاکتور را پیوست می‌کند: مبلغ خالص EUR 248.00، VAT با نرخ 21٪، مبلغ EUR 52.08، جمع EUR 300.08.

حقایق لازم برای پاسخ دادن در سه جا زندگی می‌کنند، و فقط یکی از آن‌ها در ایمیل است:

این سه را کنار هم بگذارید و فاکتور اشتباه است: reverse charge اعمال می‌شود، VAT باید صفر می‌بود، و credit note به مبلغ EUR 52.08 بدهکار است. فقط به فاکتور نگاه کنید و از نظر حسابی بی‌نقص است — 248.00 به‌علاوه 52.08 می‌شود 300.08 — و همین را خواهید گفت.

ایمیل می‌گوید «ما یک شرکت پرتغالی هستیم». این یک ادعاست، نه یک رکورد، و هیچ سیستم billing بر اساس یک ادعا credit note صادر نمی‌کند. دام یک حقه نیست: شکل معمول کار تجاری است، جایی که تصمیم به حقیقتی نیاز دارد که هیچ‌کس فکر نکرده آن را fetch کند.

همه‌چیز بالا با یک provider اسکریپت‌شده به سبک فصل 23 اجرا می‌شود، با دقیقاً یک قانون:

پاسخ فقط می‌تواند از factی استفاده کند که در prompt خودش وجود دارد.

«مدل» برای هر ابزاری که دارد، یک بار، به ترتیب catalog درخواست می‌دهد، سپس یک قانون ثابت را روی متنی که می‌تواند ببیند اعمال می‌کند. هیچ‌چیز برای هر چیدمان جداگانه اسکریپت نشده، پس تفاوت‌های جدول آغازین ادعاهایی درباره هوش مدل نیستند: information routing هستند، اندازه‌گیری‌شده. مدل واقعی شکست‌های خودش را هم اضافه می‌کند؛ این شکست‌ها را حذف نمی‌کند.

پنج نام زیر از Anthropic و مقاله Building effective agents آمده‌اند؛ جایی که این واژگان جا افتادند.¹ هیچ‌کدام از پنج ایده جدید نیست، و اینکه کدام خانه چه چیزی را نام‌گذاری کرده — و کدام ایده قدیمی‌تر است — نیمی از ارزش دانستن آن‌هاست.

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

این کل جعبه‌ابزار است: پنج function، بدون framework، و مورد موازی یک خط است — که دقیقاً دلیل نوشتنش به‌جای رسم کردنش همین است. حالا هر کدام به‌ترتیب، با تبار، قیمت و موردی که در آن اشتباه می‌کند.

Prompt chaining «یک کار را به دنباله‌ای از گام‌ها تجزیه می‌کند، که در آن هر LLM call خروجی قبلی را پردازش می‌کند».¹ این ایده قدیمی‌تر از مدل‌های زبانی است: pipeline است، با معامله pipeline — وضوح در برابر control flowی که پیش از رسیدن داده ثابت شده است.

چهار گام برای کار ما: استخراج fieldهای فاکتور، بررسی حساب، تصمیم درباره مبلغ بدهکار، نوشتن پاسخ. اینجا از دو راه متفاوت شکست می‌خورد، که از یک بار شکست خوردن آموزنده‌تر است.

--- 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 هزینه $0.001940 داشت و fieldهای فاکتور را بین گام دو و سه از دست داد، چون به گام سه فقط جمله‌ای درباره حساب داده شده بود و هیچ چیز دیگر. نتیجه‌اش یک پیام نگهدارنده بود: بی‌فایده، و آشکارا بی‌فایده.

accumulating chain — همان سطر جدول آغازین — هزینه $0.003780 داشت؛ یعنی 95٪ بیشتر برای چهار call یکسان، چون حالا هر گام همه‌چیز پیش از خودش را حمل می‌کند. خروجی خطرناک را تولید کرد. روان، با استناد به حساب خودش، درست درباره هر عددی که ذکر می‌کند، و در حال گفتن به مشتری که هیچ مبلغی بدهکار نیست در حالی که EUR 52.08 بدهکار است.

تفاوت بین این دو یک ternary است. زنجیره‌ای که کمتر حمل می‌کند پاسخ‌هایی تولید می‌کند که آشکارا ناقص‌اند؛ زنجیره‌ای که همه‌چیز را حمل می‌کند پاسخ‌هایی تولید می‌کند که با اطمینان اشتباه‌اند — و فقط نوع دوم ارسال می‌شود.

هیچ‌کدام شکست واقعی نیست. شکست واقعی این است که pipeline پیش از خواندن هر چیزی تصمیم گرفت این کار چهار گام روی محتوای یک ایمیل است. در این ساختار هیچ جایی نیست که بگوید «کشور ثبت‌نام در این ایمیل نیست؛ برو و آن را بگیر». Chaining وقتی درست است که تجزیه از پیش معلوم و پایدار باشد. اینجا حدس بود، و حدس ship شد.

Routing «یک input را طبقه‌بندی می‌کند و آن را به یک followup task تخصصی هدایت می‌کند».¹ نام جدید است؛ سازوکار همان dispatcher است، قدیمی‌تر از تقریباً هر چیز دیگری در این کتاب. چیز جدید این است که classifier می‌تواند مدل باشد — و همین باعث می‌شود به شکل‌هایی شکست بخورد که یک switch هرگز شکست نمی‌خورد.

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

دو نکته درباره آخرین argument. این error handling نیست؛ خود الگوست. router مبتنی بر مدل failure modeای دارد که dispatcher ندارد: می‌تواند labelی برگرداند که وجود ندارد، timeout شود، یا — مورد گران — labelی محتمل اما اشتباه برگرداند بی‌آنکه سیگنالی بدهد که اشتباه است. هر سه باید جایی فرود بیایند، و آن جا نمی‌تواند یک model call دیگر باشد، چون شما همین حالا در شاخه‌ای هستید که model callها شکست خورده‌اند.

نکته دوم این است که prompt خود router رایگان نیست. برای انتخاب مدل، router به catalogی از مدل‌ها نیاز دارد، و هر entry در آن inputی است که router پیش از آنکه پرسش کاربر را خوانده باشد هزینه‌اش را می‌پردازد. با نرخ inputی که این دوره با آن قیمت‌گذاری می‌کند، یک catalog حدوداً 3,800 tokenی همین حالا به اندازه کل اجرای agent با پنج call در جدول آغاز فصل هزینه دارد. در عمل routing call روی یک مدل ارزان اجرا می‌شود، و تمام دلیل اینکه routing هزینه خودش را درمی‌آورد همین است؛ اما ارزش دارد این حساب را در همین جهت انجام دهید به‌جای اینکه فرضش کنید. routing دقیقاً وقتی اشتباه است که task روت‌شده ارزان‌تر از خود تصمیم routing باشد.

Anthropic این یکی را به دو قسمت تقسیم می‌کند: sectioning — «شکستن یک کار به subtaskهای مستقل که موازی اجرا می‌شوند» — و voting — «چند بار اجرای همان کار برای گرفتن outputهای متنوع».¹ این دو یک diagram مشترک دارند و تقریباً هیچ چیز دیگری را مشترک ندارند.

Sectioning برد ارزان است، و همان خط از patterns.ts است: سه specialist — billing، tax، policy — هرکدام با window و ابزارهای خودشان، روی همان ایمیل، و یک synthesis call در پایان. همان کار، با دو ترتیب:

token به token یکسان، 1.8 برابر سریع‌تر. به همین دلیل این الگو نام خودش را به دست می‌آورد: تنها مورد از پنج مورد است که چیزی را بهتر می‌کند بی‌آنکه هزینه‌ای اضافه کند. گیر کار این است که بخش‌ها باید واقعاً مستقل باشند — اگر به بخش B factی بدهید که بخش A تولید می‌کند، Promise.all هر دو را روی stateای اجرا می‌کند که هنوز وجود ندارد. loopِ for آن bug را پنهان کرد؛ one-liner آن را آشکار می‌کند.

Voting حیوان دیگری است که همان تصویر را پوشیده. اجرای همان سؤال k بار و گرفتن اکثریت، self-consistency است؛ Wang و همکاران در مارس 2022 آن را به‌عنوان decoding strategy منتشر کردند، تقریباً سه سال پیش از آنکه کسی آن را الگوی orchestration بنامد. abstract آن درباره سازوکار دقیق است — «ابتدا مجموعه متنوعی از reasoning pathها را sample می‌کند به‌جای اینکه فقط greedy one را بگیرد، سپس با marginalize کردن reasoning pathهای sample‌شده، سازگارترین پاسخ را انتخاب می‌کند» — و درباره سود هم دقیق است: +17.9 امتیاز روی GSM8K.²

از این دو چیز نتیجه می‌شود که تصویر پنهان می‌کند. اول، voting نیازمند sampling فصل 17 است: در temperature صفر، هر k sample همان sample است، و majority یک پاسخ است که k بار برایش پول داده شده. دوم، فقط جایی کار می‌کند که majority معنا داشته باشد — در پاسخ فاکتور بالا چیزی برای شمردن وجود ندارد، چون پنج draft پنج جمله متفاوت‌اند. Voting برای کارهایی است با پاسخی کوتاه و قابل مقایسه، که دقیقاً benchmarkهای Wang است و تقریباً هیچ‌چیزی نیست که یک customer-facing agent انجام می‌دهد.

اینجا روی 20 مسئله کلامی سه‌مرحله‌ای که پاسخ‌هایشان محاسبه می‌شود نه قضاوت، با مدل محلی فصل 23 که step by step reasoning می‌کند، اندازه‌گیری شده:

پنج برابر call، پنج برابر token، دقیقاً پنج برابر صورت‌حساب، و حتی یک پاسخ درست اضافه هم نه. Voting یک شرط‌بندی است، نه یک بهبود، و این run آن را باخت.

دو caveat، پیش از آنکه کسی این را ردیه‌ای بر Wang نقل کند. بیست trial نمی‌تواند 45٪ را از 60٪ جدا کند — interval هم‌عرض ادعاست، که همان انضباط فصل 4 است وقتی علیه نتیجه خودم اعمال می‌شود. و سودهای منتشرشده از مدل‌هایی می‌آیند که چند مرتبه بزرگی بزرگ‌ترند، جایی که reasoning pathهای متنوعی که voting روی آن‌ها marginalise می‌کند واقعاً متنوع‌اند. چیزی که منتقل می‌شود عدد نیست: این است که ضریب دقیق و از پیش معلوم است، اما سود نه.

در workflowِ orchestrator-workers «یک LLM مرکزی به‌صورت پویا taskها را می‌شکند، آن‌ها را به worker LLMها delegate می‌کند، و نتیجه‌هایشان را synthesize می‌کند»، و تفاوتش با sectioning این است که «subtaskها از پیش تعریف نشده‌اند، بلکه توسط orchestrator تعیین می‌شوند».¹ تبار این یکی اصلاً از مدل‌های زبانی نیست: master-worker است، و نسخه‌ای که workerها یافته‌ها را در فضای مشترکی می‌نویسند و controller آن را می‌خواند، blackboard architecture است، از پژوهش speech understanding در دهه 1970. چیز جدید در 2026 این است که controller مدل است و بنابراین decomposition می‌تواند برای هر input تصمیم‌گیری شود — flexibility و cost، در یک جمله.

در برابر 5 call تک agent، 12 model call هزینه داشت، و به همان رأی رسید. سپس کاری کرد که ارزش دارد دقیق نگاهش کنیم:

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 خودش داشت، به نتیجه رسید، و همچنین متوجه شد — بی‌آنکه کسی پرسیده باشد — که شماره purchase order روی فاکتور با سفارش نمی‌خواند. سپس یک summary برگرداند. orchestrator می‌تواند هر دو statement را تکرار کند و هیچ‌کدام را بررسی نکند، چون evidence در windowی ماند که هرگز ندید. این پاسخ پرسش پایانی فصل 24 است: parent اجازه دارد به هر چیزی نگاه کند که child تصمیم گرفته بنویسد.

راه‌حل یک flag است، و قیمت دارد:

دوازده درصد input token بیشتر، 8.3٪ پول بیشتر، و عبارت source=worker_unverified از پاسخ ناپدید می‌شود. این معامله در هر سیستم multi-agent است و تقریباً هرگز صریح گفته نمی‌شود: window تمیز child ارزش داشتن دارد، توانایی parent برای audit کردنش ارزش پرداخت دارد، و هیچ‌کدام را رایگان با هم ندارید.

پس orchestrator-workers چه زمانی اشتباه است؟ همین‌جا، روی همین کار. پاسخ درستی خرید که یک agent با همان چهار ابزار هم به آن رسیده بود، با 1.66 برابر هزینه و 2.3 برابر زمان واقعی، و دفاع از آن پاسخ را سخت‌تر کرد. راهنمایی خود Anthropic پیش از شروع الگوها همین را می‌گوید: «ساده‌ترین راه‌حل ممکن» را پیدا کنید و «فقط وقتی لازم شد پیچیدگی را افزایش دهید»، چون «agentic systems اغلب latency و cost را با عملکرد بهتر task معاوضه می‌کنند».¹ جدول‌های بالا همان جمله‌اند، با عدد زیرشان.

یک call تولید می‌کند، دیگری ارزیابی می‌کند، و loop تکرار می‌شود تا ارزیابی قبول شود.¹ نیاکان منتشرشده Self-Refine هستند — همان مدل در نقش «generator، refiner و feedback provider»، با گزارش حدود 20 امتیاز بهبود مطلق به‌طور میانگین روی هفت task³ — و Reflexion، که critique را در episodic buffer بین تلاش‌ها ذخیره می‌کند و روی HumanEval، جایی که baseline به 80٪ رسیده بود، 91٪ pass@1 گزارش می‌دهد.⁴

cost model ساده‌ترینِ پنج مورد است: دو call در هر round، و تعداد round دست شما نیست. سه round اصلاح روی کاری که یک call می‌گرفت یعنی شش call، پس کف این الگو 6× است و سقفش هر capی است که می‌گذارید — که budget exit فصل 23 را اجباری می‌کند، نه صرفاً مرتب.

سقف ظریف‌تر است، و قابل اندازه‌گیری. روی همان 20 مسئله، مدل محلی به 9 تا درست پاسخ داد. سپس هرکدام از آن پاسخ‌ها را به خودش نشان دادند و پرسیدند آیا درست است — بدون اینکه به او گفته شود پاسخ خودش است؛ این confound چاپلوسی را حذف می‌کند و capability را باقی می‌گذارد:

این داور بهتر از چیزی است که عنوان بخش القا می‌کند، و گفتن همین نکته دلیل اندازه‌گیری است نه ادعا کردن: هیچ درست را block نکرد و 8 تا از 11 اشتباه را گرفت. به‌عنوان filter، ارزش callهایش را دارد.

اما به‌عنوان stopping rule، که loopِ evaluator-optimiser واقعاً برای آن از داور استفاده می‌کند، همان سه approval کل داستان‌اند: آن‌ها loop را با پاسخ اشتباه در دست تمام می‌کنند، و هیچ تعداد round اضافه‌ای هرگز به آن‌ها نمی‌رسد. refinement loop نمی‌تواند از داورش درست‌تر شود. خریدن roundهای بیشتر یعنی خریدن تلاش برای خطاهایی که داور می‌تواند ببیند، با قیمت کامل، و هیچ چیز در برابر خطاهایی که نمی‌تواند.

پس قاعده این است: evaluator فقط وقتی callهایش را به دست می‌آورد که چیزی داشته باشد که generator ندارد. یک compiler، یک test suite، یک schema validator، یک مدل متفاوت، یک انسان. نتایج خود Self-Refine با human preference و task metricها اندازه‌گیری شده‌اند، نه با نظر مدل درباره خودش. اگر تنها مزیت evaluator شما prompt متفاوت است، دارید دو برابر برای توافق پول می‌دهید. فصل 29 نسخه‌ای را می‌سازد که مزیت واقعی دارد: golden set با پاسخ‌هایی که از پیش نوشته شده‌اند.

پنج مورد بالا شکل‌هایی برای کد شما هستند. زیر آن‌ها خانواده دومی نشسته که اغلب کنارشان فهرست می‌شود و نباید بشود: ReAct، Reflexion، plan-and-execute و tree of thoughts reasoning loop هستند، و هزینه‌شان در requestهاست.

فصل 12 درباره reasoning داخل مدل بود، که هزینه‌اش را در output tokenهای یک call می‌پردازید. این نوع دیگر است. تفاوت وقتی قبض می‌رسد مهم می‌شود: chain of thought طولانی‌تر یک call را گران‌تر می‌کند، و reasoning loop یک task را به چندین call تبدیل می‌کند، که هرکدام همه‌چیز قبل از خود را دوباره می‌فرستد — همان quadraticی که فصل 23 در جدول runaway خودش اندازه گرفت.

مقاله tree-of-thoughts جدول cost خودش را منتشر می‌کند، چیزی که باید رایج‌تر از این باشد. روی Game of 24 با GPT-4: input/output prompting best-of-100 در 33٪ موارد با $0.13 برای هر case حل شد، chain of thought best-of-100 در 49٪ با $0.47، و tree of thoughts در 74٪ با $0.74، و نویسندگان اشاره کردند که «می‌تواند 5 تا 100 برابر token تولیدشده بیشتری نسبت به CoT لازم داشته باشد».⁷

تقریباً شش برابر قیمت روش ارزان برای کمی بیش از دو برابر نرخ موفقیت. اینکه این معامله خوب است یا نه بستگی دارد یک case شکست‌خورده برای شما چه هزینه‌ای دارد — پرسشی که پیش از پذیرفتن هرکدام از این چهار باید بپرسید.

این دوره آن‌ها را دوباره پیاده‌سازی نمی‌کند. هر چهار مورد reference implementationهایی از نویسندگان خودشان دارند، در Python، و ارزششان در source بودن است نه ترجمه: ysymyth/ReAct، noahshinn/reflexion، princeton-nlp/tree-of-thought-llm و AGI-Edgerunners/Plan-and-Solve-Prompting. promptهای آن repositoryها را بخوانید؛ promptها همان مقاله‌ها هستند.

حالا multi-agent واقعی، جایی که بیشتر سردرگمی‌ها زندگی می‌کنند. دو راه برای این وجود دارد که یک agent، agent دیگری را درگیر کند؛ این‌ها variant هم نیستند، و تفاوت در این است که بعد از آن چه کسی کنترل را دارد.

Agent به‌عنوان ابزار. parent آن را call می‌کند، پاسخ می‌گیرد، و ادامه می‌دهد. این همان interface ابزار فصل 18 است با یک agent کامل پشت آن، و parent هرگز کنترل را از دست نمی‌دهد. orchestrator بالا همین کار را می‌کند.

Handoff. parent گفتگو را منتقل می‌کند و آن را پس نمی‌گیرد. راهنمای OpenAI روشن‌ترین بیان منتشرشده است: handoffها «انتقال یک‌طرفه‌ای هستند که به یک agent اجازه می‌دهند به agent دیگری delegate کند... اگر یک agent یک handoff function را call کند، ما بلافاصله execution را روی agent جدیدی که به آن handoff شده شروع می‌کنیم و هم‌زمان آخرین conversation state را هم منتقل می‌کنیم».⁸

یک هشدار واژگانی، چون دائم مردم را زمین می‌زند: «handoff» واژه یک SDK است، نه standard. این اصطلاح از OpenAI Agents SDK و همان راهنما می‌آید، که دو چیدمان را هم «manager» و «decentralized» می‌نامد و می‌گوید در manager pattern «edgeها tool callها را نشان می‌دهند در حالی که در decentralized pattern، edgeها handoffها را نشان می‌دهند».⁸ در این فضا یک standard باز هم وجود دارد — A2A، در نسخه 1.0.0، زیر copyright بنیاد Linux، با تاریخچه release نسخه‌دار و فهرست مستند breaking changeها، که اصل اعلام‌شده‌اش opaque execution است: agentها «بر اساس capabilityهای اعلام‌شده و اطلاعات مبادله‌شده همکاری می‌کنند، بدون نیاز به اشتراک‌گذاری thoughtهای داخلی، planها یا پیاده‌سازی‌های ابزارشان».⁹ این handoff نیست، و مقایسه‌اش جای فصل 26 است. آنچه اینجا مهم است این است که یکی از این دو واژه API یک library است و دیگری specificationی با governance.

این تمایز data structure است، نه 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;
}

بیست خط، دو bug که وگرنه در production پیدایشان می‌کردید. reachable agentی را پیدا می‌کند که هیچ‌کس نمی‌تواند به آن برسد — configure شده، برایش پول داده شده، هرگز call نشده. conflicts edgeای را رد می‌کند که هم‌زمان از هر دو نوع است، چیزی که pedantic به نظر می‌رسد تا وقتی آن را بلند بخوانید: parent هم کنترل را نگه می‌دارد و هم آن را واگذار می‌کند. آن را روی یک سیستم پنج-agent با یک orphan و یک double edge اجرا کنید:

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

حالا اندازه‌گیری‌ای که این بخش برای آن وجود دارد، و تنها مورد این فصل که به‌جای مدل اسکریپت‌شده با مدل واقعی انجام شده است.

مشتری در پیام اولش یک constraint بیان می‌کند — account ما در پرتغال ثبت شده، نه اسپانیا؛ هر چیزی که به مالیات مربوط است باید از پرتغال استفاده کند — بعد درباره چیز دیگری chat می‌کند، سپس سؤالی می‌پرسد که billing باید جواب دهد. case منتقل می‌شود. بیست‌وچهار trial، هر بار کشور و شرکت متفاوت، چهار transfer payload، و سپس از agent گیرنده یک سؤال پرسیده می‌شود: account این مشتری در کدام کشور ثبت شده است؟

سطر سوم control است و مثل control رفتار می‌کند: fact آنجا نیست، پس نمی‌تواند recalled شود. سه سطر دیگر یافته‌اند.

transcript کامل 173 token است و 83٪ مواقع کار می‌کند، و چهار شکستش موضوع فصل 24 است نه این فصل. رکورد typed 69 token است — هفت تا بیشتر از summary — و هر بار کار می‌کند، چون constraint به‌جای یک جمله، در field نام‌دار نشسته است.

و summary سطری است که باید به آن خیره شد. 24 بار از 24 بار شکست خورد، و دلیلش این نیست که خواننده آن را ندید. constraint اصلاً فقط در 1 مورد از 24 summary ظاهر شد. agent گیرنده بی‌دقت نبود؛ متنی به او داده شده بود که پاسخ را در خودش نداشت. summary فشرده‌سازی‌ای است که شما ننوشته‌اید، تولیدشده توسط مدلی که window آن را نمی‌بینید، optimized برای اینکه مثل summary خوانده شود — و «مشتری می‌گوید رکوردهای ما کشور اشتباه دارند» دقیقاً همان نوع clauseای است که summariser به‌عنوان noise رویه‌ای حذف می‌کند.

یک محدودیت صادقانه برای آن عدد: summariser یک مدل نیم‌میلیارد-parameter است و مدل بزرگ‌تر بیشتر نگه می‌دارد. چیزی که با اندازه بهتر نمی‌شود شکل ریسک است — agent فرستنده، در هر handoff، با هر phrasing، به‌صورت غیرقابل مشاهده تصمیم می‌گیرد کدام factها زنده بمانند. رکورد typed اصلاً به آن judgement وابسته نیست، و به همین دلیل با construction می‌برد نه با intelligence. هر چیزی که باید از transfer زنده بماند باید field باشد، نه جمله.

همین استدلال در جهت دیگر هم برای topologyِ agent-as-tool صادق است، و جدول قبلی همین حالا قیمتش را داده بود: چیزی که از worker برمی‌گردد هم summary است، و پرداخت 8.3٪ بیشتر برای دریافت evidence همراه آن همان راه‌حل است، از سمت parent.

سه fact پایانی، همه از جدول‌های بالا.

سیستم multi-agent تعداد callها را ضرب می‌کند، و callها در context به‌صورت quadratic رشد می‌کنند. orchestrator جایی 12 model call انجام داد که یک agent 5 تا انجام داد، و هرکدام transcript در حال رشد خودش را حمل می‌کند — 3,628 input token در برابر 2,697، شکافی که با طول task بیشتر می‌شود.

هر مرز یک کانال lossy است. دو agent یعنی یک summary. چهار agent در chain یعنی سه تا، ترکیب‌شده، هرکدام نوشته مدلی که برای چیزی غیر از تصمیم شما optimize می‌کند.

single agent چیزی را پیدا کرد که هیچ‌کس نپرسیده بود. عدم تطابق purchase-order بالا آمد چون یک window هم فاکتور و هم سفارش را هم‌زمان داشت. تقسیم کار بین specialistها همچنین توانایی دیدن اینکه دو fact با هم نمی‌خوانند را تقسیم می‌کند.

هیچ‌کدام از این‌ها استدلالی علیه frameworkهای multi-agent منتشرشده نیست، که ارزش خواندن به‌عنوان primary source را دارند نه از طریق tutorialها.¹⁰ استدلالش این است که agent دوم باید جای خودش را به دست بیاورد.

پس یک آزمون، نه یک ترجیح. agent دوم را وقتی اضافه کنید که دست‌کم یکی از این‌ها درست باشد: sub-task به window تمیزی نیاز دارد که parent نباید inherit کند (فصل 24)؛ sub-taskها واقعاً مستقل هستند و زمان واقعی مهم است، که همان 1.8× بالاست؛ sub-task به permissionهای متفاوت یا مدل متفاوت نیاز دارد، که فصل 30 آن را به استدلال security تبدیل می‌کند؛ یا sub-task مال شخص دیگری است، جایی که یک protocol واقعی اهمیت پیدا می‌کند. اگر پاسخ این است «تا هر agent prompt روشن‌تری داشته باشد»، به همان یک agent prompt روشن‌تری بدهید. رایگان است.

حالا می‌توانید پنج الگو را نام ببرید، آن‌ها را روی یک task نسبت به هم price کنید، orchestrator را از sectioner و tool call را از handoff تشخیص دهید، و از single agent با جدول دفاع کنید نه با ترجیح.

همه چیدمان‌های اینجا یک راحتی مشترک داشتند که در تماس با چیز واقعی دوام نمی‌آورد: همه ابزارها مال ما بودند. فاکتور، سفارش، جدول مالیات، workerهای پشت orchestrator — همان repository، همان deploy، همان typeها، همان آدم‌ها.

حالا یکی از آن‌ها را آن‌طرف مرز یک شرکت بگذارید. جدول مالیات مال یک vendor حسابداری است، رکورد سفارش مال یک سیستم انبار، و هیچ‌کدام interfaceِ Tool شما را نخوانده‌اند. شما به راهی نیاز دارید تا مدلی که ننوشته‌اید بتواند capabilityی را که شخص دیگری operate می‌کند discover، describe و call کند — با authentication (که نیمه فصل 27 است)، versioning، و تضمین اینکه یک server نمی‌تواند بقیه conversation شما را بخواند. این یک مسئله protocol است، specificationی با schema هنجاری دارد، و تقریباً هر چیزی که درباره‌اش index شده revisionی را توصیف می‌کند که دیگر وجود ندارد.

فصل 26 به‌جای summary کردن specification، آن را می‌خواند، و با تایپ دستی JSON-RPC در terminal شروع می‌کند.

هر cost و token count بالا از provider اسکریپت‌شده توصیف‌شده در بخش دوم آمده، روی Node 22 از طریق loopback interface، با شمارش توسط encodingِ o200k_base و قیمت‌گذاری با نرخ‌هایی که فصل 16 در 6 سپتامبر 2026 خوانده بود — $2.00 برای هر یک میلیون input token و $12.00 برای هر یک میلیون output. رقم‌های wall-clock از همان runها هستند، با latency provider روی 400 ms برای هر call و ابزارها روی 50 ms، پس چیدمان را اندازه می‌گیرند نه هیچ providerی را. دو اندازه‌گیری با مدل واقعی — جدول handoff و جدول voting-and-judging — از Qwen/Qwen2.5-0.5B-Instruct در float32 روی CPU پشت endpointی با همان شکل استفاده کردند، greedy مگر جایی که temperature گفته شده، با intervalهایی که با روش Wilson از فصل 4 محاسبه شده‌اند. هیچ requestی در این فصل به endpoint پولی نرفت، و هیچ عددی در آن تخمینی نبود.