Supervizor ve Devir

Neler öğreneceksin

Part 1’den beri tam olarak tek context window’lu tek bir ajan vardı, problemi tek başına çalışan, ve bu tek şekil tüm seriyi taşıdı, ondan önceki yirmi parçalık RAG dâhil. Bu gerçek bir sınırdır, ve kendini iki ayrı biçimde gösterir. İlki breadth’tir: gerçekten bağımsız parçaları olan bir görev, “refund politikasını, warranty’yi ve shipping seçeneklerini özetle”, tek bir context içinde paralel yapılamaz. Tek bir ajan onu depth-first yapmak zorundadır, bir öğeyi diğerinin ardından, ve tek transcript’i ilerledikçe her alt görevin enkazıyla dolar. İkincisi specialization’dır: gerçekte adanmış bir uzman tarafından ele alınması gereken bir görevi bir generalist’in loop’una tıkıştırmak hantaldır, oysa daha temiz hamle her şeyi doğru ajana devretmektir. Dolayısıyla bu parça iki ana multi-agent şeklini tanıtır. İlki orchestrator-worker desenidir (bir supervisor): bir lead ajan bir görevi alt görevlere ayrıştırır, her biri kendi izole context’i ve bir typed brief’i olan N worker spawn eder, ve sonra sonuçlarını sentezler. Worker, kara kutu olarak yeniden kullanılan Part 1 ajanından ibarettir; loop’u yeniden inşa etmiyoruz. İkincisi tool çağrısı olarak handoff’tur: kontrolü, ve canlı trace’i, bir uzmana transfer etmek, iki klasik başarısızlık moduyla. Ve her ikisinin içinden geçen, en az onlar kadar önemli, multi-agent’a ne zaman uzanılMAYACAĞININ dürüst ekonomisidir, çünkü bu sistemler daha pahalı, debug etmesi daha zor, ve sık sık fazla iridir. Single, supervisor ve bir proposer-critic debate’i sayılarla yan yana koyuyoruz, ve ölçmediğimiz bir speedup’ı asla iddia etmemeye dikkat ediyoruz.

Ön koşullar

Temel Python lazım: bir fonksiyon, bir liste, bir dictionary, bir string kontrolü. Hepsi bu. Daha önceki üç parça yardımcı olur ama gerekli değildir. Part 1 worker’dır: buradaki multi-agent şekilleri ReAct loop’unu yeniden türetmek yerine o ajanı bir kara kutu olarak yeniden kullanır. Part 8 circuit breaker’dır: kaçak bir supervisor (worker’lar worker spawn ederek) onunla durdurulur, değiştirilmeden yeniden kullanılır, yeniden inşa edilmez. Part 12 tool katmanıdır: bir worker’ın tool’ları o parçadaki MCP ile keşfedilen aksiyonlardır. Ama yazı kendi içinde bütünlüklü: daha önceki bir fikre yaslandığı yerde onu tek bir cümleyle yeniden ifade eder ve yeniden türetmek yerine ona referans verir. Eşlik eden kod, supervisor_and_handoffs.py, API anahtarı, ağ ve bağımlılık olmadan offline çalışır, böylece her satırı okuyup bu yazıdaki her çıktı satırını kendiniz yeniden üretebilirsiniz. Varsayılan lead, worker’lar ve critic deterministic’tir (offline); bu rollerin her birinde gerçek bir hosted LLM tek bir generate() flag’i uzaklıktadır.

Tek ajandan beri yeni olan ne

Neyin yeni olduğu konusunda kesin olmak istiyorum, çünkü bu gerçekten yeni bir zemin, tek-ajan dünyasının rafine edilmiş hâli değil. Şu ana kadarki her parça, RAG’e kadar geriye, tek controller, tek context window kullandı: RAG baştan sona single-agent’tı, tek bir büyüyen transcript içinde retrieve edip akıl yürütüyordu, ve agents core track’i de bunu hiç sorgulamadı. Bu parçanın eklediği şey ajanlar arası koordinasyon, ve neredeyse hepsi net-yeni. Orchestration: bir hedefi ayrıştıran ve alt görevleri dispatch eden bir lead. Ayrı context’li paralel worker’lar: her worker yalnızca kendi küçük brief’ini görür, paylaşılan, sürekli büyüyen tek bir transcript’i değil. Typed brief’ler: bir supervisor’ın bir worker’a verdiği structured contract. Blackboard: worker’ların sonuçlarını post ettiği paylaşılan, append-only bir yer. Agent-control handoff: loop’un kendisini, artı canlı trace’i, farklı bir ajana transfer etmek. Ve single-vs-multi ekonomisi: daha fazla ajanın ne zaman yardım ettiğinin ve ne zaman yalnızca işlerin ters gitme yollarını çoğalttığının dürüst muhasebesi. İki parça bilinçli biçimde yeniden inşa edilmez, yeniden kullanılır. Worker, kara kutu olarak Part 1 ajanıdır, dolayısıyla ReAct loop’u asla yeniden türetilmez. Kaçak bir supervisor’a karşı güvenlik durdurması Part 8’in circuit breaker’ıdır, kopyalanmaz, referans verilir. Ve bir ayrım önemli: buradaki handoff bir router’dan kategorik olarak farklıdır. RAG’in Part 15 complexity router’ı ve Part 18 text-vs-SQL router’ı tek bir ajanın içinde bir path seçti; bir handoff kontrolü başka bir ajana transfer eder ve trace’i de beraberinde taşır. Referans ver, birbirine karıştırma.

Orchestrator ve worker’ları

Supervisor ile başla. Lead’e breadth-first bir hedef verilir, Prepare a customer briefing on refunds, the earbuds warranty, and shipping., ve işi onu cevaplamak değil ayrıştırmaktır. Hedefi üç alt göreve böler ve her biri için bir typed brief yazar: bir objective (“refund politikasını özetle”), bir output format (“tek cümle”), tool guidance (hangi tool’a uzanılacağı), ve boundaries (kapsamın içinde ve dışında ne olduğu, “yalnızca policy”). Her brief ayrı bir worker’a gider, ve kritik özellik context isolation’dır: bir worker’ın context’i yalnızca brief’idir. Hedefi, diğer brief’leri ya da diğer worker’ların çıktısını asla görmez; tek küçük objective’ini görür, tek tool’unu çalıştırır, ve tek sonucunu paylaşılan append-only bir blackboard’a post eder. İşte kendi izole context’lerinde çalışan üç worker, artefaktın gerçek çıktısından alıntılanmış:

  supervisor decomposes: 'Prepare a customer briefing on refunds, the earbuds warranty, and shipping.'
    [w1] brief: summarize the refund policy (own context, 14 tokens) -> Refunds within 30 days; a 10% restocking fee applies after the window.
    [w2] brief: state the earbuds warranty (own context, 14 tokens) -> The Globex earbuds carry a 2-year limited warranty.
    [w3] brief: list the shipping options (own context, 14 tokens) -> Standard shipping is 3 to 5 business days; express is next business day.

Her worker’ı oku. w1, “summarize the refund policy” brief’ini aldı, yalnızca 14 token’lık bir context’te çalıştı, ve Refunds within 30 days; a 10% restocking fee applies after the window. döndürdü. w2, “state the earbuds warranty“‘yi aldı, kendi 14-token’lık context’inde çalıştı, ve The Globex earbuds carry a 2-year limited warranty. döndürdü. w3, “list the shipping options“‘ı aldı ve Standard shipping is 3 to 5 business days; express is next business day. döndürdü. Dikkat edilecek sayı 14 token, üç kere, 42’ye ve ötesine büyüyen tek bir context değil. Her worker yalnızca kendi brief’ini taşır, dolayısıyla hiçbiri diğerlerinin context’i için ödeme yapmaz. Üçü de post ettikten sonra, supervisor bir worker’ın yapamayacağı tek işi yapar: blackboard’u okur ve parçaları, hedefin istediği bütüne sentezler:

  supervisor synthesizes the blackboard into the briefing:
    Refunds within 30 days; a 10% restocking fee applies after the window. The Globex earbuds carry a 2-year limited warranty. Standard shipping is 3 to 5 business days; express is next business day.
    (3 workers, each its own context; with real concurrency they run in ONE round.)

Sentezlenmiş briefing, tek bir tutarlı cevapta birleştirilmiş üç blackboard girişidir, tam olarak hedefin çağırdığı briefing, tek bir şişen transcript içinde hesaplanmak yerine üç izole iş parçasından monte edilmiş. Son satır, parallelism hakkındaki dürüst iddiadır, ve ona tam olarak sadık kalıyoruz: üç worker var, her biri kendi context’i, ve gerçek concurrency ile tek bir round’da çalışırlar. Offline’da sequential çalıştılar; isolation’ın aldığı şey şimdi küçük per-worker context’ler, ve onları gerçekten concurrent çalıştırdığında tek bir round’luk latency.

Tool çağrısı olarak handoff

Fan-out, breadth için doğru hamledir. Specialization için doğru hamle ikinci şekildir: worker spawn etmek değil, canlı trace’i de beraberinde taşıyarak bir uzmana kontrol transfer etmek. handoff(to=...) diğerleri gibi bir tool’dur, ancak transfer ettiği şey loop’un kendisi artı şu ana kadarki konuşmadır. Temiz bir handoff’un iki şeyin doğru olmasına ihtiyacı vardır: tam trace seyahat etmeli (böylece uzman ilk ajanın topladığı gerçeklere sahip olur), ve rol net olmalı (böylece uzman artık görevin sahibi olduğunu bilir). İkisi de geçerli olduğunda, handoff sadece işler, artefaktın gerçek çıktısından alıntılanmış:

  clean handoff (full trace, clear role):
    handoff(to='billing-specialist'): carrying 3/3 trace entries, role=clear
    -> [done] billing-specialist refunded order ORD-3300 using the carried trace.

Lead, ön çalışmayı zaten yapmıştı: refund için ORD-3300 order’ını belirledi, policy’ye baktı, ve kullanıcının onu istediğini doğruladı, üç trace girişi. Handoff 3/3 trace entries, role=clear taşır, dolayısıyla billing-specialist her gerçeği devralır, refund’ın sahibi olduğunu bilir, ve onu tamamlar: [done] billing-specialist refunded order ORD-3300 using the carried trace. Şimdi iki klasik başarısızlık modu, ki bunlar tam olarak kırılmış iki önkoşuldur. İlki truncation’dır: trace kesilir, ve kilit gerçek de onunla birlikte gider.

  failure mode TRUNCATION (trace cut to the last entry; the order id was earlier):
    handoff(to='billing-specialist'): carrying 1/3 trace entries, role=clear
    -> [failed] billing-specialist cannot act: the order id was truncated out of the carried trace.

Burada handoff’tan yalnızca son giriş sağ kaldı, 1/3 trace entries, ve order id daha önce belirlenmişti, kesilen bir girişte. Rol netti, uzman hazırdı, ama cannot act: the order id was truncated out of the carried trace. Uzman yanlış değil; sadece ihtiyaç duyduğu tek gerçeği kaybetmiş durumda, çünkü onu taşıması gereken trace kırpılmıştı. İkinci başarısızlık modu role confusion’dır: trace tamamdır, ama görevin sahibinin kim olduğunu kimse söylememiştir.

  failure mode ROLE CONFUSION (brief never said who owns it):
    handoff(to='billing-specialist'): carrying 3/3 trace entries, role=UNCLEAR
    -> [stalled] billing-specialist and the lead both wait: the brief never said who owns the task.

Bu kez tam 3/3 trace entries geldi, dolayısıyla gerçeklerin hepsi orada, ama role=UNCLEAR. Sonuç bir nezaket deadlock’udur: [stalled] billing-specialist and the lead both wait: the brief never said who owns the task. Her ajan diğerinin sahip olduğunu varsayar, dolayısıyla hiçbiri aksiyon almaz. Bunların bir router’ın başarısızlıklarından farkına dikkat et: bir router yanlış bir branch seçer ama tek bir ajan devam eder; bozulmuş bir handoff işi iki ajan arasında ortada bırakır, çünkü kontrolün kendisi, ve bindiği trace, temiz biçimde transfer olmadı.

Ekonomi: single vs supervisor vs debate

Şimdi bunlardan herhangi birine uzanmalı mısın diye karar veren kısım. Aynı hedefi üç şekilde çalıştırıyoruz, single agent, supervisor, ve bir proposer-critic debate, ve offline’daki tek dürüst para birimlerini raporluyoruz: LLM-call sayısı, toplam context token’ı, ve üç üzerinden kalite. İşte tablo, artefaktın gerçek çıktısından alıntılanmış:

  strategy        LLM calls   tokens  quality
  -----------------------------------------
  single                  4      300      3/3
  supervisor              5      220      3/3
  debate                  7      320      2/3

Satır satır oku. Single ajan en az call’u kullanır, dört, ama o iş için en çok token’ı, 300, çünkü tek bir büyüyen context’i vardır: her step kendinden öncekinin hepsini yeniden gönderir, dolayısıyla transcript baştan sona tırmanır. Supervisor daha fazla call kullanır, beş (decompose, üç worker, synthesize), ve yine de daha az token, 220, çünkü her worker context’i izole ve küçüktür ve büyümez; bir-iki fazla call için ödeme yaparsın ve her birinin taşıdığı context’ten tasarruf edersin. İkisi de 3/3 kaliteye ulaşır. Debate uyarıcı hikâyedir: yedi call, 320’de en çok token, ve aslında daha kötü skor yapar, 2/3. Daha çok makine, daha çok maliyet, daha az kalite. Ve sebep round-by-round dökümündedir, ki bu tüm parçanın rahatsız edici bulgusudur, artefaktın gerçek çıktısından alıntılanmış:

  Debate quality by round (more rounds is NOT more quality):
    proposer   quality 2/3
    round 1    quality 3/3
    round 2    quality 3/3
    round 3    quality 2/3  <- regressed

Proposer 2/3’te açar. Critique-and-revise’ın 1. round’u onu 3/3’e kaldırır, ve 2. round 3/3’te tutar. Sonra 3. round 2/3’e regress eder: fazladan round cevabı rafine etmedi, ona zarar verdi. Kalite round’larda monoton değildir; daha çok debate daha çok kalite değildir, ve “emin olmak için” debate etmeye devam eden bir sistem doğru bir cevaptan kendini konuşarak çıkarabilir. Aşağıdaki amiral figür üç stratejiyi yan yana koyar ve regression’ın olmasını izlemek için debate round’larında adım adım ilerlemeni sağlar.

Open figure ↗

Ne zaman YAPMAMALI

Tüm tablo tek bir yönü gösterir: multi-agent bir tool’dur, bir varsayılan değildir. Küçük, sequential bir görev için single agent doğru ve daha ucuz tool’dur, en az call ve büyüse de üç-dört kez ödenmesi gerekmeyen bir context. Supervisor’a yalnızca iş gerçekten geniş olduğunda uzan, her biri kendi temiz context’inde çalışabilen ve sonunda sentezlenebilen birkaç bağımsız alt görev, çünkü isolation’ın fazladan call’lar için ödeme yaptığı ve gerçek concurrency’nin latency’yi tek bir round’a çökerttiği tek durum budur. Bu sayıların gücüyle debate’e neredeyse hiç uzanma: en pahalı stratejiydi ve regress etti. Yöneten kural basittir ve sondan-bir-önceki sütunu izler: cost-per-success token’ları izler. Breadth için yalnızca görev geniş olduğunda ödeme yap; aksi hâlde aynı cevap için daha fazla, ya da debate’in durumunda, daha kötü bir cevap için daha fazla harcıyorsun.

Neyi iddia ediyoruz, neyi etmiyoruz

Bu dürüstlük bölümüdür, ve tüm parçanın feasibility crux’udur. Offline varsayılan worker’ları sequential çalıştırır. Asla uydurulmuş bir wall-clock speedup yazdırmıyoruz, ve koşunun hiçbir yerinde bir tane bulamayacaksın; o, deterministic path hakkında bir yalan olurdu. Multi-agent’ın gerçekte aldığı şey, ve iddia ettiğimiz her şey, iki dürüst para biriminde raporlanır. İlki LLM-call sayısı, tablonun calls sütunu. İkincisi token isolation: her worker yalnızca kendi küçük brief’ini görür, 14 tokens, sürekli büyüyen tek bir paylaşılan transcript’i değil, ki supervisor’ın 220 token’ının fazladan bir call’la bile single agent’ın 300’ünü yenmesinin sebebi budur. Koşu bunu en başta belirtir, artefaktın gerçek çıktısından alıntılanmış:

Parallelism is SEQUENTIAL in this offline default: we report LLM-call count and
TOKEN ISOLATION (each worker sees only its brief), never a fabricated wall-clock.

Latency hikâyesi bir sonuçtur, bir ölçüm değil: çünkü üç worker bağımsızdır ve her birinin kendi context’i vardır, gerçek concurrency ile tek bir round’da çalışırlar, depth 1, ki bu tam olarak Part 3’ün parallel-fan-out fikridir. Bu, işin şekli hakkında bir iddiadır (bağımsız, dolayısıyla parallelizable), offline’da aldığımız bir kronometre okuması değil. İki yeniden kullanım loop’u kapatır ve yeniden inşa edilmek yerine referans verilir. Kaçak bir supervisor, worker’lar worker spawn ederek, worker spawn ederek, Part 8’in circuit breaker’ıyla durdurulur, değiştirilmeden. Ve bu distributed koşular, fan-out’lu worker’larıyla bir lead, Part 11’in span tree’si olarak render edilir, zaten inşa ettiğimiz aynı observability’nin ileriye dönük bir devamı.

💡 Deneyimden. Multi-agent sistemleri hakkında öğrendiğim en pahalı ders, birine ihtiyaç duymadan önce bir tane inşa etmiş olmamdır. Support sorularını cevaplayan gayet iyi bir single agent’ımız vardı, ve onu bir uzman worker filosuna sahip bir supervisor’a bölmenin onu daha hızlı ve daha iyi yapacağından emindim. İkisini de yapmadı. Gerçekte sahip olduğumuz görevler için, çoğu bir lookup ve kısa bir cevap, supervisor zaten tek bir context’e sığan işin üstüne bir decompose call’u ve bir synthesize call’u ekledi, dolayısıyla her request hiçbir kalite kazancı olmadan daha yavaş ve daha pahalı hâle geldi, tam olarak bu parçadaki single-versus-supervisor satırı ama bir billing dashboard’unda yaşanmış. Supervisor ancak aylar sonra hakkını vermeye başladı, yeni bir özellik gerçekten aynı anda beş bağımsız şey toplamaya ihtiyaç duyduğunda; o zaman izole context’ler ve tek-round’luk fan-out tam olarak reklam edildiği gibi karşılığını verdi. Diğer yara bir handoff’tan. Bir refund’ı triage ajanından bir billing ajanına transfer ettik ve “context tasarrufu” için taşınan trace’i kırptık, ve kırpma order id’yi tutan girişi düşürdü. Billing ajanı her şeyi doğru yaptı ve yine de başarısız oldu, çünkü ihtiyaç duyduğu tek gerçek altından truncate edilmişti, bu parçadaki [failed] ... the order id was truncated out of the carried trace. satırı, neredeyse kelimesi kelimesine. Artık bir handoff’un taşıdığı trace’i bir contract olarak ele alıyorum: tam trace seyahat eder, ve brief görevin sahibinin kim olduğunu tek bir cümleyle söyler, yoksa handoff’u göndermem.

Özet / Çıkarımlar

• Part 1’den beri tek context window’lu tek bir ajan vardı, ve bu iki şekilde kırılır: breadth-first işi paralelleştiremez (bağımsız alt görevler tek bir şişen context’te depth-first gitmek zorundadır) ve doğru hamle bir uzmana handoff etmek olduğunda fazla iridir. Çözüm birden fazla ajandır, ve çözüm aynı zamanda bir tuzaktır.
• Orchestrator-worker (supervisor) deseni: bir lead hedefi typed brief’lere (objective, output format, tool guidance, boundaries) ayrıştırır, her biri kendi izole context’inde (burada her biri 14 tokens) N worker spawn eder, worker’lar paylaşılan append-only bir blackboard’a post eder, ve supervisor sentezler. Worker, kara kutu olarak yeniden kullanılan Part 1 ajanıdır; loop yeniden inşa edilmez.
• Tool çağrısı olarak handoff kontrolü ve canlı trace’i bir uzmana transfer eder. Temiz vaka tamamlandı: [done] billing-specialist refunded order ORD-3300 using the carried trace. İki başarısızlık modu truncation (1/3 trace, [failed] ... the order id was truncated out of the carried trace.) ve role confusion (3/3 trace ama role=UNCLEAR, [stalled] ... the brief never said who owns the task.).
• Bir handoff bir router’dan kategorik olarak farklıdır: bir router tek bir ajanın içinde bir path seçer (RAG’in Part 15 / Part 18 router’ları), oysa bir handoff kontrolü başka bir ajana transfer eder ve trace’i taşır. Bozulmuş bir handoff işi yalnızca yanlış bir branch seçmek yerine iki ajan arasında ortada bırakır.
• Ekonomi: single 4 calls / 300 tokens / 3/3, supervisor 5 / 220 / 3/3, debate 7 / 320 / 2/3. Single’da en az call ama tek bir büyüyen context var; supervisor’da daha fazla call ama izole küçük context’ler (token’larda daha ucuz ve parallelizable); debate en pahalı ve non-monoton, 2. round’da 3/3’ten 3. round’da 2/3’e regress ederek. Cost-per-success token’ları izler: breadth için yalnızca görev geniş olduğunda ödeme yap.
• Dürüstlük: offline varsayılan worker’ları sequential çalıştırır, dolayısıyla call sayısını ve token isolation’ı raporluyoruz, asla bir wall-clock speedup. Gerçek concurrency ile bağımsız worker’lar tek bir round’da çalışır (Part 3 depth). Kaçak bir supervisor Part 8’in circuit breaker’ı ile durdurulur (yeniden kullanılır), ve bu koşular Part 11 span tree olarak render edilir.

Sözlük

• Orchestrator-worker / supervisor: bir lead ajanın bir görevi alt görevlere ayrıştırdığı, her birini bir worker’a dispatch ettiği, ve sonuçları sentezlediği bir multi-agent şekli. Lead parçalamayı ve bir araya getirmeyi yapar; worker’lar parçaları yapar. Worker, kara kutu olarak yeniden kullanılan Part 1 ajanıdır.
• Typed brief: bir supervisor’ın bir worker’a verdiği structured contract, bir objective, bir output format, tool guidance, ve boundaries (kapsamın içinde ve dışında ne olduğu) ile. Bir worker’ın daha geniş hedefe dair hiçbir bilgisi olmadan kendi başına faydalı biçimde çalışmasını sağlayan şey budur.
• Worker context isolation: bir worker’ın context’inin yalnızca brief’i olması (burada 14 tokens), asla hedef, diğer brief’ler ya da diğer worker’ların çıktısı değil özelliği. Isolation, supervisor’ın toplam token’ının (220) daha fazla LLM call’uyla bile single agent’ınkini (300) yenebilmesinin sebebidir.
• Blackboard: worker’ların sonuçlarını post ettiği ve supervisor’ın sentezlemek için okuduğu paylaşılan, append-only bir yer. Paylaşılan veri üzerinden koordinasyon, hiçbir kontrol transferi olmadan, bir handoff’un spektrumun karşı ucu.
• Handoff (tool çağrısı olarak): loop’un kontrolünü, artı canlı trace’i, bir uzman ajana transfer eden bir tool. Temiz bir handoff hem tam trace’e hem net bir sahibe ihtiyaç duyar; bir router’dan ayrıdır, ki o kontrolü başkasına geçirmek yerine tek bir ajanın içinde bir path seçer.
• Truncation (başarısızlık modu): trace handoff’tan geçerken kesilir, dolayısıyla uzman kilit bir gerçeği kaybeder. Burada 1/3 giriş sağ kaldı ve order id düşürülen daha önceki bir girişteydi, dolayısıyla uzman rolü net olsa bile [failed] oldu.
• Role confusion (başarısızlık modu): tam trace gelir ama brief görevin sahibinin kim olduğunu asla söylemez, dolayısıyla iki ajan da birbirini bekler. Burada 3/3 trace ama role=UNCLEAR bir [stalled] nezaket deadlock’u üretti, her biri diğerinin sahip olduğunu varsayarak.
• Proposer-critic debate: bir proposer’ın bir cevap taslağı çizdiği ve bir critic’in onu birkaç round boyunca revize ettiği bir multi-agent şekli. Bu parçada en pahalı stratejiydi (7 call, 320 token) ve non-monoton: kalite 2. round’a kadar 3/3’e yükseldi sonra 3. round’da 2/3’e regress etti. Daha çok round daha çok kalite değildir.
• Single-vs-multi ekonomisi: birden fazla ajan kullanılıp kullanılmayacağına karar veren muhasebe, LLM call’larıyla, toplam context token’larıyla, ve kaliteyle ölçülür. Cost-per-success token’ları izler, dolayısıyla küçük sequential bir görev için single agent doğrudur ve supervisor yalnızca iş gerçekten geniş olduğunda doğrudur.
• Parallelism’i dürüstçe raporlamak: offline varsayılan worker’ları sequential çalıştırdığı için, multi-agent’ın değeri LLM-call sayısı ve token isolation olarak raporlanır, asla uydurulmuş bir wall-clock speedup. Tek-round’luk latency, işin bağımsız olmasının bir sonucudur (Part 3 depth), şekil hakkında iddia edilir, offline’da ölçülmez.

---

Bu parçanın kuralı: multi-agent’ı bir tool olarak ele al, bir varsayılan olarak değil. İş gerçekten geniş olduğunda, orchestrator-worker şeklini kullan, hedefi typed brief’lere ayrıştıran, worker’ları izole context’lerde spawn eden, onları bir blackboard üzerinden koordine eden, ve sonucu sentezleyen bir lead, Part 1 ajanını worker olarak ve Part 8’in breaker’ını kaçağa karşı durdurma olarak yeniden kullanarak. Doğru hamle bir uzman olduğunda, tool çağrısı olarak handoff et, ama tam trace’i taşı ve net bir sahip adlandır, yoksa truncation ve role-confusion stall’ları alırsın. Ve ekonomiyi önünde tut: küçük sequential bir görev için single agent daha ucuz, doğru tool’dur; supervisor yalnızca breadth’te kendini amorti eder; debate pahalı ve monoton değildir. Ama bu parçadaki her şeklin paylaştığı sınıra dikkat et: handoff’lar ve worker’lar hepsi tek bir process içinde yaşar. Supervisor bir worker spawn edebilir çünkü worker kendi kodudur; bir billing-specialist’e handoff edebilir çünkü o uzman aynı runtime’da erişilebilirdir. Billing ajanı başka bir takım tarafından sahiplenildiği, başka bir service arkasında olduğu an, o sınır kırılır. Part 15, Agent to Agent, delegasyonu o çizginin ötesine taşır, sahip olmadığı ve import edemediği bir ajanı keşfetmek, çağırmak ve ona handoff etmek için bir A2A protokolü, MCP’nin tool’lar için yaptığı özel bir dictionary’den public bir protokole aynı adım, şimdi ajanların kendileri için yapılmış.