Her birkaç ayda bir sektör, kendi başına düşündüğü iddia edilen yazılımlar için yeni bir terim uyduruyor. Şu anki kelime "Agentic AI." Satıcılar bunu açılış sayfalarına ve sunum dosyalarına yapıştırmakta oldukça hızlılar. Ancak bir etiket, sistem sizin ortamınızla, verilerinizle ve hata modlarınızla temas kurana kadar sadece bir pazarlama metninden ibarettir. Kelimenin kendisi size güvenlik, güvenilirlik veya uygunluk hakkında hiçbir şey söylemez.

Özellik listelerini okumayı bırakıp yetenekleri ölçmeye başlama zamanı geldi.

Etiket Sorunu

Satış mühendisleri, "agentic" bir mimarinin kanıtı olarak size paneller, çoklu model açılır menüleri ve mobil erişim gösterecektir. Bunlar arayüz seçimleridir, davranışsal garantiler değildir. Bir ürün son teknoloji gibi görünebilir ancak bir API zaman aşımından sonra bir planı revize etmesi gerektiği anda çökmeye başlayabilir.

Önemli olan, sistemin gerçekten otonom bir ajan gibi davranıp davranmadığıdır. İşi adımlara bölüyor mu? Katı sınırlar dahilinde gerçek sistemlere müdahale ediyor mu? Bir şeyler bozulduğunda uyum mu sağlıyor, yoksa sadece hata verip bekliyor mu? Bu soruları kendi teknoloji yığınınıza (stack) özgü kanıtlarla yanıtlayana kadar bir ürün değil, bir kavram satın alıyorsunuz demektir.

Gerçekten Önem Taşıyan Beş Yetenek Testi

Her bir "agentic" iddiasını beş spesifik yetenek üzerinden değerlendiriyorum. Her biri için basit bir triyaj sorusu soruyorum: Davranış belgelenmiş mi, bir pilot çalışmada doğrulanmış mı, yoksa hala bilinmiyor mu? Varsayılan durum "bilinmiyor"dur. Aksini kanıtlama yükümlülüğü ürüne aittir.

Planlama. Sistem, belirsiz bir hedefi sıralı ve doğrulanabilir adımlara bölüyor mu? Herkes bir yapılacaklar listesi oluşturabilir. Asıl test, "bu çeyrekte bulut harcamalarımızı yüzde on beş azaltın" gibi karmaşık bir hedefi yönetmektir. Gerçek bir ajan, mevcut kullanımın denetimini planlar, atıl kaynakları belirler, boyutlandırma (rightsizing) önerileri taslak haline getirir ve değişiklik taleplerini uygun sırayla planlar. Eğer size genel geçer beş maddelik bir yazı sunup işi bitmiş sayıyorsa, bu planlama değildir; özetlemedir.

Araçlar. Belirlenmiş bir kapsam dahilinde gerçek sistemler üzerinde işlem yapıyor mu? Şık bir demoda sahte (mock) bir API'yi çağırmak kolaydır. En az yetki prensibiyle (least-privilege) üretim ortamındaki CRM'nize kimlik doğrulaması yapmak, bir kayıt yazmak ve işlemi günlüğe kaydetmek zordur. Hangi sistemlere dokunduğunu, hangi anahtarları taşıdığını ve etki alanının (blast radius) nerede bittiğini tam olarak bilmeniz gerekir. Kapsam sınırlandırılmış olmalıdır. Eğer ajan varsayılan olarak üretim ortamına yazma erişimine sahipse, bir ajanınız yok demektir; bir riskiniz (liability) vardır.

Düzeltme. Bir hatadan sonra bir sonraki hamlesini değiştiriyor mu? Çoğu prototipin öldüğü yer burasıdır. Üçüncü adım bir 503 hatası veya şema uyumsuzluğu döndürdüğünde, ajan sonsuz döngüye mi giriyor, bir başarı mesajı mı uyduruyor (hallucinate), yoksa yolunu mu değiştiriyor? Gerçek düzeltme; hatayı gözlemlemek, iş akışının geri kalanını yeniden planlamak ve kısıtlamaları göz ardı etmeden yeni bir yol yürütmek demektir. İyimserlikle sarmalanmış bir yeniden deneme döngüsü düzeltme değildir.

Bağlam. Her adımda kısıtlamaları aktif tutuyor mu? Bellek tek başına yeterli değildir. Eğer birinci adım "beş yüz dolarlık bütçeyi aşmayın" veya "AB müşteri verilerini hariç tutun" gibi katı bir kural koyuyorsa, yedinci adım istem (prompt) bağlamı değişti diye bu sınırı görmezden gelemez. Bu durum uyumluluk kuralları, marka sesi, onay hiyerarşileri ve erişim kontrolleri için de geçerlidir. Bağlamın korunması, uzun bağlamlı (long-context) modeller ile klasik durum yönetiminin (state management) buluşması gereken noktadır.

Denetim. Bir insan süreci durdurabilir veya devam ettirebilir mi? Sadece sanal makine üzerinde bir kapatma düğmesine (kill switch) değil, ayrıntılı devre kesicilere (circuit breakers) ihtiyacınız var. Birisi ikinci adımdan sonra planı inceleyip üçüncü adımı onaylayabilir mi? Harici bir bağımlılık hata verirse, bir insan durumu (state) kaybetmeden hatayı düzeltebilir ve iş akışına devam edebilir mi? Denetim, felaket gerçekleştikten sonra okuduğunuz bir denetim günlüğü değildir; müdahale için canlı bir mekanizmadır.

Kanıt, Onay Kutularından Daha Üstündür

Bir demo, güvenilirlik oranı demek değildir. Bir tedarikçi karşılaştırma tablosundaki onay kutusu kanıt değildir. Bir hesap yöneticisi ürünün "test hatasından sonra revize ettiğini" söylediğinde, bir sonraki adımınız kanıt kartını (evidence card) istemek olmalıdır.

Bir kanıt kartı, onay kutusunun yerini spesifiklikle doldurur. Şuna benzer:

  • Yetenek: Düzeltme
  • İddia: Test hatasından sonra revize eder
  • Kanıt: Kontrollü düzenek (fixture) bekleniyor
  • Sorumlu: Geliştirici deneyimi (developer-experience) ekibi
  • Şu durumda durdur: Revizyon onaylanmış bir arayüzü değiştirirse

Bu format netliği zorunlu kılar. Pazarlama iddiasını kanıttan ayırır. Sorumluluk atar; böylece ajan, revizyon denemesi sırasında onaylanmış bir arayüzü bozduğunda, tam olarak hangi ekibin çağrılması gerektiğini bilirsiniz. Bir sahip olmadan hesap verebilirlik olmaz. Durdurma koşulları olmadan güvenlik bariyeri olmaz.

Herhangi bir pilot uygulamayı başlatmadan önce üç şeyi yazılı olarak tanımlayın. Birincisi, görevleriniz. Bunlar sentetik kıyaslamalardan (benchmarks) değil, gerçek iş mantığından türetilmelidir. İkincisi, hata testleriniz. Çalışma sırasında bir API anahtarını iptal edin, hatalı bir JSON yanıtı enjekte edin veya beklenen gecikme süresini iki katına çıkarın. Üçüncüsü, durdurma koşullarınız. Bunlar otomatik olmalıdır; birinin fark etmesini umduğunuz manuel bir panik butonu değil.

Tedarikçi İddiaları Nasıl Sorgulanır

OpenAI, ajanların beş bileşene ihtiyaç duyduğunu öne sürüyor: modeller, araçlar, talimatlar, koruma bariyerleri (guardrails) ve insan müdahalesi. Bu listeyi, tedarikçilerin özel mimarilerini benimsemeden onları sorgulamak için bir kelime dağarcığı olarak kullanabilirsiniz.

Hangi modelin sadece üretim yapmak yerine planlamayı yönettiğini sorun. Hangi araç izinlerinin sabit kodlu (hardcoded), hangilerinin dinamik olduğunu sorun. Koruma bariyerlerinin nerede uygulandığını; istem (prompt) katmanında mı yoksa orkestrasyon motorunda mı olduğunu sorun. İnsan müdahalesinin yerleşik bir kontrol noktası mı yoksa ajan veritabanınızı çoktan mahvettikten sonra gönderilen bir ölüm sonrası (post-mortem) e-postası mı olduğunu sorun. OpenAI'ın teknoloji yığını (stack) için alışveriş yapmıyorsunuz. Başkasının sistemindeki boşlukları ortaya çıkarmak için onların çerçevesini kullanıyorsunuz.

MonkeyCode açık kaynaklı bir yol ve ücretsiz bir bulut sürümü sunuyor. Bu kombinasyon, bir pilot uygulamaya başlamayı ucuz hale getiriyor. Ancak ucuz giriş, doğrulanmış başarıyla aynı şey değildir. Sistemin bilinmeyen kısımları, kendi altyapınızda kendi görevlerinizi çalıştırmadığınız sürece bilinmez kalmaya devam eder. Sıfır dolarlık bir biletin, zor soruların yanıtlandığını düşünmenize neden olmasına izin vermeyin.

Bütçe Tasarrufu Sağlayan Bir Satın Alma Kuralı

Ajan tabanlı (agentic) bir pilot uygulamayı üretim aşamasına (production) taşımak için kuralım basittir. Kapsamı ve bütçeyi yalnızca kritik yeteneklerin kanıtı olduğunda ve hatalar için net bir sahibi olduğunda artırırım. Bir yol haritası slaytı değil. Bir destek talebi kuyruğu değil. Kanıt, kendi ortamınızdan gelen günlükler (logs) demektir. Sahip ise, o spesifik hata modu için çağrı cihazı (pager) taşıyan, ismi belli bir insan demektir.

Eğer tedarikçi size kanıt gösteremiyorsa veya dahili ekibiniz bir sahip atayamıyorsa, genişlemeye hazır değilsiniz demektir. Test etmeye devam etmeye hazırsınızdır.

Unutulmaması gereken: "Agentic" kelimesi değerlendirmeniz için bir başlangıç tabancasıdır. Bitiş çizgisi değildir. Onu daha zor sorular sormak, daha sıkı pilotlar yürütmek ve kendi bünyenizde önem arz eden kanıtlar talep etmek için bir istem (prompt) olarak görün. Eğer ürün, sizin sahanızda ve sizin hatalarınızla beş yetenek testinden geçemiyorsa, gerçekten ajan tabanlı değildir. Sadece başka bir demodan ibarettir.

Kaynak: https://dev.to/bestbee/is-it-really-agentic-ai-use-a-five-capability-product-gate-1c0h

İsteğe bağlı öğrenme topluluğu: https://t.me/GyaanSetuAi