Hosted Agents: Agent’lar İçin Güvenli ve Ölçekli Bulut
Aslında, Agent dünyasında artık asıl soru “çalışıyor mu?” değil, “üretimde güvenli mi, ölçekleniyor mu, izini sürebiliyor muyuz?” sorusu. İşin can sıkıcı tarafı da burada başlıyor zaten (şaşırtıcı ama gerçek). Lokal makinede bir agent ayağa kaldırmak kolay. Aynı akışı kurumsal ölçekte, binlerce kullanıcıya hizmet verecek şekilde döndürmek bambaşka bir hikâye.
Doğrusu, Microsoft’un Foundry Agent Service içinde duyurduğu hosted agents tam bu boşluğu dolduruyor. Benim dikkatimi çeken şey sadece “sandbox var” kısmı olmadı; per-session izolasyon, filesystem kalıcılığı, kimlik entegrasyonu ve scale-to-zero yaklaşımı birlikte düşünülmüş. Kağıt üstünde düzgün dürüyor. Pratikte işe — işte orası biraz daha hayatı — gerçekten ne kadar sadeleştirdiğini görmek lazım — valla güzel iş çıkarmışlar —
Evet, doğru duydunuz.
Geçen yıl Kasım 2024’te, Logosoft tarafında bir finans müşterisi için agent tabanlı bir iç destek akışı tasarlarken benzer bir duvara tosladık: geliştirme ortamında her şey şık görünüyordu ama üretimde oturum state’i, dosya erişimi ve kimlik yönetimi birbirine giriyordu. O gün anladım ki agent için klasik container mantığı bazen yetmiyor. Agent yalnızca API çağırmıyor, bazen dosya yazıyor, bazen kod çalıştırıyor, bazen de yarım kalan işi ertesi oturumda devam ettirmek istiyor.
Neden Klasik Compute Yetmiyor?
İtiraf edeyim, Klasik web uygulaması ile agent arasında ciddi fark var. Web app genelde kısa ömürlü istekler alır; kullanıcı gelir, veriyi gönderir, cevap alır çıkar (şaşırtıcı ama gerçek). Agent işe bazen dakikalarca hatta saatlerce çalışır. Dosya okur, kod üretir, test eder, sonucu saklar ve tekrar döner. Yanı süreç lineer değil; hafızalı ve inatçı bir yapıdan bahsediyoruz.
Ben bunu ilk kez 2019’da İstanbul’da bir telco projesinde çok net gördüm. Orada otomasyon işini container üstünden çözmeye çalışıyorduk. İlk başta iyi gidiyordu ama aynı instance üzerinde iki farklı müşteri akışı çakışınca işler karıştı. Loglar birbirine girdi, geçici dosyalar yanlış oturuma taşındı ve küçük görünen hata büyüyüp operasyonel riske dönüştü. O zaman “multi-tenant” deyip geçmemek gerektiğini acı şekilde öğrenmiştik.
Yanı, Hosted agents’ın olayı burada devreye giriyor: her session kendi izole alanına sahip oluyor. Bu bana biraz eski usül kiralık kasa mantığını hatırlatıyor… kasayı sız açıyorsunuz ama anahtar sizde kalıyor. Bir başkası gelip sizin dosyanızı görmüyor. Üstelik session yeniden ayağa kalksa bile disk durumu korunuyor; bu da uzun süren işler için bayağı işe yarıyor.
Şimdi gelelim işin can alıcı noktasına.
İzolasyon neden önemli?
Ajanların yaptığı iş sadece metin üretmek değil artık. Kod yazıp çalıştırabiliyorlar, repo tarayabiliyorlar, hatta sistem araçlarına dokunabiliyorlar. Böyle olunca güvenlik çizgisi çok daha hassas hâle geliyor. Bir müşterinin dosyasını başka müşteriye sızdırma riski kabul edilemez; açık konuşayım, enterprise tarafta bu konu şaka kaldırmaz.
Şöyle söyleyeyim, Bir de şu var: izolasyon sadece güvenlik değil, teşhis meselesi de (evet, doğru duydunuz). İzole session yapısı sayesinde hangi adımın nerede patladığını daha rahat görüyorsun — bence çok yerinde bir karar —. Ben AZ-305’e hazırlanırken de benzer düşünüyordum: mimariyi sadece “çalışsın” diye değil, arıza anında anlaşılacak şekilde kurmak gerekiyor.
Bir dakika — bununla bitmedi.
Hosted Agents Neler Getiriyor?
Duyuruda öne çıkan birkaç nokta var ve bunların her biri pratikte anlamlı: Azure Cosmos DB Conf 2026: Benim Gözümden Asıl Mesaj yazımızda bu konuya da değinmiştik. Bu konuyla ilgili Kubernetes’te ExternalIPs Neden Gidiyor: Güvenlik ve Geçiş yazımıza da göz atmanızı tavsiye ederim.
| Özellik | Sahadaki karşılığı | Neden önemli? |
|---|---|---|
| Predictable cold starts | Hızlı açılış | Kullanıcı beklemez |
| Scale to zero | Boşta maliyet yok | FinOps açısından rahatlatır |
| Filesystem persistence | Kaldığı yerden devam | Uzun işlerde hayat kurtarır |
| Per-session isolation | Ayrı sandbox | Müşteri ayrımı net olur |
| BYO VNet support | Ağ kontrolü sende | Kurum politikalarıyla uyum sağlar |
Bana göre en güçlü taraflardan biri scale-to-zero ekonomisi. Türkiye’de şirketlerin çoğu hâlâ kaynakları “boşta dursun ama hazır olsun” kafasıyla tutuyor; bu da bütçeyi sessizce yiyor. En çok da TL bazında düşündüğünüzde döviz kuru yüzünden küçük görünen tüketim bile ay sonunda can sıkabiliyor.
Buna rağmen burada küçük bir hayal kırıklığı notu düşeyim: hosted compute kulağa çok temiz geliyor ama operasyon ekibi doğru gözlemleme katmanı kurmazsa sorunları yine sonradan yakalarsınız. Yanı platform sizi kurtarıyor ama sihir yapmıyor.
Küçük ekip mi büyük kurum mu?
Size bir şey söyleyeyim, Eğer startup iseniz hosted agents size hız kazandırır; infra derdiyle boğuşmadan ürün çıkarmaya odaklanırsınız (yanlış duymadınız). Ama enterprise tarafta iş değişir: identity governance, ağ çıkışları, veri saklama politikaları ve denetim kayıtları şart olur.
Küçük ekipler için önerim basit: önce tek kullanım senaryosunu alın ve uçtan uca çalıştırın. Büyük kurumsal yapılarda işe isolation key stratejisini baştan kurgulayın; yoksa sonra tenant ayrımı yapmak zorlaşır. Kubernetes v1.36: Haru ile Gelen Sakın Güç yazımızda bu konuya da değinmiştik.
MCP, Protokoller ve Kurumsal Entegrasyon Meselesi
Duyuruda benim hoşuma giden başka bir detay da protokol tarafı öldü (ciddiyim). OpenResponses desteğiyle Microsoft 365’e tek tıkla publish etme fikri güzel… ama asıl kıymetli olan şey farklı entegrasyon yollarının hazır gelmesi. Kurumsal dünyada herkes aynı kapıyı kullanmaz çünkü herkesin kapısı farklıdır.
MCP tarafını da boş geçmemek lazım. Son aylarda güvenlik konuşmalarında MCP’nın adı sık geçiyor. Haklı olarak geçiyor da; çünkü tool erişimi kontrol edilmezse ajanınız çok hızlı biçimde fazla yetkili bir çalışan gibi davranmaya başlıyor. Geçen ay Şubat 2026’da bir enerji şirketinde yaptığımız tasarım gözden geçirmesinde bunu birebir konuştuk: agent’a verilen araç sayısı arttıkça risk yüzeyi de büyüyor.
Agent’larda asıl soru “kaç tool var?” değil; “hangi tool’a ne zaman, hangi kimlikle ve hangi sınırla erişiliyor?” sorusu.
Bence kilit olan ne?
Bence en kritik parça identity ile access control birleşimi. Agent’ın kendine ait bir kimliği olacak mı? Kullanıcı adına mı hareket edecek — Yoksa servis prensibiyle mi çalışacak? Bunların cevabı baştan verilmezse sonradan audit çıktıları kabusa döner.
Bunu geçtiğimiz yıl Ankara’daki bir kamu kurumunda tartışmıştık (Mart 2025). Güzel demo çıkmıştı ama denetçi arkadaşın ilk sorusu şu öldü: “Bu agent tam olarak hangi veriyi gördü?” İşte o soru tüm mimariyi belirliyor.
Maliyet ve Operasyon Tarafı: Güzel Ama Bedelsiz Değil
Scale-to-zero kulağa ücretsiz gibi geliyor ama değil tabiî; kullanım başladığında maliyet geri gelir. Buradaki oyun idle süreyi azaltmak ve kaynak kullanımını gerçek ihtiyaca yaklaştırmakta yatıyor (kendi tecrübem)
Eğer iş yükünüz kısa patlamalar halinde geliyorsa hosted agents fena çözüm değil hatta bayağı mantıklı olabilir. Ama sürekli yüksek trafikli işlemleriniz varsa geleneksel compute ile karşılaştırma yapmak gerekir; bazı senaryolarda sabit kapasite daha ucuz çıkabilir. Bu konuyla ilgili VSLive! Microsoft AI Hackathon 2026: Takımını Kodla Eve Gönder yazımıza da göz atmanızı tavsiye ederim.
- Kısa süreli araştırma agent’ları için hosted model iyi gider.
- Saatlerce çalışan kod analiz işleri için persistence fayda sağlar.
- Sabit trafik alan müşteri hizmetleri botlarında maliyet hesabı mutlaka yapılmalı. (bence en önemlisi)
- Düşük bütçeli projelerde önce pilot yapıp sonra ölçeklemek daha doğru olur.
Türkiye’de durum nasıl?
Daha açık söyleyeyim, size bir şey söyleyeyim, Türkiye’de benim gördüğüm en büyük fark şu: şirketler teknolojiyi seviyor ama bütçe konusunda doğal olarak temkinli davranıyorlar (haklılar). O yüzden hosted agents gibi servisleri anlatırken yalnız teknik faydaya değil toplam sahip olma maliyetine bakmak gerekiyor (bizzat test ettim) Git ve GitHub: VS Code’da Başlarken İşin Püf Noktaları yazımızda bu konuya da değinmiştik.
Vallahi, Eğer bütçe dar işe ilk aşamada tüm işleri hosted agents’a taşımayın derim. Önce en çok state isteyen ya da güvenlik riski yüksek akışı seçin… sonra sonuçlara bakın. Her şeyi aynı anda göç ettirmek çoğu zaman gereksiz heyecan yaratıyor — sonra ekip yoruluyor.
Sahada Nasıl Başlanır?
Lafı gevelemeden söyleyeyim: önce basit başlayın. 1) Tek bir agent senaryosu seçin. 2) Session state’in nerede tutulduğunu netleştirin — 3) Kimlik modelini belirleyin. 4) Ağ çıkışlarını kısıtlayın. 5) Gözlemleme loglarını daha ilk günden açın. (ciddiyim)
# Mantık örneği
agent_session:
isolation_key: customer-123
filesystem_persistence: enabled
network:
vnet_integration: true
identity:
mode: managed_identity
rollout:
strategy: weighted
stable_endpoint: true
Bunu ilk denediğimde Haziran 2025’te küçük bir lab ortamında şöyle bir hata aldım: session açılıyor. Dosya yolu beklendiği gibi persist etmiyordu çünkü mount edilen dizin ile çalışma dizini farklıydı (klasik insan hatası). Sız hiç denediniz mi? Çözüm basitti ama ders büyüktü: varsayımlarla ilerleme, path’i açıkça tanımla!
[p>Neyse uzatmayayım… Aslında uzatayım biraz daha çünkü önemli olan şu: pilot sırasında sadece başarı durumuna bakmayın, başarısızlık senaryolarını da deneyin. Agent yarıda kesilirse ne oluyor？ Ağ koparsa ne oluyor？ Dosya yazımı sırasında restart gelirse ne oluyor？ Bunları test etmeyen ekip üretimde sürpriz yaşar.Bana Göre Artılar Eksiler Dengesi
[p]Bence hosted agents doğru yönde atılmış adım ama henüz ham sayılır; biraz daha pişmesi lazım demeyeceğim de diyebilirim aslında… Çünkü platform tarafında bazı parçalar olgunlaşıyor olsa bile enterprise kabul kriterleri her zaman daha serttir.
]
Sıkça Sorulan Sorular
Hosted agents ne oluyor?
Kısaca söyleyeyim: her agent oturumuna özel izole compute veren yeni bir yaklaşım bu. Dosya sistemi kalıcı yanı session yeniden başlasa bile çalışma alanı korunuyor.
Klasik container yerine neden tercih ederiz?
Çünkü agent’lar çoğu zaman kısa isteklerden ibaret değil (ben de ilk duyduğumda şaşırmıştım). Kod çalıştırıyor, dosya yazıyor, hafıza tutuyor. Container modeli bazı senaryolarda yeterli. Session bazlı izolasyon gerektiğinde, açıkçası hosted model çok daha temiz bir çözüm sunuyor.
Küçük ekipler için uygun mu?
Açık konuşayım, Evet, özellikle hızlı prototipleme yapan ekipler için gayet iyi gidiyor. Ama bütçe sınırlıysa bence önce tek bir use case ile başlamak çok daha mantıklı.
Büyük kurumlarda en önemli konu ne?
ID yönetimi, ağ kontrolü, audit logları ve veri ayrımı. Tecrübeme göre enterprise tarafta teknoloji kadar yönetişim de en az o kadar önemli.
Kaynaklar ve İleri Okuma
Microsoft Foundry Blog Yazısı — Hosted Agents Duyurusu
Microsoft Azure AI Foundry Resmî Dokümantasyonu
Azure Architecture Center — Mimarı Rehberler (yanlış duymadınız)
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