Agent Framework + AGT: Üretimde Yönetişim Şart

Geçen hafta bir bankacılık müşterisinde garip bir toplantı öldü. Ekip, Microsoft Agent Framework ile fena olmayan bir kredi danışman ajanı kurmuştu. Demo akıyordu. Sonra güvenlikten biri elini kaldırdı: “Peki bu ajan, üretimde gerçekten 50 bin TL üstü krediyi onaylamaya kalkarsa ne olacak?” Salonda hava bir anda değişti. Geliştirici tarafı “prompt’a yazarız” dedi. Güvenlik tarafı güldü. Haklıydılar da.

İşte tam o noktada, yanı ajan inşa etmekle ajan yönetmek arasındaki o rahatsız edici boşlukta, Microsoft’un yeni duyurduğu Agent Governance Toolkit (AGT) devreye giriyor. Bu yazıda hem teknik tarafını anlatacağım hem de Türkiye’deki kurumsal müşterilerde gördüğüm tabloyu paylaşacağım. Lafı gevelemeden başlayalım.

Bunu biraz açayım.

Ajan Yapmak Kolay, Üretime Almak Zor

Açık konuşayım: 2024’ten beri ajan tabanlı sistemlerde asıl dert “model seçimi” ya da “orchestration” değil. Orası artık bir yere kadar çözülmüş durumda. İlginç, değil mi? Asıl mesele, bu ajanları kurumsal politika, denetim ve KVKK gıbı gerçek dünya kısıtlarına nasıl oturtacağınız.

Bir finans projesinde başımıza şu geldi: Ajan, müşteri kimlik bilgisini bir CRM API’sine yazıyordu. Test ortamında sorun yoktu. Canlıya çıktıktan iki gün sonra fark ettik ki ajan, “yardımcı olmak” isterken müşterinin TC kimliğini başka bir endpoint’e de loglamış (inanın bana). Kötü niyet falan yoktu; sadece prompt’taki bir cümleyi fazla geniş yorumlamıştı. İşte LLM’lerin tabiatı bu. Determinizm yok. O yüzden yönetişim, prompt katmanında değil, action katmanında olmak zorunda.

İtiraf edeyim, Microsoft Agent Framework 1.0 inşa, orkestrasyon ve A2A protokol uyumu tarafını çözüyor. AGT işe bunun üstüne “çalışma zamanı yönetişimi” ekliyor: deterministik politika denetimi, zero-trust kimlik, sandbox’lı execution ve otonom ajanlar için SRE araçları. İkisi birlikte tam yığını tamamlıyor gıbı duruyor.

Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.

“Agent Framework ‘build & orchestrate’ işini yapıyor, AGT ‘govern & audit’ işini. Bu ayrımı net görmek lazım — yoksa her şeyi prompt’a yıkmaya çalışırsınız ve hüsrana uğrarsınız.”

Neden Yönetişim Tam Olarak “Action” Katmanına Ait?

Bu konuyu birçok müşteriyle tartıştım. İlk refleks genelde şu oluyor: “İçerik filtreleri var ya, prompt shield var, yeter bunlar.” Yetmiyor. Çünkü içerik güvenliği LLM’in girdi/çıktısını denetler; yanı model ne söylüyor‘a bakar. Oysa ajan tool çağırdığında kimse ne yapıyor‘a bakmıyor.

AGT bu boşluğu kapatıyor. Agent Framework’ün middleware pipeline’ına direkt takılıyor ve şöyle çalışıyor:

Ajan Aksiyonu -> Politika Kontrolü -> Izin / Red -> Audit Log
(~ 0.1 ms)

Her tool çağrısı, her kaynak erişimi, her ajandan ajana mesaj; hepsi politikaya karşı kontrol ediliyor (ciddiyim). Üstelik sub-millisecond overhead ile. Sidecar yok, proxy yok. Bu önemli; çünkü sidecar bazlı policy enforcement çözümlerinden ben çok çektim. Latency 30-40 ms’ye fırlıyordu ve müşteri de haklı olarak “neden ajan bu kadar yavaş?” diye soruyordu.

Iki Katman, Tek Pipeline

Şöyle düşünün: Agent Framework içerik güvenliği yapıyor (içerideki “ne konuşuluyor”). AGT işe eylem güvenliği sağlıyor (dışarıya “ne yapılıyor”). Katmanlar farklı ama aynı middleware borusundan akıyorlar. Bence bu mimarı tercih baya iş görüyor; iki ayrı SDK öğrenmek zorunda kalmıyorsunuz.

Kısa bir not düşeyim buraya.

Kod Tarafı: Native Entegrasyon Nasıl Görünüyor?

Şimdi pratiğe geçelim. AGT middleware’leri Agent Framework’ün middleware parametresine doğrudan ekleniyor; yanı loglama veya content safety eklediğiniz yere aynı mantıkla koyuyorsunuz:

from agent_framework import Agent, tool
from agent_framework.openai import OpenAIChatClient
from agent_os.integrations.maf_adapter import (
GovernancePolicyMiddleware,
CapabilityGuardMiddleware,
RogueDetectionMiddleware,
AuditTrailMiddleware,
)
agent = Agent(
client=OpenAIChatClient(model="gpt-5.3"),
name="Contoso Kredi Uzmani",
instructions="Sen yönetişim altında çalışan bir kredi asistanısın.",
tools=[kredi_skoru_sorgula, faiz_orani_getir, küçük_kredi_onayla],
middleware=[
AuditTrailMiddleware(audit_log=audit_log, agent_did="kredi-ajani"),
GovernancePolicyMiddleware(evaluator=evaluator, audit_log=audit_log),
CapabilityGuardMiddleware(max_amount=50000),
RogueDetectionMiddleware(threshold=0.85),
],
)

Şöyle ki, Bakın burada dört farklı middleware var ve her biri ayrı bir derdi çözüyor gıbı duruyor (şaşırtıcı ama gerçek). Audit trail var, politika değerlendirme var, yetenek kısıtlama var, anomali tespiti var. Geçen ay Handoff Orchestration: Ajanlar Birbirine Topu Atınca Ne yazısında değindiğim ajanlar arası geçişlerde bu katmanlar daha da kritikleşiyor — çünkü topu atan kim, alan kim, ne yetkiyle aldı; hepsi izlenebilir olmalı.

Middleware’lerin Görevleri: Tek Tek Bakalım

Ne yalan söyleyeyim, Bunu biraz açmak lazım. Aşağıdaki tabloyu kendi notlarımdan derledim; müşterilere anlatırken de kullanıyorum:

Middleware	Ne yapıyor?	Tipik kullanım
AuditTrailMiddleware	Her aksiyonu kim, ne zaman, neden yaptı diye loglar	Regülasyon, KVKK, denetim
GovernancePolicyMiddleware	Tanımlı politikalara karşı runtime kontrol	Iş kuralları, segregation of duty
CapabilityGuardMiddleware	Ajanın yetenek sınırlarını zorlar (örn. max tutar)	Finansal limitler, blast radius kontrolü
RogueDetectionMiddleware	Anormal davranış skorlaması yapar	Prompt injection, hijack tespiti

Pratik örnek verelim: CapabilityGuardMiddleware(max_amount=50000) dediğinizde ajan ne yaparsa yapsın 50 bin üstü bir onay vermeye kalktığında deterministik şekilde duruyor. Prompt’a güvenmiyorsunuz; matematiksel sınır koyuyorsunuz. Bence fark burada. Kubernetes v1.36 Volume Group Snapshot: Sonunda GA Oldu yazımızda bu konuya da değinmiştik.

Bir Hata Hikâyesi

Ilk denememde RogueDetectionMiddleware‘ı yanlış sıraya koymuştum — audit trail’den sonra yerleştirdim yanı. Sonuç? Anomali tespit edilince log düşüyordu ama olay zaten olmuş ölüyordu bile. Sıra önemliymiş meğersem. AGT dokümanında yazıyor aslında ama ben okumadan kullanmaya kalkmıştım; klasik hata işte. Daha fazla bilgi için Azure Red Hat OpenShift: AI Üretimine Geçişin Hikayesi yazımıza bakabilirsiniz.

Neyse uzatmayayım: doğru sıra önce detection ve guard, sonra policy, en sonda audit oluyor gıbı düşünün. Yanı savunma katmanları içten dışa doğru diziliyor.

Peki Türkiye Tarafı: Bu Is Bize Nasıl Oturur?

Şimdi kaynak makalede olmayan bir yere geçeyim biraz. Çünkü Microsoft’un bloğunda yazan şey global; ama Türkiye’deki kurumsal müşteriler açısından tablo biraz farklı. Bu konuyla ilgili CodeQL 2.25.4 Çıktı: Swift, C# ve Java Tarafında Neler Var? yazımıza da göz atmanızı tavsiye ederim.

Işin ilk kısmı KVKK ve BDDK regülasyonları. Bir bankada ajan tabanlı sistem kurduğunuzda denetçi geliyor ve “bu kararı kim verdi, neye dayanarak?” diye soruyor. “Modelin halüsinasyonu” diye cevap veremezsiniz tabii ki. AGT’nın audit trail tarafı tam burada değerli oluyor gıbı geliyor bana; her tool call’un evidence’ı var, hash’i var, zaman damgası var da var.

BDDK denetimine bu kayıtlarla girdiğinizde işiniz baya kolaylaşıyor.

Bunu söyleyebilirim çünkü iki ayrı banka projesinde benzer audit altyapısını manuel kurmaya çalıştık ve epey ter döktük. Bu konuyla ilgili Kubernetes v1.36 Workload API: PodGroup Devri Başladı yazımıza da göz atmanızı tavsiye ederim.

İkinci konu maliyet boyutu. Azure OpenAI üzerinden gpt-5 sınıfı modelle ajan çalıştırıyorsanız her gereksiz tool call hem latency hem TL demek.

AGT’nın policy katmanında “bu tool’u bu ajan zaten çağıramaz” diyebilmek modeli boş yere konuşturmuyor.

Küçük bir hesap yaparsak: Günde 50 bin ajan çalıştıran orta ölçekli bir e-ticaret şirketinde gereksiz tool çağrılarını %15 azaltmak aylık 6 haneli TL’ye denk gelebiliyor.

Bu rakamı bir müşteride bizzat gördüm; şaşırdım açıkçası.

Büyük Ekip mi Küçük Ekip mi? Hangı Yaklaşım?

Bunu çok soruyorlar gerçekten.

Kısaca şöyle diyeyim: Bu konuyla ilgili GPT-5.5 Microsoft Foundry’de: Sahadan İlk Değerlendirme yazımıza da göz atmanızı tavsiye ederim.

Kısa bir not düşeyim buraya.

• Küçük ekip / startup:Ilk başta sadece AuditTrailMiddleware + CapabilityGuardMiddleware‘den başlayın.

  Politika dosyaları yazmak için vakit harcamayın.

  En azından ne olduğunu görün, sınırları koyun; sonra ince ayar yaparsınız.

• Orta ölçek (50-500 kişi):Burası geldiğinde policy katmanı şart oluyor.

  Bir DevSecOps mühendisinizi AGT politikalarını yazmaya ayırın.

  Copilot Agent Evaluations: Ajan Kalitesini Ölçen CLI Geldi yazısında bahsettiğim test/evaluation tarafıyla beraber yürütmek lazım bence.

• Enterprise:Böyle ortamlarda AGT zaten olmazsa olmaz gıbı duruyor.

  Üstüne kendi policy DSL’ınızı yazıp git üzerinden version’layabilirsiniz.

  Zero-trust kimlik tarafını mutlaka kullanın — ajanlar arası mesajlaşmada kilit oluyor.

Ilk Adım Olarak Ne Yapmalı?

Eğer “yarın denemek istiyorum” diyorsanız somut başlangıç planı şöyle olabilir:

1. Mecut Agent Framework projenize bir AuditTrailMiddleware ekleyin.

   Hiçbir şeyi kısıtlamayın; sadece izleyin.

2. Iki hafta log toplayın.

   Ajanın daha doğrusu gerçekten hangı tool’ları hangı argümanlarla çağırdığını görün.

   Sürpriz çıkacak mı?

   Bence evet.

3. Kayıtları analiz edip blast radius’u en yüksek 3 tool’u seçin.

   Yanı yanlış çağrıldığında en çok zarar verecek olanları ayıklayın.

4. O üç tool için CapabilityGuardMiddleware tanımlayın.
5. Daha sonra policy katmanına geçin.

B u sırayı atlamayın derim.

Önce gözlem geliyor.

Sonra kısıtlama.

En son politika.

Tersi olursa kendi ajanınızı çalışamaz hâle getirirsiniz ve developer ekibi sizden nefret eder; açık konuşayım durum tam olarak bu ölür.

Eksi Bulduğum Taraflar

Sadece övmek istemem çünkü gerçek hayatta işler pek toz pembe ölmüyor.
AGT’nın şu an için bazı eksikleri var bence:

Şöyle ki, Ilk olarak,
policy authoring deneyimi henüz ham.
Yanı politikaları yazarken Open Policy Agent (OPA) benzeri bir dile alışkın olanlar AGT’de biraz tuhaf hissedebilir.
Bir DSL bekliyordum;
henüz tam o seviyede değil.
Microsoft tarafının bunu birkaç sürümde olgunlaştıracağını umuyorum.
İkinci olarak,çok büyük ölçekte (binlerce eşzamanlı ajan) performans karakteristiğini henüz saha verisiyle doğrulamadım.
Microsoft “sub-millisecond” diyor. Bu rakam tek ajan için.
10 bin paralel ajanda audit log throughput’u nasıl davranır?
Bunu birkaç ay sonra göreceğiz.
Şimdiden kesin konuşmak erken ölür.
Üçüncüsü,
görselleştirme/dashboard tarafı zayıf.
Log toplanıyor ama “ne olup bittiğini” anlamak için kendi Power BI veya Grafana dashboard’unuzu kurmanız gerekiyor.
Hazır gelen bir gözlem panosu yok;
gel gelelim bence bu da zamanla gelir.

Tam da öyle.” (şaşırtıcı ama gerçek)

Service Bus ve Asenkron Senaryolar

Bir de şu tarafta durum farklı:
birçok ajan mimarisi asenkron mesaj kuyruğu üzerinden çalışıyor.
Ajanlar Service Bus üzerinden konuşuyor.
Bu senaryoda AGT middleware’ının nereye konulacağı önemli.
Ben kendi projede consumer tarafında,
yanı mesaj işlemeye başlamadan hemen önce yerleştirdim.
Bu konuda daha derin bir
Service Bus + Azure Functions: Backoff. Circuit Breaker yazımda (belki yanılıyorum ama) da değinmiştim; oradaki retry mantığıyla AGT’nın red mekanizması arasında ince bir çizgi var. Politika reddederse Service Bus’a abandon mu diyeceksiniz, dead-letter’a mı atacaksınız? Bunu projeye özel kararlaştırmak lazım.

Sıkça Sorulan Sorular

Agent Governance Toolkit, Agent Framework’ten ayrı bir ürün mü?

Evet, ayrı bir açık kaynak proje. Ama şunu söyleyeyim — Agent Framework’ün middleware pipeline’ına native entegre çalışıyor, yanı iki ayrı runtime kurmuyorsunuz (buna dikkat edin). AGT, Agent Framework’ün içine takılan ek bileşenler sunuyor, aslında oldukça temiz bir entegrasyon.

AGT kullanmak performans kaybına yol açar mı?

Microsoft’un açıkladığı rakam policy check başına sub-millisecond — yanı tek bir tool çağrısı için 0.1 ms civarı bir overhead çıkıyor. Bence bu ihmal edilebilir bir seviye, hani düşünsenize LLM çağrısı zaten 800-2000 ms sürüyor. Audit log yazımı da asenkron yapıldığı için kritik yolu etkilemiyor, açıkçası bu detay çok önemli.

Mevcut Semantic Kernel projemde de kullanabilir mıyım?

Şu anki resmî entegrasyon Microsoft Agent Framework 1.0 üzerinden gidiyor. Semantic Kernel için doğrudan bir adapter yok maalesef,. Agent Framework’e migrate ettiğinizde otomatik olarak kullanabiliyorsunuz (evet, doğru duydunuz). Microsoft zaten Agent Framework’ü Semantic Kernel’in ileri evrimi olarak konumlandırıyor, yanı bu geçiş er ya da geç kaçınılmaz gıbı görünüyor.

KVKK uyumluluğu için AGT yeterli mi?

AGT teknik altyapıyı sunuyor — audit, policy, denetlenebilirlik gıbı şeyler. Ama tecrübeme göre KVKK — ki bu tartışılır — uyumu sadece teknik değil, ciddi bir hukukî ve süreç boyutu da var. AGT’nın sağladığı kayıtlar denetim sırasında gerçekten çok işinize yarıyor,. Mesela veri işleme envanteri veya açık rıza yönetimi gıbı konuları ayrıca ele almanız gerekiyor.

AGT’yi production’a almadan önce hangı testleri yapmalıyım?

En az üç senaryo lazım: (1) Normal akış — politika hiç tetiklenmemeli, latency baseline’ı ölçün (ciddiyim). (2) Politika reddi — beklenen bloklamaların gerçekten olduğunu doğrulayın. (3) Audit log integrity — kayıtların tam, sıralı ve değiştirilemez olduğunu test edin. Bunlara ek olarak load test şart, bence bu adımı atlamak en büyük risk; yanı tek ajanla değil 50-100 paralel istekle mutlaka deneyin.

Kaynaklar ve İleri Okuma

Microsoft DevBlogs — Governance at the Speed of Agents (Orijinal Yazı)

Garip gelecek ama, Microsoft Agent Framework Resmî Dokümantasyonu

Bence, Microsoft Agent Framework GitHub Reposu

Azure OpenAI Content Filtering — Tamamlayıcı Katman