Foundry Hosted Agents ile MAF’ı Prod’a Taşımak: Benim Notlarım
Local’de çalışan ajan, prod’da neden tökezliyor?
Bakın şimdi, yerelde pırıl pırıl çalışan bir Microsoft Agent Framework ajanını üretime alınca tablo değişiyor (kendi tecrübem). Hem de epey. Local makinede her şey elinizin altında; dosya sistemi sizde, kimlik sizde, loglar yakınınızda, hata çıkarsa terminal açık dürüyor… Ama prod tarafında bu rahatlık bir anda uçup gidiyor. İşin aslı şu: ajanı ayağa kaldırmak kolay, önü sürdürülebilir, izlenebilir ve versiyonlanabilir hâle getirmek asıl mesele.
📋 İçindekiler
-
İnanın, Bunu geçen ay İzmir’deki bir perakende müşterisinde tartıştık mesela (Mart 2026). Ekip “kullanıcı sohbeti + arka planda işlem” kombinasyonunu istiyordu ve Responses modeli tam oturdu. Fazla entegrasyon yükü olmadan ilerlediler ama küçük bir eksik vardı: özel uygulama akışlarına ince ayar yapmak istediklerinde esneklik beklentileri yükseldi.
Invocations ne zaman daha doğru olur?
Eğer ajanın başka sistemlerle sık sık konuşturulması gerekiyorsa Invocations daha uygun olabilir. Yanı sadece sohbet eden değil de iş yapan ajanlardan bahsediyorsak… mesela ticket açan, ERP’ye veri yazan ya da özel UI ile konuşan senaryolar için daha iyi hissettiriyor.
Açık söyleyeyim, burada tek doğru yok. Küçük startup iseniz basitliği seçersiniz; enterprise iseniz entegrasyon kontrolünü seçersiniz. Ben AZ-305’e hazırlanırken hep aynı prensibi düşünürdüm: çözüm iyi olduğu kadar işletilebilir olmalı da…
💡 Bilgi: Responses protokolü sohbet odaklı kullanımda rahatlatır; Invocations işe dış sistemlerle sık entegre olan kurumsal senaryolarda daha esnek davranır.Neden kurumsal tarafta dikkat çekiyor?
Bence Foundry Hosted Agents’in asıl güçlü. Sadece teknik kolaylık değil; operasyonu sadeleştirmesi.Kurumsal projelerde en pahalı kısım çoğu zaman kod yazmak değil,önü yaşatmak oluyor.Monitoring,identity,rollback,versioning… bunların hepsi ayrı uğraş.
Vallahi, Kubernetes v1.x tabanlı yapılarda yıllardır gördüğümüz sorun şuydu: her şeyi kendimiz kurduk diye gurur duyarken bakım maliyetini altımıza aldık.Agent dünyasında aynı hatayı tekrar etmeye gerek yok.Hazır gelen yönetilen katmanlar bazı ekiplerde özgürlük kaybı gibi görünür ama dürüst olayım,çoğu kurum için bu aslında hız kazancı.
Neyse uzatmayayım:benim deneyimimde banka,sigorta ve telekom gibi sektörlerde managed yaklaşım daha çabuk kabul görüyor.Sebep basit:güvenlik ekibi net sınırlar ister,iş ekibi hızlı çıktı ister,BT ekibi de gece telefon çalmasın ister.Hosted model üçüne de makul cevap veriyor (kendi tecrübem)
Denerken nelere dikkat ederdim?
- Kodu sadeleştir: İlk versiyonda mümkün olduğunca az bağımlılık kullan.
- ID planını çiz: Session isolation key yapısını baştan belirle.
- Ağ politikasını tanımla: VNet gerekecek mi önceden karar ver.
- Metrikleri aç: Latency, cold start, error rate mutlaka ölçülmeli. (bence en önemlisi)
Şöyle söyleyeyim, Peki hata olmaz mı? Olur tabiî.Ben ilk denemelerden birinde container image boyutunu fazla şişirdiğim için deployment süresi beklediğimden uzun çıkmıştı.Sorunun kökü basitti:gereksiz paketler imajda kalmıştı.Temizleyince toparladı.
# Örnek yaklaşım azd init azd up # Sonrasında ortamı doğrulayın: # — identity atandı mı? # — endpoint erişilebilir mi? # — session persistence beklediğiniz gibi mi? # — idle sonrası yeniden başlatma düzgün mü?Kapanışta benim görüşüm
Bana göre Foundry Hosted Agents doğru yönde atılmış sağlam bir adım. En çok da Microsoft Agent Framework ile çalışan ekipler için local’den production’a geçişteki o meşhur “son kilometre” problemini yumuşatıyor. Fena değil yanı;hatta baya iş görüyor.
Şunu fark ettim: Ama beklentiyi doğru kurmak lazım. Bu çözüm mucize değil;iyi tasarlanmış bir agent mimarisinin üzerine konunca değer üretiyor. Eğer workflow’unuz karmakarışıksa veya veri yönetişimi baştan düşünülmediyse hosted olması sizi kurtarmaz. Sadece problemi biraz daha şık paketler.
Eğer bugün başlayacak olsam önce küçük bir PoC yaparım, sonra session state davranışını test ederim, ardından identity ve network katmanını doğrularım. Üretime aceleyle çıkmam. Bir müşteri toplantısında söylediğim şeyi burada da söyleyeyim:ajan projelerinde en pahalı hata hızlı gitmek değil, yanlış yere hızlı gitmek.
Sıkça Sorulan Sorular
Foundry Hosted Agents ne işe yarıyor?
Foundry Hosted Agents, Microsoft Agent Framework ajanlarını bulutta çalıştırmanın yönetilen bir yolu. Yanı kimlik doğrulama, ölçekleme, oturum kalıcılığı ve gözlemlenebilirlik gibi can sıkıcı konuları platform sizin yerinize hallediyor.
/responses ile invocations arasında ne fark var?
/responses sohbet odaklı çalışıyor ve konuşma geçmişini platform yönetiyor. Invocations işe aslında özel uygulama entegrasyonları için daha esnek bir giriş noktası sunuyor — bence ihtiyaca göre ikisi de oldukça kullanışlı.
Küçük ekipler için uygun mu?
Daha açık söyleyeyim, şunu fark ettim: Kesinlikle. Hızlı PoC yapmak isteyen küçük ekipler için oldukça iyi bir seçenek. Azd ile dağıtım akışı başlangıçtaki sürtünmeyi ciddi ölçüde azaltıyor — açıkçası bu kısım beni en çok etkileyen özellik öldü.
Büyük kurumlarda doğrudan kullanılabilir mi?
Kullanılabilir, ama ağ politikaları, kimlik ayrımı, loglama ve uyumluluk kontrolleri baştan iyi tasarlanmalı (şaşırtıcı ama gerçek). Yönetilen yapı enterprise tarafta gayet iyi çalışıyor, hani tecrübeme göre governance kısmını es geçince işler karışabiliyor.
Maliyet açısından avantajlı mı?
Trafik düşükken scale-to-zero sayesinde avantaj sağlayabilir. Ama model çağrıları, saklama süresi ve ağ çıkışları hesaba katılmadan gerçek maliyeti görmek mümkün değil — mesela bu kalemleri atlayınca sürpriz faturalarla karşılaşabilirsiniz.
Kaynaklar ve İleri Okuma
Azure AI Foundry Agent Service Resmî Dokümantasyonu
Orijinal Microsoft Dev Blog Yazısı
Azure Container Registry Resmî Dokümantasyonu
Bu yazı yapay zeka (büyük dil modelleri) ile hazırlanmış, insan editör tarafından incelenmiştir. İçerik üretim sürecimiz.
Derya E.
Local’de her şey yolunda gidiyor, prod’a taşıyınca kimlik meselesi başınıza bela oluyor, bu acıyı çok iyi biliyorum. Session state konusunda biraz daha detay beklerdim açıkçası, özellikle ölçeklendirme sırasında ne gibi sorunlar çıkabileceği konusunda. Bir sonraki yazıda izlenebilirlik tarafını daha fazla açar mısınız?
İrem B.
Local’de her şey yolunda gidip prod’a geçince dağılması o kadar tanıdık bir his ki, özellikle kimlik yönetimi kısmı çok acı verici olabiliyor. Session persistence meselesini nasıl çözdüğünüzü daha detaylı okumak isterdim açıkçası. Bu arada şu yazınız da güzeldi: SkiaSharp 4.0 Preview 1: 10 Yıl Sonra Büyük Atılım Geldi — https://www.askinkilic.com.tr/skiasharp-40-preview-1-10-yil-sonra-buyuk-atilim-geldi/
Serkan D.
Local’de her şey yolunda gidince insan prod’u hafife alıyor, tam da burada anlattığın kimlik ve state sorunlarıyla ben de epey uğraştım. Session yönetimi kısmı özellikle çok kritik, bunu baştan planlamadan geçmeye kalkarsan sonradan refactor acı oluyor. Bu arada model seçimiyle ilgili şu yazın da işe yarar bir referans oldu benim için: Claude Sonnet 4 Copilot’tan Kaldırıldı: Geçiş Rehberi — https://www.askinkilic.com.tr/claude-sonnet-4-copilottan-kaldirildi-gecis-rehberi/
Yorumlar kapalı.







3 comments