Yarım kalan işi yarım diye raporla

Kullanıcı ajana ay sonu işini veriyor: faturaları kes, müşterilere gönder, muhasebe tablosuna işle. Ajan faturaları kesiyor. Gönderimde üç e-posta geri dönüyor. Tabloya yazarken dosya başka birinde açık olduğu için yazma reddediliyor. Kullanıcının telefonuna düşen bildirim tek kelime: tamamlandı.

Ajan hataları görmüş olabilir, günlükte de yazıyor olabilir. Sorun raporun biçiminde. Bildirimin, görev listesindeki rozetin, e-posta konusunun ve son mesajın ilk satırının işin bir kısmının yapıldığını söyleyecek bir yeri yok. İki durum var, bitti ve bitmedi. Ajan adımların çoğunu bitirdiği için bitti diyor.

Yarım iş sistemi iki hâlin arasında bırakıyor. Faturalar kesildi ama üçü müşteriye ulaşmadı, muhasebede Ekim satırları boş. Kullanıcı bunu bilmeden ayı kapatıyor. Üç müşteri ödeme gününü kaçırıyor, finans ekibi eksik tabloyla rapor çıkarıyor. Adımların hiçbiri tek başına büyük bir hata değil. Zararı büyüten, kimsenin işin yarım kaldığını bilmemesi.

Kullanıcı yarım kaldığını bilmediği işi tamamlayamaz.

Rapor ekranı iki durumla tasarlanır: iş ya bitti ya bitmedi. Yarım iş bu ikisinin arasına düşer ve hangisine daha çok benziyorsa onun etiketini alır. Üç adımdan ikisi bitmişse etiket tamamlandı olur.

Model de aynı yöne iter. Son mesajı model yazar ve son mesaj işin hikâyesini kapatmaya çalışır. Ajan çıktılarını inceleyen bir çalışmada, ajanın bitti dediği ama ortamın aksini gösterdiği kayıtları ayırmaya çalışan LLM hakemleri ortamdaki değişikliği doğrulamak yerine kapanış cümlesinin kendinden emin tonuna¹ tutunuyor. Hakemi yanıltan ton okuru da yanıltabilir. “İşlem başarıyla tamamlandı” cümlesi günlükteki kırmızı satırdan önce okunur.

Üçüncü neden testte ve altyapıda. Ekipler ajanı iki uçta dener: her şeyin geçtiği yol ve servisin tamamen kapalı olduğu yol. Beş öğeden birinin düştüğü, ikinci adımın yarım kaldığı yol test listesine girmez. Altyapı da yarım işi kolayca yutar. GitHub Actions'ta hata verse de devam etsin diye işaretlenen bir adım düştüğünde adımın sonucu failure olur, ama adımın nihai hükmü success² olarak yazılır. Yalnız bu özet alanını okuyup raporuna taşıyan ajan hatayı hiç görmeden tamamlandı der.

Yarım iş üçüncü bir durum. Rapor bunu ilk satırda söyler, sonra neyin bittiğini, neyin kaldığını, sistemin nerede durduğunu ve kullanıcının ne yapacağını yazar. “Yaptım” demeden önce sonucu doğrula deseni sonucu ortamdan okumayı anlatıyor. Bu desen okunan sonucun rapora nasıl yazılacağını anlatıyor.

1. Başlığı adımlar belirler. Genel durumu kod hesaplar: bütün adımlar bittiyse tamamlandı, en az biri kaldıysa kısmen tamamlandı, hiçbiri olmadıysa tamamlanmadı. Bildirim, görev listesindeki rozet, e-posta konusu ve son mesajın ilk satırı aynı değeri taşır. Model başlığı seçmez, cümleleri kurar.
2. Dört durumu ayır. Her adım tamamlandı, başarısız, atlandı ya da iptal diye işaretlenir. Başarısız adım denendi ve olmadı. Atlanan adım hiç denenmedi, çünkü dayandığı adım olmadı. İkisini aynı çarpıyla göstermek kullanıcıya neyi yeniden denemesi gerektiğini söylemez.
3. Sayıyı ve listeyi ver. Toplu işte rapor “38 faturadan 35'i gitti” der ve kalan üçünü adıyla ve nedeniyle sıralar. “Çoğu gitti” ya da tek başına bir oran, kullanıcıya hangi üç müşteriyi araması gerektiğini söylemez.
4. Sistemin şimdiki hâlini yaz. Yarım iş bir ara hâl bırakır. Rapor neyin değiştiğini, neyin eski hâlinde kaldığını ve bu karışık hâlin neyi bozduğunu söyler: fatura kesildi ama müşteriye gitmedi, muhasebede Ekim boş.
5. Sıradaki hamleyi seçenek olarak koy. Kalanı yeniden dene, yapılanı geri al, olduğu gibi bırak. Her seçenek neye dokunacağını söyler. Yeniden deneme yalnız kalan öğeleri çalıştırır, 35 müşteriye ikinci fatura gitmez.
6. Hoş gördüğün hatayı da yaz. Ajan bir hatayı önemsiz sayıp devam ettiyse rapor bunu ayrı satırda gösterir. Önemsiz olup olmadığına kullanıcı karar verir.

Raporun verisini adımları çalıştıran kod yazar, model bu veriden cümle kurar. Başlık böylece modelin o günkü iyimserliğine bağlı kalmaz.

Aynı ay sonu işi, iki raporla. Soldakinde üçüncü adım hata vermiş, ama görev durumu ve son mesaj tamamlandı diyor. Sağdaki başlığı adımlardan hesaplıyor, gitmeyen üç faturayı ve tablonun hâlini yazıyor, yeniden denemeyi kalan öğelerle sınırlıyor.

Toplu işlem arayüzleri bu sorunu ajanlardan önce çözdü, çünkü binlerce isteği aynı anda gönderen biri “bitti” ile yetinemez. Anthropic'in toplu mesaj arayüzünde işin son durumu ended. Bu değer işin bittiğini söyler, başarılı olup olmadığını söylemez. O bilgi ayrı bir alanda durur: request_counts, isteklerin dört durumdan hangisine vardığını³ sayar (succeeded, errored, canceled, expired). Her isteğin kendi sonucu da ayrıca okunur.

Elasticsearch'ün toplu işlem ucu ters yönden aynı dersi veriyor. Cevap 200 koduyla gelir ve yalnız koda bakan istemci düşen işlemleri görmez. Cevabın en üstündeki errors alanı true ise işlemlerden en az biri başarısız⁴ olmuştur. Hangisi olduğu, gönderilen sırayla dizilmiş her işlemin kendi sonucunda yazar. Özet tek bir bayrak, ayrıntı öğe öğe.

Anthropic, uzun süren kodlama ajanlarıyla yaptığı denemelerde ajanın bazı özellikler bitince etrafa bakıp işin bittiğini ilan ettiğini⁵ yazıyor. Çözümleri işi bir özellik listesine bölmek. Her özelliğin passes alanı false ile başlıyor. Ajandan dosyada yalnız bu alanı değiştirmesi ve bir özelliği ancak dikkatli testten sonra geçti diye işaretlemesi isteniyor. Bir sonraki oturum işin nerede kaldığını bu listeden okuyor.

Laksh Advani'nin ICML 2026 çalıştayına kabul edilen çalışması bu durumu “yanlış başarı” diye adlandırıyor: ajan işi bitti diye bildiriyor, ortamın kaydı aksini gösteriyor. Çalışma 8 model ailesinden 9.876 tau2-bench kaydını ve 4 aileden 1.879 AppWorld kaydını inceliyor. Yalnız ajanın ortama yazabildiği havayolu ve perakende alanlarında yanlış başarı başarısızlıkların %45-48'i¹. Durumunu açıkça bildiren kodlama ajanlarının AppWorld kayıtlarında bu pay başarısızlıkların %75,8'i¹.

Aynı çalışmada ilginç bir ayrım var. Kullanıcı simülatörünün ortamın durumunu kendisi denetleyebildiği telekom alanında yanlış başarı başarısızlıkların %3'üne¹ iniyor. Yazar bunu nedensel bir bulgu saymıyor, elde böyle tek bir alan var. Yine de yön bu desenle aynı. Kullanıcının sistemin hâlini kendisinin görebildiği yerde ajanın raporu gerçekten daha az uzaklaşıyor.

Anthropic'in kodlama ajanı denemesi aynı eğilimi başka bir yerden gösteriyor. Ajan iki yerde erken davrandı: bir kısmı bitince bütün projeyi bitti saydı⁵ ve tek tek özellikleri test etmeden geçti diye işaretledi. Anthropic'in çözümü ikisinde de durumu öğe öğe, ajanın serbest metninin dışında bir dosyada tutmak oldu.

Bu ölçümler benzetilmiş müşteri hizmetleri ve uygulama görevlerinde yapıldı, yarım kalan işi ayrıca saymıyor ve senin ürünündeki oranı söylemez. Gösterdikleri şu: ajanın kapanış cümlesi ile ortamın kaydı sık sık ayrışıyor ve kapanış cümlesine bakan hakem bu ayrışmayı kaçırıyor. Raporun başlığını ortamın kaydından hesaplamanın gerekçesi bu.

Tamamlanma oranı bu desenin çalışıp çalışmadığını söylemez. Bakılacak yer raporun başlığı ile adımların gerçek durumu arasındaki fark.

• Başlık ile adımların uyuşmazlığı. Günlükten, en az bir adımı başarısız ya da atlanmış olduğu hâlde başlığı ya da bildirimi “tamamlandı” olan raporları say. Başlık koddan hesaplanıyorsa bu sayı sıfır olmalı.
• Kısmi rapor payı. Raporların ne kadarı “kısmen tamamlandı” diyor? Sıfıra yakınsa sevinme. Ya işler hiç yarım kalmıyor ya da rapor yarımı saklıyor. Günlükteki adım hatalarıyla karşılaştır.
• Çift işlem. “Kalanı yeniden dene”den sonra ikinci kez işlenen başarılı öğeleri say: ikinci kez giden e-posta, ikinci kez açılan kayıt. Hedef sıfır.
• Sonradan öğrenilen yarım iş. Kullanıcı yarım kalan işi rapordan mı öğreniyor, yoksa sonradan bir müşteri şikâyetinden ya da destek talebinden mi? İkincisinin payı düşmeli.

Üç metin var. Denetim promptu ürünündeki ajanın rapor, bildirim ve durum alanlarını tarar, genel durumun nasıl hesaplandığını ve kısmi başarısızlıkta kullanıcının ne gördüğünü yazar, hiçbir dosyayı değiştirmez. Uygulama promptu adım durumlarını koda geçirir, başlığı bu durumlardan hesaplar ve beş öğeden birini bilerek bozan bir testle yeniden denemenin yalnız kalan öğeyi çalıştırdığını doğrular. Kural kodlama ajanının kendi raporları için. Senin ajanın da yarım işi yarım diye yazsın.

Bu depoda kullanıcı adına çok adımlı ya da çok öğeli iş yapan bir AI ajanı ya da otomasyon var. Görevin, iş kısmen başarısız olduğunda kullanıcıya giden raporun bunu doğru söyleyip söylemediğini denetlemek. Hiçbir dosyayı değiştirme, yalnız rapor yaz.

1. Ajanın işi bitirince kullanıcıya rapor, bildirim, e-posta ya da durum rozeti ürettiği yerleri bul: son mesaj şablonu, görev durumu alanı, bildirim metni, görev listesindeki rozet.
2. Genel durum ("tamamlandı", "başarısız" gibi) nasıl belirleniyor? Adımların durumundan kodla mı hesaplanıyor, yoksa modelin yazdığı metinden mi geliyor? Bir adım başarısız olduğunda bu alan hangi değeri alıyor?
3. Adım ve öğe düzeyinde durum tutuluyor mu? "başarılı", "başarısız", "atlandı" (hiç denenmedi) ve "iptal" ayrı değerler mi, yoksa yalnız başarılı ve başarısız mı var? Yakalanıp yutulan ya da "hata verse de devam et" diye geçilen adımlar raporda görünüyor mu?
4. Toplu işlerde (e-posta, kayıt, dosya) raporda sayı var mı: kaç öğe işlendi, kaç öğe kaldı, kalanların kimliği ve nedeni ne?
5. Rapor sistemin şimdiki hâlini söylüyor mu: neyin değiştiği, neyin eski hâlinde kaldığı, yarım kalan işin bıraktığı tutarsızlık?
6. "Yeniden dene" yolu var mı, yalnız başarısız öğeleri mi yeniden çalıştırıyor? Başarılı öğelerin ikinci kez işlenme riski (çift e-posta, çift kayıt) var mı? İşlemler tekrar edilebilir (idempotent) mi?

Rapor biçimi: her bulgu için dosya ve satır, ne olduğu, kısmi başarısızlıkta kullanıcının ne gördüğü (örnek: üç adımdan biri düştüğü hâlde bildirim "tamamlandı" diyor) ve önerdiğin düzeltme. Bulguları kullanıcıyı en çok yanlış karara götürenden başlayarak sırala.

Bu depodaki AI ajanına "yarım kalan işi yarım diye raporla" desenini uygula. Önce planı göster, onayımı aldıktan sonra kodu değiştir.

Hedef davranış:
1. Her adım ve her öğe için durumu kodla tut: başarılı, başarısız, atlandı (dayandığı adım olmadığı için denenmedi), iptal (kullanıcı durdurdu). Başarısız ve atlanan için kısa bir neden sakla.
2. Genel durumu adımlardan hesapla, modele seçtirme: hepsi başarılıysa "tamamlandı", en az biri başarısız ya da atlandıysa "kısmen tamamlandı", hiçbiri başarılı değilse "tamamlanmadı". Bildirim, görev listesindeki rozet, e-posta konusu ve son mesajın ilk satırı aynı değeri kullansın.
3. Raporu dört parçayla kur: başlık (hesaplanan durum ve sayılar), adım listesi (her adımın durumu, sayısı, nedeni), sistemin şimdiki hâli (ne değişti, ne eski hâlinde kaldı, yarım işin bıraktığı tutarsızlık), sıradaki seçenekler.
4. Toplu işte sayıyı ve kalan öğelerin listesini ver ("50 öğeden 47'si"). "Çoğu" ya da tek başına oran yazma.
5. "Kalanı yeniden dene" seçeneği yalnız başarısız ve atlanan öğeleri çalıştırsın. Başarılı öğeleri tekrar çalıştırma.
6. Ajanın bilerek geçtiği hatalar ("hata verse de devam et" denen adımlar) raporda ayrı satırda görünsün.

Uygularken:
- Durumu modelin serbest metninden ayrıştırma. Adımı çalıştıran kod durumu kendisi yazar, model raporun cümlelerini bu veriden kurar.
- Mevcut rapor şablonunu ve bildirim metinlerini bul, hepsini aynı hesaplanan duruma bağla.
- Değişikliği küçük adımlarla yap, her adımdan sonra mevcut testleri çalıştır.
- Bir test ekle: üç adımlı bir işte ikinci adımın beş öğesinden birini bilerek başarısız kıl. Raporun başlığının "kısmen tamamlandı" dediğini, başarısız öğenin adını ve nedenini gösterdiğini ve "yeniden dene"nin yalnız o öğeyi çalıştırdığını doğrula.

## Yarım kalan işi yarım diye raporla
- Çok adımlı bir işi raporlarken her adımın durumunu yaz: tamamlandı, başarısız, atlandı (hiç denenmedi) ya da iptal.
- Bir adım bile başarısız ya da atlandıysa raporun ilk satırına "tamamlandı" yazma. "Kısmen tamamlandı" de ve sayıyı ver.
- Toplu işte kaç öğenin bittiğini ve kalan öğelerin listesini ver. "Çoğu bitti" yazma.
- Sistemin şimdiki hâlini söyle: neyi değiştirdin, ne eski hâlinde kaldı, yarım iş neyi tutarsız bıraktı.
- Kullanıcının sıradaki seçeneklerini yaz. Yeniden denemeyi yalnız kalan öğelerle sınırla, biten öğeleri tekrarlama.
- Görmezden gelip geçtiğin bir hata varsa onu da ayrı satırda yaz.

Tek adımlı ve tek öğeli işte bu yapı gereksiz. Başarılı ya da başarısız yeter.

Adım listesi raporu boğabilir. Kullanıcıya iş birimlerini göster (faturalar, e-postalar, tablo), her araç çağrısını gösterme. Araç çağrıları günlükte kalsın.

“Kısmen tamamlandı” da bir şey saklayabilir. Yüz öğeden birinin kalması ile doksan dokuzunun kalması aynı etiketi alır. Etiketin yanında sayı yoksa kullanıcı yine tahmin eder.

Bu desen yarım işi görünür kılar, geri almaz. Yarım kalan işi geri almak ayrı bir tasarım işi ve her işlem geri alınamaz. Giden e-posta geri gelmez, yeniden denemenin onu ikinci kez göndermemesi bu yüzden önemli.