Yapay zekâ ajanlarıyla ilgili son iki yılda en çok duyduğum cümle şu oldu: “İyi çalışıyor (eh, fena değil). Prodüksiyonda saç baş yolduruyor.” Açık konuşayım, bu lafı ben de birkaç kez ettim. Çünkü mesele sadece modelin akıllı olması değil; o zekânın etrafına kurduğun sistemin de ayakta kalması gerekiyor. Anthropic’in yeni ajan mimarisi tam burada devreye giriyor ve bence asıl ilginç tarafı, işi bir tık daha olgunlaştırması.
Geçen ay İstanbul’da bir ürün ekibiyle yaptığım sohbeti hatırlıyorum; dört kişilik küçük ekip, tek container içinde hem oturum yönetimi hem araç çağrıları hem de kod çalıştırma işini halletmeye çalışıyordu. Demo günü şahane, yük binince felaket. İşte Anthropic’in anlattığı yaklaşım, tam da bu “demo güzel, prodüksiyon zor” gerçeğine parmak basıyor.
Monolitik Ajanlar Neden Tıkandı?
İlk refleks hep aynı oluyor. Her şeyi tek yerde topla. Oturum durumu, orkestrasyon döngüsü, araç çağrıları, kod yürütme… hepsi tek kapsülde dursun ki yönetmesi kolay olsun. Kulağa mantıklı geliyor, hatta prototip aşamasında baya iş görüyor; ama o noktada kafayı yeme meselesi başlıyor zaten.
Prodüksiyona çıkınca tablo değişiyor. Dramatik biçimde. Bir container çöküyor, oturum bilgisi gidiyor —. Sen orada kalakalmışsın, neyin nerede kırıldığını anlamak için sanki karanlıkta kablo arıyorsun. Üstüne bir de her ajan için ayrı container ayırınca kaynak kullanımı şişiyor; gece yarısı boş duran makineler bile masraf yazıyor, bu da cabası.
Durun, bir saniye.
Benzer bir sıkıntıyı 2023’te Ankara’da geliştirdiğimiz bir SaaS pilotunda yaşamıştık. Tek süreçte çalışan iş akışı motoru vardı. İlk hafta “idare eder” gibiydi. Sonra müşteri sayısı artınca — itiraz edebilirsiniz tabi — olay dağıldı; bir restart sonrası yarım kalan görevler ortada kaldı, kimse sahip çıkmadı. O gün anladım ki ajan sistemlerinde mesele sadece hız değil — dayanıklılık da en az onun kadar önemli, belki daha fazla bile.
Üç Parça Model: Hafıza, Orkestrasyon ve Çalıştırma
Anthropic’in önerdiği yapı aslında sade: sistemi üç bağımsız parçaya bölüyorlar. Biri hafıza gibi davranıyor, biri yöneten beyin rolünde, diğeri de işi yapan eller gibi çalışıyor. Kağıt üstünde basit duruyor ama pratikte etkisi ciddi.
1) Session: Kalıcı Hafıza
Session katmanı append-only event log mantığıyla çalışıyor (kendi tecrübem). Yani olan biten her şey kayda giriyor. Kolay kolay silinmiyor. Bunu bir ajanın günlük defteri gibi düşünebilirsin — ne olduysa orada, kaybolmuyor, uçmuyor (yanlış duymadınız)
Burada can alıcı nokta şu: Session’ın Claude’un context penceresinin dışında yaşaması. Bu çok önemli çünkü modelin belleği sınırlı olabilir, ama sistemin gerçeği o sınırın içine sıkışmak zorunda değil; ikisi ayrı şeyler, karıştırmamak lazım.
Ayrıca Session sadece kayıt tutmuyor. Rewind, slice ve pozisyon bazlı erişim gibi yeteneklerle geçmişe dönüp bakmayı da sağlıyor — yani agent “dün ne yapmıştık?” diye afallamıyor, sistemi çekip oradan devam edebiliyor. Küçük ama önemli fark bu.
2) Harness: Sessiz Orkestratör
Harness kısmını ben daha çok görünmez şef gibi görüyorum. Claude API’yi çağırıyor, tool call’ları yönlendiriyor, çıkan sonuçları tekrar Session’a yazıyor… ama kendisi stateless kalıyor. Peki neden bu önemli?
Stateless olmak burada süslü bir tercih değil (buna dikkat edin). Hayati karar. Çünkü Harness çökse bile başka bir instance kalkıp aynı Session üzerinden devam edebiliyor — bu da yatay ölçeklemeyi çocuk oyuncağına çeviriyor, abartmıyorum.
İşin garibi, Bunu geçen hafta Kadıköy’deki ofiste test ederken fark ettim; state’i dışarı alan servislerde debug süresi bariz kısalıyor. Sorun yaşayan bileşeni değiştirmek kolaylaşıyor. Dur bir saniye — aslında asıl mesele şu: bütün sistemi yeniden başlatmadan toparlayabilmek bazen altın değerinde oluyor. Gerçekten. Bunu yaşayana kadar tam anlamıyorsun. Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımızda bu konuya da değinmiştik.
3) Sandbox: Harcanabilir Çalışma Alanı
Küçük bir detay: Sandbox tarafında ise mantık net: “cattle, not pets.” Yani bu konteynerler sevdiğin evcil hayvanlar gibi korunmuyor; gerektiğinde açılıyor, işini yapıyor, kapanıyor. Hepsi bu.
Lazily initialized olmaları da cabası. Kullanıcı gerçekten kod çalıştırmak istediğinde sandbox ayağa kalkıyor; boşta bekleyip fatura şişirmiyor. Küçük startup için bu fark bazen kira parası kadar hissedilir hale geliyor — şaka değil, baya somut bir rakam. Bu konuyla ilgili 2025’te Eskiyen Mimari Kararları: 4 Sessiz Tuzak yazımıza da göz atmanızı tavsiye ederim. Daha fazla bilgi için John Deere uzlaşması: Tamir hakkı için büyük kırılma yazımıza bakabilirsiniz.
| Bileşen | Görev | Kritik Özellik |
|---|---|---|
| Session | Kayıt ve hafıza | Durağan olmayan event log |
| Harness | Orkestrasyon | Stateless çalışma modeli |
| Sandbox / Tools | Kod yürütme | Tepeden tırnağa disposable yapı |
Beyin ve Eller Ayrımı Neyi Değiştiriyor?
Vallahi, Mimarinin en hoş tarafı şu basit denklemde saklı:
Brain = Claude + Harness
Hands = Sandbox + Tools
Memory = Session / Event Log
execute(name, input) → string
Şöyle ki, Evet, gerçekten bu kadar sade görünüyor. Ama sadelik aldatmasın — iyi sistem tasarımının sırrı çoğu zaman tam da bu zaten. Bu arayüz sayesinde Harness, sandığın kadar zeki olmak zorunda değil; hangi aracın container mı yoksa başka türden bir ortam mı olduğunu bilmesine gerek yok. Yeter ki aynı sözleşmeyi konuşsunlar. Daha fazla bilgi için Flux-2-Pro Neden Dikkat Çekiyor? Görsel Üretimde Dengeli Güç yazımıza bakabilirsiniz.
Bak şimdi, İşte mühendislikte rahatlatıcı olan şey tam olarak bu. Asıl karmaşa içeride gizlenirken dışarıya temiz bir kapı bırakıyorsun. Bir nevi mutfak darmadağın ama servis tezgâhı tertemiz — müşteri görmüyor, sen hallediyorsun (ki bu çoğu kişinin gözünden kaçıyor)
Küçük projelerde bu ayrım ilk bakışta lüks gibi gelebilir. Anlarım o hissi. Ama orta ölçekten yukarı çıktığında işler değişiyor; kurumsal tarafta ekipler farklı parçaları farklı hızlarda büyütmek istiyor, hafızayı başka yerde sakla, orkestrasyonu autoscale et, sandbox’ları ihtiyaç oldukça ayağa kaldır… Hepsini tek kutuya sıkıştırırsan sonra uğraşırsın. Çok uğraşırsın hatta.
Peki Performans Tarafında Ne Kazandırıyor?
Anlatılan metrikler baya dikkat çekici: p50 TTFT’de yaklaşık %60 iyileşme varmış, p95 tarafında ise %90’ın üstünde düşüş görülmüş deniyor. Buradaki gerçek hikâye p95 zaten — çünkü kullanıcı deneyimini asıl bozan şey ortalama değil, kuyruk gecikmesi oluyor. Bunu bir kez yaşarsan bir daha unutmuyorsun.
Çok konuştum, örnekle göstereyim. PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımızda bu konuya da değinmiştik.
Editör masasında bunu okuduğumda ilk düşündüğüm şey şu oldu: demek ki problem yalnızca hızlı cevap vermek değilmiş. Bir sistem hızlı olabilir ama ara sıra patlayan gecikmeler yüzünden güven vermez hale gelir. Ben bunu 2024 başında İzmir’de test ettiğim bir RAG uygulamasında birebir gördüm; ortalama süre fena değildi. Uç vakalar kullanıcıyı bezdiriyordu. Tam da o his.
En can alıcı kazanım ortalamada değil… kuyruğun ucunda geliyor. p95 düştüyse kullanıcı “bu ürün bazen deli ediyor” demekten vazgeçmeye başlıyor.
Güvenlik Tarafı Neden Daha Rahat?
Vallahi, Ajan mimarilerinde güvenlik genelde sonradan eklenen kemer gibi düşünülür. Hep öyle olur. Ama burada yapı doğrudan güvenliği destekliyor görünür halde kurulmuş durumda; credentials’ın sandbox’a hiç ulaşmaması temel prensiplerden biri olarak öne çıkıyor.
Bana kalırsa bu yaklaşım özellikle enterprise senaryolarda kıymetli olacak. Git token’larının local remote’a init — en azından ben öyle düşünüyorum — sırasında bağlanması, MCP araçlarının session-scoped token ile proxy üzerinden erişilmesi, OAuth token’ların kontrol altında tutulması… Bunlar kağıt üstünde teknik detay gibi dursa da pratikte büyük fark yaratıyor. Çünkü saldırgan ya da hatalı agent davranışı olsa bile hasarın yayıldığı alan daralıyor — küçük ama kritik nokta bu.
- Kredi kartına benzeyen sırların sandbox içinde dolaşmasını engeller.
- Aynı altyapıda farklı ajanların birbirinin verisine burnunu sokmasını azaltır.
- Saldırı yüzeyini küçültür; denetim daha rahat olur.
- Maliyet artmadan izolasyon seviyesini yükseltir — bu nadir bulunan tatlı noktalardan biri, gerçekten. (bence en önemlisi)
Küçük Startup ile Kurumsal Yapıda Fark Nerede?
Burada, küçük startup için en büyük avantaj maliyet kontrolü olur diye düşünüyorum. Boşta çalışan sandbox istemezsin; stateless harness ile yeniden başlama derdin azalır; Session dışarıda olduğu için veri kaybından korkmazsın. Kısacası az kişiyle çok iş çıkarma şansı verir. Fena değil yani, fena değil.
Peki neden?
E tabi kurumsal tarafta resim biraz farklı. Orada mesele sadece maliyet değil — uyumluluk, denetlenebilirlik, çoklu ekip koordinasyonu. Rollback senaryoları öne çıkıyor (kendi tecrübem). Aynı ajanın farklı departmanlara hizmet verdiğini düşün: birinde hukuk dokümanı okuyor, ötekinde destek talebi çözüyor, bir diğerinde otomasyon tetikliyor. Bu ne anlama geliyor? Böyle yerlerde ayrıştırılmış mimari resmen nefes aldırır.
Nerede İyi Çalışır, Nerede Beklediğim Kadar Değil?
Açık konuşayım, bu yaklaşım kod üretimi yapan ajanlarda, araştırma odaklı yardımcı botlarda, çok adımlı otomasyonlarda baya iyi duruyor. Bilhassa uzun oturumlar, ara sıra çöküp geri gelmesi gereken işler ve tool kullanımının yoğun olduğu senaryolarda güçlü. Ama tek seferlik kısa görevlerde? Biraz ağır kaçabilir, dürüst olmak gerekirse.
Beni en çok düşündüren eksik taraf ise operasyonel karmaşıklık (buna dikkat edin). Üç parçalı yapı teoride harika; pratikte observability, log korelasyonu, token akışı. Hata sınırı tanımları düzgün yapılmazsa sistem eline yüzüne bulaşabilir. Kağıt üstünde süper, pratikte göreceğiz artık.
Tam burada kendi deneyimimi ekleyeyim: Mart 2026’da Levent’te yapılan kapalı bir demo etkinliğinde benzer ayrıştırılmış tasarımı izledim. İlk izlenim şahane idi; ama sorular başlayınca ekip tracing katmanını açıklamakta biraz zorlandı. Yani fikir güçlüydü fakat anlatımı hâlâ hamdı (kendi tecrübem). Biraz daha pişmesi lazım.
Mühendisler İçin Pratik Okuma Notları
Tuhaf ama, Eğer böyle bir mimari kuracaksan birkaç noktayı baştan planla: session formatını versiyonla, Harness’i tamamen stateless tut, sandbox yaşam döngüsünü kısa tut,. Araç arayüzünü mümkün olduğunca dar tasarla. Ne kadar az sözleşme, o kadar az sürpriz — bunu kısa yoldan öğrenmek isteyenlere tavsiye değil, uyarı bu.
Aşağıdaki sıralama bana mantıklı geliyor:
- Kullanıcı isteği gelir → Harness oturumu okur.
- Anlamlı event’leri Claude context’ine taşır.
- Ajan tool çağrısı yaparsa execute(name, input) devreye girer.
- Sonuç Session’a yazılır, gerekirse yeni sandbox açılır.
- Süreç kesilirse başka Harness instance devam eder.
Neyse, uzatmayayım: iyi tasarlanmış agent sistemi biraz trafik ışığına benziyor. Kim nereye gidecek belli, ama yol kapansa bile alternatif güzergâh hazır. Kötü tasarımda ise herkes aynı kavşağa yığılır… sonra klakson konseri başlar!
Sıkça Sorulan Sorular
Ajan mimarisinde “brain” ve “hands” ayrımı ne işe yarar?
“Brain” karar verme kısmını,”hands” ise fiziksel işi temsil eder.Bu ayrım sayesinde model ile araç yürütme birbirine bağımlı olmaz;ölçekleme ve hata yönetimi kolaylaşır.
This architecture küçük projeler için fazla mı karmaşık?
Eğer proje tek adımlıysa evet,biraz ağır gelebilir.Ama oturum süreleri uzunsa,tool kullanımı fazlaysa ya da çökmeden toparlanma istiyorsanız erken aşamada bile anlamlı olabilir.
Sessioń neden context window dışında tutuluyor?
Cünkü model context’i sınırlıdır;Session ise kalıcı gerçek kaynaktır.Bu şekilde geçmişi kaybetmeden gerektiğinde sadece gerekli parçaları modele taşırsınız.
P95 gecikmesinin düşmesi neden önemli?
P95 kötü ise kullanıcıların küçük ama can sıkıcı kısmı sürekli sorun yaşar.Ortalama iyi görünse bile deneyim bozulur.Bu yüzden tail latency çoğu zaman asıl kalite göstergesidir.
Kaynaklar ve İleri Okuma
Anthropic — Scaling Managed Agents yazısı
Bazı iç link olarak okumaya deÄŸer baÅka yazılarımız varsa Åuralara da göz atabilirsiniz:
JavaScript’te Async Mantığı:** Event Loop’u Gerçekten Anlamak**,
React Streaming SSR:** RSC Olmadan Canlı HTML Akışı**,
MCP Patladı:** 97 Milyon İndirimin Arkasındaki Hikâye**.
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.



