Ajanlar Neden Demoda Değil Üretim Ortamında Bozulur?

Bir ajan demosu, birinin önceden seçtiği yolu yürür. Girdiler temizdir, araçlar ayaktadır, müşteri kaydı yerindedir ve sunumu yapan kişi hangi soruyu soracağını bilir. Üretim ortamı bunun tam tersidir: girdiler klavyenin başındaki kim varsa ondan gelir, bağımlılıkların üçte biri zaman zaman kopan bir ağ bağlantısının arkasındadır ve ilginç vakalar tam olarak kimsenin senaryolaştırmadığı vakalardır. Gartner'ın Haziran 2025 basın bülteni sonucu sayıya döktü: 3.400'den fazla katılımcıyla yapılan ankete dayanarak, agentic AI projelerinin %40'tan fazlasının 2027 sonuna kadar iptal edileceği, gerekçe olarak da artan maliyetler, belirsiz iş değeri ve yetersiz risk kontrolleri belirtildi. Bu projeler modeller akıl yürütemediği için başarısız olmuyor; altlarındaki operasyon katmanını kimse kurmadığı için başarısız oluyor.

Aynı kuruluş, kurumsal uygulamaların %40'ının 2026 sonuna kadar göreve özel AI ajanları içereceğini, bu oranın 2025'te %5'in altında olduğunu öngörüyor. İki ifade birbiriyle çelişmiyor ve birlikte önümüzdeki iki yılı doğru tarif ediyor: birçok ekip ajan yayına alacak ve bu kurulumların önemli bir kısmı sessizce kapatılacak. İki grup arasındaki fark nadiren model ya da çerçeve seçimidir. Fark, ekibin ajanı ortasında belirsiz davranan bir bileşen bulunan dağıtık bir sistem olarak mı, yoksa üzerine araç iliştirilmiş bir istem olarak mı ele aldığıdır. Birinci bakış bütçeleri, iz kayıtlarını ve acil durdurma anahtarlarını doğurur. İkincisi dört haneli bir fatura ve kimsenin tekrar üretemediği bir olay doğurur.

Bu yazı ajanın ne olduğunu bildiğinizi varsayıyor; bilmiyorsanız temel anlatımla başlayın, kaç ajan çalıştıracağınıza ve birbirleriyle nasıl konuşacaklarına henüz karar vermediyseniz çoklu ajan desenleri yazısı topoloji sorusunu ele alıyor. Buradan sonrası daha dar ve daha tatsız: gerçek trafik geldiğinde ajan iş akışlarının tam olarak nasıl bozulduğu, genellikle ortaya çıkma sırasına göre ve her birini durduran kontrol. Hiçbiri teorik değil. Aşağıdaki her arıza biçimi canlı bir kurulumun ilk sekiz haftası içinde, çoğu zaman da bir hafta sonu ortaya çıkan türden. Anlatım sırası da rastgele değil: önce parayı yakan hatalar, sonra güveni yakan hatalar ve en sonda bunları gerçekten durduran kontroller geliyor.

Sonsuz Döngüler (unbounded loops), Yeniden Deneme Fırtınaları ve Ürettikleri Fatura

En pahalı ajan hatası yanlış cevap değildir. Döngüdür. Biçimi neredeyse her zaman aynıdır: ajan bir aracı çağırır, araç istisna fırlatmayan bir biçimde başarısız olur — gövdesinde hata nesnesi taşıyan bir HTTP 200, boş bir sonuç kümesi, sarmalayıcının yutup boş dize olarak döndürdüğü bir zaman aşımı. Model bunu veri olarak okur, sorgusunun biraz yanlış olduğu sonucuna varır, tek bir argümanı değiştirir ve yeniden çağırır. Yığının hiçbir yerinde istisna fırlamadığı için hiçbir şey geri çekilmez ve kimseye çağrı gitmez. Ajan tam olarak kendisine söylenen şeyi yapmaktadır: cevabı bulana kadar çalışmaya devam etmek.

Bunu can sıkıcı olmaktan çıkarıp tehlikeli yapan şey maliyet profilidir. Altı ila on araç çağrısı etrafında tasarlanmış bir iş akışı, tipik olarak gördüğümüz aralıkta çalışma başına 30.000 ila 80.000 token tüketir; çünkü her adım birikmiş konuşma kaydını yeniden gönderir. Altmış adıma ulaşan bir döngü altı kat değil, yirmi ila otuz kat daha pahalıya mal olur; çünkü bağlam her turda büyür ve her tur bunun tamamını yeniden öder. Bunu gece boyunca birkaç bin işi işleyen bir kuyruğun arkasına koyun, aritmetik akademik olmaktan çıkar. Yanlış yapılandırılmış tek bir yeniden deneme yolu, beklenen günlük çıkarım harcamasını sabah kimse panele bakmadan on ila kırk kat büyütebilir.

Sorunun ikinci yarısı tespittir. Sağlayıcı faturalama panelleri saniyelerle değil saatlerle ölçülen bir gecikmeyle güncellenir; yani fatura sizin alarmınız değildir. Gerçek zamanlı olarak elinizde olan sinyal kendi adım sayacınız ve kendi token muhasebenizdir, bu da saymanız gerektiği anlamına gelir. Sorunu finans ekibi faturayı sorduğunda fark eden ekipler, çalışma başına maliyeti hiç ölçmemiş ekiplerdir. Alarm kurulmaya değer metrik toplam harcama değildir, çünkü çok yavaş hareket eder; çalışma başına adım sayısının dağılımıdır. Medyanı yedi adım olan ve 99'uncu yüzdeliği elliye tırmanmış bir iş akışı, size paranın söyleyeceğini günler öncesinden söyler. Bu dağılımı iş akışı tipine göre ayrı ayrı izleyin; tek bir toplu histogram, yalnızca bir akışta patlayan döngüyü kolayca gizler.

Kontroller gösterişsizdir ve işe yarar. Çalışma başına adım sayısına sert bir tavan koyun ve uyarmak yerine orada sonlandırın. Her çalışmaya bir token bütçesi ve bir para bütçesi bağlayın ve ikisini de sistem isteminde değil çalışma zamanında zorlayın; çünkü bir modelin kendi görev algısına karşı bir limiti uygulamasına güvenilmez. Aynı aracın neredeyse aynı argümanlarla arka arkaya üç dört kereden fazla çağrılmasında tetiklenen bir döngü dedektörü ekleyin. Dış çağrıları devre kesiciyle sarın ki kopup duran bir bağımlılık, iş akışını tam ücret ödeyerek öğütmek yerine temiz bir şekilde durdursun. Bu dört kontrolün dördü de birkaç günlük iştir ve tek bir gecelik faturanın yanında son derece ucuz kalır.

Belirsizlik (non-determinism) ve Tekrar Üretemediğiniz Olay

Sıcaklığı sıfıra çekmek bir ajanı deterministik yapmaz ve bunun aksine inanmak, bu kadar çok ajan olayının incelemede ölmesinin sebebidir. Sağlayıcı tarafındaki çıkarım, donanım kuşakları ve yığın bileşimi arasında bit düzeyinde tekrarlanabilir değildir. Getirilen belgeler indeks yeniden kurulduğunda değişir. Araç yanıtları ilerlemiş bir veritabanını yansıtır. Değişken bir takma ad arkasındaki model siz haberdar olmadan değiştirilebilir. Aynı kullanıcı girdisini bir gün sonra tekrar oynatmak farklı bir çalışma üretir; yani klasik hata ayıklama hamlesi — yerelde tekrar üret, sonra ikiye bölerek daralt — elinizde yoktur. Çalışmayı olurken kaydetmediyseniz o çalışma gitmiştir ve olay incelemesi tahmin yürütmeye dönüşür.

Bu, iz kaydını (tracing) sonradan ulaşılacak bir olgunluk seviyesi değil, sert bir gereklilik hâline getirir. Kullanılabilir bir iz kaydı her adım için şunları tutar: sistem istemi sürümü, tam olarak gönderildiği hâliyle mesaj listesi, araç adı, birebir argümanlar, ayrıştırma öncesi ham yanıt, giren ve çıkan token sayıları, gecikme ve takma ad yerine çözümlenmiş model sürüm dizesi. Argümanlar olmadan modelin mi yanlış soruyu sorduğunu yoksa aracın mı yanlış cevapladığını ayırt edemezsiniz. Ham yanıt olmadan bir ayrıştırıcının sessizce alan düşürüp düşürmediğini göremezsiniz. Çalışma kuralımız şu: bir mühendis dördüncü adımda modelin gördüğü baytları birebir yeniden kuramıyorsa iz kaydı bitmemiştir. Çevresindeki pratik gözlemlenebilirlik ve değerlendirme yazısında ele alınıyor.

Bu ayrıntıda iz kaydı, veri korumayla çarpışır ve bu çarpışmayı kazara değil bilerek çözmelisiniz. Tam iz kayıtları kullanıcının yazdığı her şeyi içerir; Türkiye'deki kurumsal bir ortamda bu rutin olarak kimlik numaralarını, sözleşme metnini, maaş verisini ve bazen sağlık bilgisini kapsar. Saklama süresini iz kaydını açmadan önce kararlaştırın — otuz ila doksan gün hata ayıklama değerinin neredeyse tamamını karşılar — ve depoyu sonradan temizlemeyi ummak yerine girişte alan bazlı maskeleme uygulayın. İz kayıtlarını altındaki kayıtlarla aynı yargı alanında tutun. Bir iz kaydı deposu kişisel veri deposudur ve 6698 sayılı Kanun kapsamında, o veriyi tutan diğer sistemlerle aynı 12. madde güvenlik yükümlülüklerini taşır.

Ajanın Üstünü Örttüğü Araç Hatası

Paraya değil itibara mal olan arıza biçimi, ajanın gizlediği araç hatasıdır. Araç 503 döner, sarmalayıcı bunu 'müşteri kaydı alınamadı' dizesine çevirir, model bunu sıradan bağlam olarak alır ve durmak yerine 'mevcut bilgilere göre müşterinin durumu şu şekilde görünmektedir' diye başlayan bir özet üretir. Çıktı akıcıdır, yapısal olarak doğrudur ve yanlıştır. Kimseye çağrı gitmez; çünkü çalışma zamanının bakış açısıyla iş akışı başarıyla tamamlanmıştır. Bir operatör kendinden emin bir paragrafı okur ve ona göre hareket eder. Bu, çökmekten daha kötüdür: çökme size gerçeği anında söyler, üstü örtülmüş bir araç hatası ise incelemeden sağ çıkan bir yalan söyler.

Kök neden neredeyse her seferinde araç sınırındadır. Her araç bir dize döndürdüğünde, modelin 'işte verin' ile 'bu sistem çalışmıyor' arasında ayrım yapacak hiçbir yolu yoktur. İkisi de konuşma kaydındaki metinden ibarettir ve modelin işi metni makul bir devamla sürdürmektir. Bu yüzden araç sözleşmelerinin yapı taşıması gerekir: bir durum kodu, tiplenmiş bir hata kodu ve ya var olan ya da olmayan bir yük; böylece çalışma zamanı, model daha görmeden hata üzerinden dallanabilir. Standart bir araç katmanının pratik gerekçelerinden biri budur. MCP hata semantiğini sizin yerinize çözmez ama sizi her araca özel bir yapı uydurmak yerine şema tanımlamaya iter.

Politika katmanı en az tip katmanı kadar önemlidir. Her araç için başarısızlığın ne anlama geldiğine karar verin: bazı hatalar geri çekilmeli yeniden denenmeli, bazıları modele durup rapor etmesi yönünde açık bir talimat olarak iletilmeli, bazıları ise çalışmayı doğrudan iptal etmelidir. Başarısız olan bir fiyat sorgusunun tahmine dönüşmesine asla izin verilmemelidir. Çıkışta da doğrulamalar ekleyin. İş akışının muhasebe kaydına bakmış olması gerekiyorsa ve iz kaydında başarılı bir muhasebe çağrısı yoksa, metin ne kadar iyi görünürse görünsün o çalışma geçersizdir. Bu çıktı doğrulamaları yazması bir öğleden sonra sürer ve gizli arızaların şaşırtıcı bir kısmını insan görmeden yakalar.

Yetki Genişlemesi ve Etki Alanı (blast radius)

Neredeyse her ajan salt okunur başlar ve neredeyse hiçbiri salt okunur kalmaz. Örüntü öngörülebilirdir: pilot, talepleri özetler; biri talep durumunu da güncelleyebileceğini fark eder ve mevcut servis hesabına yazma yetkisi eklenir, çünkü o hesap zaten çalışmaktadır ve ikincisini açmak platform ekibine bir talep açmak demektir. Altı hafta sonra aynı kimlik bilgisi dört sisteme yazabilir hâle gelir ve özetleyici olarak başlayan ajan, hiçbir çalışanın tek başına sahip olmadığı bir yetkiye ulaşır. Bu kararı kimse tek oturuşta vermemiştir; her seferinde bir kolaylık olarak birikmiştir. Yetki sınırını çizmenin doğru anı ilk yazma aracından öncedir; sonrasında sınır bir tasarım kararı değil bir göç projesidir.

Üzerinde düşünülmesi gereken sayı etki alanıdır ve hesabı basittir: ajanın çağırabildiği her araç için tek bir kötü çağrının en kötü sonucunu alın ve bunu, hiçbir şey onu durdurmadan önce bu çağrıyı kaç kez yapabileceğiyle çarpın. Kısıtsız yazma yetkisi ve elli adımlık bütçesi olan bir ajan elli kaydı değiştirebilir. Yazma aracı toplu bir uç nokta ise elli bin kaydı değiştirebilir. Bu yüzden yazma araçlarındaki hız limitleri bir performans kontrolü değil bir sınırlama kontrolüdür ve istemde değil aracın kendisinde durmalıdır. Aynı akıl yürütme silme işlemleri, dışa giden iletişim ve para harcayan her şey için geçerlidir.

Yetki genişlemesi aynı zamanda enjekte edilmiş bir talimatı gerçek bir olaya çeviren mekanizmadır. Güvenilmeyen içerik okuyan bir ajan — gelen bir e-posta, tedarikçi PDF'i, çekilmiş bir web sayfası — özellikle kendisini yönlendirmek için yazılmış olabilecek bir metni okuyordur ve eklenen her yazma yetkisi bu saldırının getirisini artırır. Getirilen içeriği talimat değil düşman girdi olarak ele alın, kimlik bilgilerini ajan başına değil araç başına daraltın ve yüksek değerli araçları ayrı bir onay yolunun arkasına koyun ki başarılı bir enjeksiyon bile işlemi tek başına tamamlayamasın. Bu tehdidin mekaniği ve gerçekten tutan savunmalar prompt injection ve yapay zeka güvenliği yazısında ele alınıyor.

Kısmi Başarısızlık, Eksik İşlemler ve Katlanan Gecikme

Ajan iş akışları, etrafında hiçbir işlem sarmalı olmadan yan etki dizileri yürütür. Üçüncü adım e-posta gönderir, dördüncü adım CRM'e yazar, beşinci adım bir ödeme uç noktasını çağırır ve altıncı adım başarısız olur. Bir posta sunucusu, bir SaaS API'si ve bir muhasebe defterini kapsayan iki fazlı bir işlem taahhüdü yoktur; dolayısıyla çalışma, hiçbir tasarımcının tarif etmediği bir durumda biter: kendisine bir şey söylenmiş ama sistemin kaydetmediği bir müşteri. Klasik dağıtık yazılım bunu saga ve telafi eylemleriyle çözer; ajanlar da aynı disipline ihtiyaç duyar, üstelik dizinin kendisinin önceden bir mühendis tarafından yazılmak yerine çalışma anında model tarafından seçilmesi gibi ek bir zorlukla.

Bu yüzden araçları bağlamadan önce sınıflandırın. Geri alınabilir eylemler — bir taslak, sahnelenmiş bir kayıt, tutulan bir rezervasyon — serbestçe yürütülebilir ve kimse fark etmeden geri alınabilir. Telafi edilebilir eylemler, uygulanmış ve test edilmiş açık bir tersini gerektirir ve çalışma zamanı bunu hata durumunda çağırmalı, temizliği modelin muhakemesine bırakmamalıdır. Geri alınamaz eylemler, başta dışa giden iletişim ve para hareketi olmak üzere, iş akışının izin verdiği her yerde en sona sıralanmalıdır ki altıncı adımdaki bir hatanın geri alacak bir şeyi kalmasın. Bu sıralama kısıtı, ajanın özgürlüğünü bilerek daralttığımız birkaç yerden biridir: model ne yapacağını seçebilir ama geri alınamaz kısımların ne zaman çalışacağına çalışma zamanı karar verir.

Durum yönetimi daha sessiz bir problemdir. Konuşma belleği büyür, not defterleri birikir, getirilen belgeler bağlamda yığılır ve maliyet ile kalite aynı anda ters yöne gider. Belli bir kayıt uzunluğunu geçtikten sonra model önceki kısıtları kaybetmeye başlar; bu da on adım önce doğru uyguladığı bir kuralı unutan bir ajan olarak yüzeye çıkar. Sabit kontrol noktalarında agresif biçimde özetleyin, kalıcı olguları konuşma kaydında değil yapılandırılmış bir depoda tutun ve bağlam penceresini eklemeli bir günlük değil, yönetilmesi gereken bir çalışma kümesi olarak ele alın. Yönetilmeyen bir kayıtla uzun süre çalışan bir ajan, neredeyse önceden kestirilebilir bir takvimle bozulur.

Gecikme, tek çağrılı sistemlerin kimseye öğretmediği bir biçimde katlanır. Her model çağrısı iki ila altı saniye sürüyorsa ve her araç çağrısı buna iki yüz milisaniye ile iki saniye ekliyorsa, sekiz adımlık bir iş akışı iyi bir çalışmada yirmi ila altmış saniye arasında biter. Bir yeniden deneme ve bir yavaş bağımlılık ekleyin, 99'uncu yüzdelik dakikalarla ölçülür. Kullanıcılar beklemez; dolayısıyla ya iş akışı gerçek bir ilerleme kanalıyla asenkron hâle gelir ya da adım sayısı düşer. Pratikte cevap genellikle ikisidir birden: modele daha çok tur değil daha iyi araçlar vererek adımları birleştirin ve çok adımlı bir ajanı senkron bir isteğin arkasına koymaktan vazgeçin.

Model Yükseltmesinden Sonra Sessiz Bozulma

Üretimdeki bir ajanda en az ölçülen risk, modelin altından değişmesidir. Sağlayıcı bir sürüm görüntüsünü emekliye ayırır, siz halefine geçersiniz ve hiçbir şey hata fırlatmaz. Yeni model çoğu genel karşılaştırmada daha iyidir ve sizinkinde biraz farklıdır: bir alanı farklı biçimlendirir, daha temkinli hâle gelip eskiden karşıladığı bir talep sınıfını reddetmeye başlar ya da ayrıştırıcınızın isteğe bağlı saydığı bir anahtarı üretmeyi bırakır. Hata oranınız hiç kıpırdamaz. Kaliteniz kıpırdar. Haftalar sonra biri, alt taraftaki bir ekibin çıktıyı sessizce elle düzelttiğini fark eder ve o noktada karşılaştıracak bir referans çizginiz kalmamıştır. Bu sağlayıcının hatası da değildir; modelin sizin iş yükünüzde nasıl davrandığını ölçebilecek tek tarafın siz olmanızın doğal sonucudur.

İşe yarayan tek tespit yöntemi, geçişten sonra değil önce çalıştırdığınız bir regresyon takımıdır. Gerçek girdi dağılımınızı kapsayan, zor ve muğlak olanları bilerek içeren, yüz ila üç yüz gerçek iz kaydından oluşan bir altın küme kurun ve beklenen sonucu yalnızca sonda değil adım bazında kaydedin. Adım bazlı değerlendirme önemlidir; çünkü bir ajan yanlış bir yoldan doğru nihai cevaba ulaşabilir ve bugün tesadüfen işleyen bir yol yarının olayıdır. Takımı aday modele karşı çalıştırın, adım düzeyindeki geçme oranlarını karşılaştırın ve yüksek maliyetli herhangi bir adımdaki gerilemeyi engelleyici sayın. Bu sıradan sürüm mühendisliğidir; tek yenilik test edilen şeyin olasılıksal olmasıdır.

Operasyonel olarak üç alışkanlık sürprizlerin çoğunu ortadan kaldırır. Değişken bir takma adı işaret etmek yerine çözümlenmiş model sürümünü açıkça sabitleyin ki yükseltme, salı günü başınıza gelen bir şey değil sizin seçtiğiniz bir dağıtım olsun. Yeni sürümü küçük bir trafik payında kanarya olarak çalıştırın ve tam geçişten önce adım düzeyindeki metrikleri karşılaştırın. İş yükü kontrolsüz bir model değişimini gerçekten kaldıramıyorsa, bu kısıt bir tercih değil bir mimari karar hâline gelir; modeli kendiniz çalıştırmanın getirdiği ödünleşimler kurum içi ve egemen yapay zeka yazısında ele alınıyor. Modelinizin ne zaman değişeceği üzerindeki kontrol meşru bir gerekliliktir ve gerçek bir bedeli vardır.

Tiyatroya Dönüşmeyen İnsan Onayı Tasarımı

İnsan onayı, herkesin ilk başvurduğu ve en kötü tasarladığı kontroldür. Faydalı soru 'bunu bir insan incelemeli mi' değil, 'hangi eylemler geri alınabilir' sorusudur. Her aracı üç kovadan birine koyun ve tasarımı oradan kurun. Geri alınabilir eylemler hiçbir kapı gerektirmez; kimsenin göndermeyeceği bir taslağı inceleyen insan, uyum kokusu taşıyan saf maliyettir. Telafi edilebilir eylemler yalnızca telafi pahalı ya da müşteriye görünür olduğunda kapı gerektirir. Geri alınamaz eylemler — göndermek, ödemek, silmek, bir kuruma bildirim yapmak — istisnasız olarak eylem öncesi onay gerektirir. Çoğu ekip yanlış kümeyi kapılar; genellikle lansmanda her şeyi kapatıp kuyruk yönetilemez hâle gelince kapıları sessizce kaldırarak.

Onay yorgunluğu bir karakter zaafı değil, ölçülebilir bir arızadır. İnceleyenler gördüklerinin yüzde doksan beşini onaylıyorsa okumayı bırakmışlardır ve kontrol, arkasına denetim izi iliştirilmiş bir tiyatroya dönüşmüştür. Onay oranını ve karara kadar geçen medyan süreyi, gecikme ve maliyetle aynı düzeyde birinci sınıf metrik olarak izleyin. Üç saniye süren bir onay lastik damgadır ve öyle raporlanmalıdır. Çözüm insanları uyarmak değil hacmi düşürmektir: incelemeyi tetikleyen güven eşiğini yükseltin, yalnızca geri alınamaz eylemleri kapılayın ve düşük riskli kalemleri kesintiye uğratan bildirimler yerine periyodik bir özette toplayın. Bir inceleyicinin günde on dakikada gerçek dikkatle bitirdiği bir kuyruk, iki saniyeden günde yüz onaydan daha değerlidir.

İncelemenin gerçek olup olmadığına arayüz karar verir. İnceleyene gerekçeyi değil etkiyi gösterin: değişecek kaydın tam hâli, önceki ve sonraki değerler, alıcı ve gönderilecek metnin birebir kendisi. Görselleştirilmiş bir düşünce zinciri kanıt değildir ve onu okumak, inceleyenlerin yanlış bir eylemi onaylamaya kendilerini ikna etme biçimidir; çünkü kendinden emin bir açıklamayı takip etmek bir farkı okumaktan kolaydır. Bekleyen her onaya bir son tarih ve açık değil kapalı biten bir varsayılan verin. Reddetmeleri de kayda alın; çünkü önerileri beşte bir oranında reddedilen bir araç, özerkliğe hazır olmayan bir araçtır ve bu oran elde edeceğiniz en temiz sinyaldir.

Gerçekten Tutan Kontrol Seti

Önce bütçeler gelir ve bunlar çalışma zamanında zorlanır. Her çalışma bir azami adım sayısı, bir azami token harcaması, bir duvar saati son tarihi ve bir para tavanı alır; bunlardan herhangi birine değmek çalışmayı sonlandırır ve hangi limitin tetiklendiğini kaydeder. Limiti sistem istemine yazmak kontrol sayılmaz; bütçeye uyması istenen bir model, zaman zaman görevin devam etmeye değecek kadar önemli olduğuna karar verir. Bütçeler hem çalışma başına hem kiracı başına olmalıdır ki patolojik tek bir iş yükü herkesin kotasını tüketemesin. Sonlandırılan çalışma da kaybolmak yerine bir insanın gerçekten baktığı bir yere düşmelidir; çünkü tavana çarpan bir çalışma kılık değiştirmiş bir hata raporudur.

Idempotency anahtarları ve ölü mektup kuyrukları (dead-letter queue) ikinci katmandır ve doğrudan sıradan dağıtık sistem pratiğinden gelir. Yan etkisi olan her araç çağrısı, çalışma kimliği ve adım indisinden türetilmiş bir anahtar taşır; böylece zaman aşımından sonraki bir yeniden deneme ikinci bir kayıt yaratmak yerine aynı kaydı günceller. Bu olmadan ilk ağ kesintisi mükerrer faturaya ve bir mutabakat projesine dönüşür. Kalıcı olarak başarısız olan çalışmalar aynı duvara tekrar tekrar sürülmek yerine tam iz kayıtlarıyla birlikte ölü mektup kuyruğuna gider ve o kuyruğun adı belli bir sahibi ile bir inceleme ritmi vardır. Kimsenin okumadığı bir ölü mektup kuyruğu, aynı bilgiyi kaybetmenin daha yavaş bir yoludur.

Ardından zaten savunduğumuz değerlendirme ve iz kaydı gelir, bir de henüz savunmadığımız acil durdurma anahtarları. Üç seviyeye ihtiyacınız var: tek bir aracı kapatmak, tek bir iş akışını kapatmak ve tüm ajan yürütmesini durdurmak. Her biri nöbetteki kişi tarafından, dağıtım yapmadan işletilebilmeli ve her biri olay anında keşfedilmek yerine tatbikatla denenmiş olmalıdır. Lansman öncesi cevaplanacak soru basit: bu sistemi gece üçte kim durdurabilir ve bu kaç dakika sürer. Dürüst cevap bir pull request ve bir derleme hattı içeriyorsa elinizde acil durdurma anahtarı değil, bir niyet vardır. Tatbikatı çeyrekte bir yapın ve geçen süreyi kaydedin; hiç ölçülmemiş bir durdurma prosedürü, olay anında ilk kez denenen bir prosedürdür.

Son olarak, diğer kontrollerin hepsini karşılanabilir kılan kontrol: aşamalı özerklik (staged autonomy). Ajan, iş gerekçesi öyle varsaydığı için lansmanda yetki almaz; sicilini kurarak yetki kazanır. Birinci aşamada gölgede çalışır, önerileri kaydedilir ve insanın gerçekte ne yaptığıyla karşılaştırılarak puanlanır. İkinci aşamada önerir, insan yürütür. Üçüncü aşamada geri alınabilir araçlarda özerk davranır, geri alınamaz olanlardan önce sorar. Dördüncü aşamada açık limitler içinde davranır ve örneklemeli inceleme yapılır. Aşamalar arası geçiş, bir önceki aşamanın sayılarına dayanan bir karardır ve bir metrik bozulduğunda ileri gittiği kadar kolay geri gider. Her aşamanın terfi ölçütünü baştan yazın; yoksa karar sayıya değil, ekibin bekleme sabrına bağlı kalır.

Ajanları Nasıl Kuruyor ve Nasıl İşletiyoruz?

HatsonTech'te ajan iş akışları kurarken istemden değil araç katmanından başlarız ve bu sıralama bilinçlidir. Herhangi bir model işin içine girmeden önce her aracın şemasını, tiplenmiş hata kodlarını, idempotency semantiğini ve geri alınabilir mi, telafi edilebilir mi, yoksa geri alınamaz mı olduğunu tanımlarız. Bu belge genellikle iki üç sayfadır ve istem metninin önemi başlamadan çok önce sistemin baskı altındaki davranışının büyük kısmını belirler. İstemden başlayan ekipler bu özellikleri bir olay sırasında keşfeder. Fatura uç noktasının idempotent olup olmadığını dokuzuncu haftada gece ikide değil, birinci haftada tartışmayı tercih ederiz. Bu belge aynı zamanda müşteri tarafındaki ekiple aramızdaki teknik mutabakattır; tartışma çıktığında herkesin döndüğü referans o olur.

Ölçeklendirmeden önce de ölçeriz. Tam iz kayıtları, çalışma başına maliyet muhasebesi ve adım sayısı dağılımı, iş akışı tek bir ekibin dışına çıkmadan devreye alınır; çünkü bunları canlı bir sisteme sonradan takmak hem daha zordur hem de daha az işe yarar — o noktada karşılaştıracağınız referans çizgisini çoktan kaybetmişsinizdir. Yönetişim tarafında KVKK, 12 Mart 2026'da 'Etken Yapay Zekâ (Agentic AI)' başlıklı bir doküman yayımladı. Bu bağlayıcı bir düzenleme değil rehber niteliğindedir; ancak Türkiye'deki bir veri sorumlusuna özerk bir sistem hakkında sorulacak soruları, özellikle ilgili kişinin aydınlatılması ve otomatik kararlar üzerinde anlamlı insan gözetimi başlıklarında, makul bir kontrol listesi olarak görüyoruz.

Yaptığımız ajan işinin çoğu aslında model işi değildir. Olasılıksal bir bileşenin etrafındaki özel yazılım mühendisliğidir: kuyruklar, idempotency, daraltılmış kimlik bilgileri, iz kayıtları, onay arayüzleri ve sistemin gerçek bir iş yüküyle temastan sağ çıkıp çıkmayacağına karar veren o gösterişsiz güvenilirlik katmanı. Bir problem için ajanın yanlış biçim olduğunu söylemekten de çekinmeyiz; bize sorulan iş akışlarının önemli bir kısmında, ortasında tek bir model çağrısı olan deterministik bir hat daha ucuz, daha hızlı ve denetimde savunması çok daha kolaydır. Ajanlar karmaşıklığını ancak izlenecek yol gerçekten önceden yazılamadığında hak eder. Bu değerlendirmeyi de altı ay sonra değil, ilk iki hafta içinde yapmayı tercih ederiz.