Cloudflare Agents ile bekleyen işler için takvim kurmak

Bir sözleşme taslağı hukuk ekibine gönderiliyor. Ajan eksik maddeleri işaretlemiş, yanıt için bir hatırlatma oluşturmuş. Üç gün sonra hukuk ekibinden cevap gelmiyor. Teknik tarafta zamanlanmış görev çalışmış olabilir. Ama sözleşmenin sahibi hâlâ aynı kişi mi, taslak o sırada değişti mi, hatırlatma kime gitmeli? Ajanın saat kurabilmesi, bekleyen işin kurum içinde yönetildiği anlamına gelmiyor.

Cloudflare’ın açık kaynak Agents SDK, Durable Objects üzerinde adreslenebilir, durum tutan ajanlar kurmak için bir çalışma zemini sunuyor. Bu yazıda bazen “Cloudflare OS” diye anılan ajan araç takımından söz ederken bağımsız bir işletim sistemi ürününü kastetmiyorum. SDK ajan kimliği, kalıcı durum, bağlantılar ve zamanlama gibi parçaları sağlıyor. Bir modelin araç seçip sonuçlarına göre devam ettiği döngü ise ayrıca kurulabilir veya hazır bir harness ile yürütülebilir. Takvim meselesi, bu katmanlardan birinin tek başına çözdüğü bir sorun değil.

Bekleme bir durumdur, boşluk değil

Sözleşme örneğinde ajan incelemeyi bitirdiğinde iş tamamlanmaz. Bir insanın yanıtı beklenir. İş kaydına sadece “hatırlatma kuruldu” yazmak yetersizdir. Hangi taslak sürümünün incelendiği, kararın kimden beklendiği, kararın son tarihi ve gecikirse kimin devralacağı ayrıca tutulmalıdır. Bekleme durumunu belirginleştirmezsek üç gün sonra çalışan ajan, önceki konuşmanın son mesajına bakıp yanlış kişiye doğru görünen bir hatırlatma gönderebilir.

Cloudflare’ın uzun yaşayan ajanlar rehberi önemli bir ayrımı anlatıyor: uzun yaşayan ajan sürekli çalışan bir süreç değildir. Kimliği ve saklanan durumu sürer; ihtiyaç olduğunda uyanır, çalışır, sonra yeniden bekler. Durum, SQL kayıtları ve zamanlanmış işler korunabilir; bellekteki değişkenler ve açık bağlantılar ise aynı güvenceye sahip değildir. Bu yüzden “üç gün sonra devam et” talimatını yalnızca çalışan kodun belleğine bırakmak yerine kalıcı iş durumuna bağlamak gerekir.

Bu yapıda ajan örneği bir sözleşmeye, bir ekibe veya bir kullanıcıya karşılık gelebilir. Hangi düzeyi seçeceğimiz operasyon sorusudur. Kullanıcı başına tek ajan kurup bütün sözleşmeleri aynı durum içinde tutarsak, hatırlatmanın hangi taslağa bağlı olduğunu ayrıca ayırmalıyız. Sözleşme başına ayrı örnek kurarsak kimlik ve veri sınırı daha açık olabilir, fakat ekip çapındaki iş kuyruğunu ve devri başka bir görünümde toplamak gerekir. SDK bu kimlikleri adreslemeye yardım eder; organizasyon şemasındaki sorumlu kişiyi otomatik seçmez.

İki ayrı saat çalışır

Teknik saat, ajanın ne zaman uyanacağını söyler. İş saati ise hangi kararın ne zamana kadar geçerli olduğunu tanımlar. Sözleşme uzmanı cuma günü bir düzeltme yapmışsa pazartesi sabahı çalışan hatırlatma eski sürüm için yazılmış olabilir. Zamanlama kaydı hâlâ mevcut olsa da hatırlatmanın gerekçesi değişmiştir. Bu nedenle uyanınca önce kaydı tekrar okumak gerekir: Beklenen karar hâlâ açık mı? Referans alınan belge sürümü geçerli mi? Yanıt verilmiş ama olay ajana henüz ulaşmamış olabilir mi?

Agents API zamanlama ve durum yöntemlerini belgeler. Bunlar bir olayı ileri tarihe taşımayı ve sonra ilgili ajan örneğinde işlemeyi sağlar. İşin son tarihi, mesai takvimi, vekâlet ilişkisi ve resmî onay yetkisi ise uygulamanın kararlarıdır. Takvimdeki bir olayın gerçekleşmesi tek başına “hukuk reddetti” sonucunu doğurmaz. En fazla “belirlenen süre içinde doğrulanmış yanıt yok” diyebiliriz. Bu ayrım, olumsuz kararı sessizlikten üretmeyi önler.

Küçük bir kural tablosu yeterli olabilir. Bekleyen taslak için iş kimliği, belge sürümü, sorumlu rol, karar için son tarih, son kontrol zamanı ve sonraki işlem alanları tutulsun. Zaman geldiğinde ajan kaydı kontrol etsin. Yanıt varsa hatırlatma göndermesin. Belge değişmişse eski talebi kapatıp yeni sürüm için insanın yeniden değerlendirmesine sunsun. Yanıt yoksa görev sahibine bilgi versin; yetki devri gerekiyorsa kuralı belirlenmiş kişiye yönlendirsin. Bu, modelin serbestçe yeni bir onay mercii seçmesinden daha güvenilir bir başlangıçtır.

Yeniden deneme ile yeniden karar verme farklıdır

Hatırlatma gönderme çağrısı yanıt vermeden bağlantı kopabilir. Böyle bir durumda ajan gönderilip gönderilmediğini bilmeden tekrar denemeye kalkar. Teknik yürütmenin kesintiye dayanması, harici sistemdeki bildirimin bir kez yapıldığını kanıtlamaz. İş kimliği ve hatırlatma türüyle sabit bir işlem anahtarı kullanmak, karşı sistem destekliyorsa tekrarları ayırmayı kolaylaştırır. Desteklemiyorsa bildirim geçmişi okunmalı veya şüpheli sonuç insan incelemesine bırakılmalıdır.

Cloudflare’ın fiber belgeleri kesintiye uğrayan ajan içi işi toparlamak için runFiber() ve ara durum saklamak için stash() yöntemlerini açıklar. Daha bağımsız, adımlı süreçlerde Workflows başka bir seçenektir. Hangisi kullanılırsa kullanılsın, “uyandırıldım” ile “iş kararı değişti” olaylarını ayrı kaydetmek gerekir. Bir önceki yazıda ajanlar arası devirde bağlamın nasıl taşınacağını ele almıştık. Burada aynı devrin zaman boyutu var: işin sahibi değiştiğinde gelecekteki uyanmalar da yeni sorumluluğa göre yorumlanmalı.

Küçük bir sınama nasıl yapılır?

İlk uygulamayı tek bir sözleşme türüne sınırlayın. Ajan taslağı incelesin ve gerçek bir onay vermeden “insan yanıtı bekleniyor” durumunu oluştursun. Kısa bir test süresi sonunda zamanlanan kontrol çalışsın. Ardından üç olasılığı ayrı sınayın: Yanıt süre dolmadan gelmiş olsun, taslak beklerken güncellenmiş olsun, bildirimin sonucu belirsiz kalsın. Her seferinde sistemin son durumunu ve sonraki sorumluyu bir iş kaydından okuyabiliyor muyuz?

Bu denemede amaç hızlı otomasyon değil, yanlış kesinlik üretmemek. “Hatırlatma gönderilemedi” ile “karar verilmedi” ayrı olaylardır. “Onay bekleniyor” ile “süre aşıldı” da farklı kayıtlardır. Operasyon ekibi bunları ayırabildiğinde geciken işin nerede takıldığını görebilir, ajanın yanlış zamanda karar vermesini engelleyebilir. Süre politikası değiştiğinde yalnızca zamanlayıcıyı değil, bekleyen kayıtların hangi kurala göre değerlendirileceğini de gözden geçirmek gerekir.

Cloudflare Agents bekleyen bir ajanı kimliğiyle yeniden uyandırmak ve iş durumunu saklamak için gerekli teknik zemini verir. O işin hangi rolün masasında kaldığını, süre dolunca kimin devralacağını ayrı tanımlamak gerekir. Bu örgütsel katmana odaklanan agentic-organization, AI ajanlarını organizasyon şemasında birinci sınıf üye olarak yönetmeye yönelik self-hosted, dosya tabanlı bir platformdur.