Orkestrasi Multi-Agent: Lima Pola, dan Kapan Satu Menang

Sebuah perusahaan Portugal menulis tentang invoice FT-2026-0918. Email itu mengatakan VAT terlihat salah, dan melampirkan invoice: net EUR 248.00, VAT dikenakan 21 %, EUR 52.08, total EUR 300.08.

Fakta yang diperlukan untuk menjawab ada di tiga tempat, dan hanya satu yang ada di email:

Gabungkan ketiganya dan invoice itu salah: reverse charge berlaku, VAT seharusnya nol, credit note senilai EUR 52.08 harus diberikan. Lihat hanya invoice dan secara aritmetika ia sempurna — 248.00 plus 52.08 adalah 300.08 — dan kamu akan mengatakan begitu.

Email itu memang menyatakan "kami perusahaan Portugal". Itu klaim, bukan catatan, dan tidak ada sistem billing yang menerbitkan credit note berdasarkan klaim. Jebakannya bukan trik: ini bentuk kerja bisnis sehari-hari, ketika keputusan membutuhkan fakta yang tidak terpikirkan siapa pun untuk diambil.

Semua di atas berjalan terhadap provider berskrip dengan gaya Bab 23, dengan tepat satu aturan:

Jawaban hanya boleh memakai fakta yang ada di prompt-nya.

"Model" meminta setiap tool yang dimilikinya, sekali, dalam urutan katalog, lalu menerapkan aturan tetap pada teks yang bisa dilihatnya. Tidak ada yang discript per susunan, jadi perbedaan di tabel pembuka bukan klaim tentang kecerdasan model: itu routing informasi, diukur. Model sungguhan menambahkan kegagalannya sendiri di atasnya; ia tidak menghilangkan kegagalan ini.

Lima nama di bawah adalah milik Anthropic, dari Building effective agents, tempat kosakata ini menetap.¹ Tidak satu pun dari lima ide ini baru, dan menyebutkan rumah mana menamai apa — serta ide mana yang lebih tua — adalah separuh nilai dari memahaminya.

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

Itulah seluruh toolkit: lima fungsi, tanpa framework, dan yang paralel hanya satu baris — justru itu alasan menuliskannya, bukan menggambarnya. Sekarang masing-masing secara bergiliran, dengan asal-usulnya, harganya, dan kasus ketika ia salah.

Prompt chaining "memecah tugas menjadi urutan langkah, ketika setiap panggilan LLM memproses output dari panggilan sebelumnya".¹ Idenya lebih tua daripada language model: ini pipeline, dengan trade pipeline — kejelasan ditukar dengan control flow yang sudah ditetapkan sebelum data tiba.

Empat langkah untuk tugas kita: ekstrak field invoice, periksa aritmetika, putuskan apa yang terutang, tulis balasan. Di sini ia gagal dalam dua cara berbeda, yang mengajarkan lebih banyak daripada gagal sekali.

--- 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 menelan biaya $0.001940 dan kehilangan field invoice antara langkah dua dan tiga, karena langkah tiga diberi kalimat tentang aritmetika dan tidak ada yang lain. Ia menghasilkan pesan penahan: tidak berguna, dan jelas tidak berguna.

Accumulating chain — baris di tabel pembuka — menelan biaya $0.003780, yaitu 95 % lebih mahal untuk empat panggilan identik, karena setiap langkah sekarang membawa semua yang sebelumnya. Ia menghasilkan output yang berbahaya. Lancar, mengutip aritmetikanya, benar pada setiap angka yang ia sebutkan, dan mengatakan kepada pelanggan bahwa tidak ada yang terutang padahal EUR 52.08 terutang.

Perbedaan keduanya adalah satu ternary. Chain yang membawa lebih sedikit menghasilkan jawaban yang jelas tidak lengkap; chain yang membawa semuanya menghasilkan jawaban yang percaya diri tetapi salah — dan hanya jenis kedua yang terkirim.

Bukan itu kegagalan sebenarnya. Kegagalan sebenarnya adalah bahwa pipeline memutuskan, sebelum membaca apa pun, bahwa tugas ini adalah empat langkah di atas isi email. Di mana pun dalam struktur itu tidak ada tempat untuk berkata "negara registrasi tidak ada di email ini; ambil dulu". Chaining benar ketika dekomposisi diketahui sebelumnya dan stabil. Di sini ia tebakan, dan tebakan itu dikirim.

Routing "mengklasifikasikan input dan mengarahkannya ke tugas lanjutan yang terspesialisasi".¹ Namanya baru; mekanismenya adalah dispatcher, lebih tua daripada hampir semua hal lain di buku ini. Yang baru adalah classifier-nya bisa berupa model — dan itulah yang membuatnya gagal dengan cara yang tidak pernah terjadi pada switch.

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

Dua hal tentang argumen terakhir itu. Itu bukan error handling; itu polanya. Router berbasis model punya failure mode yang tidak dimiliki dispatcher: ia bisa mengembalikan label yang tidak ada, timeout, atau — yang mahal — mengembalikan label salah yang tampak masuk akal tanpa sinyal bahwa label itu salah. Ketiganya harus mendarat di suatu tempat, dan tempat itu tidak bisa berupa panggilan model lain, karena kamu sudah berada di cabang ketika panggilan model gagal.

Hal kedua adalah prompt milik router sendiri tidak gratis. Untuk memilih model, router membutuhkan katalog model yang bisa dipilih, dan setiap entri di dalamnya adalah input yang dibayar router sebelum router membaca pertanyaan pengguna. Pada tarif input yang dipakai kursus ini, katalog sekitar 3,800 token sudah sama mahalnya dengan seluruh run agent lima panggilan di tabel pembuka. Dalam praktiknya panggilan routing berjalan di model murah, itulah alasan utama routing membayar dirinya sendiri; tetapi aritmetikanya layak dilakukan ke arah itu, bukan diasumsikan. Routing salah persis ketika tugas yang diarahkan lebih murah daripada keputusan routing.

Anthropic membagi yang satu ini menjadi dua: sectioning — "memecah tugas menjadi subtugas independen yang dijalankan paralel" — dan voting — "menjalankan tugas yang sama beberapa kali untuk mendapatkan output beragam".¹ Keduanya berbagi diagram dan hampir tidak berbagi apa pun lagi.

Sectioning adalah kemenangan murah, dan ini baris dari patterns.ts: tiga spesialis — billing, pajak, policy — masing-masing dengan window dan tool sendiri, atas email yang sama, satu panggilan sintesis di akhir. Pekerjaan identik, diurutkan dua cara:

Sama token demi token, 1,8 kali lebih cepat. Itulah kenapa pola ini pantas punya nama sendiri: ia satu-satunya dari lima yang memperbaiki sesuatu tanpa menambah biaya apa pun. Tangkapannya adalah section harus benar-benar independen — beri section B fakta yang dihasilkan section A dan Promise.all menjalankan keduanya terhadap state yang belum ada. Loop for menyembunyikan bug itu; one-liner membukanya.

Voting adalah makhluk berbeda yang memakai gambar yang sama. Menjalankan pertanyaan yang sama k kali dan mengambil mayoritas adalah self-consistency, dipublikasikan oleh Wang dkk. pada Maret 2022 sebagai strategi decoding, hampir tiga tahun sebelum ada yang menyebutnya pola orkestrasi. Abstraknya presisi tentang mekanismenya — "pertama mengambil sampel sekumpulan reasoning path yang beragam alih-alih hanya mengambil yang greedy, lalu memilih jawaban paling konsisten dengan memarginalkan reasoning path yang disampel" — dan tentang gain-nya: +17,9 poin di GSM8K.²

Dua hal mengikuti yang disembunyikan gambar itu. Pertama, voting membutuhkan sampling dari Bab 17: pada temperature nol semua k sampel adalah sampel yang sama, dan mayoritas adalah satu jawaban yang dibayar k kali. Kedua, ia hanya bekerja ketika mayoritas bermakna — pada balasan invoice di atas tidak ada yang bisa dihitung, karena lima draft adalah lima kalimat berbeda. Voting untuk tugas dengan jawaban pendek yang bisa dibandingkan, tepat seperti benchmark Wang dan hampir tidak seperti apa pun yang dilakukan agent yang berhadapan dengan pelanggan.

Diukur di sini pada 20 soal cerita tiga langkah yang jawabannya dihitung, bukan dinilai, dengan model lokal Bab 23 bernalar langkah demi langkah:

Lima kali panggilan, lima kali token, tepat lima kali tagihan, dan tidak satu pun jawaban benar tambahan. Voting adalah taruhan, bukan perbaikan, dan run ini kalah.

Dua catatan, sebelum ada yang mengutip itu sebagai sanggahan terhadap Wang. Dua puluh trial tidak bisa membedakan 45 % dari 60 % — intervalnya selebar klaim, yaitu disiplin Bab 4 yang diterapkan pada hasilku sendiri. Dan gain yang dipublikasikan datang dari model yang berorde-orde magnitudo lebih besar, ketika reasoning path beragam yang dimarginalkan voting memang benar-benar beragam. Yang berpindah bukan angkanya: melainkan bahwa multiplier-nya tepat dan diketahui sejak awal, sedangkan gain-nya tidak.

Dalam workflow orchestrator-workers "LLM pusat secara dinamis memecah tugas, mendelegasikannya ke worker LLM, dan menyintesis hasilnya", dan perbedaannya dari sectioning adalah bahwa "subtugas tidak didefinisikan sebelumnya, tetapi ditentukan oleh orchestrator".¹ Leluhurnya di sini sama sekali bukan dari language model: ini master-worker, dan versi ketika worker menulis temuan ke ruang bersama yang dibaca controller adalah arsitektur blackboard, dari riset speech understanding pada 1970-an. Yang baru pada 2026 adalah controller-nya model sehingga dekomposisi bisa diputuskan per input — itulah fleksibilitas, dan biaya, dalam satu kalimat.

Biayanya 12 panggilan model dibandingkan 5 milik single agent, dan ia mencapai verdict yang sama. Lalu ia melakukan sesuatu yang layak dilihat dekat-dekat:

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

Keduanya benar. Hanya satu yang tahu kenapa. Tax worker punya invoice, order, dan tabel pajak dalam window-nya sendiri, mencapai kesimpulan, dan juga memperhatikan — tidak ada yang meminta — bahwa nomor purchase order pada invoice tidak cocok dengan order. Lalu ia mengembalikan summary. Orchestrator bisa mengulang kedua pernyataan dan tidak bisa memeriksa keduanya, karena evidence tetap berada di window yang tidak pernah ia lihat. Itulah pertanyaan penutup Bab 24, terjawab: parent bisa melihat apa pun yang dipilih child untuk ditulis.

Perbaikannya adalah sebuah flag, dan ada harganya:

Dua belas persen lebih banyak input tokens, 8,3 % lebih banyak uang, dan frasa source=worker_unverified menghilang dari jawaban. Itulah trade dalam setiap sistem multi-agent dan hampir tidak pernah dinyatakan: window bersih milik child berharga, kemampuan parent untuk mengauditnya layak dibayar, dan kamu tidak bisa mendapatkan keduanya gratis.

Jadi kapan orchestrator-workers salah? Di sini, pada tugas ini. Ia membeli jawaban benar yang juga dicapai satu agent dengan empat tool yang sama, dengan biaya 1,66 kali dan wall clock 2,3 kali, serta membuat jawaban itu lebih sulit dipertahankan. Panduan Anthropic sendiri mengatakan hal yang sama sebelum pola-polanya dimulai: temukan "solusi sesederhana mungkin, dan hanya tingkatkan kompleksitas saat diperlukan", karena "agentic systems sering menukar latency dan biaya demi performa tugas yang lebih baik".¹ Tabel-tabel di atas adalah kalimat itu dengan angka di bawahnya.

Satu panggilan menghasilkan, panggilan lain mengevaluasi, dan loop berulang sampai evaluasi lulus.¹ Leluhur yang dipublikasikan adalah Self-Refine — model yang sama sebagai "generator, refiner, and feedback provider", melaporkan sekitar 20 poin peningkatan absolut rata-rata di tujuh tugas³ — dan Reflexion, yang menyimpan kritik dalam buffer episodic antar percobaan dan melaporkan 91 % pass@1 di HumanEval ketika baseline mencapai 80 %.⁴

Model biayanya paling sederhana dari lima: dua panggilan per round, dan jumlah round bukan milikmu. Tiga round refinement pada tugas yang membutuhkan satu panggilan adalah enam panggilan, jadi lantai pola ini 6× dan plafonnya apa pun cap yang kamu tetapkan — yang membuat budget exit dari Bab 23 wajib, bukan sekadar rapi.

Plafonnya lebih halus, dan bisa diukur. Pada 20 soal yang sama, model lokal menjawab 9 dengan benar. Lalu ia diperlihatkan tiap jawaban itu dan ditanya apakah jawaban tersebut benar — tanpa diberi tahu bahwa jawaban itu miliknya sendiri, yang menghapus confound sanjungan dan menyisakan kemampuan:

Itu hakim yang lebih baik daripada yang disiratkan judul section, dan mengatakannya adalah inti dari mengukur, bukan menyatakan: ia tidak memblokir apa pun yang benar dan menangkap 8 dari 11 kesalahan. Sebagai filter, ia layak untuk panggilannya.

Sebagai stopping rule, yang sebenarnya dipakai loop evaluator-optimiser, tiga approval itu adalah seluruh cerita: mereka mengakhiri loop dengan jawaban salah di tangan, dan berapa pun round tambahan tidak akan pernah mencapai mereka. Loop refinement tidak bisa menjadi lebih benar daripada hakimnya. Membeli lebih banyak round membeli percobaan atas error yang bisa dilihat hakim, dengan harga penuh, dan sama sekali tidak membeli apa pun untuk error yang tidak bisa dilihatnya.

Maka aturannya: evaluator pantas mendapat panggilannya hanya ketika ia memiliki sesuatu yang tidak dimiliki generator. Compiler, test suite, schema validator, model berbeda, manusia. Hasil Self-Refine sendiri diukur terhadap preferensi manusia dan metrik tugas, bukan terhadap opini model tentang dirinya sendiri. Jika satu-satunya keunggulan evaluator-mu adalah prompt berbeda, kamu membayar dua kali untuk persetujuan. Bab 29 membangun versi dengan keunggulan nyata: golden set dengan jawaban yang ditulis sebelumnya.

Lima di atas adalah bentuk untuk kode milikmu. Di bawahnya ada keluarga kedua yang sering dicantumkan bersama mereka dan seharusnya tidak: ReAct, Reflexion, plan-and-execute, dan tree of thoughts adalah reasoning loops, dan biayanya ada pada request.

Bab 12 membahas reasoning di dalam model, yang kamu bayar dalam output tokens pada satu panggilan. Ini jenis yang lain. Perbedaannya penting saat tagihan datang: chain of thought yang lebih panjang membuat satu panggilan lebih mahal, dan reasoning loop mengubah satu tugas menjadi banyak panggilan, yang masing-masing mengirim ulang semua yang sebelumnya — kuadratik yang diukur Bab 23 dalam tabel runaway-nya.

Paper tree-of-thoughts menerbitkan tabel biayanya sendiri, yang lebih jarang daripada seharusnya. Pada Game of 24 dengan GPT-4: input/output prompting best-of-100 menyelesaikan 33 % pada $0.13 per kasus, chain of thought best-of-100 menyelesaikan 49 % pada $0.47, dan tree of thoughts menyelesaikan 74 % pada $0.74, dengan penulis mencatat bahwa ia "could require 5-100 times more generated tokens than CoT".⁷

Hampir enam kali harga metode murah untuk sedikit lebih dari dua kali success rate. Apakah itu murah tergantung berapa biaya kasus gagal bagimu — pertanyaan yang perlu diajukan sebelum mengadopsi salah satu dari empat ini.

Kursus ini tidak mengimplementasikannya ulang. Keempatnya punya reference implementation oleh penulisnya sendiri, dalam Python, dan nilainya adalah menjadi sumber, bukan terjemahan: ysymyth/ReAct, noahshinn/reflexion, princeton-nlp/tree-of-thought-llm, dan AGI-Edgerunners/Plan-and-Solve-Prompting. Baca prompts di repository itu; prompts adalah papernya.

Sekarang multi-agent yang sebenarnya, tempat sebagian besar kebingungan hidup. Ada dua cara bagi satu agent untuk melibatkan agent lain, keduanya bukan varian, dan perbedaannya adalah siapa yang memegang kendali setelahnya.

Agent sebagai tool. Parent memanggilnya, mendapat jawaban, lalu melanjutkan. Ini interface tool Bab 18 dengan seluruh agent di belakangnya, dan parent tidak pernah kehilangan kendali. Inilah yang dilakukan orchestrator di atas.

Handoff. Parent mentransfer percakapan dan tidak mendapatkannya kembali. Panduan OpenAI adalah pernyataan terpublikasi yang paling jelas: handoffs adalah "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."⁸

Peringatan kosakata, karena ini terus membuat orang tersandung: "handoff" adalah kata milik satu SDK, bukan standar. Ini terminologi dari OpenAI Agents SDK dan panduan itu, yang juga menamai dua susunan tersebut "manager" dan "decentralized" serta mencatat bahwa dalam pola manager "edges represent tool calls whereas in the decentralized pattern, edges represent handoffs".⁸ Ada standar terbuka di ruang ini — A2A, pada versi 1.0.0, di bawah hak cipta Linux Foundation, dengan riwayat rilis berversi dan daftar breaking changes terdokumentasi, yang prinsip tertulisnya adalah opaque execution: agents "collaborate based on declared capabilities and exchanged information, without needing to share their internal thoughts, plans, or tool implementations".⁹ Itu bukan handoff, dan perbandingannya ada di Bab 26. Yang penting di sini adalah salah satu dari dua kata itu API sebuah library dan yang lain spesifikasi dengan governance.

Pembedanya adalah data structure, bukan 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;
}

Dua puluh baris, dua bug yang kalau tidak kamu temukan di production. reachable menemukan agent yang tidak bisa dijangkau siapa pun — dikonfigurasi, dibayar, tidak pernah dipanggil. conflicts menolak edge yang menjadi dua jenis sekaligus, yang terdengar pedantis sampai kamu membacanya keras-keras: parent sekaligus mempertahankan kendali dan menyerahkannya. Jalankan pada sistem lima agent dengan satu orphan dan satu double edge:

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

Sekarang pengukuran yang menjadi alasan section ini ada, dan satu-satunya di bab ini yang diambil terhadap model sungguhan, bukan model berskrip.

Seorang pelanggan menyatakan constraint di pesan pertama mereka — akun kami terdaftar di Portugal, bukan Spanyol; semua yang terkait pajak harus memakai Portugal — mengobrol tentang hal lain, lalu mengajukan pertanyaan yang harus dijawab billing. Kasusnya ditransfer. Dua puluh empat trial, negara dan perusahaan berbeda setiap kali, empat payload transfer, dan agent penerima lalu ditanya satu pertanyaan: di negara mana akun pelanggan ini terdaftar?

Baris ketiga adalah control dan berperilaku seperti control: faktanya tidak ada, jadi tidak bisa diingat. Tiga lainnya adalah temuannya.

Transkrip penuh 173 tokens dan bekerja 83 % dari waktu, dengan empat kegagalannya adalah subjek Bab 24, bukan bab ini. Typed record adalah 69 tokens — tujuh lebih banyak daripada summary — dan bekerja setiap kali, karena constraint berada di field bernama, bukan di kalimat.

Dan summary adalah baris yang perlu ditatap. Ia gagal 24 kali dari 24, dan alasannya bukan pembaca melewatkannya. Constraint muncul hanya dalam 1 dari 24 summary sama sekali. Agent penerima tidak ceroboh; ia diberi teks yang tidak mengandung jawaban. Summary adalah compaction yang tidak kamu tulis, diproduksi oleh model yang window-nya tidak bisa kamu lihat, dioptimalkan agar terbaca seperti summary — dan "pelanggan mengatakan catatan kita punya negara yang salah" adalah tepat jenis klausa yang dibuang summariser sebagai noise prosedural.

Batas jujur untuk angka itu: summariser-nya model setengah miliar parameter dan model yang lebih besar akan menyimpan lebih banyak. Yang tidak membaik dengan ukuran adalah bentuk risikonya — agent pengirim memutuskan, per handoff, per phrasing, tanpa bisa diamati, fakta mana yang bertahan. Typed record sama sekali tidak bergantung pada judgement itu, itulah sebabnya ia menang secara konstruksi, bukan karena kecerdasan. Apa pun yang harus bertahan dalam transfer seharusnya menjadi field, bukan kalimat.

Penalaran yang sama berlaku ke arah lain, pada topologi agent-as-tool, dan tabel sebelumnya sudah memberi harganya: yang kembali dari worker juga summary, dan membayar 8,3 % lebih untuk menerima evidence bersamanya adalah perbaikan yang sama dilihat dari sisi parent.

Tiga fakta penutup, semuanya dari tabel di atas.

Sistem multi-agent melipatgandakan panggilan, dan panggilan bersifat kuadratik dalam context. Orchestrator membuat 12 panggilan model ketika satu agent membuat 5, dan masing-masing membawa transcript yang tumbuh sendiri — 3,628 input tokens dibanding 2,697, gap yang melebar seiring panjang tugas.

Setiap batas adalah lossy channel. Dua agent berarti satu summary. Empat agent dalam chain berarti tiga, tersusun, masing-masing ditulis oleh model yang mengoptimalkan sesuatu selain keputusanmu.

Single agent menemukan sesuatu yang tidak diminta siapa pun. Ketidakcocokan purchase order muncul karena satu window memegang invoice dan order sekaligus. Memecah pekerjaan ke spesialis juga memecah kemampuan untuk melihat bahwa dua fakta saling bertentangan.

Tidak satu pun dari itu membantah framework multi-agent yang dipublikasikan, yang layak dibaca sebagai sumber primer, bukan lewat tutorial.¹⁰ Ini argumen untuk membuat agent kedua membuktikan bahwa ia layak mendapat tempatnya.

Jadi, sebuah tes, bukan preferensi. Tambahkan agent kedua ketika setidaknya salah satu dari ini benar: sub-task membutuhkan window bersih yang tidak boleh diwarisi parent (Bab 24); sub-task benar-benar independen dan wall clock penting, yaitu 1,8× di atas; sub-task membutuhkan permission berbeda atau model berbeda, yang di Bab 30 menjadi argumen keamanan; atau sub-task dimiliki pihak lain, tempat protokol sungguhan mulai penting. Jika jawabannya adalah "agar setiap agent punya prompt yang lebih jelas", beri satu agent itu prompt yang lebih jelas. Itu gratis.

Sekarang kamu bisa menyebutkan lima pola, menghitung biaya mereka satu sama lain pada satu tugas, membedakan orchestrator dari sectioner dan tool call dari handoff, serta membela single agent dengan tabel alih-alih preferensi.

Setiap susunan di sini berbagi satu kemudahan yang tidak akan bertahan saat bersentuhan dengan hal nyata: semua tool milik kita. Invoice, order, tabel pajak, worker di balik orchestrator — repository yang sama, deploy yang sama, type yang sama, orang yang sama.

Sekarang letakkan salah satunya di sisi lain batas perusahaan. Tabel pajak milik vendor akuntansi, catatan order milik sistem gudang, dan keduanya belum membaca interface Tool milikmu. Kamu membutuhkan cara agar model yang tidak kamu tulis bisa menemukan, mendeskripsikan, dan memanggil capability yang dioperasikan orang lain — dengan authentication (yang menjadi separuh Bab 27), versioning, dan jaminan bahwa server tidak bisa membaca sisa percakapanmu. Itu problem protokol, ia punya spesifikasi dengan schema normatif, dan hampir semua yang terindeks tentangnya mendeskripsikan revisi yang sudah tidak ada.

Bab 26 membaca spesifikasi itu alih-alih merangkumnya, dan mulai dengan mengetik JSON-RPC ke terminal secara manual.

Setiap biaya dan jumlah token di atas berasal dari provider berskrip yang dijelaskan di section kedua, pada Node 22 melalui interface loopback, dihitung dengan encoding o200k_base dan diberi harga dengan tarif yang dibaca Bab 16 pada 6 September 2026 — $2.00 per juta input tokens dan $12.00 per juta output. Angka wall-clock berasal dari run yang sama dengan latency provider diset 400 ms per panggilan dan tool 50 ms, sehingga angka itu mengukur susunan, bukan provider mana pun. Dua pengukuran model sungguhan — tabel handoff dan tabel voting-and-judging — memakai Qwen/Qwen2.5-0.5B-Instruct dalam float32 pada CPU di belakang endpoint dengan bentuk yang sama, greedy kecuali ketika temperature dinyatakan, dengan interval dihitung memakai metode Wilson dari Bab 4. Tidak ada request dalam bab ini yang pergi ke endpoint berbayar, dan tidak ada angka di dalamnya yang diestimasi.