# Anthropic Multi-Agent Mimarisi: Orchestrator-Worker Pattern ile Tek Agent'a Karşı %90.2 Üstün Performans Nasıl Elde Edilir? > Source: https://sukruyusufkaya.com/blog/anthropic-multi-agent-orchestrator-worker-pattern-2026 > Updated: 2026-07-11T19:45:44.110Z > Type: blog > Category: yapay-zeka **TLDR:** Anthropic'in Multi-Agent Research sisteminde Orchestrator-Worker Pattern tek-agent Claude Opus 4.x'i internal research eval'inde %90.2 farkla geçti. Bu rehber: lead agent + paralel subagent mimarisi, structured artifact handoff, planner-generator-evaluator döngüsü, Claude Agent SDK ile .claude/agents/ implementasyonu, cost cap, deadlock, CrewAI/LangGraph/AutoGen karşılaştırması ve Türk hukuk firmasında contract analysis vakası. ## 1. Giriş: Tek Agent Niye Yetmiyor? Bir LLM agent'ı yeterince güçlü model + tool erişimi + iyi bir sistem prompt'u ile birçok iş görür. Ancak **derin araştırma, çok-belge analiz, çok-paydaşlı raporlama** gibi karmaşık görevlerde tek agent üç dar boğaza çarpar: 1. **Context dilüsyonu.** İş büyüdükçe context window içinde dosyalar, gözlemler, ara çıktılar birikir. *Lost in the middle* etkisiyle model erken adımları unutur. 2. **Sıralı bottleneck.** Tek agent paralel düşünemez; 10 belgeyi sırayla analiz eder. 1 saatlik iş 10 saate çıkar. 3. **Dikkat dağılımı.** Aynı agent hem strateji üretiyor hem ayrıntı yapıyor; ikisinde de orta kalite verir. Anthropic, bu üç problemi **multi-agent orchestrator-worker pattern**'i ile çözdüğünü Mart 2025'te yayımlanan *"How we built our multi-agent research system"* makalesinde belgeledi. Sonuç internal research eval'de tek-agent Claude Opus baseline'a karşı **%90.2 üstün performans**. ### 1.1. Multi-Agent Tarihçesi: ReAct'tan Anthropic'e Multi-agent kavramı yeni değil — fakat 2022-2026 arasında dört dalga halinde olgunlaştı: - **2022 — ReAct (Yao et al.).** Tek agent'ın "düşün → eylem → gözlem" döngüsü. Tool kullanımı standartlaştı. - **2023 — Reflexion, Tree of Thoughts, Generative Agents.** Self-reflection, çoklu reasoning yolu, agent simülasyonu. - **2024 — AutoGen, CrewAI, LangGraph.** Multi-agent için ilk Python framework'leri. Hâlâ deneysel. - **2025 — Anthropic Multi-Agent Research + Claude Agent SDK.** Üretim-sınıfı, ölçülmüş benchmark'larla gelen ilk büyük kanıt. Pattern olgunlaştı. Anthropic'in Mart 2025 yayını **akademik bir araştırma değil, üretim raporu** olduğu için ekosistem üzerinde benzersiz bir etki yaptı: gerçek kullanıcılarla, gerçek workload'lar, gerçek maliyet/kalite trade-off'larıyla belgelenmiş bir mimari. ### 1.2. Multi-Agent ile Karıştırılmaması Gereken Kavramlar - **Multi-step (multi-turn) agent ≠ multi-agent.** Tek agent çok sayıda adımda çalışabilir; bu multi-agent değildir. - **Chained LLM calls ≠ multi-agent.** Bir prompt'un çıktısını başka prompt'a vermek "chain" olur, agent değil. - **Tool use ≠ subagent.** Tool, deterministic bir fonksiyondur; subagent kendi reasoning'i olan bir LLM çağrısıdır. - **Mixture of Experts (MoE) ≠ multi-agent.** MoE mimari-içi (model parametre yönlendirme); multi-agent dış-orchestration. Bu ayrımları netleştirmek, multi-agent'ın gerçek değer yarattığı vakaları yanlış vakalardan ayırt etmek için kritik. ## 2. Mimarinin Anatomisi: Lead + Workers Pattern beş bileşenden oluşur. ### 2.1. Lead Orchestrator Agent - **Model:** En yetenekli model (Anthropic örneğinde Opus 4.7). - **Rol:** Görevi anlama, alt-görevlere ayrıştırma, subagent'ları paralel başlatma, sonuçları birleştirme, kullanıcıya sunma. - **Context:** Yüksek-seviye plan + subagent çıktılarının özetleri. Detay yok. ### 2.2. Worker Subagents - **Model:** Hızlı + ucuz (Sonnet 4.6 veya Haiku 4.5). - **Rol:** Lead'in verdiği alt-görevi temiz context'te yürütme. - **Context isolation:** Her subagent kendi context'ini taşır, diğer subagent'ların çıktısını görmez. ### 2.3. Tools - Subagent'lar web arama, kod yürütme, dosya okuma, MCP tool'ları gibi kabiliyetlere erişir. - Lead genelde sadece "subagent başlat" tool'una sahiptir; doğrudan tool kullanmaz. ### 2.4. Structured Artifact Handoffs - Subagent çıktısı düz metin değil, **JSON şemaya uyan yapılandırılmış artifact**'tır. - Örnek: `{ key_finding: ..., sources: [...], confidence: 0.x }`. - Lead, artifact'ları parse eder ve birleştirir. ### 2.5. Evaluator / Critic (opsiyonel) - Üçüncü tip subagent: subagent çıktısını kalite/doğruluk için denetler. - Planner-Generator-Evaluator pattern'inin "Evaluator" kısmı. ### 2.6. Subagent Lifecycle: 7 Faz Üretim multi-agent sisteminde bir subagent yaşam döngüsü: 1. **Spawn.** Lead, subagent SDK API'sine "yeni instance" çağrısı yapar. 2. **Initialize.** Subagent kendi system prompt + tool catalog'unu yükler. 3. **Receive Task.** Lead'in verdiği task input parse edilir (JSON). 4. **Execute.** ReAct döngüsü (think → tool → observe → think → ...). 5. **Validate Output.** Subagent kendi çıktısını schema-validation ile kontrol eder. 6. **Return Artifact.** Structured artifact orchestrator'a döner. 7. **Cleanup.** Memory, file handle, network connection bırakılır. Her fazda hata olabilir. İyi orchestrator her faz için fallback ve retry stratejisi tanımlar. ### 2.7. Structured Artifact Şema Tasarımı Artifact şema tasarımı multi-agent kalitenin **belirleyici** kararlarından biri. Şu prensipler: 1. **Sabit alan listesi.** Her artifact aynı top-level alanlara sahip (subtask_id, status, findings, sources, confidence). 2. **Type-safe.** Pydantic veya Zod ile validation. Schema-mismatch fail-fast. 3. **Confidence skoru zorunlu.** Her bulgu 0-1 arası bir güven değeriyle. 4. **Source attribution.** Her bulgu en az bir kaynak referansı. 5. **Open questions.** Subagent emin değilse açıkça flag. 6. **Hash imza.** Artifact içeriğinden hash; tampering tespit. 7. **Timestamp.** Hangi anda üretildiğini bilmek (cache invalidation için). Anti-pattern: her subagent farklı şema. Bu, orchestrator'ı patternless string parse'a zorlar ve hata yüzeyini arttırır. ## 3. Planner-Generator-Evaluator Pattern Multi-agent mimari, bir alt-pattern olan **Planner-Generator-Evaluator** ile zenginleşir. ### Pattern Akışı 1. **Planner** (Lead, Opus 4.7): kullanıcı sorgusunu okur, n alt-görev üretir. 2. **n paralel Generator/Worker**: her biri bir alt-görevi yürütür, structured artifact döner. 3. **Evaluator/Critic**: artifact'ları skorlar; düşük kaliteliler için generator'a re-try sinyali. 4. **Writer** (Lead): yüksek-kaliteli artifact'ları birleştirir, kullanıcıya cevabı yazar. 5. **Reviewer** (opsiyonel): final cevabı kullanıcıya verilmeden önce QA eder. ### 3.3. Pattern Varyasyonları Planner-Generator-Evaluator'ın dört üretken varyasyonu vardır: - **Hierarchical PGE.** Lead → Sub-lead → Worker (üç seviye). Çok büyük görevler (yüzlerce belge) için. - **PGE with Self-Reflection.** Generator önce kendi çıktısını gözden geçirir, sonra Evaluator'a verir. Hata yüzeyini azaltır. - **Adversarial PGE.** Bir Evaluator, başka bir Evaluator'ı denetler (red team). Hassas vakalar (hukuki, tıbbi) için. - **Iterative PGE.** Evaluator düşük confidence verirse Generator'a feedback ile geri gönderilir. 2-3 iterasyon yaygın. Hangi varyasyon? Görev hassasiyeti (high-stake → iterative veya adversarial), latency tolerance (yüksek hassasiyet için yavaş kabul), maliyet bütçesi. ### 3.4. Pattern'in Sınırları PGE her sorunu çözmez: - **Çok kısa görevler.** Tek prompt'la çözülebilen şeyler için overkill. - **Deterministic pipeline.** Audit zorunluluğu varsa, stochastic PGE yerine deterministic workflow tercih edilir. - **Düşük-maliyet eşiği.** Token bütçesi sıkı ise PGE kapatılmalı. ### 3.5. Pattern Karşılaştırması: Sequential vs Parallel vs Hybrid Multi-agent çalışmasında üç temel iş akışı: **Sequential** — Subagent A bitince B çalışır, B bitince C. Çıktı zincirleme bağımlı (örn. plan → araştırma → yazım). **Parallel** — A, B, C aynı anda çalışır, çıktılar bağımsız (örn. çoklu kaynak araştırma). **Hybrid (DAG)** — Bazı subagent'lar paralel, bazıları onlara bağımlı (gerçek dünya en yaygın). Bir DAG örneği: - Planner (1 subagent) - Researcher × 5 (paralel, planner'a bağımlı) - Critic × 5 (her researcher'a bağımlı, paralel) - Aggregator (1 subagent, tüm critic'lere bağımlı) - Writer (1 subagent, aggregator'a bağımlı) - Reviewer (1 subagent, writer'a bağımlı) Toplam: 14 subagent, max paralelizm 5, end-to-end latency = planner + researcher + critic + aggregator + writer + reviewer. ### 3.6. Coordination Patterns Subagent'lar arası koordinasyon dört modelden biriyle yapılır: 1. **Centralized (orchestrator-led):** Lead bütün kararı verir. En yaygın, en kontrollü. 2. **Decentralized (peer-to-peer):** Subagent'lar birbiriyle konuşur. Esnek ama deadlock riski. 3. **Blackboard:** Tüm subagent'lar paylaşılan bir "board"a okur/yazar. Klasik AI pattern, modern multi-agent'ta daha az. 4. **Auction:** Subagent'lar task'a "teklif verir" (kendi confidence + capacity). Edge case'lerde değerli. Anthropic'in raporladığı sistem **Centralized**'tır. Çoğu üretim sistemi bu modeli kullanır. ## 4. Pratik Implementasyon: Claude Agent SDK Anthropic'in Claude Agent SDK (2025'te yayımlandı) multi-agent pattern'i için referans implementasyon sağlar. Klasör yapısı: ~~~text my-project/ ├── .claude/ │ ├── settings.json │ ├── agents/ │ │ ├── researcher.md │ │ ├── critic.md │ │ ├── writer.md │ │ └── reviewer.md │ └── mcp.json └── src/ ~~~ ### 4.1. Subagent Tanımı (.claude/agents/researcher.md) ~~~markdown --- name: researcher description: | Use this subagent for deep research tasks. Given a question and authorized sources, returns a structured artifact with findings, citations, and confidence scores. tools: [web_search, fetch, read_file] model: claude-sonnet-4-6 --- You are a research subagent. For each subtask: 1. Search authoritative sources (academic, government, official docs). 2. Extract key findings with direct quotes. 3. Cite every claim with source URL + date. 4. Return JSON artifact: ~~~json { "subtask_id": "", "key_findings": ["..."], "sources": [{"url": "...", "title": "...", "date": "..."}], "confidence": 0.0-1.0, "open_questions": ["..."] } ~~~ If a source is unreliable or paywalled, lower confidence and flag in open_questions. ~~~ ### 4.2. Lead Orchestrator (uygulama tarafı) ~~~typescript import { query } from "@anthropic-ai/claude-agent-sdk"; async function multiAgentResearch(question: string) { // Step 1: Planner — Lead agent generates subtasks const plan = await query({ model: "claude-opus-4-7", systemPrompt: "You are a research planner...", prompt: "Decompose this question into 3-5 parallel research subtasks: " + question, }); const subtasks = JSON.parse(plan.text).subtasks; // Step 2: Workers — parallel subagents const workerResults = await Promise.all( subtasks.map((task) => query({ agent: "researcher", prompt: JSON.stringify(task), }) ) ); // Step 3: Evaluator const evaluations = await Promise.all( workerResults.map((r) => query({ agent: "critic", prompt: r.text, }) ) ); // Step 4: Writer const final = await query({ model: "claude-opus-4-7", systemPrompt: "You are a research writer. Synthesize the artifacts...", prompt: JSON.stringify({ subtasks, results: workerResults, evals: evaluations }), }); return final.text; } ~~~ ### 4.3. Konfigürasyon Detayları - **Cost cap:** Subagent başına maksimum token + zaman. - **Concurrency:** Maks paralel subagent sayısı (4-6 en yaygın). - **Retry policy:** Subagent fail olursa 2x retry, sonra critic ile yer değiştir. - **Telemetry:** Her subagent için latency, token, model, başarı durumu izlenir. ### 4.4. Subagent Markdown Frontmatter'ı Anthropic'in `.claude/agents/*.md` formatı, frontmatter'da yapılandırma + body'de prompt taşır: ~~~markdown --- name: critic description: Evaluates research artifacts for quality and confidence. tools: [read_file] model: claude-sonnet-4-6 max_tokens: 4000 temperature: 0 --- You are a critical reviewer. For each artifact: 1. Check that every claim has a citation. 2. Verify the source URL is reachable (use read_file if local). 3. Score the artifact 0-1 on faithfulness, relevance, completeness. 4. Return JSON: { score, issues, recommendations } ~~~ Bu format **versiyon kontrolüne girer** (git ile), code review'dan geçer, ve takım üyelerinin subagent'larını paylaşmasını sağlar. ### 4.5. MCP Entegrasyonu Multi-agent sistem MCP server'larıyla tipik şekilde birleşir: - **Lead orchestrator:** spawn_subagent, store_artifact gibi meta-tool'lar. - **Worker subagent:** web_search, github, sql, vector_db gibi MCP tool'ları. - **Evaluator:** read_artifact, score, suggest_fix tool'ları. Anthropic Claude Agent SDK + MCP entegrasyonu bu kompozisyonu konfigürasyon-driven yapar. `.claude/mcp.json` ile hangi MCP server'ların hangi subagent'a açık olduğu belirlenir. ### 4.6. State Management Multi-agent sistemde state üç katmanda yaşar: 1. **Per-subagent state.** Subagent kendi context'inde, geçici. 2. **Orchestrator state.** Lead'in tuttuğu subagent çıktılarının birleşimi. 3. **Persistent state.** Database/cache'e yazılan ara sonuçlar (uzun-running task için). Persistent state için yaygın seçimler: Redis (ara sonuç cache), Postgres (final artifact + audit), object storage (büyük blob'lar). ## 5. Performans Analizi: Niye %90.2 Fark? Anthropic'in raporladığı %90.2 üstün performansın arkasında dört etken yatar. ### 5.1. Context Isolation Her subagent kendi temiz context'inde çalışır → *lost-in-the-middle* etkisi yok. 200 sayfa belgeyi tek context'e sıkıştırmak yerine 5 subagent'a 40 sayfa veriyorsun. ### 5.2. Paralelizm 5 subagent paralel çalışırsa toplam latency tek-agent'ın 1/5'i. Internal eval'de Anthropic, paralel subagent'lı sistemin latency ile kalite arasındaki dengede tek-agent'ı domine ettiğini gösterdi. ### 5.3. Model Optimizasyonu Lead'i Opus, worker'ları Sonnet/Haiku yaparak **uygun yere uygun model** yerleştirilir. Stratejik düşünce pahalı modele, koşum işi ucuz modele. ### 5.4. Specialization "Researcher" agent specifically prompt'lanmış, kendi role'üne göre optimize. Generalist tek-agent her şeyi vasat yapar. ### 5.5. Hangi Workload'larda Fark Açılır? Anthropic'in raporladığı %90.2 figürü, tüm görevler için geçerli değil. Fark **şu workload'larda açılır**: - **Çok-belge sentezi:** 20+ belge, çoklu kaynak, çelişkili findings birleştirme. - **Çok-paydaşlı raporlama:** Hukuki + finansal + operasyonel perspektifi tek raporda birleştirme. - **Derin web research:** 50+ web kaynağı tarama, citation aggregation. - **Çoklu paralel hipotez testi:** Bir araştırma sorusu için 5 farklı yöntem. **Şu workload'larda fark açılmaz** (multi-agent overhead'e değmez): - Tek dosya kod review. - Kısa Q&A. - Tek belge özet. - Klasik RAG retrieval. - Code completion. ### 5.6. Benchmark Yorumlama Uyarısı %90.2 figürü Anthropic'in **kendi internal eval'inde**, kendi tanımladığı görev seti üzerinde. Bağımsız benchmark'lar (AgentBench, GAIA, SWE-bench) henüz aynı düzeyde fark göstermedi — fark var ama tipik %15-40 arasında. Bu, mimari tasarımının ötesinde **prompt engineering ve subagent rol tanımı**nın da etkili olduğunu gösteriyor. ### 5.7. Latency Optimizasyon Teknikleri Multi-agent latency'yi düşürmenin yolları: 1. **Streaming.** İlk subagent çıktısı gelir gelmez writer'ı parça parça başlat. 2. **Speculative execution.** Olası birkaç subtask'i pre-fire et, gerçek path belli olunca sadece gerekli olanları tut. 3. **Cached planning.** Aynı task tipinde plan cache'le (planner'ı atla). 4. **Model parallelism.** Worker'lar farklı endpoint'lere dağıtılır (rate-limit byp-ass). 5. **Prefetch tools.** Subagent başlamadan tool catalog'ları load. 6. **Early answer.** Yeterince yüksek-confidence subagent çıktısı gelince writer'ı tetikle, geç gelenler ek bilgi olarak kullan. Bu tekniklerle %30-60 latency azaltımı tipik. ### 5.8. Stop-Conditions Multi-agent ne zaman "biter"? Stop-condition tasarımı: 1. **Time budget.** Max wall-clock saat (örn. 5 dakika). 2. **Token budget.** Max toplam token (örn. 200K). 3. **Confidence threshold.** Final answer confidence > 0.9 ise dur. 4. **No-improvement detection.** Iterative PGE'de son 2 iterasyonda iyileşme yok ise dur. 5. **Human intervention.** Reviewer "stop" derse dur. Her multi-agent task'ında en az 3 stop-condition aktif olmalı. ## 6. Diğer Multi-Agent Çatılarıyla Karşılaştırma ### Hangi Framework Hangi Senaryoya? - **Claude Agent SDK:** Anthropic Claude tabanlı stack, .claude/ klasör yapısı, MCP'ye derin entegrasyon. - **LangGraph:** Karmaşık state machine + döngü gerekiyorsa; agentic graph'lar. - **CrewAI:** Hızlı POC + rol-tabanlı agent tasarımı; Python ekosistemi. - **AutoGen:** Agent'lar arası konuşma + insan-in-the-loop senaryoları. ### 6.3. Hibrit Yaklaşımlar Pratikte tek bir framework yetmez. Yaygın kombinasyonlar: - **Claude Agent SDK (lead) + LangGraph (worker state machine).** Anthropic ekosistem güveni + karmaşık state ihtiyacı. - **CrewAI (POC) → Claude Agent SDK (production).** Hızlı prototip Python'da, production-grade Anthropic stack'te. - **AutoGen (insan-in-the-loop) + LangGraph (deterministic pipeline).** İki ayrı sub-system, ortak API. Multi-framework risk: lock-in azalır, karmaşıklık artar. Karar dependency size + dev team familiarity. ### 6.4. "Don't Build Multi-Agents" Karşı-Argümanı Cognition AI (Devin'in arkasındaki şirket), Eylül 2025'te "Don't Build Multi-Agents" başlıklı bir karşı-argüman yayınladı. Tezleri: 1. Multi-agent latency'yi katlar. 2. Hata yüzeyi exponential büyür. 3. Aynı sonuç tek-agent + iyi context yönetimiyle elde edilebilir. Bu argümanın geçerli olduğu vakalar: **yazılım mühendisliği** (Devin'in ana use-case'i), **interactive coding session**. Anthropic'in raporladığı vakalar (derin araştırma) farklı bir profile sahip — multi-agent'ın değer ürettiği yer burası. **Sonuç:** "Multi-agent her zaman daha iyi" yanlış; "tek-agent her zaman yeterli" de yanlış. Use-case'e göre karar. ## 7. Türkiye Açısı: KVKK, BDDK ve Çok-Paydaşlı İşler Multi-agent sistemler Türk şirketleri için özellikle üç senaryoda değer üretir. ### 7.1. Compliance Otomasyonu KVKK ihlal denetimi: planner ihlal şikayetini okur, üç worker paralel çalışır: (1) ilgili VERBİS kaydı çekme, (2) emsal KVKK kararı arama, (3) iç politika karşılaştırma. Evaluator skorlar, writer rapor üretir. Süre: 4-8 saat insan iş → 12-18 dakika. ### 7.2. Çok-Belge Analiz Hukuk firmaları, denetim firmaları, M&A danışmanlık için 50-200 belge eş-zamanlı analiz. Tek-agent yetmez; multi-agent doğal seçim. ### 7.3. Research + Report Üretimi Strateji danışmanlığı, sektör raporları: çoklu kaynak (rapor, makale, veri tabanı) paralel taranır, structured findings birleştirilir, executive summary yazılır. ### 7.4. KVKK Mülahazaları Multi-agent sistem PII gördüğünde: (1) PII redaction katmanı orchestrator öncesi, (2) subagent'lar EU/TR hosted endpoint'lere bağlanır, (3) artifact'lar audit log'a yazılır. ### 7.5. Türk Şirketleri İçin Multi-Agent Use-Case Haritası Sektör bazında multi-agent'ın yüksek ROI sağladığı vakalar: **Bankacılık / Sigorta** - M&A due diligence sözleşme analizi - Kredi başvurusu risk değerlendirmesi (KYC + AML + finansal analiz paralel) - KVKK ihlal soruşturması otomasyonu - Fraud pattern recognition + soruşturma raporu **Hukuk** - Sözleşme due diligence - Emsal karar arama + sentez raporu - Mevzuat değişiklik impact analizi - Mahkeme dosyası özetleme **Sağlık** - Multi-uzman vaka tartışması simülasyonu (kardiyolog + endokrinolog + radyolog subagent) - Klinik araştırma literatür taraması - Klinik karar destek (uyarı: yüksek-stake, Reviewer şart) **E-ticaret / Pazarlama** - Rakip ürün katalog analizi - Müşteri segmentasyon araştırması - Çoklu kanal pazarlama planı sentezi **Üretim / Lojistik** - Tedarik zinciri risk analizi - Tedarikçi due diligence - Operasyonel ölçütler raporlama Bu haritada **yüksek-stake** alanlar (sağlık, hukuk) iterative + adversarial PGE pattern'ini gerektirir. ### 7.6. Türkçe Subagent Tasarımı Türk müşteriler için subagent prompt'ları: 1. **Sistem prompt'u Türkçe.** Model dil-tutarlı çıkar. 2. **Kaynaklar Türkçe öncelik.** Mevzuat, içtihat, akademik. Said Surucu MCP'leri burada referans. 3. **Citation format Türkiye standardı.** "Yargıtay 11. HD, E. 2024/123, K. 2024/456" gibi. 4. **KVKK + BDDK farkındalığı sistem prompt'una entegre.** Subagent kendi cevabında bu kuralları gözeterek üretir. Bu, "global multi-agent + Türkçe katmanı" yerine **Türkiye-first multi-agent** mimarisi yaratır. ### 7.7. Türkiye'de Multi-Agent Eğitim Programı Bir kurumun developer + domain ekibini multi-agent yetkin hale getirme: 6-hafta program: **Hafta 1 — Temel Agent Kavramları** - LLM agent vs LLM chat (4 saat) - Tool use, ReAct, Reflexion (6 saat) - Hands-on: tek-agent Claude Code + MCP (4 saat) **Hafta 2 — Multi-Agent Mimari** - Orchestrator-worker pattern (6 saat) - Planner-Generator-Evaluator (4 saat) - Structured artifacts (4 saat) **Hafta 3 — Claude Agent SDK + .claude/agents/** - SDK kurulum + subagent yazma (8 saat) - Critic + Writer + Reviewer rolleri (6 saat) **Hafta 4 — Cost, Latency, Observability** - Cost cap + retry policy (4 saat) - Langfuse + OpenTelemetry (4 saat) - Eval harness (8 saat) **Hafta 5 — Production Patterns** - Deployment (K8s + Redis + Postgres) (8 saat) - KVKK + BDDK uyum katmanı (4 saat) - Anti-pattern avoidance (4 saat) **Hafta 6 — Capstone** - Gerçek bir kullanım vakası için end-to-end multi-agent geliştirme (16 saat) Toplam: 88 saat. Sonunda her ekip üyesi kendi domain'inde production-ready bir multi-agent prototip teslim etmiş olur. ## 8. Vaka Çalışması (Anonim): Türk Hukuk Firmasında Multi-Agent Contract Analysis ### Problem İstanbul merkezli kurumsal hukuk firması, M&A işlemlerinde hedef şirketin tüm sözleşmelerini (90-300 adet) due diligence için analiz etmek zorunda. Tipik bir M&A: 12-18 avukat × 3-4 hafta × 60 saat/hafta = ~2.500-4.000 saat manuel iş. ### Çözüm Multi-agent orchestrator-worker pattern: - **Lead Orchestrator (Opus 4.7):** sözleşmeleri kategorize eder (NDA, hizmet, lisans, kira, istihdam, finansal), her kategori için paralel pipeline başlatır. - **6 paralel Worker (Sonnet 4.6):** her biri bir sözleşme kategorisi. Risk maddeleri, change-of-control, tazminat tavanı, KVKK uyumu, emsal hata maddeleri. - **Evaluator (Sonnet 4.6):** çelişkili findings'leri ve düşük-güven artifacts'i flagger. - **Writer (Opus 4.7):** executive due diligence raporu yazar. - **Reviewer (kıdemli avukat):** final raporu insan QA. KVKK uyumu: PII redaction katmanı pre-orchestrator. Tüm LLM çağrıları Anthropic EU endpoint'e. Audit log her artifact için. ### Sonuç - Süre: 2.500 saat → 65 saat insan + 80 saat AI işleme süresi. Net hızlanma: ~16x. - Risk maddesi tespit oranı: %23 daha yüksek (insan ekibi kaçırdığı maddeleri AI bulabildi). - Subjektif kalite: ortaklar "rapor şimdi daha tutarlı" dedi (insan ekibi yorgunlukla tutarsızdı). - Maliyet: M&A başına ~$8.500 LLM maliyeti, ~$2.4M tasarruf insan saatleri. ### 8.1. Vaka 2 (Anonim) — Türk Bankası: Kredi Başvuru Multi-Agent Triyajı **Problem.** Bankaya günde 8.000-12.000 kurumsal kredi başvurusu geliyor. Her başvuru için: KYC tarama + AML risk + finansal tablolar + emsal karar (kara liste, yapılandırma geçmişi) + müşteri profili. Tek-uzman tipik 35-50 dakika harcıyordu. **Çözüm.** Multi-agent triyaj: - **Lead Orchestrator (Opus 4.7):** başvuru paketini ayrıştırır, 5 paralel subagent başlatır. - **Subagent 1 (Sonnet):** KYC + AML + dış kaynak tarama (BIK, KKB, TCKK). - **Subagent 2 (Sonnet):** Mali tablo analizi (gelir tablosu, bilanço, nakit akış). - **Subagent 3 (Haiku):** Emsal/yapılandırma geçmişi. - **Subagent 4 (Sonnet):** Sektör risk + makro veri (CBRT, BDDK). - **Subagent 5 (Haiku):** Müşteri profil + cross-sell fırsatı. - **Evaluator (Sonnet):** çelişkili findings'leri flagger. - **Writer (Opus):** kredi memo + risk rating + öneri. - **Reviewer (kıdemli kredi analisti):** final memo'yu insan QA. KVKK + BDDK: PII redaction, EU/TR endpoint, on-prem MCP gateway, audit log. **Sonuç.** - İnceleme süresi 35 dk → 8 dk (insan) + 6 dk (AI). ~3x hızlanma. - Subjektif kalite: kredi komite ortakları "memo şimdi daha kapsamlı" dedi. - Risk skoru tutarlılığı: insan ekibinde stdev 15 → 6. - Yüksek-risk başvuruların yakalanma oranı %18 arttı. - Operasyonel kapasiteyi 1.4x artırdı, yeni personel almaya gerek kalmadı. ### 8.2. Vaka 3 (Anonim) — Türk Strateji Danışmanlığı: Sektör Raporu Multi-Agent **Problem.** Strateji danışmanlığı firması, müşterilerine sektör raporu hazırlıyor. Tipik bir rapor: 4 hafta × 3 analist = 480 saat manuel araştırma + 80 saat yazım. **Çözüm.** Multi-agent sektör raporu pipeline'ı: - **Lead (Opus 4.7):** rapor outline'ı çıkartır, alt-başlıkları subagent'lara dağıtır. - **Researcher subagent'lar (Sonnet × 6):** her biri bir alt-başlığı paralel araştırır (pazar büyüklüğü, oyuncular, regülasyon, trendler, riskler, fırsatlar). - **Data subagent (Haiku):** TÜİK, KAP, sektör birlikleri verilerini çeker. - **Critic (Sonnet):** her finding'in kaynağını ve confidence'ını denetler. - **Writer (Opus):** executive summary + ana bölümleri yazar. - **Reviewer (kıdemli partner):** narrative coherence + müşteri perspektifi. **Sonuç.** - Rapor süresi 4 hafta → 6 gün. - Analist başına 3x daha fazla projeye paralel katkı. - Kaynak çeşitliliği insan ekibinden %40 daha yüksek (subagent paralel taraması daha geniş ağ atıyor). - Müşteri NPS skoru 8 → 9.4 (rapor "daha derin ve daha güncel" geri bildirimi). ### 8.3. Vaka 4 (Anonim) — Türk Telekom Şirketi: Şikayet Tasnif + Cevap **Problem.** Türkiye'de bir telekom şirketinin sosyal medya (Twitter/X, Sikayetvar, Şikayet HD) + e-posta + çağrı merkezi kanalından günde 18.000-30.000 şikayet geliyor. Klasik sistemde her şikayet manuel tasnif edilip ilgili ekibe yönlendiriliyordu (network, faturalama, mobil, sabit, kurumsal). Tipik tasnif süresi 6-10 saat. **Çözüm.** Multi-agent şikayet işleme pipeline'ı: - **Lead (Sonnet 4.6):** şikayet metnini parse eder, kategori candidate'ları çıkartır. - **Classifier subagent (Haiku):** kategori netleştirme + öncelik. - **Researcher subagent (Sonnet):** ilgili müşteri geçmişi + benzer şikayet kayıtları. - **Solution subagent (Sonnet):** ön-cevap önerisi (FAQ + emsal çözüm). - **Tone subagent (Haiku):** cevabın empati + profesyonellik dengesi. - **Critic (Sonnet):** cevabın doğruluğu + KVKK uyumu. - **Reviewer (insan, kategori önemine göre):** %18 yüksek-öncelik cevap insan QA. KVKK: PII redaction pre-orchestrator, EU endpoint, audit log. **Sonuç.** - Tasnif süresi 6-10 saat → 18 dakika. - Müşteri memnuniyet skoru (NPS) %14 artış. - Aynı şikayetlerin tekrar etmemesi için pattern recognition, root cause analizine input. - Yıllık operasyonel tasarruf: ~7.2M TL. ### 8.4. Vaka 5 (Anonim) — Türk Hastane Zinciri: Klinik Karar Destek Multi-Agent **Problem.** Özel bir hastane zincirinde, kompleks vakalar (özellikle endokrinoloji + kardiyoloji + onkoloji çakışan) için multi-uzman konsültasyonu randevu darboğazı oluşturuyor. Tipik: 7-10 gün bekleme. **Çözüm.** Bir multi-agent klinik karar destek sistemi: - **Lead (Opus 4.7):** hasta dosyası özetler, hangi specialty'lerin gerektiğine karar verir. - **3-5 paralel uzman subagent (Sonnet):** her biri farklı specialty (kardiyolog, endokrinolog, radyolog, vb.). Her biri o specialty'nin literatür + guideline'ı + emsal vakaları erişir. - **Critic (Sonnet):** çelişkili önerileri ve düşük-confidence'i flagger. - **Writer (Opus):** entegre öneri raporu (tartışılması gereken vurgu). - **Reviewer (kıdemli klinisyen):** **zorunlu insan QA**, klinik tavsiye için. KVKK Sağlık Verisi: tüm sistem on-prem, **kişisel sağlık verisi dış API'ye gitmez**, sadece anonimleştirilmiş özet ve literatür retrieval. **Sonuç.** - Konsültasyon bekleme 7-10 gün → 24-48 saat. - Multi-disipliner görüş kalitesi (klinisyen self-report) artışı. - Klinik karar tutarlılığı: doktor-arası varyans azaldı. - **Önemli not:** Sistem **klinik tavsiye vermez**, "tartışma için içgörü üretir". Final karar klinisyenden. Hastalara verilen tavsiye yine klinisyenin imzasıyla. Bu vaka, multi-agent'ın **insan profesyoneli destekleyici** rolünün, yüksek-stake alanlarda nasıl tasarlandığını gösterir. ## 9. Riskler, Maliyetler ve Operasyonel Endişeler ### 9.1. Token Maliyeti Multi-agent tek-agent'tan 4-15x token harcar. Karar kriteri: **"Subagent başına çıktının değeri token maliyetini geçiyor mu?"** Derin research'te kolayca evet; basit chat'te kolayca hayır. ### 9.2. Deadlock ve Sonsuz Döngü Subagent başka subagent çağırma yetkisi varsa (recursive) sonsuz döngü oluşabilir. Önlem: çağrı derinliği limiti (max depth 3), per-task timeout, global cost cap. ### 9.3. Error Handling Bir subagent fail olursa ne olur? Üç pattern: (1) tüm task fail, (2) o subagent'ı atla devam, (3) yeniden başlat (max 2 retry). En sağlam: critic'in artifact'ı düşük confidence olarak işaretlemesi + orchestrator'ın aksiyon kararı. ### 9.4. Observability Her subagent için: latency, token in/out, model, başarı durumu, çıktı boyutu, evaluator skoru. Araçlar: Langfuse, Arize Phoenix, Helicone, OpenTelemetry. ### 9.5. Deterministik Olmama Subagent çıktıları stochastic; aynı görev iki kez çalıştırılırsa farklı sonuç çıkabilir. Bu, deterministik pipeline'lara (audit, finansal) zorluk getirir. Önlem: temperature=0, structured output, eval harness. Multi-agent sistem operasyonel karmaşıklığı 3-5x artırır. Eğer single-agent + iyi RAG ile %80 değer üretebiliyorsanız, multi-agent'a geçişi production değil POC sonrası yapın. "Cool factor" değil ROI karar vermeli. ## 10. Sıkça Sorulan Sorular Hayır. Basit Q&A, kısa özet, kod tamamlama gibi *single-step* görevlerde tek agent yeterlidir. Multi-agent **derin araştırma, çok-belge analiz, çoklu-paydaş raporlama** gibi *parallel + multi-step* görevlerde anlamlıdır. Anthropic'in %90.2 figürü internal *research* eval'inde — chat veya basit görevlerde değil.

Anthropic raporunda 3-5 subagent en yaygın. Daha fazlası orkestrasyon overhead'ini ve cost cap riskini artırır. Daha azı paralelizm avantajını kaybeder.

Worker'lar için Sonnet 4.6 + Haiku 4.5 karışımı en yaygın. Düşük-stake worker'lar Haiku (ucuz, hızlı), yüksek-stake worker'lar Sonnet. Lead için kesin Opus 4.7 (stratejik düşünce + uzun context).

Lead'in birleştirme kolaylığına göre. Tipik alanlar: subtask_id, key_findings, sources, confidence, open_questions, next_actions. JSON Schema + Pydantic/Zod validation orchestrator tarafında zorunlu.

Üç katman: (1) global cost cap (task başına max $X), (2) per-subagent token cap, (3) early termination (planner'ın "yeterli bilgi var" sinyali). Anthropic Claude Agent SDK bunları config-driven sunar.

Claude-merkezli stack + .claude/ workflow + MCP entegrasyonu istiyorsanız Claude Agent SDK. Çoklu LLM provider, karmaşık state machine, conditional branching gerekiyorsa LangGraph. İkisi birlikte de çalışır.

Her subagent için: full prompt + response + tools called + latency + token usage izlenir. Langfuse trace'leri ya da Anthropic'in console.anthropic.com'daki workflow viewer'ı kullanılır. Reproducibility için tüm subagent çağrıları kaydedilir.

Evet — fakat tasarım kararıdır. PII redaction pre-orchestrator, EU/TR endpoint kullanımı, audit log, ve subagent çağrılarının cross-border transfer içermemesi gerekir. Bunlar mimari katmanında çözülür, sonradan eklenmez.

Üç katman: **(1)** temperature=0 (kısmen yardım eder), **(2)** structured output + Pydantic/Zod schema (form kontrolü), **(3)** seed-based prompt + cached input. Tam reproducibility imkansız ama %80+ tutarlılık sağlanabilir. Audit zorunluluğu varsa final cevap yerine **subagent çağrı kayıtlarını saklayın** — bu, deterministic bir referans yaratır.

Multi-agent RAG'ın **üstünde** çalışır: Worker subagent'lar kendi RAG retrieval'ını yapar (paralel vektör arama). Lead orchestrator sadece "araştırma sorusu" verir, subagent kendi RAG context'ini kurar. Bu, **distributed RAG** gibi düşünülür — her subagent kendi mini-RAG'ını çalıştırır.

Genel cevap: **hayır**. Subagent'ın başka subagent başlatması (recursion), cost cap'i, deadlock'u ve hata yayılımını kontrol etmeyi zorlaştırır. İstisnai vakalarda (hiyerarşik PGE), max derinlik 3 ile sınırla ve her seviyede ayrı budget tahsisat ile.

LLM judge (örn. GPT-5 as judge) hızlı ve ucuz; insan judge altın standart ama pahalı. Karma yaklaşım: **eval set'in %80'i LLM judge ile sürekli izle, %20'sini periyodik insan QA**. Anthropic Mart 2025 raporundaki %90.2 figürü de internal eval (LLM judge + insan kalibrasyon) ile. ## 10.0. Operasyonel Mimari: Production-Grade Multi-Agent Sistem Üretim seviyesinde bir multi-agent sistemin mimari diyagramı şöyle görünür: ### Katman 1: API Gateway - Kullanıcı request'i karşılayan reverse proxy. - Rate limit, authentication, request ID. - Cloudflare, Kong, Nginx — tercih edilen. ### Katman 2: Job Queue - Multi-agent task'larını queue'ya yazar. - Worker processler queue'dan task çeker. - Redis Streams, RabbitMQ, SQS — tercih edilen. ### Katman 3: Orchestrator Service - Lead agent çalıştırır. - Subagent spawning'i yönetir. - State (orchestrator memory) saklar. - Stateless tasarlanır (state Redis'te), horizontal scale mümkün. ### Katman 4: Subagent Worker Pool - Sonnet/Haiku subagent çağrılarını paralel yürüten worker'lar. - Auto-scale (yük arttıkça artar). - Per-worker resource limit. ### Katman 5: Tool Layer - MCP gateway: tüm subagent'ların kullandığı tool'lar. - Tool-specific cache (Redis). - Rate limit per tool. ### Katman 6: Persistence - Postgres: final artifact + audit log. - Object storage (S3): büyük blob'lar. - Vector DB (Qdrant): RAG retrieval. ### Katman 7: Observability - OpenTelemetry collector → Jaeger/Honeycomb (trace). - Prometheus (metrics). - Loki/Cloudwatch (logs). - Langfuse (LLM-specific). ### Katman 8: Safety - Constitutional AI safety classifier (Anthropic). - Custom guardrails (Pydantic AI Guards, Llama Guard). - Human review queue (high-stake task'lar için). Bu 8 katmanın tamamı production multi-agent için gereklidir. ## 10.5. Multi-Agent Maliyet Optimizasyon Stratejileri Multi-agent maliyetini ezici tutmak için 10 pratik strateji: 1. **Worker'larda Haiku kullan.** Düşük-stake subagent'ları Haiku 4.5 yap, Sonnet'i orta-stake, Opus'u sadece lead/writer için. 2. **Prompt caching.** Subagent system prompt'ları tekrarlandığı için Anthropic prompt caching ile 10x ucuzlar. 3. **Early termination.** Planner'ın "yeterli bilgi var" sinyaliyle gereksiz subagent başlatmayı kes. 4. **Cache subagent çıktıları.** Aynı task tekrar geliyorsa cache'ten döndür. 5. **Batch subagent.** Mümkünse iki küçük subtask'ı tek subagent'a ver. 6. **Tool output truncation.** Tool döndürdüğü 100K token'lık veriyi summarize edip subagent'a ver. 7. **Context window optimization.** Lead context'inde subagent ham çıktısı yerine artifact özeti tut. 8. **Streaming.** İlk artifact gelir gelmez writer'ı başlat (paralel pipeline). 9. **Selective re-runs.** Critic düşük confidence verirse sadece ilgili subagent'ı re-try et, tüm pipeline'ı değil. 10. **Spot pricing / Bedrock provisioned throughput.** Yüksek-volume kullanımda Anthropic Bedrock provisioned veya Azure committed throughput ile fiyat indirimi. Bu 10 stratejinin uygulanmasıyla tipik multi-agent maliyeti **3-7x** azalabilir. ## 10.6. Multi-Agent Migration: Tek-Agent'tan Geçiş Stratejisi Mevcut tek-agent sisteminize multi-agent eklemek için 5-faz migration: ### Faz 0: Baseline Tek-agent sisteminizin eval skorlarını ölçün. Latency, cost, accuracy, hallucination rate. Bu, "öncesi" verisi. ### Faz 1: Shadow Mode Multi-agent sistemi paralel kurun, **gerçek trafiği shadow'la** (response'u kullanıcıya dönmez, log'lanır). 1-2 hafta. ### Faz 2: A/B Test Trafik %10'unu multi-agent'a yönlendir. Metrics karşılaştır. Yeşil ise %25, %50, %100'e arttır. ### Faz 3: Full Rollout %100 trafik multi-agent. Eski tek-agent fallback olarak tutulur (degraded mode için). ### Faz 4: Optimize A/B test'ten gelen verileri kullanarak prompt'ları, subagent rolleri, schema'ları optimize et. ### Faz 5: Decommission 6-12 ay sonra eski tek-agent'ı emekliye ayır. Telemetry temizliği. Bu 5-faz tipik 3-6 ay sürer. Aceleci geçişte rollback maliyetli olur. ## 10.7. Multi-Agent Eval Harness Multi-agent sistemde eval daha karmaşık çünkü intermediate (subagent çıktı) ve final (writer çıktı) ikisini ayrı ölçmek gerek: ### Intermediate Metrikler - **Subagent faithfulness:** Subagent çıktısı kendi kaynaklarına sadık mı? - **Subagent recall:** Subagent gerekli bilgiyi yakaladı mı? - **Critic accuracy:** Critic'in skorları human-rater skorlarıyla uyumlu mu? - **Plan quality:** Planner'ın alt-görevleri ortogonal mu, overlap var mı? ### Final Metrikler - **End-to-end accuracy:** Final cevap doğru mu? - **Coherence:** Subagent çıktılarının birleşimi tutarlı mı? - **Citation accuracy:** Final cevaptaki citation'lar gerçek mi? - **Latency p50, p95.** - **Cost per task.** ### Eval Araçları - **LangFuse:** Hierarchical trace ile multi-agent'a uygun. - **Anthropic Console Workflows:** workflow viewer. - **Custom dashboards:** Grafana + OpenTelemetry GenAI spans. Eval harness olmadan multi-agent'ı production'a almak, sezgisel davranış değişikliklerini fark edememek demektir. ## 10.8. Multi-Agent Anti-Patterns: Yapılmaması Gerekenler Üretimde tekrar eden başarısızlık paternleri: ### Anti-Pattern 1: Echo Chamber Tüm subagent'lar aynı kaynaktan veri çekiyorsa "paralel araştırma" hayali kuruyorsunuz ama gerçekte yedek bilgi alıyorsunuz. Çözüm: subagent'lara farklı kaynak alt-kümeleri yönlendir. ### Anti-Pattern 2: Hyper-Granular Decomposition Lead, basit bir görevi 12 alt-göreve böler. Token bütçesi patlar, faydası yok. Tipik: 3-5 alt-görev sweet spot. ### Anti-Pattern 3: No Evaluator Critic katmanını atlamak ucuza gelir ama kalite garantisini de atar. Sonuç: hallucination'a kapı. ### Anti-Pattern 4: Free-Form Artifact Structured schema olmadan subagent çıktıları string olarak Lead'e gelir; orchestrator regex parse'a düşer; flaky. ### Anti-Pattern 5: Shared Mutable State Subagent'lar aynı state objesini paylaşıyorsa race condition + non-determinism. Her subagent kendi izolasyonunda kalsın. ### Anti-Pattern 6: Synchronous Wait Lead, ilk subagent bitsin diye 4 dakika bekliyor, sonra ikinciye geçiyor. Promise.all veya asyncio.gather kullanın — gerçek paralelizm. ### Anti-Pattern 7: Recursion Without Cap Subagent başka subagent çağırıyor, cap yok. Sonsuz döngü riskinin yanı sıra cost cap için kontrolsüz. ### Anti-Pattern 8: Long-Lived Lead Context Lead'in context'i her subagent çıktısıyla şişiyor; lost-in-the-middle Lead'e de bulaşıyor. Summary-only context tutun. ### Anti-Pattern 9: No Cost Cap Pipeline tahmin edilemez maliyetlerle bitebilir. Token budget hard-limit zorunlu. ### Anti-Pattern 10: Skipping Reviewer Yüksek-stake task'larda insan reviewer'ı kaldırmak: yasal/itibar riski. Reviewer'ı tutun, hatta zorlaştırın. ## 10.9. Production'a Geçiş Checklist'i (16 Madde) - [ ] Lead + worker + critic + writer + reviewer rolleri net tanımlı - [ ] Her subagent için system prompt + tool listesi + model seçimi belge - [ ] Structured artifact JSON schema yazılı + validation aktif - [ ] Pydantic/Zod ile schema validation hatasında fail-fast - [ ] Cost cap (global + per-subagent) konfigüre - [ ] Concurrency limit (max 4-6 paralel) - [ ] Retry policy (max 2 retry, exponential backoff) - [ ] Timeout (per-subagent 60-300s) - [ ] Cancellation propagation (kullanıcı iptal ederse subagent'lar durdurulur) - [ ] PII redaction katmanı pre-orchestrator - [ ] Audit log her subagent çağrısı için - [ ] KVKK/BDDK uyumu hukuk ekibi onayı - [ ] Observability (Langfuse trace, Helicone log) - [ ] Eval harness (intermediate + final metrics) - [ ] Production smoke test (10+ gerçek görev) - [ ] Runbook (incident response, rollback) 16/16 olmadan production'a alma riski yüksek. ## 10.10. Multi-Agent Failure Modları: Diagnostik Rehberi Multi-agent sistemde sık karşılaşılan failure modları + diagnostik: ### Mod 1: Plan Çöküşü **Symptom:** Planner her zaman benzer subtask çıkarıyor, çeşitlilik yok. **Sebep:** Planner prompt'u çok dar. **Çare:** Planner'a örnekleri çeşitlendir, "diverse decomposition" talimatı ekle. ### Mod 2: Subagent Domino **Symptom:** Bir subagent fail → pipeline tamamen düşer. **Sebep:** Hard-dependency tasarım. **Çare:** Critic'in "missing finding" raporlamasına izin ver, writer eksik bilgi ile özetleme yapsın. ### Mod 3: Confidence Inflation **Symptom:** Tüm subagent'lar 0.9+ confidence veriyor ama gerçek doğruluk %60. **Sebep:** LLM confidence kalibrasyon zayıf. **Çare:** Confidence verme talimatı katı kalibrasyon kuralı ekle ("0.9 sadece çoklu bağımsız kaynak doğrularsa"). ### Mod 4: Critic Bias **Symptom:** Critic her şeyi onaylıyor (veya her şeyi reddediyor). **Sebep:** Critic prompt'u dengesiz. **Çare:** Critic'i adversarial prompt ile yeniden kalibre et; ground truth-labeled örnekler ile validation. ### Mod 5: Writer Hallucination **Symptom:** Writer subagent çıktısında olmayan iddialar üretiyor. **Sebep:** Writer "yaratıcı" olmaya yönlendirilmiş. **Çare:** Writer system prompt'unda "sadece artifact'larda olan bilgi" kuralını sertleştir. ### Mod 6: Deadlock **Symptom:** Pipeline 5+ dakika bekliyor, hiç çıktı yok. **Sebep:** Subagent'ler dış API'de timeout. **Çare:** Her subagent için aggressive timeout + cancellation propagation. ### Mod 7: Memory Bloat **Symptom:** Lead'in context'i devasa, latency artıyor. **Sebep:** Artifact full body Lead'e dönüyor. **Çare:** Artifact'ın özet versiyonunu Lead'e ver, full body'yi persistent storage'a yaz. Bu 7 mod, multi-agent debug'ın %80'ini kapsar. ## 10.11. Multi-Agent ile Single-Agent Karar Matriksi Karar verirken kullanılabilecek pratik matriks: | Kriter | Single-Agent | Multi-Agent | |---|---|---| | Görev adım sayısı | 1-3 | 5+ | | Veri kaynağı sayısı | 1-2 | 3+ | | Çıktı tipi | Tek format | Çoklu sentez | | Latency tolerance | Düşük (< 5s) | Yüksek (>30s ok) | | Cost sensitivity | Yüksek | Orta-düşük | | Output deterministic | Şart | Esnek | | Domain hassasiyeti | Düşük-orta | Yüksek | | Reviewer şart mı | Hayır | Evet | | Audit zorunluluğu | Düşük | Yüksek | | Token bütçesi | Sıkı | Esnek | 7+ kriter "Multi-Agent" tarafında ise multi-agent'a geç. ## 10.12. Multi-Agent ile Workflow Engine Birleşimi Gerçek dünyada multi-agent tek başına yetmez — bir **iş süreci** içinde yer alır. Yaygın entegrasyonlar: ### Temporal / Airflow / Prefect Workflow orchestrator'ların içinde "multi-agent task" bir step'tir. Idempotency, retry, timeout workflow engine tarafından yönetilir, multi-agent içinde değil. ### n8n / Make / Zapier Düşük-kodlu workflow araçlarında multi-agent task'ı bir node olarak çağrılır. Karma: yapay zeka'nın value-add olduğu kısımlar multi-agent, kuru iş kuralları workflow. ### BPM (Camunda, BPMN) Klasik iş süreçleri BPM ile, AI-heavy kısımlar multi-agent. Türk bankalarında bu hibrit yaygın. ### Event-Driven (Kafka, EventBridge) Bir event geldiğinde multi-agent task tetiklenir. Async, scalable, decoupled. İyi bir multi-agent sistem **bir workflow engine'in client'i** olarak konumlanır, kendi başına bir workflow engine olmaya çalışmaz. Bu, separation of concerns'i korur. ## 11. Sonraki Adım Multi-agent mimari kuruma getirmek için pratik yol haritası: 1. **POC değerlendirme.** Mevcut tek-agent iş yükünüzü inceleriz; multi-agent'ın anlamlı olduğu 1-2 use-case seçeriz. 2-3 hafta. 2. **Pattern tasarımı.** Lead + worker rolleri, structured artifact şeması, evaluator stratejisi, cost cap, KVKK katmanı. 4-6 hafta. 3. **Production deploy + observability.** Langfuse trace, retry policy, deadlock detection, eval harness. 6-10 hafta. 4. **Eğitim.** Geliştirici ve domain ekibi için Claude Agent SDK + .claude/ workflow + MCP entegrasyon atölyesi. İletişim için site üzerindeki contact formu kullanılabilir. --- Bu rehber yaşayan bir belgedir; multi-agent ekosistem her çeyrek değiştiği için **çeyreklik olarak revize edilmektedir**.