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
- Local’de çalışan ajan, prod’da neden tökezliyor?
- Hosted Agents neyi farklı yapıyor?
- azd ile dağıtım: hızlı mı, kontrollü mü?
- Responses mı Invocations mı? Burada seçim önemli
- Neden kurumsal tarafta dikkat çekiyor?
- Denerken nelere dikkat ederdim?
- Kapanışta benim görüşüm
- Sıkça Sorulan Sorular
- Kaynaklar ve İleri Okuma
Ne yalan söyleyeyim, Ben bunu ilk kez 2024 sonbaharında, İstanbul’daki bir finans müşterisinde net gördüm. Geliştirme ortamında on dakikada çalışan workflow, test ortamına geçince garip şekilde oturum bilgisini unutmaya başladı. O an şunu düşündüm: agent dünyasında “çalışıyor” demek yetmiyor. “Nerede çalışıyor, hangi state’i taşıyor, hangi kimlikle konuşuyor?” soruları kod kadar önemli oluyor.
Çok konuştum, örnekle göstereyim.
Microsoft’un Foundry Hosted Agents yaklaşımı tam da bu boşluğu doldurmaya çalışıyor. Açık konuşayım; kağıt üstünde süper duran ama pratikte çok elle ayar isteyen çözümler gördüm ben (şaşırtıcı ama gerçek). Burada hoşuma giden şey şu: kendi kodunu container olarak paketliyorsun, platform sana yönetilen altyapıyı veriyor ve sen operasyonel yükün büyük kısmını omzundan atıyorsun (kendi tecrübem) (eh, fena değil). E tabi her sihirli değnek gibi bunun da sınırı var; birazdan oraya da geleceğim.
Hosted Agents neyi farklı yapıyor?
Bi saniye — Foundry Hosted Agents’i kabaca şöyle düşünebilirsiniz: kendi ofisinizden çıkıp güvenlikli bir kampüse taşınan ekip gibi. Kendi eşyalarınız var ama bina yönetimi başka biri tarafından yapılıyor. Bu modelde agent uygulamanız container içinde koşuyor; identity entegrasyonu hazır geliyor; session state yönetimi platforma bırakılıyor; ölçekleme de otomatikleşiyor.
Durun, bir saniye.
Bu yaklaşımın en iyi tarafı scale-to-zero mantığı. Yanı ajanın işi yoksa compute tarafı boş yere yanmıyor. Türkiye’deki birçok şirkette hâlâ “gece de açık kalsın, aman kapanmasın” refleksi görüyorum. AI ajanlarında bu alışkanlık bazen gereksiz maliyet yaratıyor. Hele bir de pilot aşamasındaki ekiplerde idle kaynak tüketimi ciddi para yakabiliyor.
Açıkçası, Geçen yıl Ankara’da bir kamu yan kuruluşuyla yaptığımız PoC’de buna benzer bir durum yaşamıştık. Ajan gün içinde yoğun kullanılıyordu ama akşamları neredeyse hiç trafik almıyordu. İlk tasarımda sürekli açık VM düşünülmüştü. Sonra hesap yaptık; idle saatlerin faturası TL bazında bakınca can sıkıcıydı. Hosted model burada daha temiz dürüyor çünkü kullanılmadığında geri çekiliyor.
Hmm, bunu nasıl anlatsamdı…
Sessiyon kalıcılığı neden önemli?
Ajan işlerinde hafıza konusu çok kritik. Bir kullanıcıyla yarım kalan konuşmayı devam ettirecekseniz ya da workflow içinde dosya üretip sonra o dosyayı tekrar okuyacaksanız filesystem persistence hayat kurtarıyor. Yerelde bu zaten doğal geliyor ama prod’da çoğu ekip bunu sonradan fark ediyor — bazen acıyla.
Şunu söyleyeyim, Ben 2019’da klasik.NET servislerinde de benzer şeyi yaşadım; konteyner restart olunca temp klasörde tutulan raporlar uçup gidiyordu. O gün öğrendiğim ders hâlâ geçerli: geçici sandığınız şeyler üretimde çok kalıcı sorunlara dönüşebiliyor. Agent tarafında işe mesele daha da hassas çünkü çalışma bağlamı doğrudan deneyimin parçası (ciddiyim)
İşte tam da bu noktada devreye giriyor.
azd ile dağıtım: hızlı mı, kontrollü mü?
azd kullanarak dağıtım yapmak gerçekten pratik. Paketle, image oluştur, ACR’ye gönder, compute’u ayağa kaldır… Zincir gayet temiz ilerliyor. Bir proje açıp gerekli kaynakları kurması da hoş; özellikle küçük ekiplerde başlangıç sürtünmesini baya azaltıyor. Daha fazla bilgi için Yaş Doğrulama Yasaları: Geliştiriciler Neden Dikkat Etmeli? yazımıza bakabilirsiniz.
Ama burada küçük bir uyarı bırakayım: hız bazen rehavete dönüyor. Startup ekibinde iseniz bu akış size ilaç gibi gelir; çünkü üç kişiyle hem geliştirme hem yayın hem de gözlem yapmanız gerekir ve azd bu yükü hafifletir. Enterprise tarafta işe işler biraz farklıdır; network politikaları, VNet yönlendirmesi, Entra ID ayrımları, change management. Audit gereksinimleri devreye girer. Orada “tek komutla deploy ettik” cümlesi güzel duyulur ama tek başına yeterli olmaz.
Bunu Logosoft tarafında 2025 başında bir üretim otomasyonu projesinde yaşadık. Teknik ekip hızlıca deploy etmek istiyordu. Güvenlik ekibi outbound trafiğin nereden çıktığını görmek istedi (haklılar). BYO VNet desteği tam bu noktada kıymetli öldü çünkü ağ kontrolünü neredeyse tamamen kaybetmeden hosted modelin rahatlığını aldık.
| Konu | Küçük Ekip | Büyük Kurum |
|---|---|---|
| Dağıtım hızı | Çok avantajlı | İyi ama onay süreçleri var |
| Maliyet kontrolü | Daha görünür | FinOps şart |
| Ağ güvenliği | Basit ihtiyaçlarda yeterli | VNet ve politika zorunlu olabilir |
| Sürümleme | Tatlı bir kolaylık | Zorunlu disiplin alanı |
Maliyet tarafını hafife almayın
Maliyet deyince herkes önce compute fiyatına bakıyor ama olay sadece orası değil. Session state saklama süresi, traffic pattern’i, model çağrıları ve gözlemleme bile toplam faturayı etkiliyor. Azure’da TL bazında düşününce ufak görünen farkların ay sonunda nasıl büyüdüğünü ben defalarca gördüm.
Benim kısa hükmüm şu: Hosted Agents pilot ve orta ölçek için çok mantıklı; ama yüksek regülasyonlu ortamlarda ağ mimarisini ve veri yerleşimini baştan tasarlamazsanız sonradan duvara toslarsınız.
Responses mı Invocations mı? Burada seçim önemli
/responses ile ne kazanıyorsunuz?
Responses protokolü bana göre en rahat başlangıç yolu. OpenAI uyumlu /responses endpoint’i üzerinden konuşma geçmişi, streaming event’leri ve background execution işleri platform tarafından toparlanıyor. E peki, sonuç ne öldü? Eğer amacınız Microsoft ekosistemine daha hızlı yaslanmaksa iyi seçenek. Microsoft 365 Copilot Agent Evaluations: Ajan Kalitesi Ölçümü yazımızda bu konuya da değinmiştik.
İ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… Daha fazla bilgi için Kubernetes v1.36’da DRA: Donanım Paylaşımında Yeni Dönem yazımıza bakabilirsiniz.
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ı. Daha fazla bilgi için vcpkg Nisan 2026: Kilitler, Hız ve Küçük Ama Kritik Dokunuşlar yazımıza bakabilirsiniz.
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ı. Daha fazla bilgi için Claude Sonnet 4 Copilot’tan Kaldırıldı: Geçiş Rehberi yazımıza bakabilirsiniz.
# Ö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
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.
3 comments