Multi-agent orchestration: п’ять патернів і коли перемагає один

Португальська компанія пише щодо інвойсу FT-2026-0918. У листі сказано, що VAT виглядає неправильним, і додано інвойс: net EUR 248.00, VAT нараховано за ставкою 21 %, EUR 52.08, total EUR 300.08.

Факти, потрібні для відповіді, живуть у трьох місцях, і лише одне з них є в листі:

Складіть ці три факти разом — і інвойс неправильний: застосовується reverse charge, VAT мав бути нульовим, клієнту належить credit note на EUR 52.08. Подивіться лише на інвойс — і він арифметично ідеальний: 248.00 плюс 52.08 дорівнює 300.08 — тож ви так і скажете.

У листі справді написано «ми португальська компанія». Це твердження, а не запис у системі, і жодна billing system не виписує credit note на підставі твердження. Пастка — не трюк: це звичайна форма бізнес-роботи, де рішення потребує факту, який ніхто не подумав отримати.

Усе вище запускається проти scripted provider у стилі розділу 23, з рівно одним правилом:

Відповідь може використовувати лише факт, який є в її prompt.

«Модель» просить кожен tool, який має, один раз, у порядку каталогу, а потім застосовує фіксоване правило до тексту, який бачить. Нічого не scripted під конкретну схему, тож відмінності у вступній таблиці — це не твердження про інтелект моделі: це виміряна маршрутизація інформації. Реальна модель додає зверху власні збої; вона їх не прибирає.

П’ять назв нижче — 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 };
}

Це весь toolkit: п’ять functions, жодного framework, а паралельна — один рядок. Саме тому варто виписати це, а не малювати. Тепер по черзі: походження, ціна і випадок, де кожна схема помиляється.

Prompt chaining «розкладає завдання на послідовність кроків, де кожен LLM call обробляє output попереднього».¹ Ідея старіша за мовні моделі: це pipeline, із притаманним pipeline обміном — ясність в обмін на control flow, зафіксований до появи даних.

Чотири кроки для нашого завдання: витягти поля інвойсу, перевірити арифметику, вирішити, що належить, написати відповідь. Тут він ламається двома різними способами, і це вчить більше, ніж один збій.

--- 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 і загубив поля інвойсу між другим і третім кроками, бо третьому кроку передали речення про арифметику і нічого більше. Він видав holding message: марний і помітно марний.

Accumulating chain — рядок у вступній таблиці — коштував $0.003780, тобто на 95 % більше за чотири ідентичні виклики, бо кожен крок тепер несе все, що було до нього. Він видав небезпечний output. Плавний, із посиланням на арифметику, правильний у кожному згаданому числі — і такий, що каже клієнту: нічого не належить, хоча належить EUR 52.08.

Різниця між ними — один ternary. Chain, що несе менше, дає відповіді, які очевидно неповні; chain, що несе все, дає відповіді, які впевнено неправильні — і лише другий тип надсилають.

Жодне з цього не є справжнім провалом. Справжній провал у тому, що pipeline ще до читання будь-чого вирішив: це завдання — чотири кроки над вмістом email. У цій структурі ніде немає місця сказати: «країни реєстрації в цьому email немає; піди й отримай її». Chaining правильний, коли decomposition відомий заздалегідь і стабільний. Тут це була здогадка, і здогадку відправили.

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

Дві речі про останній аргумент. Це не error handling; це патерн. Model-based router має failure mode, якого dispatcher не має: він може повернути label, якого не існує, time out, або — дорогий варіант — повернути правдоподібно неправильний label без сигналу, що він неправильний. Усі три мають кудись потрапити, і це «кудись» не може бути ще одним model call, бо ви вже в гілці, де model calls зламалися.

Друга річ: власний prompt router не безкоштовний. Щоб вибрати модель, router потребує catalogue моделей на вибір, і кожен запис у ньому — це input, за який router платить ще до того, як прочитав запитання користувача. За input rate, за яким рахує ціни цей курс, catalogue приблизно на 3,800 tokens уже коштує стільки ж, скільки весь agent run із п’яти викликів у початковій таблиці. На практиці routing call працює на дешевій моделі, і саме тому routing себе окуповує; але цю арифметику варто робити саме в цьому напрямку, а не припускати. Routing помилковий саме тоді, коли routed task дешевший за routing decision.

Anthropic ділить цей патерн навпіл: sectioning — «розбиття завдання на незалежні subtasks, що виконуються паралельно», — і voting — «запуск того самого завдання кілька разів, щоб отримати різноманітні outputs».¹ Вони мають спільну діаграму й майже нічого більше.

Sectioning — дешевий виграш, і це рядок із patterns.ts: три specialists — billing, tax, policy — кожен зі своїм window і tools, над тим самим email, плюс один synthesis call наприкінці. Та сама робота, впорядкована двома способами:

Однаково token for token, у 1,8 раза швидше. Саме тому патерн заслуговує на власну назву: він єдиний із п’яти, що покращує щось, нічого не додаючи до вартості. Пастка в тому, що sections мають бути справді незалежними — дайте section B факт, який виробляє section A, і Promise.all запустить їх обох проти state, якого ще не існує. Loop for приховав цей bug; one-liner його показує.

Voting — інша тварина в тій самій картинці. Запустити те саме запитання k разів і взяти більшість — це self-consistency, опублікована Wang et al. у березні 2022 року як decoding strategy, майже за три роки до того, як хтось назвав її orchestration pattern. Анотація точно описує механізм — «спершу sample різноманітний набір reasoning paths замість того, щоб брати лише greedy one, а потім обирає найбільш consistent answer, marginalizing out sampled reasoning paths» — і приріст: +17.9 points on GSM8K.²

З цього випливають дві речі, які картинка приховує. По-перше, voting потребує sampling із розділу 17: за temperature zero всі k samples — той самий sample, а majority — одна відповідь, оплачена k разів. По-друге, він працює лише там, де majority має сенс: у відповіді на інвойс вище немає що рахувати, бо п’ять drafts — це п’ять різних речень. Voting — для завдань із короткою, порівнюваною відповіддю, тобто рівно для benchmarks Wang і майже ні для чого, що робить customer-facing agent.

Виміряно тут на 20 трикрокових word problems, чиї відповіді обчислюються, а не оцінюються, з локальною моделлю з розділу 23, що reason step by step:

У п’ять разів більше викликів, у п’ять разів більше tokens, рівно в п’ять разів більший рахунок — і жодної додаткової правильної відповіді. Voting — це ставка, а не покращення, і цей запуск її програв.

Дві caveats, перш ніж хтось процитує це як спростування Wang. Двадцять trials не можуть відрізнити 45 % від 60 % — interval має ширину самого твердження, і це дисципліна розділу 4, застосована до мого власного результату. А опубліковані gains отримано на моделях на порядки більших, де diverse reasoning paths, які voting marginalises over, справді diverse. Переноситься не число, а те, що множник точний і відомий наперед, тоді як gain — ні.

У workflow orchestrator-workers «центральний LLM динамічно розбиває tasks, делегує їх worker LLMs і синтезує їхні results», а відмінність від sectioning у тому, що «subtasks не визначені заздалегідь, а визначаються orchestrator».¹ Походження тут зовсім не з мовних моделей: це master-worker, а версія, де workers записують findings у shared space, який читає controller, — це blackboard architecture із досліджень speech understanding 1970-х. Нове у 2026 році те, що controller — модель, а отже decomposition можна вирішувати для кожного input — гнучкість і вартість в одному реченні.

Це коштувало 12 model calls проти 5 в single agent, і дійшло того самого вердикту. Потім сталося щось, на що варто подивитися уважно:

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 мав інвойс, order і tax table у власному window, дійшов висновку, а ще помітив — ніхто не просив — що purchase order number в інвойсі не збігається з номером у order. Потім він повернув summary. Orchestrator може повторити обидва твердження і не може перевірити жодне, бо evidence залишився у window, якого він ніколи не бачив. Це відповідь на фінальне питання розділу 24: parent може побачити лише те, що child вирішив записати.

Виправлення — один flag, і він має ціну:

На 12 % більше input tokens, на 8,3 % більше грошей — і фраза source=worker_unverified зникає з відповіді. Це tradeoff у кожній multi-agent system, і його майже ніколи не проговорюють: чистий window child вартий того, щоб його мати; здатність parent audit його варта грошей; і обидва безкоштовно ви не отримаєте.

То коли orchestrator-workers неправильний? Тут, на цьому завданні. Він купив правильну відповідь, до якої one agent із тими самими чотирма tools теж дійшов, за 1,66 раза більшу вартість і 2,3 раза більший wall clock, і зробив цю відповідь важчою для захисту. Власна рекомендація Anthropic каже те саме ще до початку патернів: знайдіть «найпростішу можливу solution і збільшуйте complexity лише за потреби», бо «agentic systems often trade latency and cost for better task performance».¹ Таблиці вище — це те речення з числами під ним.

Один call генерує, інший оцінює, і loop повторюється, доки evaluation не пройде.¹ Опубліковані попередники — Self-Refine, де та сама модель є «generator, refiner, and feedback provider» і повідомляє про приблизно 20 points absolute improvement у середньому на семи tasks³, — та Reflexion, який зберігає critique в episodic buffer між attempts і повідомляє 91 % pass@1 на HumanEval проти 80 % у baseline.⁴

Cost model — найпростіша з п’яти: два calls на round, і кількість rounds не ваша. Три rounds refinement для task, що займав один call, — це шість calls, тож floor патерну — 6×, а ceiling — будь-який cap, який ви поставите; саме тому budget exit із розділу 23 обов’язковий, а не просто охайний.

Ceiling тонший, і його можна виміряти. На тих самих 20 problems локальна модель відповіла правильно 9 разів. Потім їй показали кожну з цих відповідей і запитали, чи вона правильна — не кажучи, що відповідь її власна, що прибирає flattery confound і лишає capability one:

Це кращий judge, ніж натякає заголовок розділу, і саме це показує користь вимірювання замість тверджень: він не заблокував нічого правильного і спіймав 8 з 11 помилок. Як filter, він вартий своїх calls.

Як stopping rule, тобто саме те, для чого evaluator-optimiser loop його використовує, ці три схвалення — вся історія: вони завершують loop із неправильною відповіддю в руках, і жодна кількість extra rounds ніколи до них не добереться. Refinement loop не може стати правильнішим за свого judge. Купуючи більше rounds, ви купуєте attempts на помилки, які judge бачить, за повною ціною — і зовсім нічого проти тих, яких він не бачить.

Звідси правило: evaluator заробляє свої calls лише тоді, коли має щось, чого generator не має. Compiler, test suite, schema validator, інша модель, людина. Власні results Self-Refine виміряні за human preference і task metrics, а не за думкою моделі про саму себе. Якщо єдина перевага вашого evaluator — інший prompt, ви платите вдвічі за згоду. Розділ 29 будує версію зі справжньою перевагою: golden set із відповідями, записаними наперед.

П’ять вище — це форми для вашого коду. Під ними лежить друга родина, яку часто ставлять поруч, хоча не слід: ReAct, Reflexion, plan-and-execute і tree of thoughts — це reasoning loops, і їхня вартість у requests.

Розділ 12 був про reasoning усередині моделі, за який ви платите output tokens в одному call. Це інший тип. Різниця стає важливою, коли приходить рахунок: довший chain of thought робить один call дорожчим, а reasoning loop перетворює одне task на багато calls, кожен із яких пересилає все, що було до нього, — квадратичність, яку розділ 23 виміряв у runaway table.

Paper tree-of-thoughts публікує власну таблицю вартості, що трапляється рідше, ніж мало б. На 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; автори зазначають, що він «could require 5-100 times more generated tokens than CoT».⁷

Майже вшестеро дорожче за дешевий метод — за трохи більше ніж подвоєння success rate. Чи це вигідно, залежить від того, скільки вам коштує failed case — це питання треба поставити до adoption будь-якого з цих чотирьох.

Цей курс не реалізує їх повторно. У всіх чотирьох є reference implementations від власних авторів, Python, і їхня цінність у тому, що вони джерело, а не переклад: ysymyth/ReAct, noahshinn/reflexion, princeton-nlp/tree-of-thought-llm і AGI-Edgerunners/Plan-and-Solve-Prompting. Читайте prompts у цих repositories; prompts — це papers.

Тепер власне multi-agent, де живе більшість плутанини. Є два способи, якими один agent може залучити іншого; це не варіанти одного, і різниця в тому, хто після цього керує.

Agent як tool. Parent викликає його, отримує відповідь і продовжує. Це tool interface з розділу 18 із цілим agent позаду, і parent ніколи не втрачає control. Саме це робить orchestrator вище.

Handoff. Parent передає conversation і не отримує її назад. Guide OpenAI формулює це найчіткіше: handoffs — це «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».⁸

Попередження про словник, бо це постійно збиває людей: «handoff» — слово одного SDK, а не standard. Це термінологія з OpenAI Agents SDK і того guide, який також називає дві схеми «manager» і «decentralized» та зазначає, що в manager pattern «edges represent tool calls whereas in the decentralized pattern, edges represent handoffs».⁸ У цьому просторі є відкритий standard — A2A, версія 1.0.0, під copyright Linux Foundation, із versioned release history і documented list of breaking changes; його заявлений принцип — opaque execution: agents «collaborate based on declared capabilities and exchanged information, without needing to share their internal thoughts, plans, or tool implementations».⁹ Це не handoff, і порівняння належить розділу 26. Тут важливо те, що одне з двох слів — API бібліотеки, а інше — specification with 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;
}

Двадцять рядків, два bugs, які інакше ви знайшли б у production. reachable знаходить agent, до якого ніхто не може дістатися, — configured, paid for, never called. conflicts відхиляє edge, що є обома видами одночасно, і це звучить педантично, доки не прочитати вголос: parent одночасно зберігає control і віддає його. Запустіть це на five-agent system з одним orphan і одним double edge:

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

Тепер вимірювання, заради якого існує цей розділ, і єдине в цьому розділі, зроблене на реальній моделі, а не scripted.

Клієнт формулює constraint у першому повідомленні — our account is registered in Portugal, not Spain; everything tax-related has to use Portugal — далі говорить про щось інше, а потім ставить питання, на яке має відповісти billing. Case передають. Двадцять чотири trials, щоразу інша країна й компанія, чотири transfer payloads, а receiving agent потім отримує одне питання: у якій країні зареєстрований account цього клієнта?

Третій рядок — control і поводиться як control: факту там немає, тож його неможливо згадати. Інші три — власне finding.

Повний transcript має 173 tokens і працює у 83 % випадків; його чотири failures — предмет розділу 24, а не цього. Typed record — 69 tokens, лише на сім більше за summary, — і працює щоразу, бо constraint лежить у named field, а не в реченні.

А summary — рядок, на який треба дивитися. Він провалився 24 рази з 24, і причина не в тому, що reader його пропустив. Constraint узагалі з’явився лише в 1 із 24 summaries. Receiving agent не був неуважним; йому передали текст, що не містив відповіді. Summary — це compaction, який писали не ви, вироблений моделлю, чий window ви не бачите, optimized for reading like a summary — а «клієнт каже, що в наших записах неправильна країна» саме той тип clause, який summariser викидає як procedural noise.

Чесне обмеження цього числа: summariser — модель на пів мільярда parameters, і більша зберігала б більше. Те, що не покращується з розміром, — форма risk: sending agent вирішує, per handoff, per phrasing, unobservably, які facts виживуть. Typed record узагалі не залежить від цього judgement, тому перемагає by construction, а не intelligence. Усе, що має пережити transfer, має бути field, а не sentence.

Те саме reasoning працює і в інший бік, для topology agent-as-tool, і попередня таблиця вже оцінила це грошима: те, що повертається від worker, теж summary, і платити на 8,3 % більше, щоб отримати evidence разом із ним, — те саме виправлення, тільки з боку parent.

Три фінальні факти, всі з таблиць вище.

Multi-agent system множить calls, а calls квадратичні в context. Orchestrator зробив 12 model calls там, де one agent зробив 5, і кожен несе власний growing transcript — 3,628 input tokens проти 2,697, розрив, що ширшає з довжиною task.

Кожна boundary — lossy channel. Два agents означають одне summary. Чотири agents у chain означають три, складені разом, кожне написане моделлю, optimized for something other than your decision.

Single agent знайшов те, про що ніхто не питав. Purchase-order mismatch сплив, бо один window тримав інвойс і order одночасно. Розбиття роботи між specialists також розбиває здатність помітити, що два facts суперечать один одному.

Усе це не аргумент проти опублікованих multi-agent frameworks, які варто читати як primary sources, а не через tutorials.¹⁰ Це аргумент за те, щоб другий agent заслужив своє місце.

Отже, test, а не preference. Додавайте другий agent, коли справджується хоча б одне: sub-task потребує clean window, який parent не має успадкувати (розділ 24); sub-tasks справді independent, і wall clock важливий — це 1,8× вище; sub-task потребує different permissions або іншої моделі, що розділ 30 перетворює на security argument; або sub-task owned by someone else, і саме там починає важити справжній protocol. Якщо відповідь — «щоб кожен agent мав ясніший prompt», дайте одному agent ясніший prompt. Це безкоштовно.

Тепер ви можете назвати п’ять патернів, оцінити їхню вартість один проти одного на одному task, відрізнити orchestrator від sectioner і tool call від handoff, а також захистити single agent таблицею, а не preference.

Усі схеми тут мали одну зручність, яка не переживе контакту з будь-чим реальним: усі tools належали нам. Інвойс, order, tax table, workers позаду orchestrator — той самий repository, той самий deploy, ті самі types, ті самі люди.

Тепер перенесіть один із них по той бік межі компанії. Tax table належить accounting vendor, order record — warehouse system, і жоден із них не читав ваш interface Tool. Вам потрібен спосіб, щоб модель, яку ви не писали, могла discover, describe and call capability, якою керує хтось інший, — з authentication (це половина розділу 27), versioning і гарантією, що server не може прочитати решту вашої conversation. Це protocol problem, воно має specification with normative schema, і майже все indexed про нього описує revision, якої вже не існує.

Розділ 26 читає цю specification замість того, щоб summarise її, і починає з ручного введення JSON-RPC у terminal.

Кожна cost і token count вище взяті зі scripted provider, описаного в другому розділі, на Node 22 через loopback interface, з підрахунком encoding o200k_base і цінами за rates, які розділ 16 прочитав 6 вересня 2026 року: $2.00 за мільйон input tokens і $12.00 за мільйон output. Wall-clock figures — з тих самих runs, де latency provider було встановлено на 400 ms per call, а tools — на 50 ms, тож вони вимірюють arrangement, а не provider. Два real-model measurements — handoff table і voting-and-judging table — використовували Qwen/Qwen2.5-0.5B-Instruct у float32 на CPU за endpoint тієї самої форми, greedy except where a temperature is stated, з intervals, computed by Wilson's method from Chapter 4. Жоден request у цьому розділі не пішов на paid endpoint, і жодне число в ньому не estimated.