Microsoft Foundry Build 2026: Agent’ları Ölçekte Çalıştırmak
15 dk okuma
⏱️ 11 dk okuma📅 3 Haziran 2026👁️ görüntülenme
Build 2026 takvimini görür görmez ilk merak ettiğim şey şuydu: Microsoft bu kez agent tarafında ne kadar derine iniyor? Çünkü geçen yıl böl böl prototip gördük, herkes bir agent yapıyordu, ama çıkan işlerin çoğu laptop’un dışına çıkamıyordu. Hani şu klasik durum var ya, demo’da ışıl ışıl, prod’a geçince iki gün sonra “neden cevap vermiyor bu?” diye telefon açılan türden.
Ben de tam bu yüzden keynote’u biraz başka gözle izledim. Açık konuşayım, beklentim fena değildi; çünkü Logosoft’ta — ki bu tartışılır — son altı ayda agent tabanlı üç ayrı POC yürüttük. Her seferinde benzer duvarlara tosladık (kiminde yetki işi, kiminde veri erişimi, kiminde de orchestration tarafı). Neyse, çok dağıtmayayım, Build 2026’da duyurulan Microsoft Agent Platform kısmına gelelim. Anlatacağım şey, sahada çalışan birinin gözünden baya anlamlı duruyor.
Peki neden?
Prototip Kolay, Üretim Zor: Asıl Mesele Burada
Lafı gevelemeden söyleyeyim: GitHub Copilot ve benzeri araçlarla bir agent prototipini 2 saatte ayağa kaldırıyorsunuz. Hatta bazen 30 dakikada bile oluyor. Ama iş o agent’ı kurumsal bir akışın içine sokmaya gelince, tablo bir anda değişiyor.
Geçen ay bir sigorta şirketinde buna benzer bir şey yaşadık, hasar dosyası analiz eden bir agent yaptık ve lokal ortamda gayet iyi çalıştı; ama prod’a çıkınca her veri kaynağı (mainframe, CRM, OCR servisi, e-posta arşivi) ayrı bir auth flow, ayrı bir protokol, ayrı bir yaşam döngüsü istedi, üstüne RAG pipeline’ını da sıfırdan kurmamız gerekti, sonra session isolation çıktı karşımıza, ardından observability derdi geldi, en son da “üretimde patladı, şimdi bunu nasıl toparlayacağız?” sorusu masaya oturdu. Evet, tam olarak böyle.
Bu bana ister istemez 2014-2015’lerdeki mikroservis dalgasını hatırlatıyor. Tek bir servis yazmak kolaydı; asıl mesele service discovery, network policy, dağıtık trace ve deployment pipeline tarafındaydı. Şimdi agent dünyası da aynı yerde duruyor gıbı. Microsoft da bu boşluğu görmüş olacak ki Build 2026’da üç katmanlı bir yaklaşımla geldi: Build, Deploy, Operate.
“Agent yazmak artık kod yazmaktan ibaret değil. Doğru mimarı kararları en başta vermek gerekiyor — aksi hâlde altı ay sonra teknik borçla boğuşuyorsunuz.”
Build Katmanı: Agent Framework, Skills ve Hafıza
İlk katman geliştirici tarafı. Microsoft burada ilginç bir yol seçmiş,. Framework lock-in dayatmıyorlar; LangGraph kullanıyorsan devam ediyorsun, Claude Agent SDK ile başlamışsan oradan da yürüyorsun, GitHub Copilot SDK ile girdiysen yine sorun yok, Foundry bunların hepsini destekliyor.
Ama sıfırdan başlıyorsanız iş biraz değişiyor. Microsoft Agent Framework artık stable durumda, Python ve.NET tarafında resmî GA öldü. Bu framework, Semantic Kernel’in kurumsal altyapısıyla AutoGen’in multi-agent orkestrasyon tarafını bir araya getiriyor; yanı eskiden “hangisini seçeyim?” diye dönüp durduğumuz konu var ya, işte o biraz tarihe karıştı.
Kısa bir not düşeyim buraya.
Agent Harness: Lego Gıbı Düşünün
Yeni harness yapısı skills, memory ve middleware desteğiyle geliyor. Ben ilk bakışta bunu ASP.NET Core pipeline’ına benzettim, çünkü bir HTTP request nasıl aradan geçip filtrelerden dönüyorsa, agent çağrısı da logging, auth, retry. Rate limit gıbı katmanlardan geçiyor; bunu kendi başınıza kurmaya kalkınca insanın günü gidiyor, açık konuşayım.
Bir önceki yazıda Copilot SDK Genel Kullanıma Açıldı: Saha Notlarım başlığı altında SDK tarafındaki entegrasyonu detaylıca yazmıştım — onunla beraber okumanızı tavsiye ederim,. Iki parça birbirini tamamlıyor.
Toolboxes ve Skills: MCP’nın Olgun Hâli
Toolboxes in Foundry tarafında skills desteği geldi. Bu kısım beni baya düşündürdü aslında, çünkü her defasında tool tanımlarını JSON schema ile tek tek yazmak yorucu bir işti; şimdi skill paketleri var, versiyonlu geliyorlar, paylaşılabiliyorlar ve organizasyon içinde tekrar tekrar kullanılabiliyorlar.
Procedural memory de eklenmiş. Yanı agent’ın “nasıl yapılır” bilgisi artık kalıcı tarafta duruyor. Önceden episodic memory (geçmiş konuşmalar). Semantic memory (vector store) vardı ama “şu fatura işlemini şu sırayla yap” gıbı prosedürel bilgi her seferinde prompt’a yapıştırılıyordu; şimdi bunun için ayrı bir katman var, fena değil.
İşte tam da bu noktada devreye giriyor.
Voice Live: Telefon Hattındaki Agent
Bir de Voice Live entegrasyonu var (kendi tecrübem). Bu özellikle çağrı merkezî tarafında çalışan ekipler için ciddi bir adım. Türkiye’de bankacılık. Telco tarafında IVR sistemleri hâlâ taş devri seviyesinde; eğer biri bu işi düzgün uyarlarsa baya iş yapar.
Deploy Katmanı: Hosted Agents ve Yayın Kanalları
Hani, İkinci katman benim gözümde işin en kritik yeri (bizzat test ettim). Çünkü ne kadar uğraşırsanız uğraşın, eninde sonunda agent’ın bir yerde koşması gerekiyor. O “bir yer” de Kubernetes cluster’ı olunca, iş bir anda hafif sertleşiyor.
Evet, doğru duydunuz.
Foundry Agent Service’in hosted agents tarafı şunu yapıyor: Siz agent’ı tanımlıyorsunuz, runtime, isolation, state management, scaling — bunların hepsini Foundry üstleniyor. Kendi cluster’ınızı yönetmek istemiyorsanız baya iş görüyor. Tabii bunun öteki yüzü de var: Agent Sandbox: Kubernetes’te AI Agent’ları Çalıştırmak yazısında anlattığım gıbı, kontrolü bayağı sizde tutmak istiyorsanız Kubernetes tarafında da Sandbox yaklaşımı var; hani bazen insan “ben bunu kendim kurayım” diyor ya, tam o kafa.
Hosted vs Self-Hosted: Hangisi Sizin İçin?
Bu kararı verirken ben genelde tek bir şeye bakmıyorum. Geçen hafta bir müşteride tam da bunu konuştuk, hatta masaya oturup kriterleri tek tek döktük; kurulum süresi, maliyet, veri egemenliği. Operasyon yükü derken tablo kendiliğinden şekillendi.
Kriter
Foundry Hosted
Self-Hosted (AKS/Sandbox)
Kurulum süresi
Saatler
Haftalar
Veri egemenliği (KVKK)
Region’a bağlı
Tam kontrol
Maliyet (düşük trafik)
Avantajlı
Sabit yüksek
Maliyet (yüksek trafik)
Pahalı olabilir
Daha öngörülebilir
Özelleştirme
Sınırlı
Sınırsız
Operasyon yükü
Düşük
Yüksek
Küçük ekipseniz ya da startup’sanız hosted tarafa gitmek çoğu zaman daha rahat oluyor — çünkü operasyon için iki SRE çalıştırmanın aylık maliyeti, çoğu senaryoda hosted faturayı solluyor. Ama büyük. Kurumsal bir yapıdaysanız, özellikle finans ya da kamu tarafında dolaşıyorsanız, self-hosted seçeneği daha mantıklı gelebiliyor. Yalnız burada küçük bir ama var: self-hosted dediğiniz an “Kubernetes biliyorsunuz” varsayımı otomatik devreye giriyor. Tahmin eder mısınız? Bilmiyorsanız 6 ay AKS öğrenmeye gömülmek yerine hosted ile başlamak daha akıllıca ölür.
Long-Running Agents ve Routines
Tuhaf ama, Burası sessiz sedasız geçiliyor ama bence işin en değerli parçalarından biri bu. Bir agent’ın saatlerce, hatta günlerce çalışması gerekebiliyor; mesela aylık rapor üreten bir agent düşünün. Eskiden bunu durable (belki yanılıyorum ama) state mekanizmalarıyla, Service Bus mesajlarıyla ya da Azure Functions chain’leriyle kuruyordunuz. Şimdi runtime bunu yerleşik olarak destekliyor. Daha fazla bilgi için PostgreSQL’in Geleceği: Microsoft’tan Commit’ten Bulut’a yazımıza bakabilirsiniz.
Bir agent yazıp Teams’e publish edebilmek — bunu ilk duyduğumda ben de biraz iç çektim açıkçası. Çünkü 2023’te bir müşteride aynı şeyi yapmak için 3 hafta uğraşmıştık; Bot Framework vardı, Teams Manifest vardı, App Studio vardı, sonra Graph API izinleri çıktı karşımıza… Şimdi Foundry’den tek tıkla publish ediyorsunuz.
💡 Bilgi: Teams’e publish edilen agent’lar artık Microsoft 365 Copilot’un ana yüzeyinde de görünüyor. Yanı şirketinizin kendi agent’ını çalışanlar Copilot chat penceresinden çağırabiliyor. Bu da iç verimlilik projelerinde fena olmayan bir sıçrama yaratıyor.
Operate Katmanı: İşin Asıl Zor Kısmı
Şimdi geldik benim en çok kafa yorduğum yere. Bir agent’ı yazdınız, deploy ettiniz, çalışıyor; tamam, güzel. Peki üretimde ne oluyor? Açık konuşayım, sektörün büyük kısmı burayı ya atlıyor ya da üstünden hızlıca geçiyor — valla güzel iş çıkarmışlar —. Logosoft’ta birkaç müşteride agent observability dedik, karşılığında boş bakışlar aldık. “Loglarımız var ya” dediler. Evet, var. Ama agent log’u ile uygulama log’u aynı şey değil ki.
Tracing: Agent Sınırının Ötesine Geçmek
Distributed tracing’i bilirsiniz; bir HTTP request’in 10 servisten geçişini izlersiniz, sonra nerede takıldığını az çok anlarsınız. Agent tracing biraz daha karışık, hatta açık söyleyeyim, ilk bakışta insanın kafasını dağıtıyor. Bir agent kendi içinde LLM çağrısı yapıyor, tool çalıştırıyor, alt-agent’a delege ediyor, memory’den okuyor (bazı yerlerde hepsini aynı akışta görmek bile yetiyor) (şaşırtıcı ama gerçek). Bu ne anlama geliyor? Foundry’nın yeni tracing’i bu zinciri OpenTelemetry standartlarında çıkarıyor.
Yanı agent şöyle dedi, şu tool’u çağırdı, bu cevabı aldı, sonra başka bir tool denedi, patladı, en sonunda kullanıcıya şu mesajı verdi — hepsi tek bir trace’de duruyor. Bu kısmı bir telco müşterimizde manuel olarak Application Insights’a custom event’lerle koymaya çalışmıştık; üç hafta gitti. Sonra baktık ki artık built-in gelmiş. Hani ne farkı var diyorsunuz, değil mi? İyi öldü.
Evaluation ve Agent Optimizer
Şöyle söyleyeyim, Bence Build 2026’nın en ilginç tarafı bu — valla güzel iş çıkarmışlar —. Agent Optimizer, üretimde başarısız olan trace’leri alıp “ne yapsaydı doğru sonuç çıkardı” diye analiz ediyor. Size sırayla iyileştirme önerileri veriyor; mesela “prompt’u şöyle değiştir”, “şu tool’u şu noktada ekle”, “bu memory’yi temizle” gıbı (buna dikkat edin). Mantıklı değil mi? Kulağa basit geliyor ama işin aslı o kadar düz değil (kendi tecrübem)
Bunu yaşayan biri olarak söyleyeyim, Closed loop yanı. Üretim hatası → analiz — ki bu tartışılır — → öneri → review → deploy. Kurumsal AI’da olması gereken döngü bu ama şimdiye kadar çoğu ekip bunu elle çevirmeye çalışıyordu; yorucu işti. Tabii ben şimdilik temkinliyim — kağıt üstünde iyi duruyor, pratikte nasıl işleyecek göreceğiz. Önceki Microsoft Foundry sürümünde de benzer beklentilerle gelmiştik; deneyim için Microsoft Foundry Nişan 2026: Sahadan Notlar ve Yorum yazısına bakabilirsiniz.
Türkiye Perspektifi: Burada İşler Nasıl Yürür?
Şimdi biraz yerel taraftan konuşalım. Türkiye’de agent benimsemesi, dışarıdan bakınca basit duruyor ama içeride işler öyle akmıyor; KVKK var, veri lokalizasyonu var, bir de özellikle finans ve sağlıkta “bu veri nerede kalacak?” sorusu hemen masaya geliyor. Foundry’nın West Europe ve North Europe region’ları çoğu senaryoda iş görüyor, tamam, ama “veri Türkiye’de kalsın” diyen kurumlar için hâlâ can sıkıcı bir duvar gıbı duruyor. azure-functions-skills: AI Çağı için Functions Workspace’i yazımızda bu konuya da değinmiştik. azd update Komutu Geldi: Paket Yöneticisi Derdine Son yazımızda bu konuya da değinmiştik.
Eh, İkinci mesele Türkçe LLM performansı. GPT-4 sınıfı modeller Türkçe’de fena değil, hatta günlük kullanımda baya idare ediyor; ama agent işine girince, hele tool calling ve structured output tarafında, bazen öyle garip hatalar çıkıyor ki insan bir an ekrana bakıp kalıyor. Peki, geçen ay bir e-ticaret POC’unda tool argümanlarını Türkçe karakterlerle bozarak gönderdi — “ürün” yerine “ürün” yazdı, ürün servisi 404 verdi. Hani küçük detay gıbı duruyor. Değil; bu tıp durumlar için extra validation katmanı koymazsanız sonra uğraşıp duruyorsunuz.
İlk Adım Olarak Ne Yapmalı?
Eğer şirketinizde agent yolculuğuna yeni başlıyorsanız, bence işi çok büyütmeden başlamak lazım. Bir haftada her şeyi çözmeye çalışmayın; önce küçük bir şey kurun (tek tool olsun, tek LLM olsun), sonra neyin kırıldığını görün, çünkü asıl öğrenme orada geliyor.
İlk hafta: Microsoft Agent Framework ile lokal bir agent yazın. Bir tool, bir LLM, hepsi bu.
İkinci hafta: Skills ve memory ekleyin. Toolbox’a bir kurumsal tool koyun (CRM, ERP, ne varsa).
Üçüncü hafta: Foundry Agent Service’e hosted olarak deploy edin. Henüz Teams’e publish etmeyin.
Dördüncü hafta: Tracing ve evaluation kurun. En az 50 gerçek senaryo testle geçirin. — ciddi fark yaratıyor
Beşinci hafta: Teams’e dar bir grupla pilot çıkın. 2 hafta gözlemleyin.
Altıncı hafta+: Optimizer çıktılarına göre iterasyon. Genişletme.
Bu sırayı atlayan ekipleri tanıyorum; önce hızlandıklarını sanıyorlar, sonra 4 (evet, doğru duydunuz). ayda duvara toslayıp en başa dönüyorlar. Acele etmeyin. Siz ne dersiniz?
Tam da öyle.
Maliyet Tarafı: TL Bazında Bir Bakış
Maliyet tarafında net bir rakam vermek zor, çünkü işin içine kullanım giriyor. Ama kaba bir referans vereyim: 500 kullanıcılı, günde 2000 agent etkileşimi olan orta ölçekli bir şirkette Foundry Agent Service maliyeti, hosting + token + storage dahil, aşağı yukarı aylık 3.500-5.000 USD bandında dolaşıyor; kuru da ekleyince kabaca 130.000-180.000 TL gıbı bir tablo çıkıyor (ciddiyim)
İşin garibi, Bu rakam ilk bakışta göz korkutuyor olabilir. Evet.
Yine de iki kıdemli yazılımcının maaşının altına düşebiliyor; eğer agent gerçekten kullanıcıların işini kolaylaştırıyorsa (ROI’yi ölçmeden atlamayın), bu harcama kendini baya toparlıyor. Ama “bir deneyelim bakalım” diye bütçe açarsanız, üç ay sonra CFO’nün kapıda belirmesi hiç şaşırtmaz; yanı use case’i net koymak şart.
Sıkça Sorulan Sorular
Microsoft Agent Framework, Semantic Kernel’in yerini mi alıyor?
Aslında, Tam olarak değil aslında. Microsoft Agent Framework, Semantic Kernel’in kurumsal yeteneklerini ve AutoGen’in multi-agent yeteneklerini birleştirip yeni bir üst katman oluşturuyor. Mevcut Semantic Kernel projeleriniz sorunsuz çalışmaya devam ediyor, ama yeni projelerde Agent Framework’ü tercih etmenizi tavsiye ederler.
Hosted Agents seçeneği KVKK’ya uygun mu?
Bu biraz Foundry Agent Service’te hangı region’ı seçtiğinize bağlı. West Europe (Hollanda) ya da North Europe (İrlanda) seçerseniz veriler AB içinde kalıyor,. Çoğu KVKK senaryosu için bu yeterli oluyor (şaşırtıcı ama gerçek). Ama finans veya kamu gıbı “veri kesinlikle yurt içinde kalsın” diyen sektörler için self-hosted seçeneği bence daha güvenli bir yol.
LangGraph ile yazdığım agent’ı Foundry’de çalıştırabilir mıyım?
Evet, çalıştırabilirsiniz. Microsoft Foundry, hani framework agnostik bir yaklaşım benimsiyor. LangGraph, Claude Agent SDK ve GitHub Copilot SDK ile yazılmış agent’ları hosted runtime’da gayet rahat çalıştırabiliyorsunuz. Tek kısıt şu: observability ve optimizer gıbı bazı premium özellikler, Microsoft Agent Framework ile daha derin entegre çalışıyor.
Agent Optimizer üretim verisini eğitim için kullanır mı?
Hayır, kullanmıyor. Optimizer sizin tenant’ınızdaki trace’leri analiz ediyor, ama bu veriler Microsoft’un model eğitimine gitmiyor. Veriler tenant izolasyonu içinde kalıyor. Açıkçası yine de hassas veri içeren senaryolarda data masking ve PII filtering katmanları kurmanızı öneririm, tedbiri elden bırakmamak lazım.
Voice Live ile Türkçe IVR yapılabilir mi?
Bir şey dikkatimi çekti: Evet yapılabilir (bizzat test ettim). Voice Live Türkçe dahil 30’dan fazla dili destekliyor. Ama Türkçe’de aksan ve diyalekt çeşitliliği yüksek olduğu için, mesela gerçek üretime almadan önce ciddi bir test fazından geçirmek şart. Tecrübeme göre özellikle çağrı merkezî senaryolarında fallback olarak insan operatöre yönlendirme mekanizması büyük ihtimalle kurulmalı.
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.
🍪 Bu sitede içerik deneyiminizi iyileştirmek için çerezler kullanılmaktadır. Siteyi kullanmaya devam ederek KVKK ve Çerez Politikamızı kabul etmiş sayılırsınız.
