State machine, checkpoint, durable execution, retry policy, dead-letter queue, reconciliation ve human takeover

Bir kurum, yeni yüklenen sözleşmenin yenileme ve fesih koşullarını incelemek için yapay zekâ ajanı kullanıyor. Ajan belgeyi okuyor, tarafları ve kritik tarihleri çıkarıyor, otomatik yenileme riskini belirliyor ve hukuk yöneticisinin onayına sunulacak görevi hazırlıyor.

Tam bu sırada uygulama sunucusu yeniden başlıyor. Kullanıcı birkaç dakika sonra sisteme döndüğünde basit görünen fakat önemli bir soruyla karşılaşıyor: Ajan hangi adımları tamamladığını gerçekten biliyor mu? Belgeyi yeniden okuyacak mı? Aynı riski ikinci kez kaydedecek mi? Daha önce alınmış onayı kaybedecek mi? Yoksa kaldığı yerden güvenle devam edebilecek mi?

Sohbet geçmişinin saklanması bu soruları tek başına çözmez. Bir ajan önceki cümleleri hatırlayabilir; ancak gerçek iş ortamında güvenilir devam için tamamlanan adımların, oluşan yan etkilerin, bekleyen onayın ve yeniden deneme sayısının kalıcı biçimde kaydedilmesi gerekir.

Ajanın hatırlaması konuşmayı sürdürür; iş akışının durumunu saklamak işlemi güvenle sürdürür.

Bir önceki DERİNLEŞME bölümünde işlev çağrısının gerçek işleme dönüşmesini ve aynı işlemin iki kez yapılmasının nasıl önlendiğini incelemiştik. Bu bölümde bir sonraki soruya geçiyoruz: Uzun süren bir iş kesildiğinde sistem geçmişi nasıl yeniden kurar, hangi adımdan devam eder ve belirsizliği ne zaman insana devreder?

Önce hafıza ile iş durumu arasındaki farkı kuralım

Kayıt türü	Ne saklar	Tek başına neyi garanti etmez
Conversation memory	Kullanıcı mesajları ve konuşma bağlamı	Görevin veritabanında gerçekten oluştuğunu
Agent memory	Tercihler, özetler ve önceki gözlemler	İş akışının hangi adımda güvenle kaldığını
Workflow state	Durum, adım, deneme, onay ve sonuç kimlikleri	Dış sistemin gerçek durumuyla daima eşleştiğini
Audit trail	Kim, ne zaman, hangi kararla işlem yaptı	İşlemin otomatik olarak düzeltildiğini

Bir dil modeli, ‘Görevi oluşturdum’ cümlesini konuşma geçmişinde görebilir. Fakat bu cümle görev tablosunda gerçekten kayıt bulunduğunun kanıtı değildir. Güvenilir sistem, doğal dildeki anlatıyı değil; işlem kimliğini, durum geçişini ve dış sistem sonucunu esas alır.

State machine durum makinesi nedir

Şekil 1. Durum makinesi, sözleşme iş akışının hangi durumda bulunduğunu ve hangi geçişlerin izinli olduğunu açıkça tanımlar.

State machine (durum makinesi), bir iş akışını adlandırılmış durumlar ve bu durumlar arasındaki izinli geçişler olarak tanımlar. Sistem yalnızca ‘3. adımdayım’ demez; hangi iş sonucunun oluştuğunu, hangi koşulun sağlandığını ve sıradaki geçişin ne olduğunu kaydeder.

Sözleşme senaryosunda durumlar Yüklendi, Veri Çıkarıldı, Risk İncelendi, Onay Bekliyor, Görev Oluşturuluyor ve Tamamlandı olabilir. Eksik veri bulunursa İnsan İncelemesi; onay süresi dolarsa Durduruldu durumuna geçilebilir. Böylece yeniden başlayan sistem, belirsiz bir kod satırından değil açık bir iş durumundan devam eder.

Durum geçişleri kurallı olmalıdır. Onay Bekliyor durumundaki bir iş, onay olayı gelmeden Tamamlandı durumuna atlayamaz. Durduruldu durumundaki işin yeniden başlaması için yetkili kişinin kararı gerekir. Bu kurallar modelin yorumuna bırakılmaz; uygulama katmanında deterministik olarak uygulanır.

Checkpoint kontrol noktası neyi kaydeder

Şekil 2. Kontrol noktası, tamamlanan adımların ve üretilen sonuçların kalıcı kaydını tutar. Kesinti sonrası yürütme bu kayıt üzerinden yeniden kurulur.

Checkpoint (kontrol noktası), iş akışının güvenle geri dönülebilecek anlık durumudur. Yalnızca adım numarasını değil; o ana kadar üretilen sonuçları, dış işlem kimliklerini, bekleyen olayları, retry sayaçlarını ve kullanılan iş akışı sürümünü de içermelidir.

Checkpoint alanı	Sözleşme örneği	Neden gerekir
Workflow instance ID	WF-SZL-2026-1842	Aynı yürütmeyi benzersiz tanımak
Current state	ONAY_BEKLIYOR	Hangi geçişten devam edileceğini bilmek
Completed steps	Belge okuma, veri çıkarma, risk analizi	Tamamlanan işi tekrar etmemek
Outputs	Tarih, tutar, risk ve kaynak maddeler	Sonraki adıma doğrulanmış veri taşımak
External IDs	Görev ve bildirim işlem kimlikleri	Yan etkileri dış sistemde bulmak
Pending event	Hukuk yöneticisi onayı	Beklenen insan veya sistem olayını korumak
Version	Workflow v3 ve politika v5	Değişen kodla eski yürütmeyi karıştırmamak

Her satırdan sonra checkpoint almak güvenli görünse de maliyet ve gecikme yaratabilir. Çok seyrek checkpoint ise kesintiden sonra fazla işin yeniden yürütülmesine neden olur. Doğru sınır genellikle dış yan etki oluşturan, pahalı hesaplama yapan veya uzun süre insan bekleyen adımların öncesi ve sonrasıdır.

Durable execution kalıcı yürütme nasıl çalışır

Durable execution (kalıcı yürütme), bir iş akışının süreç veya sunucu ömründen bağımsız biçimde ilerlemesidir. Microsoft Durable Functions dokümantasyonu; durum, checkpoint, retry ve recovery işlemlerinin çalışma zamanı tarafından yönetildiğini belirtir. Yürütme geçmişi yeniden oynatılarak orkestratör daha önceki checkpoint durumuna getirilebilir (Microsoft, 2026a; Microsoft, 2026b).

Buradaki replay, bütün dış işlemleri tekrar yapmak anlamına gelmemelidir. Orkestratörün kararları geçmiş olaylardan yeniden kurulur; e-posta gönderme, görev açma veya ödeme başlatma gibi yan etkiler ayrı activity adımlarında ve idempotent biçimde çalıştırılır. Aksi hâlde yeniden oynatma, aynı görevi veya bildirimi ikinci kez oluşturabilir.

Kalıcı yürütme şu üç veriyi birbirinden ayırır:

• History: Şimdiye kadar gerçekleşen durum geçişleri ve olaylar.
• State: Bu geçmişten türetilen mevcut iş durumu.
• Command: Mevcut durumdan sonra çalıştırılması gereken yeni faaliyet.

Güvenli devam, eski kodu kaldığı satırdan çalıştırmak değil; kayıtlı iş geçmişinden sıradaki doğru kararı yeniden üretmektir.

Kesinti anını adım adım inceleyelim

1. Ajan sözleşmeyi okur ve belge kimliğiyle birlikte metin çıkarma sonucunu kaydeder.
2. Taraf, tarih, tutar ve yenileme maddeleri doğrulanır; Veri Çıkarıldı checkpoint’i oluşur.
3. Risk analizi tamamlanır; kaynak maddeler ve politika sürümü kaydedilir.
4. İş akışı Onay Bekliyor durumuna geçer ve hukuk yöneticisine benzersiz onay olayı gönderilir.
5. Sunucu yeniden başlar. İş akışı geçmişi kalıcı depodan yüklenir.
6. Tamamlanmış belge okuma ve risk analizi tekrar çağrılmaz; sistem Onay Bekliyor durumunu yeniden kurar.
7. Onay olayı daha önce geldiyse olay kimliğiyle eşleştirilir; gelmediyse bekleme sürer.
8. Onay sonrası görev idempotency anahtarıyla oluşturulur ve sonuç yeni checkpoint’e yazılır.

Retry policy yeniden deneme politikası

Şekil 3. Yeniden deneme yalnızca geçici hatalara, sınırlı sayıda ve artan bekleme aralıklarıyla uygulanır. Kalıcı veya tekrarlayan hata inceleme yoluna alınır.

Retry policy (yeniden deneme politikası), hangi hatanın kaç kez, hangi aralıklarla ve hangi toplam süre içinde yeniden deneneceğini tanımlar. Microsoft Durable Functions ve AWS Step Functions dokümantasyonları; maksimum deneme, ilk bekleme süresi, artış katsayısı ve zaman aşımı gibi alanlarla retry davranışının sınırlandırılabildiğini gösterir (Microsoft, 2026c; AWS, 2026a).

Hata türü	Örnek	Önerilen davranış
Geçici	Ağ kesintisi, 503, hız sınırı	Sınırlı retry, exponential backoff ve jitter
Kalıcı veri	Zorunlu sözleşme alanı eksik	Retry yok; insan incelemesi
Yetki	Kullanıcının görev açma yetkisi yok	Retry yok; işlemi durdur
İş kuralı	Son tarih geçmişte	Veriyi düzeltmeden retry yapma
Belirsiz yan etki	Görev çağrısı timeout oldu	Durumu sorgula; aynı idempotency anahtarıyla devam et

Retry sayısını artırmak güvenilirlik değildir. Kalıcı bir hatayı yüz kez tekrarlamak yalnızca servisi yorar ve gerçek sorunu geciktirir. Ayrıca yeniden denenebilecek activity adımları idempotent olmalıdır; aynı çağrının tekrarı ikinci bir iş etkisi üretmemelidir.

Dead letter queue hatalı ileti kuyruğu

Dead-letter queue veya DLQ (hatalı ileti kuyruğu), belirlenen deneme sayısından sonra işlenemeyen iletilerin ana akışı engellemeden ayrıldığı özel kuyruktur. AWS SQS dokümantasyonu DLQ’ların başarısız iletileri izole ederek hata nedenini incelemeye yardımcı olduğunu belirtir (AWS, 2026b).

Sözleşme senaryosunda görev oluşturma iletisi üç denemede işlenemediyse DLQ’ya taşınabilir. Ancak kuyruk bir mezarlık olmamalıdır. Her iletiyle birlikte hata sınıfı, deneme geçmişi, workflow kimliği, son checkpoint, ilişkili sözleşme ve güvenli yeniden işleme talimatı saklanmalıdır.

• DLQ’ya düşen ileti için sorumlu ekip ve müdahale süresi tanımlanmalıdır.
• Sorun düzeltilmeden toplu redrive yapılmamalıdır.
• Yeniden işleme aynı idempotency ve workflow kimliğiyle yapılmalıdır.
• Kişisel ve gizli veri log veya kuyruk mesajına gereksiz biçimde yazılmamalıdır.

Reconciliation uzlaştırma neden gereklidir

Şekil 4. Uzlaştırma, iş akışının beklediği durum ile gerçek iş sistemindeki kayıtları karşılaştırır. Çelişki otomatik çözülemiyorsa işlem insana devredilir.

Reconciliation (uzlaştırma), kayıtlı beklenen durum ile dış sistemlerdeki gerçek durumun karşılaştırılmasıdır. Kubernetes denetleyicileri de benzer bir kontrol döngüsüyle istenen durumu mevcut durumla karşılaştırır ve aradaki farkı azaltmaya çalışır (Kubernetes, 2026).

Workflow geçmişi ‘Görev oluşturuldu’ diyebilir; görev veritabanında kayıt bulunmayabilir. Tersi de mümkündür: Görev oluşmuş, ancak sonuç checkpoint’e yazılamadan sistem kapanmıştır. Uzlaştırma işlemi sözleşme kimliği, idempotency anahtarı ve dış görev numarasıyla gerçek kaydı arar; sonra güvenli kararı verir.

Beklenen	Gerçek	Uzlaştırma kararı
Görev yok	Görev yok	Yetki ve onay geçerliyse oluştur
Görev oluştu	Aynı anahtarlı görev var	Mevcut kimliği checkpoint’e bağla
Görev oluştu	Görev bulunamadı	Olay geçmişini incele; gerekirse kontrollü yeniden oluştur
Onay bekliyor	Onay olayı var	Olay kimliğini doğrula ve sıradaki duruma geç
Onay bekliyor	Çelişkili iki karar var	Otomasyonu durdur ve insana devret

Uzlaştırma her zaman otomatik düzeltme anlamına gelmez. Sistem yalnızca yeterli ve güvenilir kanıt olduğunda kendini düzeltmelidir. Finansal, hukuki veya geri döndürülemez sonuçlarda belirsizlik insan incelemesine yönlendirilmelidir.

Human takeover insan devralması

Human takeover (insan devralması), ajanın yürüttüğü işi bağlamını kaybetmeden yetkili kişiye aktarmasıdır. OpenAI Agents SDK insan onaylı akışlarında çalışma durumu serileştirilebilir, işlem onay veya ret için duraklatılabilir ve karar sonrasında aynı durumdan devam ettirilebilir. Microsoft’un insan etkileşimi deseni de orkestrasyonun dış olay veya onayı zaman sınırıyla beklemesini ele alır (OpenAI, 2026; Microsoft, 2026d).

İnsana devretmek yalnızca e-posta göndermek değildir. Sistem önce yürütmeyi kilitlemeli, otomatik retry’ı durdurmalı ve karar için gerekli bağlam paketini hazırlamalıdır:

• Sözleşme ve ilgili kaynak maddeler
• Mevcut state ve son güvenli checkpoint
• Tamamlanan ve bekleyen adımlar
• Deneme sayıları, hata sınıfı ve dış işlem kimlikleri
• Ajandan beklenen karar ve olası etkiler
• Devam et, düzelt, atla, iptal et veya yeniden başlat seçenekleri

İnsan karar verdiğinde bu karar yeni bir olay olarak audit trail’e yazılmalı ve workflow yalnızca izin verilen geçişten devam etmelidir. İnsan müdahalesi geçmişi silmemeli; otomasyonun neden durduğunu ve hangi kararla sürdüğünü görünür kılmalıdır.

Yedi kavramın görevleri birbirinden farklıdır

Kavram	Temel görevi	Tek başına yetmediği nokta
State machine	Durumları ve izinli geçişleri tanımlar	Durumu kalıcı saklamaz
Checkpoint	Güvenli geri dönüş noktasını kaydeder	Dış sistemin gerçekliğini kanıtlamaz
Durable execution	Kesinti sonrası yürütmeyi yeniden kurar	Yan etkileri otomatik idempotent yapmaz
Retry policy	Geçici hataları kontrollü tekrarlar	Kalıcı hatayı düzeltemez
Dead-letter queue	İşlenemeyen iletiyi izole eder	Sorunu kendiliğinden çözmez
Reconciliation	Beklenen ve gerçek durumu karşılaştırır	Belirsiz kararı her zaman otomatik veremez
Human takeover	Kontrolü bağlamıyla insana aktarır	Eksik kayıt varsa geçmişi yeniden üretemez

Şeytanın avukatlığı kalıcı yürütme her zaman gerekli mi

Her yapay zekâ işlemini ağır bir orkestrasyon altyapısına taşımak doğru değildir. Bir metni yeniden yazmak veya taslak başlık üretmek birkaç saniyede tamamlanır ve yan etkisi yoktur. Böyle bir işlem başarısız olursa kullanıcı yeniden deneyebilir.

Ancak süreç dakikalar veya günler sürüyorsa, insan onayı bekliyorsa, birden fazla sisteme yazıyorsa veya hukuki ve mali sonuç yaratıyorsa kalıcı yürütme maliyet değil güvence hâline gelir. Teknik karmaşıklık, işlemin süresi ve etkisiyle orantılı kurulmalıdır.

Bir başka risk de yanlış checkpoint’tir. Hatalı veya doğrulanmamış sonuç kalıcılaştırılırsa sistem kesinti sonrasında aynı yanlış durumdan güvenle devam eder. Bu nedenle checkpoint yalnızca dayanıklılık değil, doğrulanmış iş sınırı olarak tasarlanmalıdır.

Kurumsal uygulama için on iki kontrol sorusu

• İş akışının durumları ve izin verilen geçişleri açıkça tanımlı mı?
• Konuşma geçmişi ile kalıcı workflow state birbirinden ayrılmış mı?
• Her kritik checkpoint hangi veri ve işlem kimliklerini saklıyor?
• Kesinti sonrası hangi adımlar replay ediliyor, hangileri activity olarak tekrar çağrılıyor?
• Yan etkili activity adımları idempotent mi?
• Retry yalnızca geçici hata sınıflarına mı uygulanıyor?
• Maksimum deneme, bekleme artışı ve toplam retry süresi tanımlı mı?
• İşlenemeyen iletiler DLQ’ya giderken yeterli teşhis bilgisi taşıyor mu?
• DLQ izleniyor ve kontrollü redrive süreci bulunuyor mu?
• Beklenen ve gerçek durumlar düzenli olarak uzlaştırılıyor mu?
• İnsan devraldığında otomasyon kilitleniyor ve bağlam eksiksiz aktarılıyor mu?
• İş akışı sürümü değiştiğinde devam eden eski yürütmeler nasıl yönetiliyor?

Kısa kavram sözlüğü

State machine — durum makinesi: Bir iş akışının durumlarını ve izin verilen geçişlerini tanımlayan model.

Checkpoint — kontrol noktası: Kesinti sonrasında güvenle geri dönülebilecek kalıcı yürütme kaydı.

Durable execution — kalıcı yürütme: İş akışını süreç ve sunucu ömründen bağımsız olarak sürdürebilen yürütme yaklaşımı.

Replay — yeniden oynatma: Kayıtlı olay geçmişinden orkestratörün karar durumunu yeniden kurma işlemi.

Retry policy — yeniden deneme politikası: Hangi hatanın kaç kez ve hangi aralıklarla tekrar edileceğini belirleyen kurallar.

Dead-letter queue — hatalı ileti kuyruğu: Deneme sınırını aşan iletilerin inceleme için izole edildiği kuyruk.

Reconciliation — uzlaştırma: Beklenen iş durumu ile dış sistemdeki gerçek durumun karşılaştırılması.

Human takeover — insan devralması: Otomatik yürütmenin durdurulup bütün bağlamıyla yetkili kişiye aktarılması.

Sonuç bir ajanın devam edebilmesi için yalnızca hatırlaması yetmez

Bir yapay zekâ ajanının yarım kalan işi güvenle devam ettirmesi, konuşma geçmişini yeniden yüklemekten daha kapsamlıdır. İş akışının açık durumları, doğrulanmış checkpoint’leri, kalıcı olay geçmişi, sınırlı retry politikası ve dış sistemlerle uzlaştırma mekanizması bulunmalıdır.

Sistem, tamamlanan adımları tekrar etmemeli; belirsiz yan etkileri sorgulamalı; çözülemeyen iletileri görünür bir kuyruğa ayırmalı ve risk yükseldiğinde kontrolü insana bağlamıyla devretmelidir.

Güvenilir ajan, her şeyi hatırlayan ajan değildir; neyi tamamladığını kanıtlayabilen ve ne zaman durması gerektiğini bilen ajandır.

Bir sonraki DERİNLEŞME bölümünde

“Bir yapay zekâ ajanının kararları ve yaptığı işlemler uçtan uca nasıl izlenir?”

DERİNLEŞME 17’de distributed tracing (dağıtık izleme), correlation ID (ilişkilendirme kimliği), span, event log (olay günlüğü), metrics (ölçümler), alerting (uyarı üretimi), model ve prompt versioning (sürümleme) kavramlarını tek bir sözleşme iş akışının izini sürerek inceleyeceğiz.

Yazar

Dr. Mert Dönerçark

Yapay Zekâ Araştırmacısı ve Yazılım Stratejisti

Yayın Destekçisi ve Şeffaflık Notu

Bu yayın, MicroDestek katkılarıyla hazırlanmaktadır. Yazılarımda zaman zaman örneklerine yer verdiğim KolayOfis, ContractFlow ve MicroDestek Yapay Zekâ Asistanı, görev yaptığım MicroDestek tarafından geliştirilmektedir. Paylaştığım değerlendirmeler ise akademik ve uygulamalı çalışmalarım doğrultusunda oluşturulmuş kişisel görüşlerimi yansıtmaktadır.

Kaynakça

• Amazon Web Services. (2026a). Handling errors in Step Functions workflows. Bağlantı
• Amazon Web Services. (2026b). Using dead-letter queues in Amazon SQS. Bağlantı
• Kubernetes. (2026). Controllers. Bağlantı
• Microsoft. (2026a). Durable Functions overview. Bağlantı
• Microsoft. (2026b). Durable orchestrations overview. Bağlantı
• Microsoft. (2026c). Handle errors and retries in Durable Functions. Bağlantı
• Microsoft. (2026d). Human interaction pattern. Bağlantı
• Microsoft. (2026e). Handle external events in Durable orchestrations. Bağlantı
• OpenAI. (2026). Human-in-the-loop. OpenAI Agents SDK. Bağlantı