Production'da Agent Orchestration: Tools, Memory ve State

En basit kalıp tek bir ajan döngüsü: model düşünür, bir araç çağırır, sonucu görür, tekrar karar verir, bitince cevap verir. Üretimdeki işlerin çoğu bu kalıpla ve iyi araçlarla çözülebilir. Bir üst seviye, sabit adımlı iş akışı (workflow): adımların sırası kodda belli, model yalnızca belirli adımlarda karar verir. Daha karmaşık kalıplar orkestratör-işçi (bir ajan görevi böler, alt ajanlar paralel çalışır) ve devir (handoff) yapıları.

Pratik kural: en basit kalıpla başlayın ve karmaşıklığı ancak ölçülmüş bir ihtiyaç için ekleyin. Çok ajanlı bir sistem her ajan sınırında bağlam kaybı, ek token maliyeti ve debug zorluğu getirir. Anti-pattern: 'araştırmacı', 'yazar', 'editör' gibi insan rollerini taklit eden beş ajan kurup, aslında tek bir ajanın iyi bir prompt ve üç araçla yapabileceği işi beş kat token'la yapmak. Paralellik gerçek bir kazanç sağlıyorsa (ör. 20 bağımsız dokümanı ayrı ayrı özetlemek) çoklu ajan anlamlıdır.

Son on iki ayda orkestrasyonun altındaki zemin belirgin biçimde değişti. MCP'nin 28 Temmuz 2026'da yayımlanan spesifikasyonu protokolü durumsuz hale getirdi: başlangıç el sıkışması ve `Mcp-Session-Id` başlığı kalktı, uzun işler sorgulama tabanlı `tasks` uzantısına taşındı, Roots, Sampling ve Logging en az on iki aylık bir geçişle deprecated oldu. Ağustos 2026'da yayımlanan MCP yol haritası, uzun süren ajan işleri için webhook benzeri sunucu olaylarını ve ajan kimliği ile yetki devrini öncelik olarak sıraladı.

Thoughtworks'ün Nisan 2026 Radar'ı iki uyarı yaptı: ajan iş akışlarında dayanıklılığı göz ardı etmek ve her entegrasyonda varsayılan olarak MCP'ye uzanmak, ikisi de 'Caution' halkasında. Radar, önce framework'ün yerleşik durable execution desteğiyle (LangGraph, Pydantic AI) başlayıp iş kritikleştikçe Temporal, Restate gibi bağımsız platformlara geçmeyi öneriyor. Temporal Ekim 2026'da AWS Strands Agents SDK için model, araç ve MCP çağrılarını Activity olarak çalıştıran entegrasyonlar duyurdu. Benimseme tarafında LangChain'in Haziran 2026 anketine göre ekiplerin yüzde 57,3'ünün üretimde ajanı var ve en büyük engel yüzde 32 ile kalite.

Ajan için araç, bir insan için kullanıcı arayüzü neyse odur. Kötü tasarlanmış bir araç, en iyi modeli bile yanlış yönlendirir. İyi aracın özellikleri: tek ve net bir amaç, modelin anlayacağı bir açıklama (ne zaman kullanılır, ne zaman kullanılmaz), sıkı bir giriş şeması (enum'lar, zorunlu alanlar) ve modelin üzerinde işlem yapabileceği hata mesajları. 'Error 500' yerine 'customer_id bulunamadı; önce search_customers ile arayın' dönen bir araç, ajanın kendini düzeltmesini sağlar.

Yanıt boyutu da tasarımın parçası. 2.000 satırlık bir veritabanı sonucunu modele döndürmek bağlamı doldurur; sayfalama, filtreleme ve özet alanı sunmak daha iyidir. Araç sayısında da eşik var: tek bir ajana 40-50 araç vermek, yanlış araç seçimini artırır. İlgili araçları gruplayın ya da göreve göre araç setini daraltın. MCP (Model Context Protocol) ile dışarıdan araç bağlarken de aynı kurallar geçerli; sunucunun sunduğu her aracı ajana otomatik açmak zorunda değilsiniz. Thoughtworks Nisan 2026'da 'MCP by default' yaklaşımını 'Caution' olarak işaretledi: birçok durumda net yardım metni, yapılandırılmış JSON çıktısı ve öngörülebilir hata mesajları olan iyi bir CLI, ajana daha az kayıpla aynı işi görüyor.

Okuma araçları (arama, listeleme) güvenle tekrar denenebilir. Yazma araçları (ödeme al, e-posta gönder, kayıt sil) tekrar denenemez, en azından kontrolsüz şekilde. Ajan döngüsü bir zaman aşımından sonra aynı aracı yeniden çağırırsa müşteriden iki kez ödeme alınabilir. Çözüm idempotency key (tekrar etkisizlik anahtarı): her yan etkili çağrıya görev ve adım kimliğinden türetilmiş bir anahtar eklemek, sunucunun aynı anahtarla gelen ikinci isteği yeni işlem olarak değil, önceki sonucun tekrarı olarak cevaplaması.

İkinci önlem insan onayı (human-in-the-loop). Geri alınamayan ve belirli bir eşiğin üstündeki işlemler (ör. 5.000 TL üzeri iade, 100'den fazla alıcıya e-posta, üretim veritabanında silme) ajanın 'öneri' üretip durduğu, onay geldikten sonra devam ettiği adımlar olmalı. Bu, durum yönetimiyle doğrudan bağlantılı: onay saatler sürebilir ve ajan süreci o sırada bellekte beklememeli.

Ajanda 'hafıza' üç farklı şeyi kapsar. Çalışma hafızası: o anki bağlam penceresi, yani modelin her çağrıda gördüğü mesajlar ve araç sonuçları. Görev hafızası (session): tek bir görev ya da konuşma boyunca biriken geçmiş. Uzun dönem hafıza: görevler ve konuşmalar arası taşınan bilgiler (kullanıcı tercihleri, önceki kararlar, proje notları).

Çalışma hafızasının sınırı maliyet ve kalite. Bağlam büyüdükçe her çağrının token maliyeti artar ve model eski ama alakasız bilgiye takılabilir. Yaygın teknikler: eski araç sonuçlarını kırpmak, belirli bir eşikte (ör. bağlamın yüzde 70'i dolduğunda) konuşmayı özetleyip sıkıştırmak (compaction) ve ajanın kendine not tuttuğu harici bir dosya veya kayıt alanı. Uzun dönem hafızada asıl soru 'ne yazılmalı' sorusu. Her şeyi bir vektör veritabanına atıp benzerlikle geri çağırmak, eski ve çelişkili bilgileri de geri getirir. Daha sağlam yol: hafızaya yazılacak bilgiyi yapılandırmak (tarih, kaynak, kapsam) ve güncellenmiş bilgilerin eskisinin üstüne yazılmasını sağlamak. Thoughtworks'ün Nisan 2026'da 'Assess' halkasına aldığı context graph tekniği aynı fikri ileri taşıyor: eskiyen bilgiyi silmek yerine geçerlilik süresi dolmuş olarak işaretliyor.

Bir ajan görevi 12 adım sürüyorsa ve 9. adımda pod yeniden başlıyorsa ne olur? Durum yalnızca bellekteyse, görev ya baştan başlar (8 adımın token maliyeti ve yan etkileri tekrarlanır) ya da kaybolur. Üretimde ajan durumunun açıkça kalıcı hale getirilmesi gerekiyor: her adımdan sonra görev kimliği, tamamlanan adımlar, araç sonuçları ve bir sonraki adım bir depoya yazılmalı.

Bunun için iki yaygın yol var. Birincisi kendi checkpoint tablonuz: Postgres'te `agent_runs` ve `agent_steps` gibi tablolarla, her adımı işlem içinde kaydetmek. İkincisi durable execution (dayanıklı yürütme) motorları: Temporal gibi sistemler iş akışının olay geçmişini saklar, çökme sonrasında akışı bu geçmişten yeniden oynatarak kaldığı yerden devam ettirir. Temporal'ın OpenAI Agents SDK entegrasyonu (Eylül 2025'te public preview) ve Ekim 2026'da duyurulan AWS Strands Agents SDK entegrasyonları, model, araç ve MCP çağrılarını yeniden denenebilir ayrı adımlar olarak çalıştırıyor. LangGraph'ın checkpointer yapısı ve Pydantic AI'ın yerleşik durable execution desteği de aynı ihtiyaca yönelik. Thoughtworks'ün Nisan 2026 önerisi: önce framework'ün yerleşik desteğiyle başlayın, iş kritikleştikçe bağımsız bir platforma geçin.

Üretimde her ajan döngüsünün sert sınırları olmalı: maksimum adım sayısı (ör. 25), görev başına token bütçesi, araç başına çağrı limiti ve toplam süre limiti. Sınır aşıldığında ajan sessizce durmamalı; o ana kadarki durumu kaydedip kullanıcıya ya da bir operatöre devretmeli. Bu sınırlar gözlemlenebilirlikle birlikte çalışır: hangi görevlerin limite takıldığını izlemek, araç tasarımındaki sorunları gösterir.

Protokol tarafında da durum yönetimi tartışılıyor. MCP spesifikasyonunun 28 Temmuz 2026'da yayımlanan revizyonu protokolü durumsuz (stateless) hale getirdi: `Mcp-Session-Id` başlığı ve başlangıç el sıkışması kaldırıldı, çağrılar arası durum gerektiren sunucuların bunu açık tanıtıcılarla (handle) tool argümanı olarak taşıması öneriliyor. Uzun süren işler için 'tasks' yapısı çekirdekten resmi bir uzantıya taşındı ve sorgulama (polling) tabanlı hale geldi; kopan bir yanıt akışı artık devam ettirilmiyor, istemcinin isteği yeniden göndermesi gerekiyor. Ajan orkestrasyonunu tasarlarken bunun anlamı net: durumu araç sunucusunun bağlantısına değil, kendi orkestrasyon katmanınıza ve açık kimliklere bağlayın.