Yapay Zekâ Ajanlarında Doğrulama Döngüsü: Hatasını Görüp Düzelten Sistemler Tasarlamak

Bir yapay zekâ ajanı raporu hazırladı, dosyayı güncelledi veya müşteriye gönderilecek taslağı oluşturdu. Ardından da güven veren bir cümle kurdu: “Görev başarıyla tamamlandı.” Peki bunu nereden biliyor?

Ajanın işi yaptığına dair açıklaması, işin gerçekten doğru yapıldığının kanıtı değildir. Üstelik sorun yalnızca modelin yanlış bilgi üretmesi de değildir. Doğru metni yanlış müşteri dosyasına yazabilir, çalışan kodu eski sürüme ekleyebilir, güncel olmayan verilerle kusursuz görünen bir rapor hazırlayabilir. Bir adımı başarıyla tamamlayıp bütün görevin bittiğini sanabilir.

Bu nedenle güvenilir bir ajan, yalnızca “düşün ve eyleme geç” döngüsüyle kurulmaz. Eylemin dünyada oluşturduğu yeni durumu gözlemleyen, beklenen sonuçla karşılaştıran, hatayı sınıflandıran ve güvenli olduğunda düzelten bir doğrulama döngüsüne ihtiyaç duyar.

Bu yazıda doğrulamayı sonradan yapılan bir kalite kontrolü olarak değil, ajanın çalışma biçiminin merkezi olarak ele alacağız. Önce döngünün teorisini kuracak, ardından içerik üretimi, yazılım geliştirme ve müşteri operasyonları gibi gerçek işlere uygulayacağız. Sonunda kendi ajanınız için kullanabileceğiniz küçük bir doğrulama sözleşmesi çıkaracağız.

Doğrulama döngüsü nedir?

Doğrulama döngüsü, ajanın gerçekleştirdiği bir eylemin sonucunu bağımsız kanıtlarla sınaması ve çıkan sonuca göre ilerlemesi, düzeltme yapması ya da durmasıdır. En sade hâliyle şöyle işler:

Hedefi ve başarı koşullarını oku
↓
Eylemi gerçekleştir
↓
Gerçek durumu yeniden gözlemle
↓
Kanıtları başarı koşullarıyla karşılaştır
↓
Geçti mi?
├─ Evet → Sonraki adıma geç veya tamamla
└─ Hayır → Hatayı sınıflandır
           ├─ Güvenle düzeltilebilir → Düzelt ve yeniden doğrula
           └─ Belirsiz / riskli → Dur ve insana bildir

Buradaki kritik ayrım, ajanın kendi cevabını yeniden okuyup “evet, iyi görünüyor” demesiyle gerçek doğrulama arasındadır. İlkinde aynı sistem kendi iddiasını değerlendirir. İkincisinde ise iddia, görevden mümkün olduğunca bağımsız bir kanıtla karşılaştırılır.

Örneğin bir ajan “12 faturayı işledim” diyorsa kanıt, ajanın yazdığı özet değildir. Kaynak klasörde 12 uygun fatura bulunması, çıktı tablosunda 12 benzersiz kayıt oluşması, toplam tutarın yeniden hesaplanması ve hata günlüğünde işlenmemiş dosya kalmaması daha güçlü kanıtlardır.

Doğrulama, ajana “Emin misin?” diye sormak değil; ona “Hangi gözlenebilir kanıt bu işin doğru tamamlandığını gösteriyor?” diye sormaktır.

Neden tek bir son kontrol yetmez?

Bir görevi yalnızca sonunda kontrol etmek, uzun bir matematik işleminin sadece son rakamına bakmaya benzer. Sonuç yanlışsa hatanın nerede başladığını bilemezsiniz. Daha kötüsü, ara adımlardaki bir hata sonraki eylemleri de yanlış yöne sürükleyebilir.

Bir müşteri destek ajanını düşünelim. Ajan önce müşteriyi buluyor, sonra siparişi seçiyor, iade koşullarını değerlendiriyor ve mesaj hazırlıyor. Yanlış müşteriyi seçtiyse son mesajın dil bilgisi, tonu ve iade politikası kusursuz olabilir; fakat bütün işlem yanlış kişi üzerinde yürümüştür.

Bu nedenle doğrulama yalnızca görevin sonunda değil, geri dönüşü pahalı veya riskli kararların hemen ardından yapılmalıdır. Her küçük adımı kontrol etmek sistemi yavaşlatır; yalnızca finali kontrol etmek ise hatanın büyümesine izin verir. İyi tasarım, kontrol noktalarını riskin yükseldiği yerlere koyar.

Pratik karar kuralı şudur: Bir hata sonraki adımları zehirleyebiliyorsa, dış dünyada geri alınması zor bir sonuç üretiyorsa veya hassas veriyle ilgiliyse o adım ayrı bir doğrulama kapısı hak eder.

Döngünün beş temel parçası

1. Gözlenebilir bir başarı tanımı

“İyi bir rapor hazırla” doğrulanabilir değildir. “Son 30 günün satışlarını bölgelere göre özetle; toplamları kaynak tabloyla eşleştir; eksik verileri ayrı bölümde belirt; PDF taslağı oluştur fakat gönderme” daha iyi bir görev tanımıdır. Çünkü başarı, gözlenebilir koşullara ayrılmıştır.

İyi bir başarı tanımı üç tür koşul içerir:

• Varlık koşulları: Hangi çıktıların oluşması gerekiyor?
• Doğruluk koşulları: Değerler hangi kaynak veya kuralla eşleşmeli?
• Yasaklar: Ajan ne yapmamalı?

Küçük bir alıştırma yapalım. Düzenli verdiğiniz bir görevi seçin ve “tamamlandı” kelimesini kullanmadan başarıyı tanımlayın. Örneğin “toplantı notları tamamlandı” yerine şunu yazabilirsiniz: “Kararlar, sorumlular ve tarihler ayrı alanlarda yer alıyor; sorumlusu olmayan maddeler belirsiz olarak işaretleniyor; katılımcılara hiçbir mesaj gönderilmiyor.”

2. Eylemden sonra yeniden gözlem

Ajanlar bazen araç çağrısının başarılı olmasını iş sonucunun başarılı olmasıyla karıştırır. Bir dosya yazma aracı hata vermemiş olabilir; fakat dosya yanlış dizine kaydedilmiş, boş kalmış veya başka bir değişiklik tarafından üzerine yazılmış olabilir.

Bu yüzden eylemden sonra ajanın hafızasındaki niyete değil, dünyanın yeni hâline bakması gerekir. Dosyayı yazdıysa tekrar okumalı, veritabanını güncellediyse ilgili kaydı yeniden sorgulamalı, form doldurduysa kaydedilen değerleri ekrandan veya sistem yanıtından kontrol etmelidir.

Burada kullanışlı bir tasarım ilkesi vardır: Yazdıktan sonra oku; değiştirdikten sonra karşılaştır; göndermeden önce önizle. Bu üçlü, basit görünse de birçok operasyon hatasını erken yakalar.

3. İddiadan bağımsız kanıt

Modelin ürettiği bir özeti yine aynı metne bakarak değerlendirmesi yararlı olabilir, fakat güçlü bir doğrulama sayılmaz. Çünkü ilk hataya yol açan eksik bağlam veya yanlış varsayım ikinci değerlendirmede de devam edebilir.

Kanıtın gücü, doğrulanan iddiadan ne kadar bağımsız olduğuyla artar. Bir hesaplamayı doğal dille tekrar düşünmek yerine hesap makinesiyle yeniden yapmak; kodu açıklatmak yerine test çalıştırmak; kaynaklı bir yazıyı akıcılık açısından değerlendirmek yerine iddiaları kaynak belgelerle eşleştirmek daha güçlüdür.

Bu, her görev için ikinci bir yapay zekâ modeli gerektiği anlamına gelmez. Çoğu zaman en iyi denetçiler deterministik araçlardır: şema kontrolü, toplam hesabı, dosya karşılaştırması, bağlantı denetimi, zorunlu alan kontrolü veya izin listesi.

4. Hata sınıflandırması

Her başarısız kontrol aynı tepkiyi gerektirmez. Ajanın önce hatanın türünü anlaması gerekir:

• Biçim hatası: Zorunlu alan eksik, tarih yanlış biçimde veya çıktı şemaya uymuyor.
• İçerik hatası: Hesap yanlış, iddia kaynaksız veya talimatın bir bölümü atlanmış.
• Bağlam hatası: Ajan yanlış dosyayı, müşteriyi, sürümü ya da zaman aralığını kullanmış.
• Araç hatası: Yetki, bağlantı, kota veya zaman aşımı sorunu yaşanmış.
• Belirsizlik: Kaynaklar çelişiyor ya da doğru karar için bilgi eksik.
• Yetki sınırı: Teknik olarak mümkün olan eylem, ajana verilmiş izinlerin dışında.

Biçim hatası çoğunlukla otomatik düzeltilebilir. Belirsizlik ise yeni bir denemeyle ortadan kalkmayabilir. Ajanın aynı eksik bilgiyle tekrar tekrar karar üretmesi, yalnızca hatayı daha pahalı hâle getirir.

5. Durma ve yükseltme koşulu

Doğrulama döngüsünün amacı ajanı sonuç doğru olana kadar sınırsızca çalıştırmak değildir. Bazı hatalar tekrar denemeyle düzelmez; bazılarıysa her denemede yeni risk doğurur. Bu nedenle döngünün başlamadan önce bir bütçesi olmalıdır.

Basit bir politika şöyle yazılabilir:

• Aynı biçim hatası için en fazla iki düzeltme denemesi yap.
• Aynı kontrol iki kez başarısız olursa yeni bir strateji dene veya dur.
• Kaynaklar çelişiyorsa tahmin yürütme; çelişkiyi raporla.
• Para, hukuki taahhüt, erişim yetkisi veya dış iletişim içeren eylemden önce insan onayı iste.
• Her denemede aynı iki durum arasında gidip geliyorsan döngüyü kes.

Son madde özellikle önemlidir. Ajan bir metni kısaltıp “ayrıntı eksik” kontrolünden kalabilir, sonra uzatıp “kelime sınırı aşıldı” kontrolünden kalabilir. Bu bir ilerleme değil, salınımdır. Sistem önce iki koşulu birlikte karşılayacak yeni bir çözüm aramalı; bulamıyorsa çatışmayı insana göstermelidir.

Doğrulama döngüsü ile yeniden deneme aynı şey değildir

Bir araç hata verdiğinde aynı çağrıyı tekrarlamak bazen yeterlidir. Geçici bağlantı sorunu ortadan kalkabilir. Fakat düşünsel veya yapısal bir hata karşısında aynı işlemi aynı bağlamla tekrarlamak çoğu zaman aynı sonucu üretir.

İyi bir döngüde her yeni denemenin bir gerekçesi vardır. Ajan şu dört soruya cevap verebilmelidir:

1. Hangi kontrol başarısız oldu?
2. Muhtemel neden nedir?
3. Yeni denemede ne değişecek?
4. Başarılı olduğunu hangi kanıt gösterecek?

Bu sorulardan üçüncüsüne cevap verilemiyorsa tekrarın değeri düşüktür. “Bir kez daha deneyeyim” strateji değildir. “Kaynak tabloyu yanlış filtrelediğim için tarih aralığını düzelterek toplamı yeniden hesaplayacağım” ise test edilebilir bir düzeltme planıdır.

Gerçek hayat uygulaması: Haftalık satış raporu hazırlayan ajan

Şimdi bütün parçaları tek bir senaryoda birleştirelim. Bir e-ticaret ekibi, her pazartesi bölgelere göre satış raporu hazırlayan bir ajan kullanıyor olsun. Ajanın görevi verileri toplamak, geçen haftayla karşılaştırmak, dikkat çeken değişimleri açıklamak ve bir yönetici özeti hazırlamaktır.

Birinci aşama: Girdiyi doğrulama

Ajan önce rapor dönemini ve veri kaynağını kontrol eder. “Geçen hafta” ifadesini kendi yorumuna bırakmaz; başlangıç ve bitiş tarihlerini açıkça hesaplar. Para birimini, saat dilimini ve iptal edilen siparişlerin dahil edilip edilmeyeceğini doğrular.

Kontrol örneği: Kaynak sistemin döndürdüğü en erken ve en geç kayıt tarihleri istenen aralıkla uyuşuyor mu? Beklenen bölge listesinde eksik değer var mı? Veri boşsa bunu “satış yok” diye mi, yoksa “veri alınamadı” diye mi yorumlamak gerekiyor?

İkinci aşama: Hesapları doğrulama

Ajan bölgesel toplamları üretir. Ardından bu toplamların birleşiminin genel satış toplamıyla eşleşip eşleşmediğini bağımsız olarak hesaplar. Fark varsa rapor yazmaya geçmez. Yuvarlama, mükerrer kayıt veya filtreleme hatasını araştırır.

Buradaki doğrulama kuralı açık olabilir: “Bölgesel toplamlarla genel toplam arasındaki açıklanamayan fark sıfır olmalı.” Finansal bağlama göre küçük yuvarlama farkları kabul edilecekse tolerans da önceden belirtilmelidir; ajan kendi başına uygun tolerans uydurmamalıdır.

Üçüncü aşama: Açıklamaları doğrulama

Satışların yüzde 18 arttığını hesaplamak başka, neden arttığını söylemek başkadır. Ajan kampanya verisini görmeden “başarılı reklam çalışması satışları yükseltti” diyemez. Burada doğrulama, sayısal sonuç ile nedensel yorum arasındaki sınırı korur.

Kanıt yoksa doğru ifade şuna benzer: “Satışlar önceki haftaya göre arttı; mevcut veriler artışın nedenini belirlemek için yeterli değil.” Bu cümle daha az heyecanlı olabilir ama operasyonel olarak daha güvenilirdir.

Dördüncü aşama: Çıktıyı ve yetkiyi doğrulama

Rapor hazırlandıktan sonra ajan zorunlu bölümleri, tarihleri ve toplamları yeniden kontrol eder. Dosyanın açıldığını ve doğru klasörde bulunduğunu doğrular. Fakat görev yalnızca taslak hazırlamayı kapsıyorsa raporu yöneticilere göndermez. Başarılı doğrulama, yetki sınırını ortadan kaldırmaz.

Son rapor şu kanıt paketiyle teslim edilebilir:

• Kullanılan veri kaynağı ve rapor tarihleri,
• işlenen ve hariç tutulan kayıt sayıları,
• toplamların eşleşme sonucu,
• karşılanamayan veya uyarı üreten kontroller,
• oluşturulan taslağın konumu,
• gönderim yapılmadığı bilgisi.

Böylece yönetici yalnızca raporu değil, rapora güvenmek için gereken izi de teslim alır.

Farklı işlerde doğrulama nasıl değişir?

İçerik üretiminde

İçerik ajanı için dil bilgisi kontrolü tek başına yeterli değildir. Başlık ile içerik uyumu, zorunlu bölümler, iddiaların kaynak desteği, alıntıların doğruluğu, bağlantıların çalışması ve yayın yetkisi ayrı kontrollerdir. “Metin akıcı” değerlendirmesi öznel olabilir; fakat “içerikte başlık alanı tekrar edilmiş mi?” veya “her dış kaynak yapılandırılmış kaynak listesinde mevcut mu?” gibi kontroller nettir.

Yazılım geliştirmede

Kodun derlenmesi, gereksinimin karşılandığını kanıtlamaz. Bir geliştirme ajanı önce ilgili testleri çalıştırabilir, sonra değişen davranış için yeni test ekleyebilir, ardından daha geniş regresyon testlerine geçebilir. Fakat testlerin geçmesi de yanlış dosyanın değişmediğini veya hassas bilginin günlüğe yazılmadığını garanti etmez. Değişiklik özeti, kapsam karşılaştırması ve güvenlik kontrolleri ayrı kanıtlar üretir.

Müşteri iletişiminde

En önemli ayrım taslak oluşturmak ile mesaj göndermektir. Ajan hitabı, sipariş numarasını, tutarı ve politikaya uygunluğu kontrol edebilir. Ancak düşük riskli, önceden onaylanmış bir şablon dışında gönderim için insan onayı gerekebilir. Burada doğrulama döngüsü doğru içeriği üretirken yetki modeli yanlış alıcıya veya geri alınamaz bir taahhüde karşı koruma sağlar.

Kendi doğrulama sözleşmenizi hazırlayın

Doğrulama sözleşmesi, ajana verilen uzun bir “dikkatli ol” öğüdü değildir. Görevin hangi kanıtlarla kabul edileceğini, hangi hataların otomatik düzeltilebileceğini ve ajanın hangi sınırda duracağını baştan belirleyen küçük bir çalışma anlaşmasıdır. En kullanışlı sözleşmeler, görevin kendisinden önce hazırlanır; çünkü başarı ölçütünü çıktı geldikten sonra seçmek, hedef tahtasını ok atıldıktan sonra taşımaya benzer.

Sözleşmeyi yazarken görevi tek parça hâlinde düşünmeyin. Önce çıktıyı, sonra doğruluğu, ardından yetki sınırını ve son olarak hata davranışını tanımlayın. Her maddeyi gözlenebilir bir koşula çevirin. “Rapor doğru olsun” yerine hangi kaynakla karşılaştırılacağını; “gerekirse düzelt” yerine hangi hata için kaç kez yeniden deneneceğini yazın.

Doldurulmuş örnek: Haftalık satış raporu

Aşağıdaki sözleşme, yazı boyunca kullandığımız satış raporu senaryosunun çalışır bir örneğidir. Buradaki amaç metni olduğu gibi kopyalamak değil, her alanın ne kadar somut olması gerektiğini göstermektir.

GÖREV:
1-7 Temmuz dönemindeki tamamlanmış siparişleri kullanarak
bölgelere göre haftalık satış raporu taslağı hazırla.
Raporu oluştur fakat hiçbir alıcıya gönderme.

BAŞARI KOŞULLARI:
- Rapor dönemi 1 Temmuz 00.00 ile 7 Temmuz 23.59 arasındadır.
- Yalnızca “tamamlandı” durumundaki siparişler hesaba katılır.
- Bölgesel satış toplamlarının toplamı, genel satış toplamına eşittir.
- Önceki haftayla değişim hem tutar hem yüzde olarak gösterilir.
- Veriden kanıtlanamayan nedenler olgu gibi yazılmaz.
- Yönetici özeti, bölgesel tablo ve veri kalitesi notu raporda bulunur.
- PDF taslağı doğru klasörde oluşturulur ve yeniden açılabilir.

YASAK EYLEMLER:
- Raporu e-posta, mesajlaşma aracı veya başka bir kanalla gönderme.
- Eksik veriyi sıfır satış olarak yorumlama.
- Kampanya, mevsimsellik veya ekip performansı hakkında kanıtsız
  nedensel açıklama üretme.
- Kaynak sipariş kayıtlarını değiştirme.

KRİTİK EYLEMLERDEN SONRA OKUNACAK GERÇEK DURUM:
- Filtrelemeden sonra en erken ve en geç sipariş tarihini yeniden oku.
- Hesaplamadan sonra bölgesel ve genel toplamları ayrı sorgularla al.
- Dosya oluşturulduktan sonra dosyayı yeniden aç ve zorunlu bölümleri kontrol et.
- Teslimden önce gönderim günlüğünde bu rapora ait işlem olmadığını doğrula.

KULLANILACAK BAĞIMSIZ KANITLAR:
- Kaynak sistemdeki sipariş durumu ve tarih alanları.
- Genel toplam için bölgesel hesaplamadan ayrı bir toplam sorgusu.
- Önceki hafta için aynı filtre kurallarıyla alınmış karşılaştırma sonucu.
- PDF dosyasının açılabildiğini gösteren dosya okuma kontrolü.
- Gönderim yapılmadığını gösteren işlem günlüğü.

OTOMATİK DÜZELTİLEBİLEN HATALAR:
- Eksik başlık, yanlış tarih biçimi ve tablo sütunu sıralaması.
- PDF oluşturma sırasında oluşan geçici biçim bozukluğu.
- Yuvarlama yönteminden kaynaklandığı açıkça kanıtlanan gösterim farkı.

HEMEN DURMAYI GEREKTİREN DURUMLAR:
- Kaynak sistemde aynı sipariş kimliği birden fazla kez görünüyorsa.
- Bölgesel toplam ile genel toplam arasındaki farkın nedeni bulunamıyorsa.
- Rapor döneminin bir bölümüne ait veriler alınamıyorsa.
- Para birimi bilgisi eksik veya kayıtlar arasında çelişkiliyse.
- Gönderim ya da kaynak veriyi değiştirme talebiyle karşılaşılırsa.

EN FAZLA DENEME / MALİYET / SÜRE:
- Biçim hataları için en fazla iki otomatik düzeltme yap.
- Veri sorgusundaki geçici araç hatasını en fazla iki kez yeniden dene.
- Aynı doğrulama ikinci kez başarısız olursa döngüyü durdur.
- Toplam çalışma süresi 15 dakikayı aşarsa mevcut kanıtlarla birlikte
  insana bildir.

İNSAN ONAYI GEREKTİREN EYLEMLER:
- Raporun herhangi bir kişiye gönderilmesi.
- Açıklanamayan veri farkına rağmen raporun kabul edilmesi.
- Eksik bölge verisiyle tahmini değer üretilmesi.
- Daha önce onaylanmamış bir veri kaynağının kullanılması.

TESLİM EDİLECEK KANIT PAKETİ:
- Kullanılan veri kaynağı ve kesin tarih aralığı.
- İşlenen, hariç tutulan ve hatalı kayıt sayıları.
- Bölgesel toplam, genel toplam ve aralarındaki fark.
- Geçen haftaya göre değişim hesabı.
- Geçen, başarısız olan ve uyarı veren kontroller.
- Oluşturulan PDF taslağının konumu.
- Hiçbir gönderim yapılmadığına ilişkin kayıt.

Bu örnekte dikkat edilmesi gereken nokta, sözleşmenin yalnızca “iyi çıktı”yı tarif etmemesidir. Yanlış veya eksik bir durumla karşılaşıldığında ajanın nasıl davranacağını da belirler. Örneğin para birimi çelişkisi, daha güzel bir metin yazarak çözülemez; bu nedenle otomatik düzeltme değil, durma koşuludur. Buna karşılık eksik bir tablo başlığı düşük riskli ve kolayca sınanabilir olduğu için ajan tarafından düzeltilebilir.

Kendi görevinize uyarlamak için dört adım

1. Tekrarlanan bir görev seçin. İlk sözleşmeniz için şirketin en karmaşık sürecini değil, haftalık rapor hazırlama, toplantı notlarını düzenleme veya içerik taslağı çıkarma gibi sınırları görülebilen bir işi seçin.
2. Başarısızlığın maliyetini düşünün. Yanlış sonuç yalnızca yeniden çalışma mı doğurur, yoksa müşteriye yanlış mesaj, para kaybı veya veri değişikliği mi yaratır? Maliyet yükseldikçe kontrol kapısı ve insan onayı ekleyin.
3. Her başarı koşuluna bir kanıt bağlayın. Koşul “toplamlar eşleşiyor” ise kanıt ayrı hesaplamadır. Koşul “doğru müşteriye ait” ise kanıt ad değil, benzersiz müşteri ve sipariş kimliklerinin eşleşmesidir.
4. Düzeltme ile durmayı ayırın. Biçim, sıralama ve geçici bağlantı sorunları sınırlı sayıda yeniden denenebilir. Çelişkili kaynak, eksik yetki ve geri alınamaz dış eylem ise insana yükseltilmelidir.

Sözleşmenizi bitirdiğinizde her maddeye şu testi uygulayın: “Görevi hiç görmemiş bir kişi yalnızca kayıtlara ve kanıtlara bakarak bu koşulun geçip geçmediğine karar verebilir mi?” Cevap hayırsa ölçüt hâlâ fazla belirsizdir. “Kaliteli”, “uygun” ve “mantıklı” gibi kelimeleri silmek zorunda değilsiniz; fakat bunların yanına kararın hangi somut özelliklere dayanacağını eklemelisiniz.

Son bir kontrol daha yapın: Sözleşmenin kendi içinde çatışan talepleri var mı? Örneğin hem “hiçbir ayrıntıyı atlama” hem de “en fazla 100 kelime yaz” diyorsanız ajan iki koşul arasında gidip gelebilir. Böyle bir çatışmada hangi koşulun öncelikli olduğunu baştan yazın. Doğrulama sözleşmesi yalnızca ajanı denetlemez; bizim görev tanımımızdaki belirsizlikleri de görünür kılar.

Sonuç: Güven, döngünün ürettiği kanıttır

Yapay zekâ ajanlarını güvenilir kılan şey, ilk denemede hiç hata yapmamaları değildir. Gerçek sistemlerde veri eksik olur, araçlar hata verir, talimatlar çatışır ve dünya görev sürerken değişebilir. Güvenilirlik; ajanın bu sorunları görünür kılması, güvenli olanları kontrollü biçimde düzeltmesi ve karar veremediği yerde durabilmesidir.

İyi bir doğrulama döngüsü dört davranış üretir: Ajan yaptığı eylemin sonucunu yeniden görür, iddiasını bağımsız kanıtla sınar, başarısızlığı anlamlı biçimde sınıflandırır ve her hatayı körlemesine tekrar etmek yerine doğru durma kararını verir.

Başlangıç için bütün iş akışınızı yeniden kurmanız gerekmiyor. Tek bir sık kullandığınız görevi seçin. Başarı koşullarını yazın, en riskli iki adımı bulun ve bu adımların ardından okunabilecek gerçek kanıtları belirleyin. Son olarak, ajanın hangi durumda kendi başına düzelteceğini ve hangi durumda size geleceğini açıkça tanımlayın.

Bir ajan “iş bitti” dediği için değil, işin bittiğini gösterebildiği ölçüde güvenilirdir. Doğrulama döngüsü tam olarak bu gösterme kapasitesini tasarlar.