Multi-agent recovery ve lifecycle yönetimi

Domain 5.3 + 5.4 — multi-agent workflow’da hata yönetimi ve agent yaşam döngüsü. Sınavın “workflow’u bozmadan değiştirme” senaryoları.

Agent durumları — ayırt etmek

Durum	Tanım	Aksiyon
Healthy	Beklenen sürede, beklenen output	Devam
Stalled	Aktif değil ama fail de demedi — heartbeat yok	Timeout + alert + restart denemesi
Degraded	Çalışıyor ama hedefin altında (slow, partial output)	İzle, threshold aşılırsa müdahale
Partial	Bazı adımlar tamam, bazıları yok	Rollback + retry kararı
Failed	Bitti ve başarısız	RCA + tuning + retry

Stalled detection (operasyonel)

# Pattern: heartbeat + timeout
agent_run:
  start_time: "10:00"
  heartbeat_interval: 60s
  last_heartbeat: "10:15"  # 15 dk önce — STALLED
  timeout: 30 min

GitHub Actions’da job timeout (default 6 saat) — özelleştirilebilir:

jobs:
  agent:
    timeout-minutes: 30
    runs-on: ubuntu-latest

Multi-agent rollback — “coordinated checkpoint” zorluğu

Single-agent’ta rollback basit (PR revert). Multi-agent’ta:

• Agent A commit’lerini yaptı (T1)
• Agent B onları gördü, kendi commit’lerini yaptı (T2)
• Agent C T2 sonrası fail oldu

C’yi rollback etmek B’yi ve A’yı da etkiler — coordinated rollback gerekir.

Pattern: coordinated checkpoint

Workflow boyunca düzenli “checkpoint” oluştur:

T0: Checkpoint 0 (baseline)
T1: Agent A done       → Checkpoint 1 (snapshot: A's commits)
T2: Agent B done       → Checkpoint 2 (snapshot: A + B)
T3: Agent C fail

Rollback hedefi: Checkpoint 1 (A var, B+C yok) veya Checkpoint 0 (hepsi yok).

GitHub’da checkpoint = tagged commit veya repo state snapshot (Actions artifact).

Pattern: independent rollback (mümkünse)

Eğer agent’lar bağımsız alanlarda çalışıyorsa (örn. her biri ayrı servis), tek agent’ı rollback edebilirsin. Pattern seçimi sırasında bağımsızlık önceden tasarlanır.

Recovery zinciri (multi-agent)

Failure (partial/stalled/degraded)
  ↓
[1] Stop active agents — yeni iş başlamasın
  ↓
[2] Snapshot current state — RCA için
  ↓
[3] Rollback — coordinated veya independent
  ↓
[4] HITL gerekirse — yargısal karar
  ↓
[5] Re-plan — workflow yeniden başlat veya kısmi devam
  ↓
[6] Resume + traceability — kararları belge

Domain 5.3 bullet: “Implement multi-agent recovery patterns, including rollback and human-in-the-loop”. HITL multi-agent’ta single-agent’tan daha sık devreye girer (karmaşıklık fazla).

Lifecycle yönetimi — add / update / retire

Add (yeni agent ekleme)

Sınavın istediği pattern: shadow / canary cutover.

[1] Shadow mode — yeni agent paralel çalışsın, output sadece logla (apply etme)
  ↓
[2] Output karşılaştırma — eski agent vs yeni — eşleşiyor mu?
  ↓
[3] Canary — küçük yüzde trafikte yeni agent (örn. %10 issue'lar)
  ↓
[4] Genişletme — %50 → %100
  ↓
[5] Eski agent emekliye ayır (retire)

Bu pattern aktif workflow’u bozmaz. Sessizce v1’i v2 ile değiştirmek = anti-pattern.

Update (mevcut agent değişikliği)

Aynı pattern: yeni version’u paralel çalıştır, doğrula, cutover.

Konfigürasyon değişikliği için minimum:

1. Değişikliği branch’te uygula
2. Test repo’sunda doğrula
3. Production cutover (env protection ile gate’lenmiş)
4. Rollback planı hazır (revert config commit)

Retire (emekliye ayırma)

Domain 5.4 bullet: “Retire agents while preserving auditability and workflow continuity”.

İki kriter birlikte:

• Auditability — geçmiş kayıtlar (PR/issue/Actions logs) silinmez
• Continuity — workflow durmaz; dependency’ler yenisine geçirilir

Retire prosedürü

[1] Dependency analizi — bu agent'ın yokluğunda ne çalışmaz?
  ↓
[2] Replacement / removal kararı — yerine yenisi mi, görev iptal mi?
  ↓
[3] Cutover — yukarıdaki Add pattern'i tersine
  ↓
[4] Agent config archive — repo'da `archive/agents/<name>-retired-YYYYMMDD/` altında
  ↓
[5] Trigger'ları disable — workflow stop çalıştırılmasın
  ↓
[6] Geçmiş artifact'lar aynen kalır — audit erişimi açık

Anti-pattern: hard delete

❌ Agent’ın tüm geçmiş PR/issue/commit’lerini silmek = audit kaybı, compliance ihlali (özellikle yasal kayıt gereği).

✅ Doğru: config archive, trigger disable; geçmiş kalır.

Yargısal: ne zaman retire?

Sinyal	Karar
Agent 6 ayda 1 kez fail oluyor	Tut + tuning
Agent her gün fail oluyor	RCA → tuning veya retire
Agent’ın görevi artık iş gereği yok	Retire
Yeni agent eski’nin işini daha iyi yapıyor	Replace (cutover)
Agent’a güven kalmadı (RCA çözmüyor)	Retire + RCA dokümantasyonu

Mini quiz — Recovery & lifecycle (3 soru)

Multi-agent workflow'da bir agent fail oldu, partial output bıraktı. Sınavın önerdiği iki recovery pattern hangisidir?

1. Retry sonsuz / sessiz kapat
2. Rollback + human-in-the-loop
3. Yeni agent oluştur + eskisini sil
4. Hiçbir şey yapma — pipeline kendiliğinden toparlanır

Kontrol et

Aktif workflow'a yeni agent eklerken sınavın önerdiği yaklaşım hangisidir?

1. Önce shadow mode'da paralel çalıştır, output karşılaştır; güven kazanınca production trafiğine al
2. Direkt prod'a koy
3. Mevcut agent'ları durdur, yenisini ekle, yeniden başlat
4. Sadece test'te dene, asla prod'a alma

Kontrol et

Bir agent emekliye ayrılırken hangisi YANLIŞTIR?

1. Agent'ın dependency'lerini önce yenisine aktar
2. Geçmiş PR/issue/Actions kayıtlarını sil
3. Auditability korunsun diye config archive et
4. Workflow'u durdurmadan kontrollü cutover yap

Kontrol et

Sırada ne var?

Domain 6 — Guardrails & accountability modülüne geçiyoruz. Otonomi matrix derin + HITL karar kriterleri.