Microsoft Agent Framework ve AGT: Ajanları Üretimde Güvende Tutmak
İşin garibi, Yapay zekâ ajanlarıyla ilgili son iki yılda en çok duyduğum laf şu öldü: “Model iyi, demo da fena değil… peki prod’a çıkınca ne olacak?” Açık konuşayım, asıl düğüm tam orada. Prompt yazmak kolay. Ajanı konuşturmak da kolay. Ama o ajanın hangi araca uzanacağı, hangi veriyi okuyacağı, hangi adımı atabileceği. Bütün bunların nasıl kayıt altına alınacağı — işte hayatı yer burası.
Benim açımdan Microsoft Agent Framework ile Agent Governance Toolkit’in birlikte gelmesi bu boşluğu bayağı toparlıyor. Biri orkestrasyonu kuruyor, diğeri de “dur bakalım, bu aksiyon gerçekten serbest mi?” diye soruyor. Hani mutfakta bir şef vardır, bir de dolabın anahtarını tutan görevli; şef ne kadar hevesli olursa olsun, anahtar kimdeyse kontrol ondadır. Tam da öyle.
Logosoft’ta 2025 başında görüştüğümüz bir finans müşterisinde buna çok benzeyen bir tablo vardı. Pilot aşamada ajanlar kredi notu sorguluyor, rate çekiyor, hatta bazı iç sistemlere bağlanıyordu. Her şey çalışıyordu ama güvenlik ekibi haklı olarak kaşlarını çatıyordu. Çünkü “çalışıyor” demekle “kontrollü çalışıyor” demek arasında ciddi fark var.
Durun, bir saniye.
Neden Bu Konu Şimdi Bu Kadar Önemli?
Agentic sistemler artık sadece sohbet eden botlar değil. Dosya açıyorlar, API çağırıyorlar, veri tabanına dokunuyorlar, hatta başka ajanlarla mesajlaşıyorlar. İş burada biraz karışıyor… çünkü klasik uygulama güvenliği yaklaşımı tek başına yetmiyor. Model çıktısını filtrelemek güzel bir başlangıç, ama aksiyon katmanını da sıkı tutmanız gerekiyor.
Ben AZ-500. AZ-305 sınavlarına hazırlanırken de aynı yere takılmıştım: mimariyi doğru kurmazsanız sonradan yamayla yürütmeye çalışırsınız. Ajan tarafında durum daha sert. Çünkü karar veren sadece insan olmuyor; bazen modelin kendisi de karar zincirine giriyor. Bir adımı fazla serbest bırakırsanız sorun çıkıyor, fazla kısıtlarsanız bu sefer sistem işe yaramaz hâle geliyor.
2024 Eylül’ünde Ankara’da bir üretim şirketiyle yaptığımız görüşmede bunu net gördüm. Ekip güzel bir demo hazırlamıştı ama canlıya geçince tool çağrılarının kim tarafından, ne zaman ve neden yapıldığını izleyememişlerdi. Sonuç? Güvenlik onayı gecikti. Proje beklediğim kadar hızlı ilerlemedi, açık söyleyeyim biraz can sıkıcıydı.
İşin aslı şu: kurumlar artık “ajan yapalım mı?” diye sormuyor; “ajanı nasıl denetleyelim?” diye soruyor. Bence doğru soru da bu.
Agent Framework Ne Sağlıyor?
Microsoft Agent Framework tarafında hoşuma giden şey şu: size sadece bir SDK vermiyor; orkestrasyon mantığını düzgün kurmanızı sağlıyor. Çoklu ajan akışları, A2A uyumluluğu, middleware katmanı ve memory gibi parçalar tek yerde toplanmış durumda. Yanı elinizde lego kutusu var ama parçalar birbirine gerçekten oturuyor.
Şöyle söyleyeyim, Bunu küçük ekipler için anlatmak gerekirse… startup iseniz hızlı prototip çıkarırsınız; birkaç tool bağlarsınız ve akışı ayağa kaldırırsınız. Enterprise tarafta işe aynı yapı daha ağır ilerliyor çünkü IAM entegrasyonu, loglama standardı, veri sınıflandırması ve değişiklik yönetimi devreye giriyor. Küçük ekipte hız öncelik olurken büyük organizasyonda izlenebilirlik öne çıkıyor.
Geçen yıl Kasım ayında İstanbul’da bir e-ticaret firmasının AI ekibinde benzer bir yapı tasarladık. Orada middleware yaklaşımı sayesinde içerik filtresiyle iş kuralını ayırabildik; prompt’u kirletmeden müdahale ettik. Bu ayrım kıymetli çünkü prompt içine güvenlik kuralı gömmeye başladığınız an bakım maliyeti yükseliyor.
Mimariyi neden seviyorum?
Çünkü sade kalıyor. Model tarafı model işini yapıyor; iş kuralı ayrı katmanda dürüyor; gözlemleme başka yerde kalıyor. Mantıklı değil mi? Bir de dürüst olayım: bana göre en iyi mimariler görünmez olanlardır — kullanıcıya karmaşıklık hissettirmeyen ama içeride disiplinli çalışan yapılar…
agent = Agent(
client=OpenAIChatClient(model="gpt-5.3"),
name="Contoso Loan Officer",
instructions="You are a governed loan assistant.",
tools=[check_credit_score, get_loan_rates],
middleware=[
AuditTrailMiddleware(audit_log=audit_log),
GovernancePolicyMiddleware(evaluator=evaluator),
RogueDetectionMiddleware(),
],
)AGT Neyi Farklı Yapıyor?
İlginç olan şu ki, AGT’nın olayı tam burada başlıyor: policy enforcement’ı runtime seviyesinde yapıyor. Yanı ajan “ben bu aracı çağırıyorum” dediğinde sistem oturup düşünüyor — izin var mı yok mu? Böylece tool erişimi, kaynak kullanımı. Ajanlar arası mesajlaşma kontrol altında kalıyor.
Yanı, Bunu pratikte şöyle düşünün: kapıda turnike yoksa herkes içeri dalar; sadece kamera koymak yetmez; içeride ne yaptığını da bilmeniz gerekir. AGT biraz turnike gibi davranıyor ama öyle hantal değil… sub-millisecond overhead iddiası burada önemli çünkü gecikme büyürse kullanıcı deneyimi bozulur. Daha fazla bilgi için agent ile ilgili önceki yazımız yazımıza bakabilirsiniz. Daha fazla bilgi için Segment Heap: Visual Studio’da C++ Belleği Neden Değişti? yazımıza bakabilirsiniz. Bu konuyla ilgili Kubernetes v1.36: Workload-Aware Scheduling Yeni Boyutta yazımıza da göz atmanızı tavsiye ederim.
Bir dakika — bununla bitmedi. NL2SQL’de Asıl Soru: Prompt mu, Veritabanı mı? yazımızda bu konuya da değinmiştik. Daha fazla bilgi için Azure Functions’ta Retry Fırtınasını Durdurmak: Backoff ve Circuit Breaker yazımıza bakabilirsiniz.
Bu servisleri ilk denediğimde bir ortamda policy evaluator yanlış konfigüre edildiği için sürekli Deny dönüyordu. Hata mesajı çok süslü değildi doğrusu! Çözüm basitti: capability map’i netleştirdik ve audit trail’i önce açıp sonra policy’yi sıklaştırdık. İlk etapta sistemi yumuşak açmak daha mantıklı geldi.
| Konu | Agent Framework | AGT |
|---|---|---|
| Ana amaç | Ajan kurmak ve orkestre etmek | Ajan aksiyonlarını yönetmek |
| Zamanlama | Tasarım / çalışma akışı | Anlık karar anı |
| Kazanım | Esneklik ve hız | Denetlenebilirlik ve güvenlik |
Nerede işe yarar?
Yanı, E tabi en çok finans, sağlık, kamu ve regülasyon baskısı olan alanlarda parlıyor. Ama yalnızca oralarda değil; SaaS ürününüzde bile müşteri verisine dokunan otomasyon varsa iş ciddileşiyor.
Bence Asıl Kazanç Nerede?Bana göre gerçek kazanım “güzel demo”dan üretim disiplini yaratmaya geçişte yatıyor. Maliyet tarafını da hesaba katın: Azure üzerinde böyle bir governance katmanı kurmanın bedeli sadece işlem sayısı değil; log saklama süresi, izleme altyapısı ve operasyonel bakım da masraf çıkarıyor — TL bazında düşününce orta ölçekli firmalarda hissediliyor.
Eğer bütçe kısıtlıysa her şeyi ilk günden kurmaya kalkmayın derim. Önce can alıcı tool’ları kapsayın: para hareketi yapan işlemler, müşteri verisi çeken API’ler. Dış sisteme yazan aksiyonlar… Geri kalan akışları sonra genişletirsiniz.
Küçük startup’larda tavsiyem yalın gitmek: tek agent + birkaç korumalı tool + basit audit log yeterli olabilir. Büyük enterprise yapılarda işe merkezî policy engine, rol bazlı yetki modeli ve SIEM entegrasyonu şart hâle geliyor.
- Kritik tool’ları belirleyin — bunu es geçmeyin
- Aksiyon bazlı policy tanımlayın
- Audit trail’i ilk günden açın
- Deny senaryolarını test edin — ciddi fark yaratıyor
- Sahte pozitifleri azaltana kadar ince ayar yapın
Lafı Gevelemeden Pratik TavsiyelerNeyse uzatmayalım: üretime çıkacak ajan sistemi kuruyorsanız önce sınırı çizin sonra modeli konuşturun.
Ha bu arada önemli bir nokta var: observability olmadan governance kör kalır.
Bir de şu var; agent memory ile policy birbirine karışmamalı.
Memory kullanıcı deneyimini iyileştirir;
policy işe risk iştahınızı düşürür. İkisini aynı sepete koyarsanız işler çorba olur — Ben böyle durumlarda hep sadeleşmeye giderim.”
Ajanlara güvenebilirsiniz; ama sınır vermeden bırakmayın.
Üretimde özgürlük kadar denetim de gerekir.
Birini eksik bırakırsanız ya risk artar ya da sistem kullanılmaz hâle gelir.
Nereden başlamalı?
Sıkça Sorulan Sorular
Microsoft Agent Framework ne işe yarıyor?
Ajanları kurmak, orkestre etmek ve çalıştırmak için temel altyapıyı sağlıyor. Yanı çoklu ajan akışları ve middleware desteğiyle aslında oldukça esnek bir geliştirme zemini sunuyor.
AGT neden gerekli?
Ajanların araçlara erişimini runtime sırasında denetlemek için gerekiyor. Ayrıca audit trail ve deterministik politika kontrolü sağlıyor, hani böylece üretimde risk ciddi ölçüde azalıyor. Bence bu özellik özellikle büyük sistemlerde çok kritik.
Küçük ekipler de kullanmalı mı?
Evet, ama kapsam dar tutulmalı. Açıkçası ilk aşamada yalnızca kritik aksiyonlara uygulamak daha mantıklı. Yoksa operasyon yükü gereksiz yere artabiliyor, tecrübeme göre yavaş yavaş genişletmek çok daha sağlıklı.
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder