Managed Agents’i Ölçeklendirmek: Beyin ile Elleri Ayırmak

• Uzun süre çalışan ajanlar için bir barındırma hizmeti olan Managed Agents, harness model geliştikçe değişse bile kararlı kalan arayüz tabanlı bir mimariyi benimsiyor
• Harness, Claude’un tek başına yapamadığı işler hakkındaki varsayımları kodluyor; ancak model geliştikçe bu varsayımlar eskimiş (stale) hale geliyor ve gereksiz ek yük oluşturuyor
• İşletim sisteminin donanımı süreçler ve dosyalar gibi soyutlamalarla sanallaştırması gibi, Managed Agents da ajan bileşenlerini (session, harness, sandbox) sanallaştırarak bağımsız biçimde değiştirilebilir hale getiriyor
• Beyni (harness) ve elleri (sandbox) ayırarak p50 TTFT’te yaklaşık %60 düşüş, p95’te ise %90’dan fazla düşüş sağlayan performans iyileştirmesi elde edildi
• Bu tasarım, gelecekte hangi harness veya sandbox ortaya çıkarsa çıksın bunları barındırabilecek bir meta-harness işlevi görüyor

---

Harness varsayımları model geliştikçe eskir

• Harness, Claude’un kendi başına yapamadığı işler hakkındaki varsayımları kodlayan bir yapı; ancak model geliştikçe bu varsayımlar gereksiz hale geliyor
• Claude Sonnet 4.5’te bağlam sınırına yaklaşınca işi erken sonlandıran bir "context anxiety" davranışı görüldüğü için harness’e bağlam sıfırlama eklendi
• Claude Opus 4.5’te bu davranış ortadan kalktı ve sıfırlama mantığı gereksiz koda dönüştü
• Harness’in sürekli değişeceği öngörüldüğünden, belirli bir uygulamaya bağlı olmayan genel amaçlı arayüzler üzerine kurulu bir Managed Agents hizmeti oluşturuldu

İşletim sisteminden ilham alan tasarım felsefesi

• İşletim sistemi, donanımı süreçler, dosyalar gibi soyutlamalarla sanallaştırarak henüz var olmayan programları bile çalıştırabilecek şekilde tasarlanır
• read() komutunun 1970’lerdeki disk paketinde de en yeni SSD’de de aynı çalışması gibi, soyutlamalar donanımdan daha uzun ömürlüdür
• Managed Agents da aynı deseni izleyerek ajan bileşenlerini sanallaştırıyor
  • Session: meydana gelen tüm olayların append-only günlüğü
  • Harness: Claude’u çağıran ve araç çağrılarını yönlendiren döngü
  • Sandbox: Claude’un kod çalıştırdığı ve dosya düzenlediği çalışma ortamı

İlk tasarım: tek konteynerin sınırları ("pet" sorunu)

• İlk aşamada session, harness ve sandbox tek bir konteyner içine yerleştirildi
• Dosya düzenlemenin doğrudan syscall ile yapılabilmesi ve servis sınırı tasarımına gerek olmaması gibi avantajları vardı
• Ancak konteynerin bir **"pet"**e (yerine yenisi konamayan tekil örnek) dönüşmesi sorunu ortaya çıktı
  • Konteyner arızalanınca session kaybı yaşanıyordu
  • Yanıt vermediğinde konteynerin elle kurtarılması gerekiyordu
• Hata ayıklama açısından yalnızca WebSocket olay akışıyla arızanın nerede meydana geldiğini belirlemek mümkün değildi; ayrıca konteynere kabuk erişimi kullanıcı verisi içerdiği için hata ayıklamanın kendisi de zordu
• Harness, tüm çalışma hedeflerinin konteyner içinde bulunduğunu varsaydığından, müşterilerin VPC bağlantısı taleplerinde ağ eşleştirmesi ya da harness’in kendi ortamlarında çalıştırılması gerekiyordu

Beyin ile ellerin ayrılması (çekirdek mimari)

• "Beyin" (Claude ve harness), "eller" (sandbox ve araçlar) ve "session" (olay günlüğü) ayrı ayrı bağımsız arayüzlere bölündü
• Her bileşen bağımsız olarak arızalanabilir veya değiştirilebilir

Harness’in konteynerden çıkışı

• Harness konteyner dışına taşındı; artık konteyneri diğer araçlar gibi execute(name, input) → string ile çağırıyor
• Konteyner bir **"cattle"**a (değiştirilebilir örnek) dönüştü
• Konteyner arızalandığında harness bunu araç çağrısı hatası olarak ele alıyor; Claude yeniden denemeye karar verirse provision({resources}) ile yeni bir konteyner başlatılıyor

Harness arızasından kurtarma

• Session günlüğü harness’in dışında bulunduğu için, harness içinde hayatta kalması gereken bir durum yok
• Arıza anında wake(sessionId) → getSession(id) ile olay günlüğü alınıp son olaydan devam ediliyor
• Harness, ajan döngüsü sırasında emitEvent(id, event) ile kalıcı olay kaydı tutuyor

Güvenlik sınırı

• Birleşik tasarımda Claude’un ürettiği güvenilmeyen kod, kimlik bilgileriyle aynı konteynerde çalışıyordu; bu da prompt injection ile ortam değişkenlerinin sızdırılmasına yol açabiliyordu
• Saldırgan bir token elde ederse sınırsız yeni session oluşturup iş devredebilirdi
• Yapısal çözüm: sandbox’ın token’lara asla erişemeyeceği şekilde ayrılması
• Git: depo erişim token’ı ile sandbox başlatılırken clone işlemi yapılıyor ve yerel git remote bağlanıyor; ajan token’ı doğrudan kullanmadan push/pull yapabiliyor
• MCP özel araçları: OAuth token’ları güvenli bir vault içinde saklanıyor; özel bir proxy üzerinden MCP aracı çağrıldığında, vault’tan session ile ilişkili kimlik bilgileri çekilip dış servise istek yapılıyor

Session, Claude’un bağlam penceresi değildir

• Uzun süreli işler çoğu zaman Claude’un bağlam penceresi uzunluğunu aşar; bu yüzden neyin korunacağına dair geri döndürülemez kararlar gerekir
• Compaction: Claude, bağlam penceresinin bir özetini kaydeder
• Memory tool: Claude bağlamı dosyalara yazarak session’lar arasında öğrenebilir
• Bağlam kırpma: eski araç çıktıları veya düşünce blokları gibi seçili token’ların kaldırılması
• Bağlamın geri döndürülemez biçimde atılması, gelecekteki turda hangi token’ların gerekeceğini öngörmenin zor olması nedeniyle başarısızlığa yol açabilir
• Önceki araştırmalar, bağlamı bağlam penceresinin dışında bulunan bir nesne olarak saklayıp LLM’in kod yazarak buna programatik erişim sağlamasını inceledi

Managed Agents’te session günlüğünün kullanımı

• Session, bağlam penceresinin dışında yer alan bir bağlam nesnesi işlevi görüyor
• Sandbox veya REPL’de değil, session günlüğünde kalıcı olarak saklanıyor
• getEvents() arayüzüyle olay akışının konum tabanlı dilimleri seçilebiliyor
  • Son okuma noktasından itibaren okumaya devam etme
  • Belirli bir andan önceki birkaç olayı geri sarıp inceleme
  • Belirli bir eylem öncesindeki bağlamı yeniden okuma
• Getirilen olaylar harness içinde dönüştürülerek Claude’un bağlam penceresine aktarılabiliyor
• Bu dönüşüm, yüksek prompt cache isabet oranı için bağlam temizliği ve bağlam mühendisliğini içerebiliyor
• Session yalnızca kalıcı depolama ve sorgulama garantisi verir; somut bağlam yönetimi ise gelecekteki model gereksinim değişimlerine uyum sağlamak için harness’e bırakılır

Çok sayıda beyin, çok sayıda el

Çok sayıda beyin (Many Brains)

• Beyin ile ellerin ayrılması, ilk müşteri şikâyetlerini çözdü: VPC içindeki kaynaklarla çalışırken artık ağ eşleştirmesi gerekmiyor
• İlk tasarımda her beyin için bir konteyner gerekiyordu; dolayısıyla konteyner hazırlanana kadar çıkarım başlatılamıyordu
• Sandbox gerektirmeyen session’lar bile depo klonlama, süreç başlatma ve bekleyen olayları çekme gibi tam konteyner kurulum maliyetini taşıyordu
• Ayrımdan sonra konteyner yalnızca gerektiğinde araç çağrısıyla hazırlanıyor ve gereksiz bekleme süresi ortadan kalkıyor
• Çıkarım, orkestrasyon katmanı session günlüğünden bekleyen olayları çeker çekmez başlayabiliyor
• p50 TTFT yaklaşık %60 azaldı, p95 TTFT ise %90’dan fazla azaldı
• Çok sayıda beyne ölçeklenmek, yalnızca durumsuz (stateless) harness örneklerini çoklu biçimde başlatıp gerektiğinde ellere bağlamak anlamına geliyor

Çok sayıda el (Many Hands)

• Her beyni birden fazla çalışma ortamına bağlama yeteneği gerekiyor
• Claude’un birden fazla çalışma ortamı üzerinde akıl yürütüp işi nasıl dağıtacağına karar vermesi gerektiğinden, bu tek bir shell’den bilişsel olarak daha zor bir görev
• Başlangıçta model yetenekleri yetersiz olduğu için beyin tek konteynere yerleştirildi; ancak zeka arttıkça tek konteyner tersine bir kısıta dönüştü
• Ayrık tasarımda her el, execute(name, input) → string aracı olarak ele alınıyor
  • Özel araçlar, MCP sunucuları ve şirket içi araçların tümü destekleniyor
  • Harness’in sandbox’ın konteyner, telefon ya da Pokémon emülatörü olup olmadığını bilmesi gerekmiyor
• Beyin ile eller birbirine bağlı olmadığından, eller beyinler arasında da aktarılabiliyor

Sonuç: meta-harness olarak Managed Agents

• İşletim sisteminin donanımı sanallaştırarak henüz var olmayan programları desteklemesine benzer bir yaklaşım
• Managed Agents, belirli bir harness’e bağlı olmayan bir meta-harness olarak çeşitli harness’leri barındıran genel amaçlı arayüzler sunuyor
• Claude Code da bir harness olarak kullanılabiliyor; ayrıca göreve özel ajan harness’leri de destekleniyor
• Arayüzler konusunda net bir duruş var: Claude’un durumu yönetme (session) ve hesaplama yapma (sandbox) yeteneklerine ihtiyaç duyduğu kabul ediliyor
• Arayüzler, çok sayıda beyin ve ele ölçeklenme ile uzun vadede kararlı ve güvenli işletim için tasarlanıyor
• Beyinlerin ve ellerin sayısı ya da konumu hakkında hiçbir varsayım yapılmıyor