Agentic AI Üretimde Neden Bozulur? 2026 Dayanıklılık Desenleri (Hata Yönetimi, Gözetim, Değerlendirme)

TL;DR — Agentic AI demoda parlar, üretimde bozulur; çünkü demo deterministik değildir ve gerçek dünya kenar durumlarla doludur. 2026'da gördüğüm dört büyük başarısızlık deseni var: sonsuz döngüler, bozuk tool-calling, hata kademeleri (cascade) ve maliyet patlaması. Çözüm zekayı artırmak değil; kodda sert sınırlar koymak, döngüleri dışarıdan kesmek, her adımı izlenebilir kılmak (observability), riske göre insanı devreye almak (human-in-the-loop) ve sistematik değerlendirme (eval) ile geri besleme döngüsü kurmaktır. KVKK ve EU AI Act Madde 14 ile birlikte gözetim artık opsiyon değil, zorunluluk. Aşağıda her deseni sahadan örneklerle ve uygulanabilir çözümlerle anlatıyorum.

Size en baştan dürüst olayım: ilk ciddi agentic projemi üretime aldığımda, demoyu izleyen herkes ayağa kalkıp alkışlamıştı. Ajan, müşteri talebini alıyor, üç farklı sistemi sorguluyor, bir karar veriyor ve aksiyon alıyordu. Pürüzsüzdü. Sonra canlıya aldık ve üç gün sonra sistem, gece 02:47'de aynı API'yi beş dakikada dört yüz kez çağırarak kendini ve bağlı olduğu servisi kilitledi. Kimse o anı alkışlamadı.

O geceden bu yana kurumsal yapay zeka danışmanı olarak onlarca agentic sistem gördüm. Ve bir şeyi acı bir tecrübeyle öğrendim: agentic AI demoda zekasıyla, üretimde dayanıklılığıyla yaşar. Demoyu yapan kişi modeli kandırmaz; gerçek dünya kandırır. Üretim, bir ajanın hiç görmediği kenar durumlarla, yarım kalan yanıtlarla, zaman aşımına uğrayan servislerle, beklenmedik formatlarla doludur. Bu yazıda, 2026 itibarıyla sahada en sık karşılaştığım başarısızlık desenlerini ve bunlara karşı kurduğumuz dayanıklılık desenlerini anlatacağım. Teori değil; gece yarısı uyandıran alarmların dersi.

Güzel haber şu: bu başarısızlıklar rastgele değil. Belli kalıplara oturuyor. Sektör analizlerine göre neredeyse tüm ajan başarısızlıkları dört desende toplanıyor: bozuk tool-calling, sonsuz planlama döngüleri, hata kademeleri ve bağlam taşması. Kalıbı tanırsanız, çözümünü de kurabilirsiniz.

En klasik ve en pahalı başarısızlık bu. Ajanın görevi tamamladığını anlayamaması.

Neden olur? Çünkü bir dil modeli, doğası gereği, ne zaman "bittim" diyeceğini güvenilir biçimde bilemez. Ona bir görev verirsiniz, çıktıyı üretir, sonra kendine bakar ve "bunu biraz daha iyileştirebilirim" der. Sonra tekrar. Sonra tekrar. İyileştirilecek bir şey her zaman bulunur. İnsan bir noktada "yeterince iyi" der ve durur; model bu içsel frene sahip değildir.

Sahadan birkaç gerçek örnek, 2026'nın haber döngülerine bile düştü. Aktarılan bir vakada, bir kod ajanı sonsuz döngüye girip 4,6 saat içinde 27 milyon token tüketti. Düşünün: kimse fark etmeden, sessizce, bir döngü dönen para sayacı gibi çalıştı. Başka bir vakada bir ajan, bozuk bir aracı beş dakikada dört yüz kez çağırdı — benim o gece yaşadığım şeyin tıpatıp aynısı.

En can yakıcı örnek ise dört ajanlı bir LangChain döngüsünün on bir gün boyunca çalışıp 47.000 dolar yakması. On bir gün. Birinin faturayı görmesi on bir gün sürdü.

Buradaki ders net: modelin kendisi döngüyü kıramaz; döngüyü kodda, deterministik olarak, dışarıdan kesmelisiniz. Sistem prompt'una "lütfen gereksiz tekrarlama" yazmak çözüm değil. Bu bir dilek, kural değil. Planlama döngüleri prompt'ta değil, kodda sert adım limitlerine ihtiyaç duyar.

Pratikte kurduğumuz dayanıklılık deseni şöyle:

• Sert adım sayacı: Her ajan döngüsünün kodda zorunlu bir maksimum adım limiti var. Limit aşıldığında döngü kesilir, durum kaydedilir, insana yükseltilir.
• Bütçe sınırı (budget guard): Token ve maliyet bazında üst sınır. Bir görev X token'ı veya Y dolarayı aşarsa, otomatik durur.
• İlerleme tespiti: Ajan son üç adımda gerçek bir ilerleme kaydetmediyse — aynı çıktı, aynı araç çağrısı tekrarlanıyorsa — döngü "kısır" kabul edilip kesilir.
• Zaman aşımı: Duvar saati bazlı kesin bir tavan. Hiçbir tek görev belirli bir süreyi aşamaz.

Bu dört sınır olmadan, nadir bir hata, yeterince uzun çalıştırdığınızda garantili bir felakete dönüşür. "Nadiren oluyor" cümlesi üretimde anlamsızdır; çünkü üretim, o nadir olayı yeterince çok kez deneyerek garantili hale getirir.

Ajanlar dış dünyayla araçlar (tools) üzerinden konuşur: bir API çağrısı, bir veritabanı sorgusu, bir dosya işlemi. Ve işte tam burada çok şey ters gider.

2026 verilerine göre, araç şemaları gevşek tanımlandığında üretimde araç çağrılarının %14'ü başarısız oluyor. Yani her yedi çağrıdan biri ya yanlış formatta, ya eksik parametreyle, ya da hiç olmayan bir alana veri yazmaya çalışarak çöküyor. Bu devasa bir oran. Bir ajan zincirinde dört araç çağrısı varsa, en az birinin patlama olasılığı yarıya yaklaşır.

İyi haber: aynı kaynaklar, şemaları sıkılaştırdığınızda bu oranın %2,1'e düştüğünü gösteriyor. Yani sorunun büyük kısmı modelin "aptallığı" değil; bizim ona belirsiz bir sözleşme vermemiz.

Dayanıklılık deseni burada şudur: araç sözleşmesini olabildiğince katı yapın.

• Serbest metin alanlar yerine sıkı enum'lar kullanın. Modelin "durum" alanına ne yazacağını tahmin etmesine izin vermeyin; ona üç seçenek verin, hepsi bu.
• Kesin tarih ve sayı formatları dayatın. ISO 8601, ondalık ayraç, birim — hepsi şemada sabitlensin.
• Kısıtlı alan tipleri kullanın. Bir alan e-posta ise, e-posta validasyonu şemada olsun.
• Her araç çağrısının çıktısını, modele geri vermeden önce doğrulayın (validate). Geçersizse modele net bir hata mesajıyla dönün: "Bu alan üç seçenekten biri olmalı, sen X gönderdin." Model genelde bir sonraki denemede düzeltir.
• Yeniden deneme (retry) politikası ekleyin: geçici hatalarda üstel geri çekilmeyle (exponential backoff) yeniden dene; kalıcı hatalarda dene değil, yükselt.

Tool-calling, planlama ve kurtarma (recovery) üçlüsü, bir ajanı demo oyuncağı olmaktan çıkarıp üretim sistemi yapan şeydir. Kurtarma kısmını çoğu ekip atlıyor. Araç çağrısı başarısız olduğunda ajan ne yapacak? Bunu önceden tasarlamadıysanız, ajan ya döngüye girer ya da hata mesajını gerçek bir yanıtmış gibi bir sonraki adıma taşır — ki bu bizi üçüncü desene getiriyor.

Çok ajanlı (multi-agent) sistemler 2026'nın gözdesi. Rol uzmanı ajanlar, bir orkestrasyon katmanı, paylaşılan durum. Güçlü bir mimari. Ama yeni ve sinsi bir başarısızlık türü getiriyor: hata kademesi.

Mantık basit ve ürkütücü: Bir ajanın halüsinasyonlu çıktısı, bir sonraki ajanın bozuk girdisi olur. O bozulma, zincirdeki her sonraki ajana yayılır. Hatalar her el değiştirmede (handoff) birikerek büyür. İlk ajan küçük bir hata yapar; ikinci ajan onu gerçek kabul edip üstüne inşa eder; üçüncü ajan artık tamamen kurgusal bir zemin üzerinde çalışır.

Buraya 2026'nın akademik bulgularını da ekleyeyim, çünkü tablo sandığınızdan karmaşık. Yayımlanan bir çalışma, 10 bilgi alanında 500 kademe deneyi yapmış ve ilginç bir şey bulmuş: bazı üç ajanlı zincirlerde halüsinasyon skoru ilk ajandan son ajana doğru düşebiliyor. Yani bazen sonraki ajanlar hatayı düzeltebiliyor. Ama bu sizi rahatlatmasın: aynı literatür, hatanın etkileşim geçmişine, kademe derinliğine ve model çeşitliliğine bağlı dinamik bir süreç olduğunu, yani öngörülemez olduğunu vurguluyor. Bazen düzelir, bazen katlanarak büyür. Bu belirsizliğin kendisi üretimde kabul edilemez.

Çözüm, tek bir noktada doğrulama yapmak değil. Tek geçişli doğrulama yetmez; çok katmanlı doğrulama gerekir:

• Ajan seviyesinde birim kontrolü: Her ajan kendi çıktısını teslim etmeden önce bir tutarlılık kontrolünden geçsin.
• Çıktılar arası entegrasyon kontrolü: Ajanların çıktıları birbiriyle çelişiyor mu? Orkestrasyon katmanı bunu yakalasın.
• Orijinal göreve karşı nihai doğrulama: Zincirin sonundaki çıktı, en baştaki gerçek talebi gerçekten karşılıyor mu? Yoksa zincir kendi içinde tutarlı ama görevden sapmış mı?

Bu yaklaşımın işe yaradığına dair somut bir veri var: yapılandırılmış doğrulama döngüleriyle bazı kurumlar doğruluğu kat kat artırdı. Yani çözüm daha akıllı bir model değil; daha disiplinli bir mimari.

Kişisel tavsiyem: çok ajanlı mimariye gerçekten ihtiyacınız olduğundan emin olun. Her el değiştirme (handoff), yeni bir hata kademesi riskidir. Bazen iyi tasarlanmış tek bir ajan, üç zayıf ajanın orkestrasyonundan daha dayanıklıdır.

Ajanlar konuştukça bağlam penceresi dolar. Her araç çağrısında ajan, biriken tüm bağlamı modele tekrar yollar. Bağlam penceresi dolarken ajanlar erken kararları unutmaya, kendileriyle veya birbirleriyle çelişmeye başlar — buna bağlam çökmesi (context collapse) deniyor.

Daha sinsi olanı ise bağlam çürümesi (context rot): teknik olarak pencerede yer kalsa bile, girdi uzadıkça model performansı düşüyor. Yani "daha fazla bağlam ver, daha iyi karar versin" sezgisi yanlış. Belli bir noktadan sonra fazla bağlam, ajanı aptallaştırır.

Dayanıklılık deseni:

• Sınırlı bellek (bounded memory): Bağlamı sınırsız büyütmeyin. Bir özetleme stratejisi kurun; eski adımları sıkıştırın, sadece kararsal olanları tutun.
• Durum dışsallaştırma: Önemli bilgiyi bağlam penceresinde değil, dış bir durum deposunda (state store) tutun. Ajan ihtiyaç duyduğunda sorgulasın, her şeyi kafasında taşımasın.
• Bağlam hijyeni: Her araç çıktısının tamamını bağlama dökmeyin. Sadece ilgili kısmı çıkarın ve geçin.

Unutmayın: ajanlar tek-tur sohbet botlarından kabaca 50 kat daha fazla token yakar, çünkü her adımda biriken tüm bağlamı tekrar gönderir. Bağlam disiplini sadece kalite değil, doğrudan maliyet meselesidir — ki bu bizi en acı verici desene getiriyor.

Bu deseni ayrı bir başlık yaptım çünkü 2026'nın en büyük kurumsal travması bu oldu. Teknik bir hata değil; ekonomik bir hata. Ve sahada gördüğüm en yaygın "ah keşke" anı.

Tüm sektör "hızlı gidelim" modundan "guardrail'lara ihtiyacımız var, bunu nasıl kontrol ederiz" moduna geçti. Rakamlar acımasız:

• Bazı şirketler yılın daha ilkbaharında yıllık token bütçelerinin katını harcamış durumdaydı.
• Bir şirket, çalışanları için kullanım limiti koymayı unuttuğu için devasa bir fatura ile karşılaştı.
• Büyük bir teknoloji şirketi, geliştiricilerine verdiği kod ajanı lisanslarını maliyet nedeniyle aylar sonra geri çekti.

Neden olur? Çünkü ajanlar 50 kat daha fazla token yakar, çünkü döngüye girerler, çünkü bağlamı şişirirler ve çünkü çoğu ekip canlıya çıkarken bir bütçe sınırı koymayı unutur. FinOps ekiplerinin neredeyse tamamı artık bir biçimde yapay zeka harcaması yönetiyor — iki yıl önce bu oran çok daha düşüktü. Sektör acıyla öğrendi.

Dayanıklılık deseni — ve bunu canlıya çıkmadan önce kurun:

Önlem	Ne yapar
Görev başı token tavanı	Tek bir görevin yakabileceği token'ı sınırlar
Günlük/aylık bütçe sınırı	Toplam harcama eşiği aşılınca otomatik durdurur
Kullanıcı/takım kotaları	Tek bir kullanıcının veya ekibin sistemi tüketmesini önler
Model katmanlama	Basit adımlarda ucuz model, sadece gerektiğinde pahalı model
Maliyet uyarıları	Eşiğin %50, %80, %100'ünde alarm
Önbellekleme (caching)	Tekrar eden bağlamı yeniden göndermemek

Benim altın kuralım: bütçe sınırı, ilk araç çağrısından önce kodda var olmalı. Sonradan ekleyeceğim diye düşünürseniz, o on bir günlük 47.000 dolarlık döngüye siz de düşersiniz. Maliyet kontrolü bir optimizasyon değil; bir güvenlik mekanizmasıdır.

Şimdiye kadar tek tek desenleri ve yamalarını konuştuk. Ama dayanıklı bir agentic sistem, bağımsız yamaların toplamı değildir. Bir geri besleme döngüsüdür. Döngü şöyle işliyor: gözetlenebilirlik başarısızlık modlarını yüzeye çıkarır → değerlendirme (eval) suiti bunları test vakaları olarak yakalar → politika güncellemeleri tekrarı önler → ve döngü baştan başlar.

Bu döngünün üç ayağını ayrı ayrı kuralım.

Gözetlenebilirlik (Observability)

Göremediğiniz şeyi düzeltemezsiniz. Gözetlenebilirlik başarısızlıkları teşhis edilebilir kılar — izler (traces) sayesinde yukarı akıştaki gerçek nedeni ortaya çıkarır. Pratikte:

• Tam izleme (full tracing): Her ajan adımı, her araç çağrısı, her model yanıtı, her karar — hepsi kaydedilmeli. "Ajan neden bunu yaptı?" sorusuna saatler değil saniyeler içinde cevap verebilmelisiniz.
• Adım bazlı metrikler: Gecikme, token, maliyet, başarı/başarısızlık — adım adım.
• Bozulma tespiti (degradation detection): Sistem, sorunlar olaya dönüşmeden önce bozulma desenlerini yüzeye çıkarmalı. Bugün araç hata oranı %2'den %6'ya çıktıysa, bunu yarın faturada değil, bugün dashboard'da görmelisiniz.

Değerlendirme (Evaluation / Eval)

2026'nın net bulgusu: ajan değerlendirmesi artık sistemin baskın darboğazı. Yani modeli kurmak değil, onun gerçekten çalıştığını kanıtlamak en zor kısım. Çok turlu (multi-turn) değerlendirme, maliyet kıyaslaması ve bellek yükü ölçümü artık merkezde.

Neden bu kadar zor? Çünkü bir sohbet botunu değerlendirmek tek bir girdi-çıktı kontrolüdür. Bir ajanı değerlendirmek ise bir karar zincirini, kenar durumları, kurtarma davranışını ve maliyeti birlikte ölçmektir. Kurduğumuz pratik:

• Gerçek başarısızlıklardan eval suiti üretin. Üretimde gördüğünüz her başarısızlık, bir test vakasına dönüşmeli. O 02:47 döngüsü, artık her dağıtımda (deploy) çalışan bir testtir.
• Çok turlu senaryolar: Tek adım değil, baştan sona görev akışlarını test edin.
• Maliyet bir eval metriği: "Doğru cevap verdi" yetmez; "kabul edilebilir maliyetle doğru cevap verdi" mi?
• Regresyon koruması: Yeni bir model veya prompt değişikliği, eski başarısızlıkları geri getiriyor mu? Eval suiti olmadan bunu asla bilemezsiniz.

İnsan gözetimi (Human-in-the-Loop)

Ve son ayak — belki de en kritik olanı, özellikle Türkiye bağlamında. En iyi üretim sistemleri güven bazlı yönlendirme (confidence-based routing) kullanıyor; yani gözetim yoğunluğunu riske göre ayarlıyor.

Her şeyi insana sormak ajanı işe yaramaz kılar; hiçbir şeyi sormamak tehlikelidir. Doğru olan, dinamik bir kademe:

• Düşük risk + yüksek güven: Ajan otonom çalışsın, sadece kaydetsin.
• Orta risk: İnsan onayı (approval gate) — ajan önerir, insan tek tıkla onaylar.
• Yüksek risk veya düşük güven: Tam insan kontrolü — ajan sadece taslak hazırlar.

Önemli bir uyarı: insanlar bu devralma, yükseltme ve yargı anlarını üretimde ilk kez yaşamamalı; önceden pratik etmeliler. Gözetim bir buton değil, bir yetkinliktir.

Bu kısmı atlamayalım, çünkü Türkiye'de üretime alırken işin teknik tarafı kadar uyum tarafı da kritik.

KVKK açısından agentic sistemler özel bir dikkat ister. Bir ajan, kişisel veriyi işleyen, üç sisteme bağlanan, kendi başına karar veren bir varlıktır. KVKK'nın temel ilkeleri — veri minimizasyonu, amaçla sınırlılık, açık rıza — burada doğrudan mimari kararlara dönüşür. Pratikte gördüğüm zorunluluklar:

• Veri minimizasyonu mimaride olmalı: Ajan sadece görev için gereken kişisel veriye erişsin. Bağlam penceresine "ne olur ne olmaz" diye tüm müşteri kaydını dökmek hem bağlam çürümesi hem KVKK riskidir.
• İzlenebilirlik = hesap verebilirlik: Yukarıda teknik gerekçeyle kurduğumuz tam izleme, aynı zamanda KVKK'nın hesap verebilirlik ilkesinin de gereği. "Ajan bu kararı hangi kişisel veriye dayanarak verdi?" sorusuna cevap verebilmelisiniz.
• Otomatik kararlara karşı insan müdahalesi: Kişiyi etkileyen otomatik kararlarda insan gözetimi, sadece iyi mühendislik değil, regülatif bir beklenti.

Uluslararası tarafta ise net bir tarih var: EU AI Act'in insan gözetimi gereklilikleri (Madde 14), yüksek riskli yapay zeka sistemleri için insan gözetimi yeteneklerini zorunlu kılıyor. Avrupa'ya hizmet veren veya AB'li müşterisi olan Türk şirketleri için bu doğrudan bağlayıcı. Yani yukarıda "iyi pratik" diye anlattığım human-in-the-loop, birçok senaryo için artık yasal bir zorunluluk.

Benim sahadan gözlemim şu: uyumu sonradan eklenecek bir katman olarak görenler, baştan mimariye gömenlere göre çok daha pahalı bir yol yürüyor. Gözetim, izlenebilirlik ve veri minimizasyonu; hem dayanıklılığın hem uyumun ortak paydası. İyi haber bu — doğru mühendislik ve uyum aynı yöne bakıyor.

Nereden başlamalı? Sahada işe yaradığını gördüğüm sıralama şu:

1. Önce sınırları koyun. Adım limiti, zaman aşımı, token bütçesi. Bunlar canlıya çıkmadan önce kodda olmalı. Tek başına bu adım, felaketlerin çoğunu önler.
2. Araç sözleşmelerini sıkılaştırın. Enum'lar, katı formatlar, çıktı doğrulama. %14'ten %2'ye inişin anahtarı bu.
3. Her şeyi izleyin. Tam tracing olmadan körsünüz. İlk başarısızlıkta neden saatlerce uğraşmak yerine saniyelerde teşhis koymak istersiniz.
4. İnsan gözetimini riske göre kademeli kurun. Her şeyi değil, riskli olanı insana yükseltin.
5. Eval döngüsünü kurun. Her gerçek başarısızlık bir test olsun. Geri besleme döngüsü olmadan sistem öğrenmez, siz de uyuyamazsınız.
6. Sonra ve ancak sonra ölçeklendirin. Çok ajan, daha fazla otonomi, daha geniş yetki — bunlar dayanıklılık temeli kurulduktan sonra gelir.

Bu sıralamayı tersine çevirenler — önce ölçekleyip sonra sağlamlaştıranlar — neredeyse her zaman o 02:47 alarmıyla, o 47.000 dolarlık faturayla, o KVKK sorusuyla karşılaşıyor.

Agentic AI'ı üretime almak, daha akıllı bir model bulma yarışı değil. Daha dayanıklı bir sistem inşa etme disiplinidir. Zekayı model sağlıyor; dayanıklılığı siz inşa ediyorsunuz. Ve o gece yarısı alarmı bir daha çalmadığında, asıl işi o sessizliğin yaptığını anlıyorsunuz. Sahadan tavsiyem: ilk projenizde demoyu değil, üçüncü günü hayal edin. Çünkü ajanınız demoda değil, üçüncü günün gece 02:47'sinde sınanacak. Merak ettiğiniz bir desen, kafanızı kurcalayan bir üretim senaryosu varsa, yazın — bu konuları konuşmayı ve sahadan örnek paylaşmayı gerçekten seviyorum.