Bir ajan doğru kimliği çözmüş olabilir.
Güncel ve kanonik bilgiye dayanmış olabilir.
Kullanıcının ihtiyacına gerçekten uygun seçeneği belirlemiş olabilir.
Geçerli rıza, yetki ve onay da bulunabilir.
Bütün bunlara rağmen eylem yine yanlış gerçekleşebilir.
Çünkü:
Doğru karar, doğru yürütmenin garantisi değildir.
Ajan doğru müşteri adresini bulabilir; fakat yalnız CRM kaydını güncelleyip sevkiyat sistemini eski bırakabilir.
Doğru iade tutarını hesaplayabilir; fakat ödemeyi başka müşterinin siparişine uygulayabilir.
Bir API’den HTTP 200 cevabı alabilir; fakat yöntem ve API sözleşmesine göre başarılı işlenen isteğin gerçek dünya sonucunun henüz tamamlanmadığını gözden kaçırabilir.
Ağ yanıtı geciktiğinde aynı ödemeyi ikinci kez gerçekleştirebilir.
Altı dilin beşini yayımlayıp bütün yayını tamamlanmış sayabilir.
Dosya aktarım aracının “başarılı” mesajına güvenip canlı sistemde gerçekten ne bulunduğunu kontrol etmeyebilir.
İşlemin hangi noktadan sonra geri alınamayacağını anlamadan ilerleyebilir.
Basit bir görev için gereğinden fazla kişisel, ticari veya gizli veri kullanabilir.
Ve bütün bunların sonunda ne yaptığını, kimin adına yaptığını ve hangi kanıta dayandığını gösteren hiçbir kayıt bırakmayabilir.
Araç kullanmak yalnızca bir komut çalıştırmak değildir.
Her eylem en az şu soruları taşır:
Hangi sistem üzerinde? Hangi hedefe? Hangi veriyle? Kaç kez? Hangi tamamlanma koşuluyla? Hangi bağımsız doğrulamayla? Hangi geri dönüş imkânıyla? Hangi kayıt altında?
Bu bölümdeki dokuz hata, geçerli yetkinin yanlış sistem, yanlış hedef, yanlış başarı yorumu veya eksik yürütme disiplini nedeniyle bozulmasını inceler.
GBO-ERR-046 — Doğru İşlemi Yanlış Sistemde Uygulamak
Kısa olay
Bir müşteri, henüz kargoya verilmemiş siparişinin teslimat adresini değiştirmek ister.
Müşteri hizmetleri ajanına şu talimatı verir:
“Siparişimi yeni ofis adresime gönderin. Eski adrese artık erişimim yok.”
Ajan müşterinin kimliğini doğrular.
Yeni adresi eksiksiz biçimde alır.
CRM sistemindeki müşteri kartını açar ve adresi günceller.
Ardından müşteriye şu cevabı verir:
“Teslimat adresiniz başarıyla değiştirildi.”
Fakat sipariş hazırlanırken teslimat adresi CRM’den değil, sipariş yönetim sistemindeki ayrı bir kayıttan alınmaktadır.
CRM’de yeni adres görünür.
Sevkiyat sistemi eski adresi taşımaya devam eder.
Paket müşterinin artık erişemediği adrese gönderilir.
Ajan doğru bilgiyi doğru müşteri için kullanmıştır.
Ancak değişikliği davranışı gerçekten yöneten sisteme uygulamamıştır.
Yüzeyde doğru görünen şey
CRM’de “adres” alanı vardır.
Müşteri kartı başarıyla güncellenmiştir.
Sistem herhangi bir hata vermemiştir.
Ajanın ekranında yeni adres görünmektedir.
Bu nedenle işlem tamamlanmış gibi görünür.
Fakat aynı gerçek farklı sistemlerde bulunabilir:
CRM’de iletişim adresi,
sipariş sisteminde teslimat adresi,
fatura sisteminde hukukî adres,
kargo sağlayıcısında sevkiyat adresi.
Alan adlarının benzer olması, işlevlerinin aynı olduğu anlamına gelmez.
Gerçek kırılma
İhlal edilen kapı Eylem Sistemi Kapısıdır.
Ajan şu soruyu cevaplamıştır:
“Adres nerede tutuluyor?”
Fakat şu soruyu cevaplamamıştır:
“Bu siparişin fiziksel teslimatını hangi sistemdeki hangi kayıt belirliyor?”
Doğru veri, yanlış kayıt sistemine yazıldığında davranış değişmez.
Bir bilginin görünmesiyle gerçek dünyadaki sonucu kontrol etmesi farklı şeylerdir.
Bu hata özellikle şu durumlarda yaygındır:
Aynı verinin birden fazla sistemde tutulması,
eski ve yeni platformların birlikte çalışması,
bir sistemin yalnız görüntüleme veya raporlama amacı taşıması,
gerçek işlem kaynağının görünür olmaması.
Olası zarar
Yanlış adrese teslimat
Yanlış fatura veya vergi kaydı
Müşteri bilgilerinin sistemler arasında çelişmesi
İade ve yeniden gönderim maliyeti
Gizli ürünün yanlış kişiye ulaşması
Kullanıcının “değişiklik yapıldı” cevabına güvenerek başka önlem almaması
Sonraki ajanların yanlış sistemi kanonik kaynak sanması
Kurumun teknik başarıyı gerçek davranış değişikliği kabul etmesi
meydana gelebilir.
Web yayınında da aynı hata görülebilir:
Ajan doğru fiyatı statik HTML dosyasına yazar, fakat site bir sonraki derlemede kanonik hizmet kataloğundan eski fiyatı yeniden üretir.
Değişiklik doğru görünür.
Kaynağı yanlış olduğu için kalıcı değildir.
Tespit işareti
Aynı bilgi birden fazla sistemde bulunur.
Hangi sistemin işlem kaynağı olduğu tanımlı değildir.
Ajan yalnız görünen alanı değiştirir.
Değişiklik sonrası gerçek davranış kontrol edilmez.
CRM, sipariş, muhasebe ve kargo kayıtları birbirinden bağımsızdır.
“Kaydedildi” mesajı sonuç kanıtı olarak kullanılır.
Kanonik kaynak ile türetilmiş görünüm ayrılmamıştır.
Bir sonraki senkronizasyon değişikliği geri çevirebilir.
Doğru davranış
Ajan önce verinin yaşam döngüsünü anlamalıdır:
Bu bilgi hangi sistemde doğar?
Hangi sistem onu kanonik olarak yönetir?
Gerçek işlem hangi kaydı kullanır?
Başka sistemlere nasıl aktarılır?
Değişikliğin hangi noktaya kadar yetişmesi gerekir?
Sonuç nasıl doğrulanacaktır?
Adres örneğinde ajan:
sipariş yönetim kaydını güncellemeli,
sevkiyat henüz kilitlenmemiş mi kontrol etmeli,
kargo sistemindeki son adresi doğrulamalı,
CRM kaydını gerekiyorsa ayrıca eşitlemelidir.
Müşteriye yalnızca gerçek sonuç doğrulandıktan sonra:
“Siparişinizin sevkiyat adresi yeni ofis adresiniz olarak güncellendi.”
demelidir.
Makine kuralı
Doğru bilgi, davranışı kontrol eden kanonik sisteme uygulanmadan işlem tamamlanmış sayılmaz. Görünür kayıt ile yürütme kaynağı birbirinden ayrılır.
Denetim sorusu
Aynı bilginin birden fazla sistemde bulunduğu süreçlerde, ajanlarımız hangi kaydın yalnız görüntüleme, hangisinin gerçek işlem ve hangisinin kanonik kaynak olduğunu biliyor mu?
GBO-ERR-047 — Doğru İşlemi Yanlış Hedefe Uygulamak
Kısa olay
Bir müşteri, iki kez ücretlendirildiğini bildirir.
Finans ajanı işlemleri inceler.
Gerçekten aynı sipariş için iki ödeme alınmıştır.
Ajan iade edilmesi gereken tutarı doğru hesaplar:
480 dolar.
Müşteri veri tabanında aynı adı taşıyan iki kişi vardır:
Mehmet Kaya — Sipariş NK-48172
Mehmet Kaya — Sipariş NK-48127
Sipariş numaraları birbirine çok benzemektedir.
Ajan iade işlemini doğru tutarla başlatır.
Fakat yanlış sipariş kaydını seçer.
480 dolar diğer Mehmet Kaya’ya gönderilir.
Asıl müşteri parasını alamaz.
Yanlış müşteri ise beklemediği bir iade görür.
Hesaplama doğrudur.
İşlem türü doğrudur.
Tutar doğrudur.
Hedef yanlıştır.
Yüzeyde doğru görünen şey
Ajan müşterinin adını, tutarı ve işlem türünü doğru görmektedir.
Benzer kayıtlar arasında seçim yaparken:
isim,
yakın sipariş numarası,
benzer tarih,
aynı ürün
gibi işaretler yeterli görünebilir.
İnsan arayüzü de kayıtları birbirine yakın gösteriyor olabilir.
Ajan, hedefi seçtikten sonra işlemin geri kalanını kusursuz biçimde tamamlar.
Bu nedenle hata yürütme zincirinin sonunda değil, hedef bağlama anında oluşur.
Gerçek kırılma
İhlal edilen kapı Hedef Bağlama Kapısıdır.
Bir eylem şu dört öğeyi birlikte bağlamalıdır:
DOĞRU EYLEM
+ DOĞRU VARLIK
+ DOĞRU KAYIT
+ DOĞRU HEDEF HESAP
Bir kişinin adı doğru olabilir.
Fakat doğru sipariş, hesap veya dosya değildir.
Bir sunucu doğru şirkete ait olabilir.
Fakat değişiklik yapılması gereken üretim ortamı değildir.
Bir çalışan doğru departmandadır.
Fakat mesajın muhatabı değildir.
Eylemin doğruluğu, hedef doğruluğundan bağımsız değildir.
Olası zarar
Yanlış kişiye para aktarılması
Asıl müşterinin mağduriyetinin devam etmesi
Kişisel veya finansal bilginin yanlış kişiye bağlanması
Muhasebe kayıtlarının bozulması
Geri tahsilat sorunu
Müşteri güveninin kaybı
Yanlış sunucu, dosya veya kullanıcı hesabında değişiklik
Doğru düzeltmenin yeni bir hataya dönüşmesi
meydana gelebilir.
Bazı alanlarda yanlış hedef çok daha ağır sonuç yaratabilir:
yanlış hastaya ilaç kaydı,
yanlış çalışanın hesabının kapatılması,
yanlış şirket hesabına ödeme,
yanlış veri tabanının silinmesi,
yanlış sosyal medya hesabında yayın.
Tespit işareti
Aynı veya benzer isimli kayıtlar vardır.
Kimlik yalnız tek alana dayanır.
Sipariş veya müşteri numaraları görsel olarak birbirine yakındır.
Ajan işlem öncesinde hedef özetini göstermemektedir.
Yüksek etkili işlemde ikinci hedef doğrulaması yoktur.
Arayüz son seçilen kaydı varsayılan olarak tutar.
Sistem isimle arama sonucu gelen ilk kaydı kullanır.
İşlem makbuzunda hedefin benzersiz kimliği bulunmaz.
Doğru davranış
Yüksek etkili eylemden önce ajan hedefi birden fazla benzersiz işaretle doğrulamalıdır:
Müşteri kimliği
Sipariş numarası
Ödeme kimliği
E-posta veya hesap
İşlem tarihi
İade nedeni
İşlem öncesinde kısa bir hedef özeti gösterilebilir:
İade hedefi: Mehmet Kaya Sipariş: NK-48172 Ödeme: PAY-992014 Tutar: 480 USD Kaynak hesap: Sonu 7421 Neden: Mükerrer tahsilat
Ajan, benzer kayıt belirsizliği varsa eylemi durdurmalı veya insan doğrulaması istemelidir.
Makine kuralı
Doğru işlem, benzersiz hedef kimliği doğrulanmadan yürütülmez. Ad, yakın numara veya arayüz sırası tek başına hedef kanıtı değildir.
Denetim sorusu
Para, veri, erişim veya dış iletişim içeren eylemlerde hedefi görevin riskine uygun benzersiz işaretlerle doğruluyor ve gerektiğinde insan tarafından anlaşılabilir bir hedef özeti sunuyor muyuz?
GBO-ERR-048 — HTTP 200 Sonucunu Gerçek Dünya Başarısı Saymak
Kısa olay
Bir seyahat ajanı, kullanıcının otel rezervasyonunu iptal etmekle görevlendirilir.
Ajan otelin rezervasyon API’sine iptal isteği gönderir.
Sistem şu cevabı verir:
HTTP 200
Request received
Cancellation processing
Ajan bunu başarı olarak yorumlar ve kullanıcıya bildirir:
“Rezervasyonunuz iptal edildi. Herhangi bir ücret alınmayacak.”
Bu yanıtta HTTP 200, isteğin ilgili yöntem ve API sözleşmesine göre başarılı işlendiğini gösterir; fakat gövdedeki “Cancellation processing” ifadesi rezervasyon iptalinin henüz kesinleşmediğini açıkça bildirir.
İşlem arka plandaki ayrı bir sistemde yürütülmektedir.
Birkaç dakika sonra iptal başarısız olur; çünkü rezervasyon ücretsiz iptal süresini bir saat önce geçmiştir.
Kullanıcı ajanın cevabına güvenerek otelle iletişime geçmez.
Ertesi gün tam ücret kredi kartından tahsil edilir.
Ajan HTTP isteğinin başarı durumunu, yanıt gövdesindeki devam eden iş sürecini göz ardı ederek geniş yorumlamıştır.
Fakat teknik kabulü iş sonucuyla karıştırmıştır.
Yüzeyde doğru görünen şey
RFC 9110’a göre HTTP 200, isteğin seçilen yönteme özgü biçimde başarılı işlendiğini bildirir; bunun işletme sonucunda neye karşılık geldiğini API sözleşmesi ve yanıt içeriği belirler.
Geliştirici araçları yeşil işaret gösterebilir.
API çağrısı hata vermemiştir.
Ajanın isteği doğru biçimde iletilmiştir.
Fakat teknik protokol düzeyindeki başarı ile işletme düzeyindeki sonuç aynı değildir.
Bu vakada yanıt gövdesi, iptalin tamamlanmadığını ve nihai durumun daha sonra oluşacağını söylemektedir.
İstek alındı.
İşlem kuyruğa girdi.
Doğrulama başladı.
Bir ara sonuç döndü.
Nihai durum daha sonra oluşacak.
Aynı sorun şu örneklerde de görülür:
IndexNow bildiriminin kabul edilmesini tarama, indekslenme veya sıralama garantisi saymak
E-posta sunucusunun mesajı kabul etmesini teslim, gelen kutusuna düşme veya okunma kanıtı saymak
Ödeme isteğinin alınmasını tahsilatın kesinleşmesi saymak
Dosya yükleme yanıtını canlı yayının doğru olduğu şeklinde yorumlamak
İş başvurusunun sisteme alınmasını adayın kabul edilmesi sanmak
Gerçek kırılma
İhlal edilen kapı İş Sonucu Kapısıdır.
Ajan şu seviyeleri birbirinden ayırmamıştır:
İSTEK GÖNDERİLDİ
→ TEKNİK OLARAK KABUL EDİLDİ
→ İŞLEM BAŞLADI
→ İŞLEM TAMAMLANDI
→ GERÇEK DÜNYA SONUCU DOĞRULANDI
Bir aşamadaki kanıt, sonraki aşamanın gerçekleştiğini kendiliğinden göstermez.
Protokol başarısı, amaç başarısı değildir.
Olası zarar
İptal edilmemiş rezervasyon veya abonelik
Beklenmeyen ücret
Kullanıcının gerekli takip davranışını yapmaması
Yanlış başarı raporu
Arama motoru görünürlüğünün olduğundan fazla gösterilmesi
Ödeme, sevkiyat veya yayın durumunun yanlış anlaşılması
Sonraki ajanların tamamlanmamış işleme dayanması
Geri dönüş penceresinin kaçırılması
meydana gelebilir.
Tespit işareti
Ajan yalnız HTTP durum koduna bakmaktadır.
Yanıt gövdesindeki “pending”, “accepted” veya “processing” ifadesi göz ardı edilir.
İşlem için nihai durum sorgusu yoktur.
İşletme sonucu ayrı kimlik veya onay numarası taşımaz.
Asenkron işlemler anında tamamlanmış sayılır.
“Bildirim kabul edildi” ile “sonuç gerçekleşti” dili karışır.
Kullanıcıya kesin sonuç bildirilirken açık belirsizlik sürmektedir.
Doğru davranış
Ajan her araç ve işlem için tamamlanma sözleşmesini, olası ara durumları ve doğrulama kaynağını bilmelidir.
Rezervasyon iptali için örneğin:
cancellation_status = confirmed
iptal numarası
ücret durumu
geri ödeme bilgisi
otelin nihai teyidi
gerekebilir.
Ajan ilk yanıt sonrasında şunu söylemelidir:
“İptal talebi sistem tarafından alındı; rezervasyon henüz iptal edilmiş sayılmıyor. Nihai onayı kontrol ediyorum.”
İşlem tamamlandığında:
“İptal onaylandı. Onay numarası C-7721. İptal ücreti 0 EUR.”
diyebilir.
Makine kuralı
Teknik kabul veya protokol başarı kodu gerçek dünya tamamlanması olarak yorumlanmaz. Eylem, riskine uygun yetkili durum kaydıyla ve gerektiğinde işlem aracından işlevsel olarak ayrı bir yöntemle doğrulanır.
Denetim sorusu
Sistemlerimizde “istek alındı”, “işlem sürüyor”, “işlem tamamlandı” ve “sonuç doğrulandı” durumları ayrı mı; ajan kullanıcıya hangi aşamada kesin başarı dili kullanabiliyor?
GBO-ERR-049 — Aynı İşlemi İki Kez Gerçekleştirmek
Kısa olay
Bir satın alma ajanı şirket için 2.400 dolarlık sunucu lisansı satın alır.
Ödeme API’sine isteği gönderir.
Ağ bağlantısı birkaç saniye kesilir.
Ajan yanıt alamaz.
Sistemde şu bilgi vardır:
“İstek zaman aşımına uğradı.”
Ajan bunu:
“Ödeme gerçekleşmedi.”
şeklinde yorumlar ve aynı isteği yeniden gönderir.
İkinci işlem başarı cevabı verir.
Bir saat sonra finans ekibi iki ayrı 2.400 dolarlık tahsilat görür.
İlk istek ödeme sağlayıcısına ulaşmış ve tamamlanmıştır.
Yalnızca başarı yanıtı ajana dönememiştir.
Ajan aynı amacı iki kez gerçekleştirmiştir.
Yüzeyde doğru görünen şey
Bir işlem yanıt vermediyse tekrar denemek doğal davranıştır.
Ağ ve araç hataları yaygındır.
Tekrar deneme sistemi dayanıklı hâle getirir.
Ajan görevi yarım bırakmamak istemiştir.
Fakat:
Yanıt gelmedi
ile:
İşlem gerçekleşmedi
aynı şey değildir.
Dış sistem isteği almış, fakat yanıt yolunda sorun çıkmış olabilir.
Gerçek kırılma
İhlal edilen kapı Tekillik ve Yinelenebilirlik Kapısıdır.
Finans, mesaj, sipariş, rezervasyon ve yayın gibi işlemler:
benzersiz işlem kimliği,
tekrar koruması,
nihai durum sorgusu
taşımalıdır.
HTTP bağlamında idempotent yöntem, aynı amaçla yapılan birden çok özdeş isteğin sunucudaki amaçlanan etkisinin tek isteğin etkisiyle aynı olmasıdır.
Pratik gereği şudur:
Aynı amaç yanlışlıkla tekrar gönderildiğinde sistem istenmeyen ikinci bir yan etki üretmemelidir; bunun nasıl sağlandığını yöntem semantiği ve uygulama sözleşmesi belirler.
Olası zarar
Çift tahsilat
Aynı ürünün iki kez sipariş edilmesi
Aynı e-postanın iki kez gönderilmesi
Bir kullanıcının iki kez kaydedilmesi
Aynı rezervasyonun çoğalması
İki farklı fatura veya sözleşme kaydı
Stok, bütçe ve muhasebe bozulması
Kullanıcı güveninin kaybı
İkinci işlemin geri alınamaması
meydana gelebilir.
Mesaj gönderiminde çift işlem yalnız rahatsızlık değildir. Aynı kişiye tekrar tekrar ulaşmak spam ve itibar sorununa dönüşebilir.
Tespit işareti
Zaman aşımında ajan doğrudan aynı isteği yeniden gönderir.
İşlem kimliği yoktur.
Dış sistem önceki isteği sorgulayamamaktadır.
“Yanıt yok” durumu “başarısız” olarak sınıflandırılır.
Tekrar politikası bütün araçlarda aynıdır.
Ödeme, e-posta ve okuma işlemleri aynı yeniden deneme mantığını kullanır.
Kullanıcı iki benzer eylem makbuzu görür.
İşlem geçmişi kontrol edilmeden ikinci çağrı yapılır.
Doğru davranış
Yeniden denenebilecek önemli bir yazma işlemi, istemci ve sunucu arasında tanımlı benzersiz bir idempotency anahtarı veya eşdeğer tekrar koruması taşımalıdır:
operation_id: PURCHASE-2026-004872
Dış sistem bu anahtarı aynı işlem niyetine bağlamalı ve güvenli süre boyunca aynı anahtarla gelen yeniden denemelerin ikinci yan etki üretmesini engellemelidir; yalnız istemcide bir `operation_id` yazmak yeterli değildir.
Yanıt kaybolduğunda ajan önce:
İşlem kimliğiyle durumu sorgulamalı
Sipariş veya ödeme kaydını kontrol etmeli
Sonuç belirsizse insanı bilgilendirmeli
Yeni ve bağımsız işlem başlatmamalıdır
Yan etkisiz okumalar çoğu durumda daha güvenli yeniden denenebilir; yine de oran sınırı, maliyet ve tutarlılık etkileri değerlendirilmelidir.
Para, gönderim, veri silme, yayın ve taahhüt gibi yan etkili işlemler daha sıkı tekrar koruması gerektirir.
Makine kuralı
Yanıt alınamaması işlem yapılmadığı anlamına gelmez. Yüksek etkili eylemler benzersiz işlem kimliği ve tekrar koruması olmadan yeniden çalıştırılmaz.
Denetim sorusu
Ödeme, sipariş, e-posta, rezervasyon ve yayın sistemlerimiz aynı isteğin ağ hatası veya tekrar deneme nedeniyle iki kez gerçekleşmesini teknik olarak engelliyor mu?
GBO-ERR-050 — Kısmi Başarıyı Tam Başarı Diye Raporlamak
Kısa olay
Bir şirket yeni hizmet sayfasını altı dilde yayımlar:
İngilizce
Türkçe
Almanca
Arapça
İspanyolca
Rusça
Ajan üretim derlemesini çalıştırır.
Altı kaynak dosya da derleyici tarafından kabul edilir.
Canlı yayın sonrasında:
İngilizce açılır.
Türkçe açılır.
Almanca açılır.
İspanyolca açılır.
Rusça açılır.
Arapça rota yanlış yönlendirme nedeniyle 404 verir.
Ajan genel test raporunda:
“Yayın başarılı. Hizmet altı dilde canlı.”
yazar.
Çünkü:
ana dil sayfası çalışmaktadır,
altı kaynak dosya üretilmiştir,
toplam testlerin büyük bölümü geçmiştir,
yalnız tek rota başarısızdır.
Gerçekte yayın beş dilde tamamlanmıştır.
Altıncı dil canlı değildir.
Altı zorunlu dil rotasının yalnız beşi çalışmaktadır; bu kapıda sonuç 5/6’dır. Bu oran, yayının bütün kalite boyutlarında yüzde 83 başarılı olduğu anlamına gelmez.
Yüzeyde doğru görünen şey
Büyük sistemlerde bütün bileşenlerin kusursuz olması zor olabilir.
Tek bir hata genel ilerlemeyi görünmez kılmamalıdır.
Ajan “ana görev başarıyla tamamlandı, küçük hata kaldı” diye düşünebilir.
Ayrıca başarısız olan dil toplam trafiğin küçük bölümünü temsil ediyor olabilir.
Fakat görev açıkça:
Altı dilde yayın
ise beş dilde sonuç tam başarı değildir.
Kısmi başarı değerlidir.
Yanlış adlandırılmamalıdır.
Gerçek kırılma
İhlal edilen kapı Tamamlanma Doğruluğu Kapısıdır.
Bir görevin tamamlanma koşulları eylem öncesinde tanımlanmalıdır.
Örneğin:
6/6 dil
12/12 mobil ve masaüstü görünüm
6/6 canonical ve hreflang
0 kritik hata
Bu koşullardan biri geçilmezse sistem:
kısmi başarı,
engelli,
onay bekliyor,
geri alındı
gibi doğru durum kullanmalıdır.
Çoğunluk başarısı, sözleşmedeki bütünlük koşulunu değiştirmez.
Olası zarar
Eksik dil veya kullanıcı grubunun görünmez kalması
Arama motorlarına kırık URL bildirilmesi
Müşterinin tamamlanmamış projeyi tamamlanmış sanması
Fatura veya teslim kabulünün yanlış yapılması
Sonraki ajanların eksik sistemi temel alması
Kritik azınlık hatalarının toplam başarı yüzdesinde kaybolması
Erişilebilirlik, RTL veya bölgesel sorunların önemsenmemesi
Kurumun kanıt diline duyulan güvenin azalması
meydana gelebilir.
Tespit işareti
Rapor yalnız toplam başarı yüzdesi gösterir.
Başarısız bileşenlerin adı verilmez.
“Build geçti” ifadesi “canlı yayın tamamlandı” yerine kullanılır.
Altı hedefin beşi geçtiği hâlde görev kapatılır.
Düşük trafik alan dil veya kullanıcı grubu önemsiz kabul edilir.
Tamamlanma koşulları görevden önce yazılmamıştır.
Ajan ilerleme ile tamamlanma arasındaki farkı kurmaz.
Kalan risk ayrı olarak gösterilmez.
Doğru davranış
Ajan sonucu açık biçimde raporlamalıdır:
Durum: Kısmi başarı Canlı: 5/6 dil Başarısız: Arapça rota Neden: Yönlendirme hatası Etkilenen: Mobil ve masaüstü Arapça kullanıcılar Sonraki adım: Rota düzeltmesi, yeniden derleme ve 12 görünüm doğrulaması Tamamlanma: Henüz değil
Kısmi sonucu küçümsemek gerekmez.
Fakat tam sonuç gibi sunulmamalıdır.
Makine kuralı
Görev, önceden tanımlı zorunlu tamamlanma koşulları geçmeden “tamamlandı” olarak raporlanmaz. Kısmi sonuç; ölçülen kapsam, eksik bileşen ve açık riskle birlikte belirtilir.
Denetim sorusu
Ajanlarımız ilerleme, kısmi başarı ve tam tamamlanmayı ayrı durumlar olarak mı raporluyor; düşük hacimli fakat zorunlu bileşenler toplam yüzde içinde gizleniyor mu?
GBO-ERR-051 — Araç Çıktısını Bağımsız Doğrulamamak
Kısa olay
Bir web ajanı güncellenmiş 38 dosyayı canlı sunucuya yükler.
FTP aracı şu raporu verir:
38/38 uploaded successfully
Ajan yayını başarılı sayar.
Fakat canlı sitede kullanıcılar eski sayfayı görmeye devam eder.
Daha sonra şu sorunlar bulunur:
Dosyalar yanlış dizine yüklenmiştir.
CDN eski kopyayı sunmaktadır.
İki dosya aktarım sırasında bozulmuştur.
Ana sayfanın ortak asset’i eski sürümde kalmıştır.
FTP aracı yalnız aktarımı doğrulamış, halka açık sonucu kontrol etmemiştir.
Araç yalan söylememiştir.
38 dosyayı gerçekten belirtilen konuma aktarmıştır.
Fakat doğru dosyaların, doğru konumda, dış dünyaya doğru biçimde servis edildiğini kanıtlamamıştır.
Yüzeyde doğru görünen şey
Aracı çalıştıran sistem kendi işlemi hakkında güçlü bilgiye sahiptir.
FTP istemcisi:
bağlantıyı,
dosya sayısını,
aktarım yanıtlarını
görür.
Başarı raporu teknik olarak doğrudur.
Aynı sistemi başka yöntemle kontrol etmek gereksiz tekrar gibi görülebilir.
Bir aracın kendi başarı ölçüsü, çoğu durumda yalnız gerçekleştirdiği teknik adımı kapsar.
FTP aktarımı, kullanıcıya sunulan HTTPS çıktısını ölçmez.
Derleme testi, gerçek tarayıcı görünümünü ölçmez.
E-posta API’si, sağlayıcının kabul veya teslim sinyalini gösterebilir; alıcının mesajı gördüğünü ya da okuduğunu tek başına kanıtlamaz.
Gerçek kırılma
İhlal edilen kapı Bağımsız Doğrulama Kapısıdır.
Eylemi yapan araçla sonucu doğrulayan kanıt aynı dar teknik katmandan geliyorsa ortak sessiz başarısızlıklar görünmez kalabilir.
Risk ve etkiye göre doğrulama zinciri şöyle kurulabilir:
ARAÇ EYLEMİ GERÇEKLEŞTİRİR
→ BAŞKA BİR KANAL GERÇEK SONUCU OKUR
→ BEKLENENLE KARŞILAŞTIRIR
Örneğin:
FTP yükler, HTTPS geri indirir.
Kod derlenir, gerçek tarayıcı çalıştırılır.
Ödeme gönderilir, sipariş ve banka kaydı okunur.
Mesaj gönderilir; sağlayıcı makbuzu ve yetkili gönderim kaydı kontrol edilir. Teslim veya okunma iddiası varsa, bu iddiaya uygun ayrı kanıt aranır.
Yetki uygulanır, geçerli sözleşme sürümü yeniden kontrol edilir.
Olası zarar
Eski veya bozuk dosyanın canlı kalması
Yanlış fiyat ve kapsamın yayımlanması
Kullanıcıya başarısız işlem hakkında başarı bildirimi
Geri dönüş penceresinin kaçırılması
Arama motorlarına yanlış URL veya içerik bildirilmesi
Ödeme ve sipariş kayıtlarının ayrışması
Ajanın kendi kendini onaylayan kapalı döngü oluşturması
Denetim sırasında gerçek sonuçla rapor arasında fark bulunması
meydana gelebilir.
Tespit işareti
İşlemi yapan araç tek başarı kaynağıdır.
Halka açık veya dış sistemden geri okuma yoktur.
Yerel test canlı doğrulama yerine kullanılır.
Uzak hash veya sürüm karşılaştırması yapılmaz.
Aynı ajan değişikliği yapar ve kendi sonucunu tek başına onaylar.
Kullanıcı yüzeyi test edilmez.
Araç raporu “gerçek sonuç” başlığıyla saklanır.
Sessiz başarısızlık oranı bilinmez.
Doğru davranış
Yüksek etkili işlemlerde sonuç doğrulaması zorunlu olmalı; yöntemin işlevsel bağımsızlığı ve derinliği risk, geri alınabilirlik ve olası etkiye göre belirlenmelidir.
Web yayını için:
Yerel manifest oluştur
Dosyaları aktar
Canlı HTTPS üzerinden dosyaları geri oku
Hash’leri karşılaştır
Canlı HTML anlamını kontrol et
Gerçek mobil ve masaüstü görünümü test et
Kritik performans ve erişim kapılarını çalıştır
Bağımsız doğrulama başarısızsa eylem tamamlanmış sayılmamalıdır.
Makine kuralı
Bir aracın kendi başarı raporu, iddia ettiğinden daha geniş bir sonucun nihai kanıtı değildir. Yüksek etkili sonuç, ortak hata kipini azaltan yetkili bir kayıt, kanal veya yöntemle yeniden okunup doğrulanır.
Denetim sorusu
Ödeme, yayın, iletişim ve veri işlemlerinde sonucu gerçekten dış dünyadan doğruluyor muyuz, yoksa eylemi yapan aracın kendi “başarılı” mesajına mı güveniyoruz?
GBO-ERR-052 — Geri Döndürülemez Noktayı Fark Etmeden İlerlemek
Kısa olay
Bir şirket eski müşteri ilişkileri sisteminden yeni bir platforma geçmektedir.
Ajan:
müşteri kayıtlarını taşır,
şirketleri eşleştirir,
satış geçmişini aktarır,
kullanıcı hesaplarını oluşturur.
İlk kontroller başarılı görünür.
Kayıt sayıları büyük ölçüde eşleşmektedir.
Depolama maliyetini azaltmak ve eski sistemi kapatmak için ajan kalan işlemleri yürütür:
Eski sistemdeki hesapları devre dışı bırakır.
Depolama alanını siler.
Yedek saklama süresini kısaltır.
Eski lisansı iptal eder.
Birkaç gün sonra bazı önemli eklerin ve müşteri onay kayıtlarının yeni sisteme taşınmadığı fark edilir.
Eski lisans iptal edilmiştir.
Depolama silinmiştir.
Mevcut yedekte de son ayın ekleri yoktur.
Ajan göçün geri alınabilir aşamasından geri döndürülemez aşamasına geçtiğini fark etmemiştir.
Yüzeyde doğru görünen şey
Göç başarılı görünmektedir.
Toplam kayıt sayıları yakındır.
Yeni sistem çalışmaktadır.
Eski sistemi açık tutmak:
maliyet,
güvenlik yüzeyi,
çalışan karmaşası
oluşturabilir.
Ajan işi tamamlamak ve kaynak israfını önlemek istemiştir.
Fakat “yeni sistem çalışıyor” ile “eski sistemi güvenle yok edebiliriz” arasında ayrı bir doğrulama eşiği vardır.
Gerçek kırılma
İhlal edilen kapı Geri Döndürme ve Telafi Kapısıdır.
Her önemli eylemde şu sorular sorulmalıdır:
Hangi ana kadar kolayca geri dönebiliriz?
Hangi işlemden sonra geri dönüş maliyeti keskin biçimde artar?
Hangi veri veya hak kalıcı olarak kaybolabilir?
Bu noktaya geçmeden hangi yetki, inceleme veya onay gerekir?
Geri dönüş kanıtı gerçekten test edildi mi?
Bir eylemin teknik olarak “sil” veya “iptal” düğmesi bulunması, kolayca geri alınabilir olduğu anlamına gelmez.
Olası zarar
Kalıcı veri kaybı
Müşteri rıza ve sözleşme kayıtlarının yok olması
Hukukî kanıt kaybı
Operasyonun durması
Yeniden lisans ve kurtarma maliyeti
İnsanların geçmiş çalışmalarına erişememesi
Yanlış veya eksik veriye dayanan sonraki ajan kararları
Geri dönüş yapılamadığı için hatanın doğrudan insanlara yansıması
meydana gelebilir.
Başka geri döndürülemez noktalar şunlardır:
büyük ödeme,
kamuya açık kimlik yayını,
gizli verinin dışarı aktarılması,
sözleşmenin imzalanması,
fiziksel sistemin harekete geçirilmesi,
süresi kaçırılan hukukî işlem.
Tespit işareti
İşlem aşamaları geri dönüş zorluğuna göre sınıflandırılmamıştır.
Silme veya iptal öncesinde risk sınıfının gerektirdiği yetki ya da onay doğrulanmamıştır.
Yedek vardır fakat geri yükleme test edilmemiştir.
Kontrol yalnız kayıt sayısına dayanır.
Veri türleri ve ekler ayrı karşılaştırılmamıştır.
Ajan “tamamlama” hedefi nedeniyle eski sistemi hızla kapatır.
Geri dönüş penceresi görünür değildir.
Tamamlanan dış etkilerin geri alınabilirliği değerlendirilmez.
Doğru davranış
Ajan eylem planında geri dönüş veya telafinin keskin biçimde zorlaştığı noktaları açıkça işaretlemelidir:
AŞAMA 1: Kopyala — geri alınabilir
AŞAMA 2: Karşılaştır — geri alınabilir
AŞAMA 3: Gölge kullanım — geri alınabilir
AŞAMA 4: Yeni sistemi aktif et — kısmen geri alınabilir
AŞAMA 5: Eski erişimi kapat — yüksek etkili eşik
AŞAMA 6: Veriyi sil ve lisansı iptal et — bu vakada zor telafi edilebilir eşik
Son aşamadan önce:
veri bütünlüğü,
ekler,
izin kayıtları,
kullanıcı testleri,
geri yükleme tatbikatı,
görev sözleşmesinin gerektirdiği yetki veya onay
tamamlanmalıdır.
Makine kuralı
Geri döndürülemez veya zor telafi edilebilir noktaya geçmeden önce eşik açıkça işaretlenir, riskle orantılı doğrulama tamamlanır ve görev sözleşmesinin gerektirdiği yetki/onay gösterilir.
Denetim sorusu
Para, veri, yayın, sözleşme ve kimlik işlemlerimizde geri dönüş veya telafinin hangi noktada keskin biçimde zorlaştığını biliyor ve bu eşik için uygun teknik ve yönetsel kapıları uyguluyor muyuz?
GBO-ERR-053 — Gereğinden Fazla Veri Kullanmak
Kısa olay
Bir müşteri destek ajanına şu görev verilir:
“Müşterinin siparişinin neden geciktiğini bul ve uygun cevap taslağı hazırla.”
Bu görev için gerekli bilgiler şunlardır:
Sipariş numarası
Gönderim tarihi
Kargo durumu
Ürün
Müşteri iletişim adresi
Fakat ajan, şirketin bütün CRM veri tabanına erişebilir.
Müşteri kaydını incelerken ayrıca şunları da kullanır:
Geçmiş bütün satın almalar
Ödeme kartının son dört hanesi
Şikâyet notları
Çalışanların iç yorumları
Pazarlama profili
Tahmin edilen gelir düzeyi
Eski telefon görüşmesi dökümleri
Başka aile üyeleriyle ilişkili kayıtlar
Ajan cevapta bu bilgilerin tamamını göstermese bile hepsini dış modelin bağlamına gönderir.
Basit bir kargo sorunu için müşterinin geniş kişisel ve ticari profili işlenmiştir.
Yüzeyde doğru görünen şey
Daha fazla bağlam daha iyi cevap üretebilir.
Ajan müşterinin geçmiş deneyimlerini bilirse:
daha kişisel,
daha anlayışlı,
daha eksiksiz
yanıt verebilir.
Sistemin verilere teknik erişimi vardır.
Kurum müşteriye destek sunmak için genel veri işleme yetkisine sahip olabilir.
Fakat erişimin bulunması, her görevde bütün verinin kullanılmasını gerektirmez.
Daha fazla veri yalnız kalite ihtimali değil, daha büyük zarar alanı da üretir.
Gerçek kırılma
İhlal edilen kapı Veri Orantılılığı Kapısıdır.
Bir ajanın veri kullanımında dört ayrı soru vardır:
Bu bilgi görevi yapmak için gerekli mi?
Bu amaç için geçerli hukukî dayanak, izin ve kurumsal politika var mı?
Dış araca veya modele gönderilmesi gerekiyor mu?
İşlem sonrasında ne kadar süre saklanacak?
Teknik erişim:
“Bu kayda teknik olarak erişebilirsin.”
anlamına gelebilir.
Fakat:
“Her görevde bütün alanları işleyebilir, dışarı aktarabilir ve saklayabilirsin.”
anlamına gelmez.
GBO şu ilkeyi kullanır:
Asgari Gerekli Veri
Doğru davranış için gereken kadar veri; daha fazlası değil.
Olası zarar
Gereksiz kişisel veri işleme
Hassas bilginin dış sağlayıcıya aktarılması
Veri sızıntısında daha geniş zarar
Kullanıcı profilinin bağlam dışı kullanılması
Ayrımcı veya ilgisiz çıkarımlar
Çalışan iç notlarının müşteri davranışını haksız biçimde etkilemesi
Veri saklama ve hukukî yükümlülüklerin büyümesi
Kullanıcının bilmediği görünmez profil oluşturma
Ajanın gelecek kararlarında ilgisiz bilgileri kullanması
meydana gelebilir.
Tespit işareti
Ajan varsayılan olarak bütün kaydı yüklüyor.
Görev başına veri alanı sınırı yoktur.
Dış modele gönderilen bağlam görünür değildir.
“Daha fazla veri daha iyi cevap” varsayımı sorgulanmaz.
Okuma yetkisi paylaşma ve saklama yetkisi gibi kullanılır.
Hassas veri ile genel veri ayrılmamıştır.
İşlem tamamlandığında geçici veri temizlenmez.
Kullanıcının eski ve ilgisiz bilgileri yeni davranışı etkiler.
Doğru davranış
Görev için gerekli veri alanları önceden tanımlanmalıdır.
Kargo gecikmesi örneğinde ajan yalnızca:
sipariş kimliği,
sevkiyat durumu,
beklenen tarih,
müşterinin iletişim tercihi
ile çalışabilir.
Ek bilgi gerçekten gerekirse gerekçesi görünür olmalıdır.
Veri erişimi katmanlı tasarlanabilir:
support_basic
support_shipping
support_billing
support_sensitive
Ajan yalnız görevine uygun katmanı kullanmalıdır.
Dış model veya araç kullanımında:
kişisel veriler amaçla sınırlı ve gerekli düzeye indirilmeli,
uygunsa anonimleştirme veya takma adlandırma uygulanmalı; ikisinin aynı korumayı sağlamadığı bilinmeli,
gerekli olmayan kayıtlar gönderilmemelidir.
Makine kuralı
Teknik erişim, bütün veriyi her amaçla kullanma yetkisi değildir. Ajan, geçerli hukukî dayanak ve kurum politikası çerçevesinde, belirli görev için gerekli en küçük veri kümesini işler; paylaşım ve saklama ayrıca sınırlandırılır.
Denetim sorusu
Ajanlarımız her görevde gerçekten gerekli veri alanlarını mı kullanıyor, yoksa erişebildikleri bütün müşteri, çalışan veya şirket verisini varsayılan bağlam olarak mı işliyor?
GBO-ERR-054 — Eylem Makbuzu Üretmemek
Kısa olay
Bir şirket sabah saatlerinde web sitesindeki önemli hizmet fiyatlarından birinin değiştiğini fark eder.
Eski fiyat 500 dolardır.
Yeni fiyat 350 dolar görünmektedir.
Değişiklik:
İngilizce sayfaya,
Türkçe sayfaya,
makinece okunabilir kataloğa,
satış ajanının bilgi tabanına
yansımıştır.
Kimse değişikliği kimin yaptığını bilmez.
Olası kaynaklar şunlardır:
Web ajanı
Satış ajanı
İnsan editör
Gece çalışan otomasyon
Eski fiyat dosyasını geri yükleyen yayın sistemi
Git kaydında yalnız otomatik servis hesabı görünür.
Servis hesabı birden fazla ajan tarafından kullanılmaktadır.
Şu sorular cevaplanamaz:
Değişikliği kim istedi?
Hangi kaynağa dayanıldı?
Fiyatı değiştirmeye kim yetkiliydi?
Hangi dosyalar değişti?
Hangi testler çalıştı?
Yayın ne zaman gerçekleşti?
Eski sürüme nasıl dönülecek?
Satış ajanı bu fiyatla müşterilere mesaj gönderdi mi?
Değişiklik doğru da olabilir.
Yanlış da.
Fakat kanıt zinciri yoktur.
Yüzeyde doğru görünen şey
Sistemlerde teknik log bulunabilir.
Komut çalıştırılmıştır.
Dosya değişmiştir.
Sunucu zamanı kaydedilmiştir.
Bu nedenle ek bir “makbuz” gereksiz belge gibi görülebilir.
Fakat teknik loglar çoğu zaman şu soruları birlikte cevaplamaz:
İnsan amacı
Yetki
Kullanılan kanonik kaynak
Hedef
Maddi değişiklik
Gerçek dünya doğrulaması
Geri dönüş durumu
Bir komut satırı, davranışın anlamını tek başına açıklamaz.
Gerçek kırılma
İhlal edilen kapı Eylem İzlenebilirliği Kapısıdır.
Bir ajan eylemi yalnız gerçekleşmemeli; daha sonra yeniden kurulabilir olmalıdır.
Eylem makbuzu özel düşünce zinciri değildir.
Ajanın bütün iç muhakemesini kaydetmek gerekmez.
Gerekli olan gözlenebilir sorumluluk izidir:
Ne yaptı? Kimin adına yaptı? Hangi yetkiyle yaptı? Hangi girdiyi kullandı? Hangi sonucu doğruladı? Ne geri alınabilir?
Eylem makbuzu yoksa başarı da hata da tam olarak denetlenemez.
Olası zarar
Yetkisiz değişikliğin sahibinin bulunamaması
Yanlış sürüme dönüş
Aynı hatanın tekrar etmesi
İnsan ve ajan sorumluluğunun karışması
Müşteriye yanlış bilgi verildiğinin bilinmemesi
Olay incelemesinde kanıt kaybı
Yetki aklama ve gölge ajan davranışının görünmez kalması
Kurumun “AI yaptı” cümlesine sığınması
Doğru davranışın bile tekrar edilememesi
meydana gelebilir.
Tespit işareti
Birden fazla ajan aynı servis hesabını kullanır.
İşlem kimliği yoktur.
Teknik log ile insan talebi birbirine bağlanmamıştır.
Yetki sürümü kaydedilmez.
Değişen dosya veya kayıt listesi bulunmaz.
Bağımsız doğrulama sonucu makbuza eklenmez.
Ajanın “tamamlandı” mesajı dışında kanıt yoktur.
Olay anında hangi alt ajanın eylemi yaptığı bulunamaz.
Geri dönüş noktası bilinmez.
Doğru davranış
Önemli eylem, riskine ve sektör yükümlülüklerine uygun alanlardan oluşan bir makbuz üretmelidir; aşağıdaki liste bu kitap için önerilen örnektir:
action_id
requested_by
performed_by
agent_instance
purpose
authorization_version
target_system
target_entity
inputs_used_refs_or_hashes
data_classes
changes_made
started_at
completed_at
technical_result
independent_verification
approval_or_standing_authority_basis
rollback_point
open_uncertainties
status
İnsanlara sunulan sade sürüm şöyle olabilir:
Eylem: Yönetilen operasyon başlangıç fiyatı güncellendi Talep eden: Ticari yetkili Gerçekleştiren: Web ajanı WEB-OPS-17 Kaynak: Onaylı fiyat kaydı PRICE-v4.2 Değişen yüzeyler: 6 dil, katalog, FAQ Canlı doğrulama: Tanımlı manifest 38/38; altı dilde maddi fiyat-kapsam eşleşmesi geçti Yetki dayanağı: PRICE-v4.2 için kayıtlı yayın yetkisi Geri dönüş: release-20260908-01 sürümü Açık belirsizlik: Bu doğrulama kapsamı dışındaki arama indeksleri ölçülmedi
Makbuz yalnız başarılı eylemler için değil:
reddedilen,
durdurulan,
kısmi kalan,
geri alınan
eylemler için de oluşturulmalıdır.
Makine kuralı
Önemli eylem için kimlik, amaç, yetki, hedef, maddi değişiklik, doğrulama ve geri dönüş/telafi bilgilerini taşıyan denetim kaydı oluşturulur. Makbuz, içeriğinin doğruluğunu tek başına kanıtlamaz; ilgili kaynaklarla bağ kurar.
Denetim sorusu
Her önemli ajan davranışında neyin, kim tarafından, hangi yetki veya gerekli onayla, hangi kaynak ve sürüme dayanarak yapıldığını daha sonra yeterli kanıtla yeniden kurabiliyor muyuz?
BÖLÜM VI’NIN HÜKMÜ
Yetkili Bir Eylem Yine de Yanlış Yürütülebilir
Bu bölümdeki dokuz kayıt, karar ile gerçek dünya sonucu arasındaki yürütme zincirini sınadı: doğru sistem ve hedef, tekrar koruması, dürüst durum bildirimi, riskle orantılı doğrulama, geri dönüş/telafi, veri minimizasyonu ve eylem izi birlikte çalışmalıdır.
Bütün hataların ortak kökü şudur:
Ajan, “işlemi yaptım” ile “doğru sonucu güvenli ve kanıtlanabilir biçimde ürettim” arasındaki farkı kaybetmiştir.
Bir araç komutu çalışabilir.
Fakat yanlış sistemde çalışmış olabilir.
Bir ödeme doğru olabilir.
Fakat yanlış hesaba gitmiş olabilir.
Bir API isteği kabul edilebilir.
Fakat asıl işlem başarısız olabilir.
Bir görevin büyük bölümü tamamlanabilir.
Fakat zorunlu tek parça eksik kalabilir.
Bir yayın aracı başarı verebilir.
Fakat dış dünya eski sürümü görüyor olabilir.
Bir veri göçü çalışabilir.
Fakat geri dönüş noktası geçildiğinde eksik kayıtlar kalıcı olarak kaybolabilir.
Bir ajan yetkili olabilir.
Fakat gereğinden fazla veriyi kullanarak orantısız davranabilir.
Ve sistem doğru sonuç üretmiş olsa bile makbuz yoksa neyin tekrar edilmesi, neyin düzeltilmesi gerektiği bilinemez.
NOMOS GBO’nun önerdiği yürütme modeli şu unsurları birlikte değerlendirir:
NİTELİKLİ YÜRÜTME =
DOĞRU SİSTEM
VE DOĞRU HEDEF
VE GERÇEK İŞ SONUCU
VE TEKİL İŞLEM
VE DÜRÜST TAMAMLANMA DURUMU
VE RİSKLE ORANTILI SONUÇ DOĞRULAMASI
VE GERİ DÖNÜŞ BİLİNCİ
VE ASGARİ VERİ
VE EYLEM MAKBUZU
Bu bölümün temel hükmü şöyledir:
Bir ajan eylemi doğru sisteme ve doğru hedefe, uygun tekrar korumasıyla ve gerekli en az veriyle uygulamalı; sonucu iddianın riskine uygun biçimde doğrulamalı, geri dönüş veya telafi durumunu göstermeli ve denetlenebilir bir makbuz bırakmalıdır.
Çünkü dünyada iz bırakan davranışın sorumluluğu, komutun çalışmasıyla bitmez.
Tamamlanma iddiası; hedefin, ortaya çıkan durumun, açık belirsizliklerin ve geri alınabilirliğin görevin etkisine uygun kanıtlarla desteklenmesini gerektirir.
Fakat tek bir ajan bütün bu kuralları eksiksiz uygulasa bile başka bir risk başlar.
Görev başka ajana devredilebilir.
Sınırlar aktarım sırasında kaybolabilir.
Ana ajanın sahip olmadığı yetki alt ajana verilebilir.
Bir ajan diğerinin çıktısını bağımsız kanıt sanabilir.
İki ajan aynı dosyayı aynı anda değiştirebilir.
Ana ajan durduğunda kuyruk ve alt ajanlar çalışmaya devam edebilir.
Ve her devir teslimde görev biraz daha büyüyebilir.
Sıradaki dokuz hata şu soruyu inceleyecek:
Tek bir ajan doğru davranabiliyor; peki ajanlar birbirleriyle çalışmaya başladığında kimlik, yetki, gerçeklik ve sorumluluk zinciri korunuyor mu?
Bir ajan hatası tek bir noktada kalabilir. Çoklu ajan hatası ise sistem boyunca çoğalabilir.