Doğrudan yanıt: Başarılı bir demo, bir yapay zeka ajanının güvenilirliği hakkında hiçbir şey kanıtlamaz; çünkü doğru soru görevi bir kez tamamlayıp tamamlamadığı değil, her seferinde doğru tamamlayıp tamamlamadığıdır. Microsoft'un 20 Ağustos 2026 tarihinde yayımladığı bir çalışmada en güçlü model, her görev bir kez çalıştırıldığında %65,36 puan aldı, ancak yirmi denemenin tamamını görevlerin yalnızca %25,25'inde geçti. Bu fark, sizi bir toplantıda etkileyen ajan ile müşteri verilerinizi emanet edebileceğiniz ajan arasındaki mesafenin ta kendisidir.

Microsoft gerçekte ne geliştirdi

Aracın adı Thinkingbox; GitHub'da MIT lisansıyla yayımlanan açık kaynaklı bir test ortamı. Fikir basit ve zekice: Araçları doğrudan ajana bağlamak yerine onları MCP uyumlu sunucular olarak tanımlıyor, ajanı kendi arka plan veritabanına sahip yalıtılmış bir oturumda çalıştırıyor ve yürütmenin tam izini kaydediyorsunuz.

Asıl önemli nokta değerlendirme biçiminde. Çerçeve, ajanın ne yaptığını söylediğini okumuyor; görev bittiğinde veritabanında gerçekte neyin değiştiğini inceliyor. Bu ayrım teknik bir ayrıntı değil. Ajanlar hiç gerçekleşmemiş bir iş için ikna edici bir özet yazmakta çok iyidir ve konuşma dökümüne dayanan her değerlendirme yürütmenin değil, metnin kalitesini ölçer.

Ekip bu ortamın üzerine Thinkingbox-bench adlı bir benchmark kurdu. Benchmark, beş alanda 507 politikaya bağlı iş akışı içeriyor: perakende ve e-ticaret, seyahat ve konaklama, kasko sigortası, bir neobankada şirket içi BT desteği ve bir danışmanlık firmasında BT ile İK desteği. Her görev, hem tescilli hem de açık ağırlıklı on iki model üzerinde yirmi kez çalıştırıldı.

Bu rakam bir işletme sahibi için neden önemli

Mağazanızdaki iade taleplerini işleme görevini bir ajana verdiğinizi düşünün. %65'lik bir başarı oranı kağıt üzerinde kabul edilebilir görünür. Operasyonda ise taleplerin üçte birinin yanlış bir sonuçla bittiği anlamına gelir: iki kez yapılan bir geri ödeme, stok yeniden eklenmeden kapatılan bir sipariş ya da politikanızın izin vermediği bir müşteriye tanınan bir istisna.

Daha da kötüsü, bu çalışmadaki hatalar bariz çökmeler değildi. Makale, pek çok hatanın temiz biçimde sonlandığını ve geçerli görünen adımlar attığını, ancak sistemin nihai durumunun yine de yanlış olduğunu açıkça anlatıyor. Hata mesajı yok, durma yok, izleme panosunda yanan hiçbir şey yok. Yalnızca normal okunan bir kayıt ve sessizce yanlış hale gelmiş veriler.

Sistemi durduran bir hata can sıkıcıdır ama görünürdür. Akışı tamamlayıp verilerinizi yanlış bırakan hata ise size gerçekten pahalıya mal olandır, çünkü onu bir ay sonra mutabakat sırasında fark edersiniz.

Bu, yaygın bir hayal kırıklığı kaynağını da açıklıyor. Pilot çalışma başarılı olur, çünkü görevi temiz veriler üzerinde bir kez çalıştırmıştır. Gerçek operasyon ise aynı görevin birikmiş ve dağınık bir durum üzerinde binlerce kez yapılmasıdır; %65 ile %25 arasındaki fark tam da orada ortaya çıkar.

Herhangi bir ajanı benimsemeden önce yapmanız gerekenler

  • Tek bir demo değil, tekrarlanan çalıştırmalar isteyin. Kabul kriteriniz, aynı görevin aynı veriler üzerinde art arda yirmi kez çalıştırılması olsun. Bunu reddeden bir tedarikçi size bir şey söylüyordur.
  • Yanıt metnini değil, veri durumunu ölçün. Görevden sonra veritabanınızdaki kaydın nasıl görünmesi gerektiğini önceden tanımlayın ve gerçeği bununla karşılaştırın. Ajanın kendi özetini okumakla yetinmeyin.
  • Yalnızca kolay görevleri değil, politikaları test edin. İşinizin büyük kısmı serbest değildir; kurallarla sınırlıdır: iade süreleri, kredi limitleri, öncelikli müşteriler için istisnalar. Kısıtlama olmadan başarılı olan bir ajan, ilk gerçek koşulda çökebilir.
  • Test setini kendi vakalarınızdan oluşturun. Son aylardan, ekibinizin kafasını karıştıran tuhaf olanlar da dahil yirmi gerçek vaka alın ve bunları, herhangi bir modeli benimsemeden önce ve her güncellemeden sonra çalıştırdığınız sabit bir test paketine dönüştürün.
  • Yetkiyi aşamalı olarak verin. Öneren ama uygulamayan bir ajanla başlayın, ardından düşük etkili işlemler yapmasına izin verin, sonra gerçek bir ölçüm geçmişi biriktikçe kapsamını genişletin. Yetki izlenimle değil, veriyle kazanılmalıdır.

Origami'de bunu nasıl ele alıyoruz

Bir yapay zeka ajanı içeren bir sistem geliştirdiğimizde ajana diğer tüm yazılım bileşenleri gibi davranırız: Otomatik bir test paketi, her işlemden sonra veritabanı durumunu inceleyen doğrulama kontrolleri ve bir güven eşiği aşıldığında bir insana devretmek için net bir nokta alır. Modelin kendisi koda kaynaklanmış bir şey değil, değiştirilebilir bir ayar olarak kalır; çünkü bugünün en iyi modeli üç ay sonra en iyisi olmayabilir.

Bu çalışmadan çıkarılması gereken sonuç, ajanların kullanılamaz olduğu değil. Onları değerlendirdiğimiz ölçütün yanlış olduğu. Bugünün ajanları, iyi tanımlanmış ve sürekli ölçülen bir kapsam içinde güçlü araçlardır; ikna edici bir demoya dayanarak hassas bir süreç kendilerine teslim edildiğinde ise çok zayıftırlar. Fark modelde değil, onun etrafındaki mühendislik disiplinindedir.

Kaynaklar