Geçen hafta MIT Technology Review'da kurumsal ajan mimarisi üzerine bir yazı çıktı. İçinde operasyon masasına doğrudan oturan somut bir ölçüt var. Künyesi de en az ölçüt kadar önemli.
Künyeyi önce yazayım. Sayfanın üstünde “Sponsored” etiketi ve “Provided by Intel” ibaresi duruyor, sonunda da bir not var. Notun Türkçesi şu: bu içeriği Intel üretti, MIT Technology Review'ın editör kadrosu yazmadı. Dergi kaynağı gizlemiyor. Ama etiketi gören okuyucu yazıyı iki katmanda okur: ölçüt ve tavsiye. İkisi aynı şey değil.
Ne oldu
Building the enterprise environment for agentic AI 27 Temmuz 2026'da yayımlandı. Yazarlar Keegan Sheedy ve Lucas Melo, içerik Intel tarafından sağlandı.
Ana iddia şu: kurumsal ajan bir çıkarım sorunu değil, bir sistem sorunudur. Yazı beş ders sıralıyor, ikisi doğrudan işine yarar.
Birincisi kapasite. Ajan kapasitesi ajan sayısıyla planlanmaz, vCPU başına ajan yoğunluğuyla planlanır. Yazıdaki örnek net: 8 vCPU üzerinde 10 ajan ile 16 vCPU üzerinde 20 ajan benzer davranır, çünkü yoğunluk aynıdır. Hedef yoğunluk da işin türüne göre değişir. Kullanıcının karşısında duran yardımcılar düşük yoğunlukta çalışmalı, çünkü yanıt süresi önemli. Toplu işler çoğu zaman daha yüksek yoğunluğu kaldırır.
İkincisi izleme. Ortalama CPU kullanımı ajan yükü için zayıf bir sinyal. Ajan, model yanıtını beklemekle kısa ve yoğun hesap patlamaları arasında gidip geliyor. Bu kesikli desende ortalama kullanım iyi görünürken kuyruk büyüyor ve kullanıcı deneyimi yavaşlıyor. Yazı P95 görev gecikmesini daha iyi bir öncü gösterge sayıyor, doğrulamayı da sürekli görev süresine bırakıyor.
Yazının altı metrikli bir görünüm önerisi de var; bunlardan ajan yoğunluğu ve gecikme, kapasite sözleşmesine girecek kadar somut.
Kanıt nereden geliyor
Yazı "binlerce ajan iş yükü deneyi" yapıldığını söylüyor. Yayımlanmış tek bir sayı yok. Tablo yok, veri seti yok, hakemli makale yok. Ölçümün kendisi değil, ölçümden çıkarılan dersler paylaşılmış.
Kullanılan koşum takımı ise açıkça yazılmış: Intel, Terminal-Bench adlı açık kaynak kıyaslama takımını profilleme ve telemetri ile genişletmiş. Terminal-Bench ciddi bir iş; deposu çalışmayı ICLR 2026 bildirisi olarak gösteriyor. Aynı depo takımın hâlâ beta olduğunu, yaklaşık 100 görev içerdiğini ve yeni kullanıcıların 2.0 sürümü için başka bir çatıya yönlendirildiğini söylüyor. Görev karışımı derlemeden ışın izlemeye, veritabanı işlemlerinden video dönüştürmeye uzanıyor.
Bir yöntem tercihi daha var: model yanıtları bir kez kaydedilip her koşuda aynen tekrar oynatılmış. Bu, koşular arası sapmayı azaltıyor ve karşılaştırmayı temizliyor. Karşılığında ölçülen sistem, gerçek model gecikmesinin değişkenliğini hiç yaşamıyor. Laboratuvar için doğru karar. Sahanın birebir kopyası değil.
Yani elimizde beta bir görev setinde, model gecikmesi sabitlenmiş koşullarda ölçülmüş bir sistem davranışı var. Yönler mantıklı. Sayılar senin ortamının taahhüdü değil.
Saha yorumum: kapasite yönetimi yeni bir birim aldı
20+ yıldır BT operasyonunun içindeyim ve kapasite yönetiminin dili hep aynı birimlerden kuruldu: CPU, bellek, disk IOPS, bağlantı havuzu, lisans adedi. Ajan iş yükü bunların hiçbirine temiz oturmuyor. Bu yüzden çoğu kurumda ajan konuşması kapasite masasına hiç gelmiyor.
Türkiye'de gördüğüm tablo bunu keskinleştiriyor. Ajan projeleri genelde bir dönüşüm başlığı altında başlıyor, bütçesi proje bütçesinden çıkıyor ve kapasite planına hiç girmiyor. Sorun pilotta görünmüyor. Ajanlar üretim yükünü paylaşmaya başladığı gün görünüyor.
vCPU başına ajan yoğunluğunun kıymeti tam burada. Sayının kendisinde değil, soruyu değiştirmesinde. "Kaç ajan çalıştırıyoruz" bir kadro sorusu. "Hangi hizmet seviyesinde kaç ajan çalıştırabiliriz" bir kapasite sorusu. İkincisi ITIL v4'ün kapasite ve performans yönetimi pratiğinin zaten sorduğu soru; ajan çağında yalnız birimi değişti.
P95 gecikme önerisi de yabancı değil. Hizmet seviyesi hedefini yüzdelik dilimle kuran her ekip bu dili zaten konuşuyor. Yeni olan, dili ajan filosuna taşımak. Ortalama kullanım üzerinden alarm kuran bir izleme yapısı ajan yükünde geç uyarır, çünkü sorun ortalamada değil kuyrukta birikir.
Bir uyarı: yoğunluk hedefi tek başına anlamlı değil. Hangi hizmet seviyesi için geçerli olduğu yazılmadan taşınırsa, bir sonraki kapasite tartışmasında herkesin elinde farklı bir sayı olur.
Tavsiyeyi kim veriyor
Yazının mimari önerisi net: varsayılan olarak yatayda ölçekle, dikey ölçeklemeyi istisnaya sakla. Gerekçeler makul. Ajanlar yarı bağımsız çalışır, ajan başına yük patlaması ölçülüdür, yatay büyüme performansı ve erişilebilirliği artırır, hedef yoğunluk oranını korumayı kolaylaştırır ve yazıya göre genelde toplam maliyeti düşürür. Son maddeyi özellikle yazıyorum; birazdan kuracağım itirazın karşısında duruyor.
Şimdi baştaki künyeyi hatırla. Bu tavsiyeyi bir işlemci üreticisi veriyor. Yatayda ölçeklemek daha çok sunucu, daha çok soket, daha çok genel amaçlı CPU demek. Tavsiye ile satıcının ürün hattı aynı yöne bakıyor.
Bu, tavsiyeyi yanlış yapmaz. Satıcı kaynaklı içeriğin çoğu yanlış değildir, eksiktir. Sorulmayan sorular vardır. Burada sorulmayan mesela şu: aynı iş yükünün ne kadarı hızlandırıcı tarafında veya yönetilen bir servis üzerinde daha ucuza koşar? Yazının çerçevesi bu soruyu hiç açmıyor, açmak zorunda da değil.
Kurumsal okuyucu için pratik kural: satıcı kaynaklı mimari tavsiyesini reddetme, çerçevesini test et. Sorulmayan soruyu sen sor.
Hazır olmak kalıcı bir durum değil
Aynı günlerde bambaşka bir alandan ikinci bir uyarı geldi. Nature Machine Intelligence'ın 24 Temmuz tarihli başyazısı veri kümelerinin yapay zekâya hazırlığını tartışıyor. Konu kurumsal ajan değil, biyolojik veri; bunu açıkça söyleyeyim. Ama tek bir tespiti doğrudan senin masana oturuyor: hazır olmak, veri kümesinin kalıcı bir özelliği değil.
Amarda Shehu ve Ruth Nussinov'un aynı sayıdaki yorumuna göre ClinVar veri kümesinde 2015 ile 2023 arasında 2 milyon klinik genetik varyantın yüzde 4,6'sı yeniden sınıflandırılmış. 2022 sürümüyle eğitilmiş bir klinik tahmin modeli, 2026 verisini yanlış yorumlayabiliyor. Model bozulmadı; altındaki gerçek değişti.
Aynı yorumun sorduğu dört soru, kurumsal ajan yönetişimine olduğu gibi taşınır: amaç ne, hangi varsayımlarla, ne kadar süreyle, hangi güvencelerle.
İki kaynak farklı şeyi ölçüyor. Biri hazır olmayı platform kapasitesi sayıyor. Diğeri hazır olmanın zamanla aşınan bir hizalanma olduğunu söylüyor. Kapasite planı bir kez kurulur ve bir süre tutar. Hizalanma sürekli bakım ister. Kurumsal ajan programında ikisine de ihtiyacın var, ama bütçe genelde yalnız birincisine ayrılıyor.
Ne yapmalı
Dört somut adım:
- Yoğunluğu ölç, sayıyı değil. Pilotunda kaç vCPU üzerinde kaç ajan koşuyor, yaz. Bu oran senin taban çizgin.
- Alarmı kuyruğa taşı. Ortalama kullanım eşiğinin yanına yüzdelik dilim tabanlı bir görev gecikmesi eşiği koy, önce onu izle.
- Çerçeveyi test et. Satıcı kaynaklı her mimari belgesinde, belgenin sormadığı soruların listesini çıkar. O liste senin gerçek değerlendirme kriterin.
- Dört soruyu yaz. Bu ajan ne için var, hangi varsayımlarla çalışıyor, bu varsayımlar ne kadar geçerli, hangi güvenceler devrede. Dördü de yazılı olmadan üretime alma.
Asıl soru şu: kurumundaki ajan tartışması hâlâ inovasyon masasında mı duruyor, yoksa kapasite ve hizmet seviyesi masasına oturdu mu?
İlgili Yazılar
Beş mühendisin üç günlük işi 30 dakikaya inince
NTT DATA'nın Codex vakasında olay analizi 30 dakikaya indi. Rakamın arkasındaki asıl ders: araçlar arası korelasyon, insan dikkatinin sınırını aşıyor.