Agent state ve durable execution

State, sistemin bir sonraki karar için taşıdığı anlamlı durum bilgisidir. Agent dünyasında bu kelime tek bir kutu değildir; farklı dayanıklılık beklentileri olan birkaç katmandan oluşur. Conversation state modelin konuşmayı sürdürebilmesini sağlar. Task state işin hangi adımda olduğunu gösterir. Tool state hangi tool çağrısının ne döndürdüğünü saklar. External side-effect state ise e-posta gönderildi mi, ödeme alındı mı, ticket açıldı mı gibi dış dünyada oluşmuş gerçekleri izler.

Bu ayrım önemlidir çünkü her state aynı şekilde geri alınamaz. Yanlış bir mesaj özetini düzeltmek kolaydır; yanlış müşteriye iki kez fatura kesmek kolay değildir. İyi agent mimarisi state'i yalnızca belleğe değil, sorumluluğa göre sınıflandırır.

Conversation state, modelin kullanıcıyla aynı konuşmanın içinde kalmasını sağlayan bağlamdır. Mesaj geçmişi, özetlenmiş geçmiş, sistem talimatları, son response kimliği ya da session kaydı bu katmana girer. OpenAI Responses API'de previous_response_id ile cevaplar zincirlenebilir; bu, modelin önceki dönüşlerdeki bağlamı takip etmesine yardım eder.

Fakat bu katmanın sınırı nettir: conversation state, agent'in operasyonel ilerlemesini tek başına garanti etmez. Kullanıcıya “raporu hazırlıyorum” dedikten sonra sistem çökerse, sadece konuşma geçmişi raporun hangi sorguları çalıştırdığını, hangi dosyayı yazdığını, hangi tool sonucunun geçerli olduğunu ve hangi adımın güvenle tekrar koşulabileceğini söylemez.

Bu yüzden sohbet belleği ile yürütme belleğini karıştırmamak gerekir. Conversation state kullanıcı deneyimi için şarttır; ama durable execution için yalnızca bir girdidir.

Task state, agent'in işi yürütürken nerede olduğunu anlatan yapısal durumdur. Bir planın hangi maddesi tamamlandı? Hangi node sırada? Hangi dependency bekleniyor? Kullanıcı onayı hangi branch'i açtı? Bunlar sohbet geçmişine gömülürse okunabilir ama güvenilir çalıştırılamaz; bu yüzden task state'in makine tarafından tüketilebilir bir şema içinde tutulması gerekir.

LangGraph gibi graph tabanlı sistemlerde thread_id ve checkpoint kavramları tam da bu yüzden merkezde durur. Checkpointer, tek bir thread'in graph state snapshot'larını saklar; store ise thread'ler arası uzun ömürlü bilgi için kullanılır. Bu ayrım üretimde hayat kurtarır: aktif koşunun nerede kaldığı ile kullanıcının kalıcı tercihi aynı veri tipi değildir.

Tool state, agent'in dış dünya ile temasında oluşan kanıt defteridir. Tool çağrısının input'u, output'u, hata sınıfı, süre bilgisi, retry sayısı ve varsa operation id burada tutulmalıdır. Çünkü tool'lar model cevabından farklıdır: bir arama tool'u gözlem döndürür, bir ödeme tool'u ise gerçek dünyada sonuç üretir.

Bu katmanda en önemli terim idempotency. Bir operasyon idempotent ise aynı istek aynı anahtarla tekrar geldiğinde dış etki ikinci kez oluşmaz. Örneğin “invoice-123 için tahsilat başlat” çağrısı timeout verdiğinde agent tekrar denemek isteyebilir. Eğer ödeme tool'u idempotency key tanımıyorsa aynı ödeme iki kez alınabilir. Eğer tanıyorsa ikinci deneme önceki sonucu döndürür veya güvenli biçimde no-op olur.

Agent sistemlerinde retry çoğu zaman iyi niyetli bir felaket kaynağıdır. Model “deneyelim” der, orchestrator “retry edelim” der, ağ “cevap kayboldu” der; ama dış sistem işi çoktan yapmış olabilir. Tool state bu belirsizliği görünür kılar.

Checkpoint, çalışan sürecin ham RAM görüntüsü değildir; daha çok işin mantıksal bir durak fotoğrafıdır. Hangi thread'deyiz, state değerleri ne, hangi node tamamlandı, sıradaki node ne, hangi tool sonucu kaydedildi, parent checkpoint hangisi? Bunlar bilinirse sistem aynı noktadan devam edebilir, farklı bir branch açabilir ya da insan müdahalesinden sonra akışı sürdürebilir.

Checkpoint'i değerli yapan şey yalnızca “kaydetmek” değildir; geri okunabilirlik ve fork edilebilirliktir. Bir insan “bu tool sonucunu yanlış kabul etmişsin, buradan devam et” dediğinde sistem eski konuşmayı tekrar okutmak yerine belirli bir checkpoint'ten yeni bir çizgi açabilmelidir.

Bu nedenle checkpoint tasarımında isimler operasyonel kararlardır: thread id, checkpoint id, namespace, parent id, created_at, schema version ve source metadata ileride debug ekranının omurgası olur.

Durable execution, uzun süren bir işin process ömründen bağımsız yaşamasıdır. Worker kapanabilir, deployment değişebilir, network kopabilir; ama işin ilerlemesi güvenilir bir kayıt üzerinden yeniden kurulabilir. Temporal'ın Event History yaklaşımı, Azure Durable Task'ın event sourcing düzeni ve Durable Functions literatüründeki record/replay modeli bu fikrin farklı olgunlaşmış biçimleridir.

Buradaki ana fikir event sourcing: sistem yalnızca son state'i saklamak yerine, state'i oluşturan olayları append-only bir geçmişe yazar. Sonra gerekirse bu geçmiş replay edilerek mantıksal state yeniden kurulur. Bu, “program belleğini dondurdum” demek değildir; programı deterministik sınırlar içinde yeniden çalıştırıp aynı kararlara varacak kanıtı saklamak demektir.

Agent bağlamında kritik nokta şudur: LLM çağrısı, HTTP isteği, rastgele sayı, saat bilgisi, shell komutu ve browser tıklaması nondeterministic olabilir. Durable orchestration içinde bu tür işler doğrudan karara karışırsa replay aynı yolu izlemeyebilir. Bu yüzden dış eylemler activity/tool sınırına alınmalı, sonuçları kaydedilmeli ve orchestrator mümkün olduğunca deterministik kalmalıdır.

Rollback kelimesi agent sistemlerinde çoğu zaman yanlış rahatlık verir. Veritabanı transaction'ı gibi her şeyi geri almak her zaman mümkün değildir. Bir e-postayı gönderdikten sonra onu “gönderilmemiş” yapamazsınız; ancak açıklama e-postası atabilir, ticket'ı kapatabilir, ödeme için refund başlatabilirsiniz. Bu ikinci tür işleme compensation denir.

Redrive, failed execution'ı baştan değil, başarısız adımdan veya güvenli bir ara noktadan yeniden yürütme fikridir. AWS Step Functions redrive davranışında başarılı adımlar korunur; başarısız state yeniden çalıştırılır. Agent tarafında bu karar açık olmalıdır: hangi tool sonuçları korunuyor, hangi step tekrar koşuyor, hangi side effect asla tekrar edilmiyor?

Rollback tasarımı bu yüzden üç kutudan oluşur: logical rollback, yani checkpoint'ten eski bir mantıksal state'e dönmek; retry/redrive, yani başarısız adımı kontrollü tekrar etmek; compensation, yani dış dünyada oluşmuş yan etkiyi yeni bir eylemle telafi etmek.

State ve durable execution tasarımı iyi yapılınca agent daha gösterişli değil, daha hesap verebilir olur. Geliştirici “model neden böyle yaptı?” sorusuna konuşma geçmişinden değil; checkpoint, event history, tool evidence ve side-effect kayıtlarından cevap verir.

Benim pratik kuralım şu: conversation state kullanıcıya akıcı deneyim verir; task state işi yönetir; tool state kanıt üretir; durable execution ise tüm bunları process ömründen bağımsız hale getirir. Bu katmanlardan biri eksikse agent bazen çalışır, ama olay çıktığında anlatacak defteri olmaz.