Anthropic Multi-Agent Mimarisi: Orchestrator-Worker Pattern ile Tek Agent'a Karşı %90.2 Üstün Performans Nasıl Elde Edilir?

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.

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.

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.

Anthropic'in Claude Agent SDK (2025'te yayımlandı) multi-agent pattern'i için referans implementasyon sağlar. Klasör yapısı:

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)

---
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": "<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:

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

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ı.

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.

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.

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.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.

Ü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.

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.

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.

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.

Ü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.

• 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.

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.

Karar verirken kullanılabilecek pratik matriks:

7+ kriter "Multi-Agent" tarafında ise multi-agent'a geç.

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.

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.