Microsoft Foundry Ajanlar Çağı: GPT-5.6 ve Production Ajan
Şöyle gireyim: son bir senedir kurumsal müşterilerle yaptığım toplantıların neredeyse hepsinde aynı laf dönüyor — “Biz de bir ajan kuracağız,. Pilotta kaldı, prod’a bir türlü çıkaramıyoruz.” Tanıdık mı? Bana baya tanıdık geliyor. İşin aslı şu: mesele modelin aklı değil. Model zaten fena değil. Asıl dert; kimlik, güvenlik, gözlemlenebilirlik, dağıtım ve yönetişimin aynı yerde, tek düzende oturmaması.
Microsoft da bu hafta duyurduğu Foundry güncellemeleriyle tam buraya abanıyor. GPT-5.6 ailesi genel kullanıma açıldı, Asia-Pacific Data Zone hattı geldi, Foundry Agent Service tarafında hosted agents, toolboxes. Doğrudan Microsoft 365 Copilot ile Teams’e yayınlama eklendi. Kağıt üstünde güzel dürüyor. Ama pratikte ne ediyor, hangi ekibe ne kazandırıyor — esas konuşulması gereken bu.
Önce büyük resim: neden “ajan platformu” işi bu kadar kritik?
Bir ajanı lab ortamında çalıştırmak kolay. GitHub’dan bir SDK çekersiniz, bir prompt yazarsınız, bir tool bağlarsınız, tamamdır. Ama o ajanı 40.000 kullanıcısı olan bir kurumun içine sokmak — Entra ID kimlikleriyle, DLP politikalarıyla, denetim izleriyle, maliyet takibiyle — işte orası başka oyun.
Sahada en çok gördüğüm hata şu: ekipler önce “en havalı frameworkü” seçip başlıyorlar. Sonra kimlik entegrasyonunu ayrı yere atıyorlar. Vector store başka yerde kalıyor. Observability için Datadog, LangSmith, Application Insights derken üç ekran açık geziyorlar. Prod zamanı gelince de… hmm, iş biraz yumak oluyor.
“AI ancak gerçek sistemlerde göründüğünde değer üretiyor — güvenilir, gözlemlenebilir ve iş sonuçlarıyla hizalanmış sistemlerde.” Microsoft’un bu cümlesine ben de kafa sallıyorum açıkçası. Prod’a çıkmayan ajan da ajandan çok PowerPoint sunumu gibi dürüyor.
Şunu söyleyeyim, Foundry’nın iddiası da zaten bu parçaları tek çatı altında toplamak. Build (model + framework), Generate (veri + tool + kullanıcı bağlantısı) ve Govern (güvenlik, maliyet, uyumluluk). Bunun ne kadarı gerçekten işe yarıyor, ne kadarı broşür dili — birlikte kurcalayalım.
GPT-5.6 Sol mı, Terra mı? Hangisi neye yarıyor?
OpenAI’ın yeni frontier model serisi artık Foundry içinde genel kullanıma açık durumda. Üç varyant var ve her biri farklı yükler için ayarlanmış. Açık konuşayım; bunu bekliyordum biraz da. Tek modelle her işi çözmeye kalkınca hem fatura şişiyor hem sistem hantallaşıyor.
Modelleri işe göre eşleştirmek
Açık konuşayım, Kısaca şöyle düşünün — hatta ajans planlaması yaparken masanın kenarında dursun:
| Model | Güçlü Olduğu Alan | Tipik Kullanım | Maliyet Yaklaşımı |
|---|---|---|---|
| GPT-5.6 | Genel amaçlı, dengeli reasoning | Sohbet, özetleme, orta seviye ajan görevleri | Orta |
| GPT-5.6 Sol | Derin muhakeme, uzun zincirli görevler | Kod refactoring’i, karmaşık planlama, çok adımlı ajanlar | Yüksek |
| GPT-5.6 Terra | Hızlı, düşük latency, ekonomik kullanım | Sınıflandırma, tool routing, yüksek throughput isteyen ajanlar | Düşük |
Bence bunları tek tek değil birlikte kullanın. Orchestrator ajan Terra ile karar versin — “Bu istek basit mi yoksa karmaşık mı?” — sonra gerekirse Sol’a atsın; basitse Terra kendi kapatsın işi (ki bu çoğu kişinin gözünden kaçıyor). Bu yaklaşım bazen maliyeti %40-60 bandında aşağı çekebiliyor, tabiî iş yüküne göre değişir. Detaylı kıyas için daha önce yazdığım GPT-5.6 Sol, Terra, Luna Copilot’ta : Hangisi Sizin İçin? yazısına bakabilirsiniz.
Standard Global mi Standard Data Zone mu?
Bir de deployment tipi meselesi var; kafa karıştırabiliyor. Kısaca : Global daha ucuz ama isteğiniz dünyanın herhangi bir OpenAI kapasitesine gidebiliyor. Data Zone işe coğrafi olarak sınırlandırılıyor ; Avrupa’daysanız Avrupa’da kalıyor. GDPR ve KVKK tarafına kafa yoran bir Türkiye şirketiyseniz Data Zone seçmek dürüstçe daha az baş ağrısı demek. Fiyat farkı da uçuk değil, yaklaşık %10-15 civarı. Peki neden herkes hemen buna geçmiyor? Çünkü alışkanlık var biraz da.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Asia-Pacific Data Zone geldi; peki Türkiye tarafında durum ne?
Bunun yerel yansımasını konuşmadan geçmeyelim. APAC Data Zone, Asya-Pasifik müşterilerine frontier OpenAI modellerini bölge içinde işletme imkanı veriyor. Güzel haber. E bizde durum ne? Türkiye şu an EU Data Zone kapsamında değerlendiriliyor; yanı aslında bize avantaj sağlıyor. Verileriniz Avrupa sınırları içinde kalıyor. Basit ama önemli detay bu.
Müşterilerimde sık gördüğüm şey şu : hukuk ekibi “veri Türkiye’de kalsın” diye bastırıyor ama Azure OpenAI hâlâ Türkiye bölgesinde yok. Böyle olunca EU Data Zone’u seçip KVKK açısından “uygun ülke / uygun aktarım” konusunu hukukla birlikte yürütmek şu an en mantıklı yol oluyor. Alternatif olarak açık kaynak modelleri (Phi, Llama, Mistral) Türkiye bölgesindeki bir AKS üzerinde koşturabilirsiniz ; fakat kalite tarafında GPT-5.6 seviyesine çıkmadığınızı da dürüstçe kabul etmek lazım. Şey yanı, bunu bilerek karar verin (inanın bana)
Bir dakika — bununla bitmedi.
Ajan artık laboratuvardan çıktı mı? Production Agents kısmına bakalım.
Bence bu güncellemenin en kıymetli tarafı modeller değil ; runtime altyapısı. Neden? Çünkü model her ay değişebilir ama altyapıyı bir kere kurarsınız ve yıllarca onunla yaşarsınız. İşte can sıkıcı kısım da orasıdır zaten.
Hosted Agents
Foundry Agent Service artık ajanlarınızı direkt host ediyor. Yanı illâ Azure Function ya da Container App kurmanız gerekmiyor. Mantıklı değil mi? Hatta sırf agent kodu için ayrı CI/CD pipeline yazmak istemiyorsanız Foundry Toolkit for VS Code üzerinden direkt deploy edebiliyorsunuz ; hani bazen insanın içinden sadece “çalışsın yeter” demek geliyor ya, tam o modda işe yarıyor.
Şöyle söyleyeyim, Bunu Türkiye’deki şirketler açısından düşünürsek : özellikle 20-50 kişilik yazılım ekiplerinde altyapı ekibinin yükünü baya azaltabiliyor ; yüzde olarak söylersem kabaca %70 civarı rahatlatabiliyor diyebilirim. Küçük ekipseniz hosted agent sizin için ciddi kolaylık olur ; büyük kurumsal yapılarda işe PCI-DSS, ISO 27001, network izolasyonu ve private endpoint gibi şeyler gerekiyorsa yine çalışır ama VNet integration ve managed identity ayarlarını sık tutmanız lazım. Yoksa mevzu kayar gider.
Hmm, bunu nasıl anlatsamdı…
Toolboxes
Bunu bekliyordum doğrusu. Ajan geliştirirken en sıkıcı işlerden biri her ajan için tool’ları tekrar tekrar tanımlamak oluyor. Toolboxes ile artık mesela bir “SharePoint tool paketi”, bir de “Dynamics 365 tool paketi” oluşturup bunları farklı ajanlara aynen bağlayabiliyorsunuz (en azından benim deneyimim böyle). Reusability açısından iyi iş görüyor ; lafı gevelemeden söyleyeyim bunun emeklilik maaşı gibi faydası var : bugün koyuyorsun yarın tekrar alıyorsun sonunda rahat ediyorsun! Benzer mantığı daha önce Agent Skills for .NET Kararlı Sürümde : Uzmanlık Artık Paketli yazısında anlatmıştım — uzmanlığı paketle, sonra yeniden kullan !
Microsoft 365 Copilot ve Teams’e yayınlamak neden önemli?
Şimdi işin düştüğü yer distribution problemi . Ajanınız hazır , tamam . Peki bunu 15.000 çalışana nasıl ulaştıracaksınız ? Ayrı web uygulamasımƒk yazacaksınız ? Hayır . Foundry’den doğrudan Copilot ve Teams’e publish edebiliyorsunuz . Kullanıcı zaten Teams’t e geziyor ;¿ajan orada olunca buluyor, konuşuyor, işi bitiriyor\.
\footnotesize{}\end{document}
Sıkça Sorulan Sorular
GPT-5.6 Türkiye’den kullanılıyor mu?
Evet, kullanılıyor. Ama şunu söyleyeyim — Türkiye Azure bölgesinde henüz OpenAI servisi yok. EU Data Zone’u seçerseniz verileriniz Avrupa sınırları içinde kalıyor, bu da KVKK açısından aslında savunulabilir bir yaklaşım. Yanı hukuk ekibinizle konuşun, ama bence makul bir çözüm. Nihai karar tabiî ki sizin uyum politikanıza bağlı.
Foundry Agent Service ile Azure OpenAI arasındaki fark ne ki?
Azure OpenAI sadece model API’si veriyor, hepsi bu. Burada, foundry Agent Service işe ajanın tümünü barındırıyor — kimlik, tool orchestration, hafıza, gözlemlenebilirlik, dağıtım, hepsi paket olarak geliyor. Mesela biri motor, diğeri komple araç gibi düşünün. Açıkçası basit bir chat uygulaması için Azure OpenAI yeterli, ama üretim ajanı kuruyorsanız Foundry’ye ihtiyacınız var.
Hosted agent yerine kendi container’ımda çalışsam olur mu?
İlginç olan şu ki, Olur. Hatta bazı senaryolarda daha mantıklı bile. En çok da çok özel ağ izolasyonunuz, custom runtime bağımlılıklarınız veya on-premise entegrasyonunuz varsa AKS üzerinde self-hosted daha esnek olabiliyor. Ama şunu da söyleyeyim — observability ve dağıtım avantajlarının bir kısmından vazgeçmiş oluyorsunuz. Tecrübeme göre hibrit yaklaşım da gayet işe yarıyor: hassas ajanlar kendinizde, genel amaçlılar Foundry’de mesela.
GPT-5.6 Sol neredeyse her zaman GPT-5.6 Terra’dan daha mı iyi sonuç veriyor?
Hayır, kesinlikle değil. Sol derin muhakeme için ayarlanmış, yanı basit sorularda gereksiz yere “düşünüyor”. Bu da hem latency’yi artırıyor hem maliyeti şişiriyor. Basit sınıflandırma veya routing işlerinde Terra çoğu zaman daha işabetli ve hızlı çalışıyor. Bence “ne kadar pahalı model, o kadar iyi sonuç” düşüncesi büyük ölçüde yanlış — işe göre model seçin, hepsi bu.
Foundry’e geçmeden önce hangi ajan framework’ünü öğreneyim?
Microsoft ekosisteminde çalışıyorsanız Microsoft Agent Framework en doğal seçim. Ama Foundry, Claude Agent SDK, GitHub Copilot SDK ve LangChain gibi framework’leri de destekliyor zaten. Yanı bugün hangi framework’le başladıysanız onunla devam edebilirsiniz — bu konuda çok takılmayın. Önemli olan Foundry’nın runtime, güvenlik ve dağıtım katmanını kullanmanız.
Kaynaklar ve İleri Okuma
Microsoft Azure Blog: Frontier Models and Production Agents — Tina Schuchman’ın orijinal duyuru yazısı.
Bunu yaşayan biri olarak söyleyeyim, Microsoft Foundry Resmî Dokümantasyonu — Foundry’nın build, generate, govern pillar’larına dair detaylı teknik rehberler.
Bakın, Microsoft Agent Framework GitHub Reposu — Örnek ajan senaryoları, toolbox tanımları ve SDK referansları.
Bi saniye — Azure OpenAI Model Karşılaştırması — Sol, Terra. GPT-5.6 varyantlarının teknik detayları ve deployment seçenekleri.
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.
2 comments