Orchestration pattern'leri ve isolation derin

Domain 5.1 — multi-agent workflow yönetiminin temel mimarisi. Pattern seçimi + isolation + çakışma çözümü.

Orchestration pattern’leri

1. Sequential (chain)

Agent A → Agent B → Agent C → done

Her agent öncekinin çıktısını input olarak alır. Ne zaman:

• Adımlar birbirine bağımlı (B, A’nın output’una ihtiyaç duyar)
• Sıra önemli
• Hata noktasında zinciri durdurmak istiyorsun

Örnek: code-gen agent → review agent → test agent → deploy agent.

2. Parallel (fan-out / fan-in)

         ┌→ Agent A ┐
Input → ┤  Agent B  ├→ aggregate → output
         └→ Agent C ┘

Bağımsız agent’lar aynı anda çalışır, sonuçlar birleştirilir. Ne zaman:

• Adımlar bağımsız
• Hız öncelikli
• Her agent farklı perspektif (örn. security review + style review + perf review)

3. Hierarchical (supervisor / worker)

       Supervisor agent
       /     |     \
   Worker  Worker  Worker
     A       B       C

Supervisor görev dağıtır, worker’lar yürütür, sonuçlar supervisor’a döner. Ne zaman:

• Karmaşık görev, dinamik alt-task ayırma
• Worker’ların bağımsız çalışması
• Tek karar noktası (supervisor)

4. Handoff chain (state passing)

Agent A ──[state]──> Agent B ──[state]──> Agent C

State explicit olarak handoff edilir. Ne zaman:

• Uzun süreli görev, farklı uzmanlık alanları
• Her aşama belirgin checkpoint
• Auditability kritik

Pattern seçim kriteri

Sor	Bağımlılık var mı?	Kaç worker?	Karar noktası
Sequential	Evet, lineer	1 worker / aşama	Her aşama sonu
Parallel	Hayır	Çoklu	Sonunda aggregate
Hierarchical	Dinamik	Çoklu, dinamik	Tek (supervisor)
Handoff	Aşama-aşama	1 worker / aşama	Her handoff’ta

GitHub’da isolation 3 seviyesi (Domain 5.1 ezbere)

Seviye	Ne ayrılır	Tipik kullanım	Cost
Branch	Aynı repo, farklı branch	Paralel feature work	Düşük
Actions job	Aynı workflow, farklı job (farklı runner)	Concurrent CI tasks	Orta (runner saati)
Repo	Tamamen farklı repo	Bağımsız ürün/güvenlik domain	Yüksek (admin overhead)

Branch isolation (en yaygın)

main
  ├── agent-a/feature-x   (Agent A burada çalışır)
  ├── agent-b/feature-y   (Agent B burada çalışır)
  └── agent-c/fix-bug     (Agent C burada çalışır)

Her agent kendi branch’inde özgürce çalışır. Merge sırası ile çakışma yönetilir.

Job isolation

jobs:
  security-review:
    runs-on: ubuntu-latest
    permissions:
      security-events: write
    steps: [...]

  style-review:
    runs-on: ubuntu-latest
    permissions:
      pull-requests: write
    steps: [...]

  perf-review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps: [...]

Üç job paralel çalışır, farklı runner ve farklı permissions’da.

Repo isolation

org/product-a-agent → org/product-a-repo
org/product-b-agent → org/product-b-repo
org/internal-agent  → org/internal-repo

En güçlü ayrım. Bağımsız güvenlik domain’leri (örn. public vs internal).

Çakışma tipleri (Domain 5.1 bullet)

Bullet: “Detect and resolve agent conflicts, including overlapping code changes, duplicated effort, and contradictory outputs”.

Overlapping code changes

İki agent aynı dosya / aynı satır range’inde değişiklik yapıyor.

Tespit: GitHub PR’da otomatik conflict detection (merge yapamıyorsa). Çözüm:

1. Merge sırasını belirle (önce hangi PR)
2. İkinci agent rebase yapar (eski’nin değişikliklerini al)
3. Conflict resolution (otomatik veya HITL)

Duplicated effort

İki agent aynı işi yapıyor (örn. aynı bug için iki PR).

Tespit: Aynı issue için 2+ açık PR (issue.assignee + PR.related_issue). Önleme:

• Issue assignee lock (bir agent issue’yu assignee’sine alır)
• Supervisor agent (görev dağıtımı)
• System of record (kim hangi işi yapıyor)

Çözüm:

• Geç gelenin çalışmasını iptal et (sessizce değil, agent’a “bu görev başkasında” bildir)
• Eğer ikisi de değerli output ürettiyse: birleştir (HITL)

Contradictory outputs

İki agent zıt karar verdi (örn. agent A “library X kullan”, agent B “library Y kullan”).

Tespit: Decision history diff (system of record’ta). Çözüm:

1. System of record üstünden tek karar (örn. ADR dosyası)
2. Karar yetkisi belirle (supervisor agent veya HITL)
3. Diğer agent’ı karara uyacak şekilde re-instruct et

Anti-pattern’ler (sınav favorisi)

Anti-pattern	Doğru pattern
Çakışmayı sessizce iptal	Tespit + audit + çözüm (HITL gerekirse)
Otomatik birleştirme (ML ile conflict çözmek)	Manuel veya HITL — risk var
Agent’lardan birini silmek	Pattern değişikliği yapmadan silme = sebep gizleme
İki kararı birden uygulamak	State inconsistency, drift kaynağı
Her agent kendi state’i	System of record’a yönelt

Mini quiz — Orchestration & isolation (3 soru)

GitHub'da paralel agent'ları izole etmek için kullanılan 3 seviye hangisidir?

1. Process / thread / fiber
2. Branch / Actions job / repo
3. Container / VM / serverless
4. Tenant / org / enterprise

Kontrol et

İki agent aynı dosyayı eş zamanlı değiştirdi (overlapping changes). Sınavın istediği yaklaşım?

1. İlk merge olanı tut, ikincisini sessizce iptal et
2. Çakışmayı tespit et, merge sırası belirle, gerekirse HITL ile çöz; output'lar audit'e kalır
3. İki PR'ı otomatik birleştir, ML ile çöz
4. Agent'lardan birini sil

Kontrol et

Sequential ve parallel orchestration arasındaki seçim kriteri nedir?

1. Agent'ların birbirine output bağımlılığı var mı? Varsa sequential; bağımsızsa parallel
2. Hep parallel
3. Hep sequential
4. Random

Kontrol et

Sırada ne var?

Domain 5’in son dersi — multi-agent recovery pattern’leri ve agent lifecycle yönetimi (add / update / retire).