İki dev.to yazısına göre ajan başarısızlıklarının kaynağı model değil, araçlar ve koruma bariyerleri

Ajanlar model olarak değil, sistem olarak önce çöker

Aynı gün dakikalar arayla yayımlanan Hossein Hezami'nin iki dev.to yazısı, aynı savunmayı iki yönden ortaya koyuyor: bir yapay zeka ajanı üretim ortamında başarısız olduğunda, bunun nedeni genellikle modelin zekası değil, modeli çevreleyen mühendisliktir — tool sözleşmeleri, izinler, bütçeler ve kurtarma yolları.

İlk yazı tanıdık bir olayla açılıyor. Bir CRM endpoint'i 502 döndürdü, agent çağrıyı yeniden denedi, iki destek talebi oluşturdu, güncelliğini yitirmiş bir bilgi tabanı makalesini okudu, context window'unu stack trace'lerle doldurdu ve sonra müşteriye her şeyin yolunda olduğunu söyledi. Ekipler bu tür olaylara modeli yükselterek karşılık veriyor; ancak yazarın vurguladığı nokta şu: aynı başarısızlık büyük olasılıkla yeniden ortaya çıkıyor, sadece daha akıcı bir dille yazılmış olarak.

Yazının çerçevesi şuna dayanıyor: bir agent bir kontrol döngüsüdür — görev al, durumu gözle, sıradaki adıma karar ver, bir tool çağır, sonucu doğrula, durumu güncelle ve devam etme, yükseltme ya da durma arasında seçim yap. Model yalnızca karar adımını üstlenir; gerisi, olasılıksal planlama, arızalı tool'lar, düşmanca dış içerik ve dağınık state ile karmaşıklaşmış geleneksel yazılım mühendisliğidir. Yazı ayrıca 2026 itibarıyla modellerin tool çağırma ve çok adımlı akıl yürütme konusunda epey geliştiğine dikkat çekiyor; bu da zayıf koruma bariyerlerini daha tehlikeli hale getiriyor, çünkü sistem bozulmadan önce daha uzun süre yetkin görünüyormuş izlenimi veriyor.

Yazarın üretim sistemlerinde tekrar tekrar karşılaşılan zayıf noktalar arasında şunlar sayılıyor: belirsiz hedefler, zayıf tool şemaları, aşırı izinler, context çürümesi, sınırsız döngüler, idempotent olmayan tool'lar, prompt injection açıkları, eksik trajectory değerlendirmesi, yalnızca son yanıtta duran gözlemlenebilirlik ve kurtarma yerine otonomiyi önceliklendiren tasarımlar.

Asıl işi sözleşmeler ve şemalar yapıyor

İlk yazının önerileri güvenilirliği modelin değil, döngünün bütününün bir özelliği olarak ele alıyor. Ajanların bir görev sözleşmesine ihtiyacı var: bir hedef, mümkün olduğu ölçüde makine tarafından doğrulanabilir başarı ölçütleri, yasak eylemler, en fazla adım sayısı, zaman ve maliyet bütçeleri ve insanına yükseltme gibi bir geri dönüş davranışı. Yazarın pratik kuralı şu: bitmiş bir görevin nasıl göründüğüne dair gerçekçi on örnek yazamıyorsanız, o görev ajan için henüz hazır değil.

Tool şemaları ise sözde eylem prompt'ları olarak işlev görüyor. Serbest metin sorgusu kabul eden genel amaçlı bir tool, belirsiz çağrıları ve çöp sonuçları davet eder; bu yüzden tool'lar katı dahili API'ler gibi tasarlanmalı: tipli girdiler, dar kapsamlar, açık kısıtlar ve ham blob yerine kompakt yapılandırılmış çıktı. İzinler de en az ayrıcalık ilkesiyle benzer biçimde ele alınıyor: tool'lar salt okunur, geri alınabilir yazma ya da geri alınamaz yazma olarak sınıflandırılıyor ve risk arttıkça daha katı kurallar uygulanıyor. Idempotent olmayan tool'ları yeniden denemek, arızalı bir bağımlılığı kendinden emin, ikilenmiş yan etkilere dönüştürmenin klasik yolu olarak ayrıca vurgulanıyor.

Bir hatayı hangi katmanın durduracağına karar vermek

İkinci yazı başka bir üretim hatasından yola çıkıyor: bir destek agentı, 12 dolarlık bir ek hizmet yerine müşterinin tüm yıllık aboneliğini iade etti. Model çökmedi, API bir exception fırlatmadı ve tool tam olarak tasarlandığı gibi çalıştı. Postmortem analizler modelin kötü kararlar vermesini nasıl engelleriz diye soruyor; yazar ise daha iyi sorunun şu olduğunu savunuyor: hata zarara dönüşmeden önce onu hangi katmanın durdurması gerekiyordu?

Yazı, ajan hatalarını altı başarısızlık kipine ayırıyor — yanlış niyet, tehlikeli planlar, geçersiz tool argümanları, yetkisiz eylemler, zararlı çıktılar ve kontrolsüz yürütme — ve her birini farklı bir savunma katmanına atıyor: niyet sınıflandırması, plan doğrulama, tool sözleşmeleri, yetkilendirme, yürütme denetimleri, çıktı doğrulama, runtime izleyicileri ve insan onayı.

İki nokta öne çıkıyor. Prompt'lar olasılıksal yönlendirmedir, icra mekanizması değil; dolayısıyla modelin talimatlarındaki bir cümleye uymasına dayanan bir güvenlik senaryosu pek de güvenlik senaryosu sayılmaz. Ve temel kural: bir eylem geri döndürülemez zarara ne kadar yakınsa, onu durduracak katman o kadar deterministik olmalı; en iyi fren, zararı önleyebilen en erken deterministik katmandır. Yazar, global kapsamlı istekleri en tehlikeli durum olarak öne çıkarıyor — agent etkilenen kümeyi hassas biçimde tanımlayamıyorsa, hiçbir şeyi değiştirmesine izin verilmemelidir — ve önce pasif kullanıcıları listelemeyi sonra her birini silmeyi öngören bir plan örneği veriyor; burada her tekil çağrı geçerlidir ama dizilim geçerli değildir.

Neden önemli

Her iki yazı da ajan olaylarına daha büyük modeller ya da daha uzun prompt'larla karşılık verme refleksine karşı çıkıyor. Ajanları üretime taşıyan ekipler için pratik program gösterişsiz: tamamlanma ölçütlerini tanımlayın, tool'ları tiplendirin, izinleri daraltın, döngüleri bütçeler ve devre kesicilerle sınırlayın, son yanıtlar yerine tüm trajectory'leri değerlendirin ve geri alınamaz eylemlerin önüne deterministik kapılar — yetkilendirme, plan doğrulama, insan onayı — yerleştirin. Modeller geliştikçe başarısızlıklar anlamadan yürütmeye göç ediyor ve güvenilirlik çalışması da ajanların çevresindeki tesisata kayıyor.