Geçen hafta bir sigorta şirketinde ufak ama can sıkıcı bir tartışma çıktı. Ekip, Microsoft Agent Framework ile yazdığı ajanı haftalardır local’de geliştiriyordu — Visual Studio’da çalıştır, debug et, yoluna bak. Sonra mimarı toplantısında biri soruyu patlattı: “Peki bu canlıya nasıl çıkacak?” Bir anda hava değişti. Üç-dört saniyelik o garip sessizliklerden biri işte.
İşin aslı şu: ajan yazmak başka şey, ajan işletmek bambaşka bir dert. İlki bir hafta içinde toparlanıyor, ikincisi işe siz fark etmeden uzayıp gidiyor; kimlik yönetimi, session state, ölçekleme, versiyonlama, gözlemlenebilirlik (bir de üstüne bakım işi) derken, bunların hepsini sıfırdan kurmaya kalkarsanız açık konuşayım epey yorucu oluyor.
Şunu fark ettim: Microsoft tam da bu boşluğu kapatmak için Foundry Hosted Agents diye yeni bir hosting modeli duyurdu. Lafı gevelemeden söyleyeyim: MAF ajanlarını bulutta çalıştırmak için bugün baya iş gören yollardan biri bu. Ama dür bir saniye — her şey güllük gülistanlık değil tabii; eksik tarafları da var, birazdan ona da geleceğim.
Hosted Agents Aslında Ne Yapıyor?
Kısaca söyleyeyim: kendi kodunuzu bir container image olarak paketliyorsunuz, sonra Foundry Agent Service bunu yönetilen bir altyapıda koşturuyor. Üstüne de ajanlara özel servisler ekliyor; yanı bu, bildiğiniz App Service deployment’ı değil, agent iş yükleri için ayrı kafada tasarlanmış bir compute katmanı.
Evet, doğru duydunuz.
İlk gördüğümde ben de “Bu, Container Apps’in ajan kostümü giymiş hâli mi?” diye düşündüm. Açık konuşayım, öyle sandım. Ama biraz eşeleyince fark ortaya çıkıyor; per-session VM isolation var, scale-to-zero sırasında filesystem’in korunması var, session bazlı dedicated identity var… Bunlar genel amaçlı compute tarafında pek karşıma çıkmadı.
Açıkçası, En çok burası hoşuma gitti: session boşta kaldığında para akmıyor. 15 dakika idle olunca compute deprovision oluyor. Sonra yeni istek geldiğinde session, dosyalarıyla birlikte ve disk durumu da yerinde olacak şekilde geri geliyor. Kâğıt üstünde baya iş görüyor. Gerçekte cold start nasıl ölür, önü ayrıca görmek lazım.
Temel Yetenekler — Bana Önemli Gelenler
- Predictable cold starts: Yeni session açılışı neredeyse anlık gıbı duruyor. “Neredeyse” diyorum çünkü sahada ben daha ölçmedim, o yüzden kesin konuşmayayım. (bu kritik)
- Scale-to-zero: Idle iken sıfır maliyet. FinOps tarafında biri olarak bu cümleyi duyunca insanın içi rahatlıyor, hatta biraz fazla rahatlıyor bile diyebilirim.
- Per-session VM isolation: Her son kullanıcı kendi sandbox alanına düşüyor. Isolation key ile namespace yönetimi yapabiliyorsunuz; hani kurumsal tarafta işler biraz daha derli toplu kalsın diye.
- BYO VNet: Outbound trafiği kendi VNet’ınız üzerinden yönlendirebiliyorsunuz. Kurumsal müşteride bu detay kilit oluyor, çünkü ağ tarafı şakaya gelmiyor. — ciddi fark yaratıyor
- Versionlama + weighted rollout: Stable endpoint’ler ve sürümler arasında kademeli geçiş var. Güzel özellik gıbı duruyor ama asıl değerini rollout sırasında hissedersiniz bence.
- Çoklu protokol: Responses (OpenAI uyumlu), Invocations (generic), AG-UI desteği, Activity Protocol mapping. Yanı tek kapıya sıkışmıyorsunuz; bu da fena değil. (bu kritik)
“Filesystem’in scale-to-zero’da korunması” cümlesini ilk okuyunca ben de durup bir daha baktım. Çünkü kulağa basit geliyor ama altyapı tarafında epey emek isteyen bir iş; dosya state’ını bir yere snapshot’layıp sonra restore ediyorlar gıbı düşünün, üstelik bunu 30 güne kadar persist edecek şekilde yapıyorlar. Bu detay aslında “stateful agent” lafının altını dolduruyor.
Protokol Seçimi: Responses mi, Invocations mı?
Bilmem anlatabiliyor muyum, Burada ilk karar, hangı protokolü kullanacağınıza geliyor. İkisini de aynı projede açabiliyorsunuz aslında,. Pratikte senaryoya göre biri daha öne çıkıyor, yanı işin aslı biraz kullanım şekline bağlı.
Responses protokolü, OpenAI’nın /responses API’sıyla uyumlu çalışıyor. Konuşma geçmişini, streaming event’leri ve background execution kısmını platform hallediyor; siz de kendi tarafta message history tutayım mı, state nasıl saklanacak diye uğraşmıyorsunuz. Microsoft 365’e tek tıkla publish için Activity Protocol mapping de bunun üstünde dönüyor, baya iş görüyor açıkçası.
Invocations işe daha generic bir yapı (ki bu çoğu kişinin gözünden kaçıyor). Custom uygulama entegrasyonları, kendi UI’ınız, AG-UI gıbı senaryolar için daha esnek kalıyor. Ben şahsen kurumsal entegrasyonlarda Invocations tarafına daha sıcak bakarım çünkü kontrol sizde oluyor. Teams’e ya da Copilot’a bağlanacak bir ajan yazıyorsanız, Responses tarafı açık konuşayım daha mantıklı duruyor.
Evet. Bu konuyla ilgili Bankacılıkta Customer 360: Azure DocumentDB ile Pratik Yol yazımıza da göz atmanızı tavsiye ederim.
Hangisini Ne Zaman?
| Senaryo | Önerilen Protokol |
|---|---|
| Microsoft 365 / Teams entegrasyonu | Responses |
| Custom web/mobil arayüz | Invocations |
| OpenAI SDK’larıyla mevcut kod tabanı | Responses |
| Backend-to-backend, headless çağrı | Invocations |
| React tabanlı zengin UI (AG-UI) | Invocations + AG-UI |
Şimdi, peki neden? Çünkü burada mesele sadece işim değil; akışın kim tarafından yönetildiği, state’in nerede durduğu ve entegrasyonun ne kadar sıkı olacağı belirleyici oluyor, yoksa kağıt üstünde ikisi de benzer gıbı görünüyor ama sahaya inince tablo değişiyor.
Mesela Microsoft 365 tarafına yakınsanız Responses sızı daha az yorar. Ama kendi ürününüzde özgür hareket etmek istiyorsanız Invocations biraz daha rahat hissettirir; hani bazen böyle küçük farklar var ya, ilk bakışta önemsiz sanıyorsunuz. Sonra bütün mimariyi o küçük fark kurtarıyor.
Neyse uzatmayalım. Tabloya bakıp karar vermek çoğu zaman yeterli oluyor; yine de ben olsam önce hedef kanalı seçerim, sonra protokolü ona göre oturturum (ben de ilk duyduğumda şaşırmıştım)
Deployment Akışı: azd ile Tek Komut
azd tarafı, hani bazen insanı gereksiz uğraştan kurtarıyor ya, işte burada öyle bir durum var. Tek komutla birkaç işi birden toparlıyor; ilk bakışta “bu kadar mı?” dedirtiyor, sonra detaylara girince aslında epey şey yaptığını görüyorsunuz. Bu konuyla ilgili GitHub MCP Server’da Secret Scanning GA: Sahadan Notlar yazımıza da göz atmanızı tavsiye ederim.
- Foundry projesi yoksa oluşturuyor, model deploy ediyor (opsiyonel).
- Kodu paketliyor, container image build ediyor.
- Image’ı Azure Container Registry’ye push ediyor. — ciddi fark yaratıyor
- ACR’den çekip compute provision ediyor.
- Ajana dedicated bir Entra ID atıyor (bu çok önemli — birazdan değineceğim).
https://{project_endpoint}/agents/{agent_name}formatında endpoint açıyor.- Scaling, session state, observability, lifecycle… hepsini üstleniyor.
Peki akış nasıl başlıyor? Şöyle (inanın bana). Ben genelde önce giriş yapıp sonra init tarafına geçiyorum; ama dür bir saniye — burada kilit nokta komutların sırası değil, ortamın hazır olması. Yoksa en sonda küçük bir RBAC sürprizi pat diye geliyor.
Şimdi gelelim işin can alıcı noktasına.
# Foundry'ye giriş
azd auth login
# Init — mevcut dizinde MAF projesi varsayılıyor
azd init --template maf-hosted-agent
# Provision + deploy
azd upAçık konuşayım: ilk denememde azd up komutunda bir RBAC hatası aldım. Sebep de şuymuş; kullanıcımın Foundry projesinde “AI — itiraz edebilirsiniz tabi — Developer” rolü yoktu. Üstüne bir de “Cognitive Services User” rolü gerekiyordu. Dokümantasyonda yazıyor ama gözden kaçması çok kolay, yanı insan okurken atlayabiliyor. Bu detayı not edin, vakit kaybetmeyin. Daha fazla bilgi için mssql-python’da Apache Arrow Desteği: Sahadan Notlar yazımıza bakabilirsiniz.
Evet.
Dedicated Entra ID: Neden Bu Kadar Önemli?
Şimdi durun bir saniye, çünkü bu kısım atlanırsa sonra baş ağrısı çıkıyor. Her ajana ayrı bir Entra ID (söylemesi ayıp) veriliyor; yanı ajan, Azure tarafında kendine ait gerçek bir kimlik gıbı davranıyor. Storage’a, Key Vault’a, SQL’e de bu identity ile gidiyor.
Bunun pratik karşılığı baya net: connection string saklamıyorsunuz. Ajanın identity’sine RBAC veriyorsunuz, bitti gitti. Audit log’larda da hangı ajan ne yapmış açık açık görüyorsunuz (en azından benim deneyimim böyle). Entra Agent ID GA: Sponsor Grup Tipi Kısıtlaması Geldi yazısında bunun yan etkilerine değinmiştim — sponsor grup tipi kısıtlaması, özellikle kurumsal tarafta ufak sürtüşmeler çıkarabiliyor, ona da bir göz atın derim. GitHub Copilot CLI: Kurumsal Plugin Yönetimi Public yazımızda bu konuya da değinmiştik.
Peki neden?
Türkiye Perspektifi: Kim Bunu Hemen Kullanmalı, Kim Beklemeli?
Logosoft’ta son birkaç ay agent projeleri konusunda epey görüşme yaptım. Hatta bazı toplantılarda konu uzadı da uzadı, sonra bir baktık herkes aynı yere gelmiş: Foundry Hosted Agents şu an belli profiller için baya iş görüyor, ama herkese göre değil. VS Code Nişan Sürümleri: Copilot’ta Neler Değişti? yazımızda bu konuya da değinmiştik.
- Orta-büyük kurumsal müşteriler: M365 entegrasyonu, BYO VNet ihtiyacı olanlar. Kendi Container Apps + Front Door + Key Vault setup’ını kurmaya kıyasla ciddi zaman kazandırıyor, yanı o altyapı zincirini tek tek örmek yerine daha hızlı ayağa kalkıyorsunuz.
- Yüksek varyanslı kullanım örüntüleri: Gece kimsenin kullanmadığı, gündüz patlayan iç araçlar. Scale-to-zero burada altın değerinde. TL bazında düşününce de iş değişiyor; idle 16 saat x 30 gün hesabını yapınca fark bir anda göze batıyor. — ciddi fark yaratıyor
- Çok kiracılı (multi-tenant) SaaS yapanlar: Per-session VM isolation, müşteri verilerini ayrıştırmak için çok temiz bir model. Şey, bunu ilk duyduğumda “abartılıyor mu acaba” dedim ama pratikte fena durmuyor. — bunu es geçmeyin
Hani, Kim beklemeli peki? Açık konuşayım, küçük ekipler. Startup’lar için bu biraz “fil kullanmak” gıbı olabilir. 2-3 kullanıcılı bir iç araçta Container Apps ile basit bir FastAPI çoğu zaman yeterli oluyor, hatta çoğu senaryoda daha ucuz kalıyor; ben olsam önce ürün-pazar uyumunu netleştirir, sonra Hosted Agents tarafına geçerim.
Evet.
Bir de Türkiye region’ı meselesi var. Foundry Agent Service şu an sınırlı region’larda dönüyor, yanı her senaryo için eliniz kolunuz bağlı kalabiliyor; KVKK kapsamında veri ikametgâhı (data residency) isteyen işlerde Batı Avrupa ya da Kuzey Avrupa’ya yönelmek zorunda kalabilirsiniz. Bunu hukuk ekibiyle baştan netleştirin, yoksa sonra “biz bunu neden en başta konuşmadık” diye bakakalırsınız.
Peki neden?
İşin aslı, agent tarafında teknik karar kadar mevzuat ve operasyon da belirleyici oluyor. Yanı sadece “çalışıyor mu” diye bakmak yetmiyor; veri nerede duruyor, hangı tenant nereye gidiyor, gece trafik sıfırlanınca maliyet neye dönüyor gıbı sorular da masaya geliyor ve bazen teknoloji seçimini ters köşe yapıyor.
Versiyonlama ve Weighted Rollout
Beni en çok heyecanlandıran şeylerden biri bu, açık konuşayım. Stable endpoint aynı kalıyor, ama arkada v1, v2, v3 diye versiyonları rahatça yönetebiliyorsunuz; hatta trafiği %90 v1 / %10 v2 gıbı bölmek de mümkün oluyor. Yanı canary deployment, ajan tarafında biraz daha doğal akıyor.
Çok konuştum, örnekle göstereyim.
Açık konuşayım, Bu özelliği ilk duyduğumda aklıma direkt şu geldi: prompt değişikliğini production’a taşımak hep geriyor insanı. “Yeni system prompt saçmalar mı, kullanıcı deneyimini bozar mı?” diye düşünüyorsunuz işte. Weighted rollout ile önce %5’e açıp metriklere bakmak, sonra devam etmek baya iş görüyor; Agent’ları Test Etmek: “Doğru” Tek Bir Yol Değilse Ne Ölür? yazısında değindiğim “agent değerlendirmesi tek bir doğru cevap üzerine kurulamaz” meselesi de tam burada production stratejisine bağlanıyor, yanı test yaklaşımıyla canlıya alma kararı aynı masaya oturuyor (evet, doğru duydunuz)
Eksikler ve Beklediğim Kadar Olmayan Yerler
Hayır, her şey güllük gülistanlık değil. Birkaç noktaya özellikle takıldım, açık konuşayım; ilk bakışta küçük gıbı duran şeyler, işin içine gerçek trafik girince bir anda can sıkabiliyor.
- Cold start performansı reklam edildiği kadar mı? “Virtually instantly” diyorlar ama benim ilk ölçümlerimde ilk session açılışında 1-2 saniyelik bir ısınma vardı. Tipik chat senaryosunda çoğu kişi bunu fark etmez, evet, ama düşük gecikmeli bir akış kuruyorsanız (özellikle kullanıcı “hemen cevap gelsin” diyorsa) mutlaka test edin; ben olsam bu kısmı küçümsemem.
- Local development experience henüz olgunlaşıyor: Local emülatöre bakınca insan “fena değil” diyor, sonra bir bakıyorsunuz tam parite yok. Bazı session davranışları sadece cloud tarafında ortaya çıkıyor, işte o zaman debug uzuyor da uzuyor; hani kod çalışıyor sanıyorsunuz ama asıl sürpriz ortam farkında saklanıyor.
- Maliyet öngörülebilirliği: Per-session VM isolation güzel iş görüyor, buna lafım yok, ama fiyatlandırma katmanlı olunca tablo biraz dağılıyor. Aylık 10K aktif kullanıcılı bir senaryoda kalem kalem modelleme yapmadan ilerlerseniz, %100 doğru olmayabilir ama sürpriz fatura görme ihtimaliniz baya artar; burada “sonra bakarız” demek pek iyi fikir değil.
- Dokümantasyon hâlâ ham: Bazı konfigürasyon parametreleri için GitHub örneklerine dönmek zorunda kaldım, yanı resmî doküman tek başına yetmedi. Yamana yamana iyileşecek tabii, ama şu an için biraz el yordamı gerekiyor; neyse ki örnekler var da bayağı karanlıkta kalmıyorsunuz. (bu kritik)
Pratik Başlangıç Rehberi
Sıfırdan girecekseniz, ben olsam sırayı şöyle kurarım: (buna dikkat edin)
- MAF ajanınızı önce local’de ayağa kaldırın, biraz kurcalayın, stabil mi bakın. Microsoft Agent Framework:.NET’te Akıllı Ajan Devri yazısı burada iyi bir başlangıç noktası olabilir.
- Foundry projenizi açın, model deployment’ı hazırlayın; yanı işin omurgasını önce kurun, sonrasını zaten üstüne eklersiniz.
- Container’a paketlenebilir bir yapı oluşturun (Dockerfile + sağlık endpoint’i), çünkü sonra “bende çalışıyordu” cümlesi pek işe yaramıyor.
azd initile Hosted Agent template’ını alın.- Identity ve RBAC’i en başta doğru bağlayın — açık konuşayım, sonradan toparlamak hem vakit yiyor hem de can sıkıyor.
- Dev/Staging/Prod ortamları için ayrı projeler kullanın; aynı projede environment ile bölmeye çalışmayın, ilk bakışta pratik geliyor ama sonra karışıyor.
- Observability’yi ilk gün açın. Yoksa sonra “neden yavaş” diye dönüp log ararken ortada log bulamıyorsunuz, işte o zaman sınır bozuyor.
Bir de küçük bir saha notu var: ilk deploy’ta en basit ajanı deneyin. “Hello world” seviyesinde kalsın, abartmayın; pipeline’ı, identity akışını ve endpoint erişimini doğruladıktan sonra gerçek ajanınızı taşırsınız. Microsoft Agent Framework’te Durable Workflow’lar: Saha yazımdaki akışları devreye alacaksanız, bunları özellikle session persistence tarafında test etmek gerekiyor, çünkü orada ufak bir boşluk bile sonradan garip davranışlara yol açabiliyor.
Evet.
Sıkça Sorulan Sorular
Foundry Hosted Agents ile Azure Container Apps arasında ne fark var?
Container Apps aslında generic bir compute platformu; kimliği, session state’i, ölçekleme stratejisini kendiniz kuruyorsunuz (yanlış duymadınız). Hosted Agents işe ajan iş yüklerine göre özelleştirilmiş. Yanı per-session VM isolation, filesystem persistence, dedicated Entra ID, weighted versioning gıbı şeyler kutudan çıkıyor. Bence en kısa tanım şu: ajanlar için hazır bir “managed” katman.
Scale-to-zero ne zaman devreye giriyor, uyandırma ne kadar sürüyor?
Bakın, bilmem anlatabiliyor muyum, Şu anki davranışa göre 15 dakika idle kaldıktan sonra compute deprovision ediliyor. Sonraki istekte session, dosyaları ve disk durumuyla birlikte yeniden ayağa kalkıyor. Cold start çoğu senaryoda 1-2 saniye civarında. Ama açıkçası bu rakam workload boyutuna ve image büyüklüğüne göre değişiyor.
Mevcut OpenAI SDK kullanan kodumu nasıl entegre ederim?
Responses protokolünü etkinleştirin, çünkü /responses endpoint’i OpenAI uyumlu. Tecrübeme göre mevcut SDK çağrılarınızda sadece base URL’yi ve auth header’ını değiştirmek genelde yeterli oluyor. Bir de şu var: konuşma geçmişi platform tarafında yönetildiği için kendi history saklama kodunuzu kaldırabilirsiniz. Hani gereksiz bir yük kalkmış gıbı düşünebilirsiniz.
BYO VNet zorunlu mu, yoksa public endpoint ile başlayabilir mıyım?
Zorunlu değil. Public endpoint ile hızlıca başlayabilirsiniz (buna dikkat edin). Kurumsal güvenlik gereksinimleri netleştikçe BYO VNet’e geçmek de mümkün. Ama bence production’a çıkmadan önce bu kararı almanız çok önemli — sonradan değiştirmek bazı endpoint URL’lerini etkiliyor ve işler karışabiliyor.
Session verisi 30 gün sonra ne oluyor?
30 gün boyunca hiç dokunulmamış session’lar otomatik temizleniyor. Daha uzun saklama gerekiyorsa, kritik state’i mesela Cosmos DB veya Storage gıbı kendi kalıcı depolamanıza periyodik olarak yazmalısınız. Aslında Hosted Agents’ı kalıcı bir veri tabanı gıbı değil, konuşma çalışma alanı olarak düşünmek çok daha doğru.
Kaynaklar ve İleri Okuma
Microsoft DevBlogs: Deploy MAF Agents with Foundry Hosted Agents (Orijinal Duyuru)
Azure AI Foundry Agent Service Resmî Dokümantasyonu
Azure Developer CLI (azd) Dokümantasyonu
Microsoft Agent Framework GitHub Repository
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.
