Drift detection, stale context, multi-tool continuity — GH-600 Hazırlık

Domain 3’ün son dersi — uzun yürütme, multi-tool, multi-environment ortamlarda agent state’inin tutarlılığını koruma.

Drift detection — operasyonel sinyaller

Drift = agent uzun yürütmede önceki kararlarından / başarı kriterinden sessizce sapar. Tespit etmek zor; spesifik sinyaller var:

Drift sinyalleri (✓ olarak işaretle)

Aynı görev tekrar edildiğinde sonucun belirgin değişmesi
Önceki kararlarla çelişen çıktı
Başarı kriterini görmezden gelen output
Plan’da yokken yeni step icat etme
Daha önce kabul edilen constraint’i sessizce esnetme
Tool kullanım sıklığında ani değişim (örn. her zaman X tool kullanıyordu, şimdi Y)

Drift sinyali DEĞİL (trap!)

CPU kullanımı artışı (performance metric)
Yanıt süresi (latency)
Token kullanımı (cost metric)
Memory size (resource metric)

Bunlar performance/cost sinyalleri; drift bir tutarlılık sorunu.

Drift düzeltme zinciri

Drift tespit edildiğinde:

Drift tespit
  ↓
[1] Rollback — bilinen iyi state'e dön (PR revert, state dosyası restore)
  ↓
[2] Context refresh — agent'a güncel system of record yeniden yükle
  ↓
[3] Plan revalidation — mevcut plan hala geçerli mi, yeni risk var mı?
  ↓
[4] Resume veya escalation

Eski karar değişmesi gerekiyorsa (örn. dış koşul değişti), explicit override ile decision history’e yaz — sessiz değişme.

Stale context — en sık neden: cache invalidation eksikliği

Stale context = agent eski state üzerinden karar veriyor; güncel gerçeklikle uyumsuz.

En sık kaynak: cache + invalidation yokluğu

# Anti-pattern
class AgentCache:
    def __init__(self):
        self._cache = {}

    def get_repo_status(self, repo):
        if repo not in self._cache:
            self._cache[repo] = fetch_status(repo)  # cache miss
        return self._cache[repo]  # cache hit — eski state olabilir

Cache 3 saat eski state veriyor, agent bunu güncel sanıyor → drift.

Doğru pattern: TTL veya event-based invalidation

# TTL-based
class AgentCache:
    def __init__(self, ttl_seconds=60):
        self._cache = {}  # {key: (value, expires_at)}

    def get_repo_status(self, repo):
        cached = self._cache.get(repo)
        if cached and cached[1] > time.now():
            return cached[0]
        value = fetch_status(repo)
        self._cache[repo] = (value, time.now() + self.ttl_seconds)
        return value

# Event-based (daha doğru)
# Webhook ile cache invalidate:
# repo.pushed → cache.invalidate(repo)

Sınavda “stale context’in en sık nedeni” sorusunun cevabı cache + invalidation eksikliği.

Multi-tool continuity — state paylaşımı

Aynı agent farklı tool’lar kullanıyor, veya birden çok agent aynı state’i okuyor. Üç bullet:

Pattern: ortak system of record + read/write disiplini.

Tool A ──┐
         ├──> system of record (repo file / issue / PR description)
Tool B ──┤
         │
Tool C ──┘

Her tool okur ve yazar; system of record tek doğruluk.

2. Prevent conflicting context

İki tool aynı entity için farklı bilgi tutarsa → conflict. Önleme:

Tek doğruluk kaynağı
Tool’lar arası sync mekanizması (event veya periyodik)
Conflict detection + alert

3. Prevent stale context

Cache invalidation pattern’i (yukarıda) + agent başlangıcında context yeniden yükleme.

Conflicting context çözüm yolu

İki tool farklı bilgi tuttu, conflict tespit edildi:

1. Tespit (otomatik)
   └── system of record vs tool state diff
2. Kaynak seç
   └── system of record kazanır (her zaman)
3. Tool state'i resync
   └── tool'lar system of record'tan okur
4. Sebep loglama
   └── conflict neden olduğunu RCA için kaydet
5. Tekrarlama riski yüksekse HITL
   └── insan kararı: tool kaldır mı, sync mekanizması güçlendir mi

Sınavda “self-healing kendiliğinden olur” cevabı anti-pattern — bağımsız state çelişki kaynağıdır.

Pattern: time-windowed memory

Agent’ın memory’sine “geçerlilik süresi” eklemek:

# Long-term memory entry
- key: "team_pref_typescript_strict_mode"
  value: true
  set_at: "2026-01-15"
  ttl_days: 365            # 1 yıl sonra re-validate
  source: "TEAM_DECISION.md"

TTL bittiğinde:

Memory entry “stale” işaretlenir
Agent re-validate eder (kaynak hâlâ geçerli mi?)
Re-validate fail ise expire

Bu pattern uzun-vadede drift’i otomatik temizler.

Mini quiz — Drift & continuity (3 soru)

Sırada ne var?

Domain 4 — Eval & tuning modülüne geçiyoruz. RCA üçlüsü, otomatik tarama, hedefli tuning kararları.