Microsoft Foundry Haziran 2026: Haziran’da Ne Değişti?
Haziran ayı Foundry tarafında baya hareketli geçti. Build 2026’da söylenen şeylerin bir kısmı aynı ay içinde sahaya indi, bazıları GA öldü, bazıları preview kaldı. Hepsi ciddiydi. Claude’un Azure faturasına tek satır olarak düşmesi mesela. Ya da Foundry ajanlarının artık Microsoft 365 — ki bu tartışılır — Copilot ve Teams’e doğrudan yayınlanabilmesi. Küçük detay gibi dürüyor, değil aslında.
Hani, Ben bu ayki değişiklikleri okurken şunu düşündüm: Microsoft, “hosted agent” işini artık kenarda köşede duran bir yan başlık gibi değil, Foundry’nın ana iskeleti gibi konumluyor. Toolboxes, Routines, Memory, Agent Optimizer… hepsi aynı hatta bağlanıyor. Hani ilk bakışta dağınık görünüyor ya, aslında değil; işin omurgası orada dürüyor (en azından benim deneyimim böyle). Gelin sırayla bakalım — ama bu, klasik bir “ne yenilendi” listesi olmayacak. Bu ne anlama geliyor? Sahadan konuşalım biraz.
Önce Kısa Bir Bilanço
Eh, Kabaca bir özet çıkarayım, Haziran’da öne çıkan dört hamle var. Evet, sayı az gibi dürüyor ama içerik hiç de öyle değil.
- Claude GA — Anthropic modelleri artık Azure’da first-party. Messages API, prompt caching, extended thinking, tool streaming… hepsi geliyor, hatta bazı yerlerde beklediğimden daha rahat çalışıyor.
- Foundry ajanları M365 Copilot ve Teams’e tek boru üzerinden yayınlanıyor (GA).
- Autopilot Agents — kendi Entra Agent ID’si, kendi e-postası, kendi Teams presence’ı olan ajanlar (public preview).
- Toolboxes içine Skills, Work IQ, Fabric IQ, Browser Automation ve Tool Search eklendi.
Bunların üstüne bir de Memory tarafında TTL kontrolleri var, Routines ile scheduled ya da triggered çalışma geliyor, Agent Optimizer’ın closed-loop iyileştirme akışı da işin cabası (şey, biraz laboratuvar kokuyor ama işe yarar gibi), Foundry Local’in Azure Local üzerinde multi-node çalışması da ayrı bir başlık. Neyse uzatmayayım; aşağıda hepsine gireceğim ama önce en göze çarpan parçayla başlayayım.
Kısacası, tam da öyle.
Claude’un GA’ya Geçmesi: Gozukenin Fazlası
Claude’un Azure’da barındırılması aslında Mayıs sonlarında duyurulmustu, ama Haziran’da resmî olarak GA’ya geçti. Bunu yazının başına koymamın sebebi su: Microsoft, OpenAI dışında bir modelin bu kadar derin entegre olduğu ilk ciddi deneyimi yaşıyor. Küçük gibi dürüyor, ama değil; model çeşitliliği tarafında uzun vadede bayağı iş görüyor.
Garip gelecek ama, Su şekilde düşünün: Bir kurumsal müşteride Azure sozlesmeniz var, EA’niz var, Enterprise Skills Initiative egitimleriniz var — bir tarafta da Anthropic’in Claude’ünü kullanmak istiyorsunuz. Eskiden ayrı vendor, ayrı fatura, ayrı DPA, ayrı güvenlik değerlendirmesi. Şimdi tek satır Azure faturasina dönüyor. Bunu. Procurement ekipleriyle didisen biri iyi anlar; yanı kağıt üstünde minik duran şey, pratikte epey büyük rahatlık sağlıyor (ben de ilk duyduğumda şaşırmıştım)
Bunu biraz açayım.
Türkiye tarafında konuşayım: KVKK ve veri ikametgahi kaygıları olan şirketler için Claude’un Azure üstünden gelmesi, “bu model verimi nereye gönderiyor?” sorusuna daha net cevap veriyor. Bu da benimsemenin önündeki en büyük duvarı biraz indiriyor.
Detaylara Claude Microsoft Foundry’de GA: Azure Faturasında Tek Satır yazımda daha derin girmiştim, oraya bakabilirsiniz. Burada tekrar etmeyeyim; zaten konu dağılıyor biraz.
Foundry Agent Service Claude’u Reasoning Core Olarak Kullanabiliyor
Doğrusu, Bu kısım kritik. Multi-step ajan senaryolarında Claude’u planner olarak kullanıp, alt görevler için başka modeller çalıştırabiliyorsunuz. Yanı “her şeyi tek modele yaptirma” anti-pattern’inden çıkmak için fena olmayan bir kapı açılıyor. Sahada gördüğüm en büyük hata bu. — insanlar GPT-4 sınıfı bir modeli tokenize etme, embedding çıkarma gibi ucuz işlere de koşuyor; sonra neden maliyet şişiyor diye şaşırıyorlar. Işin aslı, görevi bölmek daha mantıklı.
Bunu biraz açayım.
Şimdi, peki neden?
Bi saniye — Çünkü her is aynı ağırlıkta değil. Bir modeli düşünme katmanına koyup diğerini hızlı yan gorevlere çekince hem gecikme azalabiliyor hem de maliyet daha dengeli kalıyor (tabi senaryo doğru tasarlanmisysa) (kendi tecrübem). Az önce tek modele yuklenmeyelim dedim ama aslında mesele sadece yük bindirmemek değil; doğru işi doğru modele vermek.
Evet.
Ajanların M365 Copilot ve Teams’e Yayınlanması
Build 2026’da “Haziran’da GA” denmişti, sözlerini tutmuşlar. Güzel haber bu. Buradaki hayatı nokta şu: Aynı ajanı Copilot, Teams ve Foundry Agent Service için ayrı ayrı build etmiyorsunuz artık; tek governed pipeline var, sonra birden fazla surface’e dağıtıyorsunuz.
Küçük bir ekipseniz, açık konuşayım, bu kısım ilk bakışta çok çarpıcı gelmeyebilir. Bir tane ajanınız olur, bir yere koyarsınız, biter. Ama enterprise tarafında iş öyle akmıyor; bir bankada 40-50 ajan çıkabiliyor, biri IT helpdesk, biri HR, biri satış, biri compliance (buna dikkat edin). Bunların her birini ayrı surface’lere taşıyınca iş biraz karışıyor (hatta bazen fena dağılıyor), governance kayboluyor. Kim hangi versiyonu kullanıyor sorusu havada kalıyor.
Açık konuşayım, Tek pipeline yaklaşımı tam da bu can sıkıcı noktayı toparlıyor. Ajan tek yerde build ediliyor, Entra Agent ID ile kimlik veriliyor, DLP politikaları uygulanıyor, sonra hangi yüzeye publish edileceği kararına geliyorsunuz; yanı asıl mesele teknoloji değil de kontrol tarafı oluyor. Evet.
Autopilot Agents: Group Chat İçinde Yaşayan Ajanlar
Bu kısmı görünce ben de durup baktım. Klasik ajan mimarilerinde sen — en azından ben öyle düşünüyorum — sorarsın, ajan cevap verir; olay genelde 1-1 gider. Autopilot agents işe shared space için tasarlanmış gibi dürüyor — Teams group chat’e giriyor, konuşmayı izliyor, kendi kimliği oluyor, kendi takvimi oluyor, kendi e-postası oluyor; nasıl desem, biraz dijital ekip arkadaşı gibi davranıyor.
Örnek olarak Workstream Manager sample’ı yayınlanmış. Group chat’e giriyor, görevleri takip ediyor, konuşmaları action item’a çeviriyor, geciken işleri hatırlatıyor. Kısaca küçük bir proje yöneticisi gibi davranıyor; hatta doğru kurarsanız bir scrum master’ın tekrar eden işlerinin %30-40’ını üstlenebilir diye düşünüyorum (ciddiyim). Yanlış kurarsanız işe olay hızla “AI spam bot”a döner. İkisi arasındaki fark da sadece prompt engineering değil; asıl fark politikalarda ve tool erişim kısıtlarında yatıyor.
Toolboxes: Skills, Work IQ, Fabric IQ, Browser Automation
Haziran ayında Toolboxes tarafı bir anda kalabalıklaştı. Kısaca ne geldi, hemen bakalım: (ciddiyim)
| Özellik | Ne İşe Yarıyor | Durum |
|---|---|---|
| Skills | Ajanın “yapabildiği işler” kataloğu — reusable | Preview |
| Work IQ | Microsoft Graph üstünden iş bağlamı (mail, takvim, dosyalar) | Preview → GA yolunda |
| Fabric IQ | Microsoft Fabric verisine erişim | Preview |
| Browser Automation | Ajan gerçek bir tarayıcıda sörf yapabiliyor | Preview |
| Tool Search | Çok sayıda tool varsa hangisini kullanacağını bulma | Preview |
Work IQ tarafını geçen ay Work IQ Genel Kullanıma Açılıyor: Ajanlar İçin Zekâ Katmanı başlıklı yazımda uzunca anlatmıştım. Kısaca şunu söylüyorum: ajanın “bu kullanıcı kim, hangi ekipte, hangi projelerde çalışıyor, dün kimlerle toplantı yaptı” gibi bağlam bilgilerine ulaşması lazım. Yoksa her sohbette hafızası silinmiş gibi davranıyor, biraz tuhaf oluyor.
Hmm, bunu nasıl anlatsamdı…
Tool Search — Beklediğim Kadar Değildi
Açık konuşayım, Tool Search önizlemesini görünce ben biraz duraksadım. Fikir güzel; ajan 200 tane tool arasından doğru olanı RAG benzeri bir mantıkla seçiyor. Ama şey var, iş açıklamaları düzgün yazılmadıysa sonuçlar hemen dağılıyor ve arama beklediğiniz kadar akıcı gitmiyor. Yanı mucize değil, daha çok semantik search’ün tool listesine uyarlanmış hali; yine de hiç olmamasından iyi (kendi tecrübem)
Evet.
Bir de işin şu tarafı var: bazen tool sayısı artınca sorun çözülmüyor, tam tersine seçim zorlaşıyor. Uzun uzun katalog yapmak kolay, ama ajanın o katalog içinde kaybolmaması ayrı mesele. Sız ne dersiniz?
Brower Automation? Bir Dakika…
Neyse, burada küçük bir düzeltme yapayım: Browser Automation kısmı ilk bakışta “ajan web’i gezer” diye basit görünüyor. Aslında olay biraz daha karışık. Gerçek bir tarayıcı oturumu üzerinden ilerlediği için login akışları, buton tıklamaları. Sayfa davranışları devreye giriyor; yanı API olmayan yerlerde baya iş görüyor, fakat doğal olarak her site aynı şekilde davranmıyor.
Peki neden önemli? Çünkü bazı senaryolarda veri kaynağı API vermiyor ya da verdiği API yetersiz kalıyor. O noktada tarayıcı otomasyonu kurtarıcı olabiliyor. Tabiî burada da sınır belli; her şeyi çözen sihirli değnek değil.
Kendi deneyimimden konuşuyorum, Bazen en basit görünen parça en çok uğraştırıyor. Mesela oturum yönetimi ve beklenmedik UI değişiklikleri işi uzatabiliyor.
Skills ve Fabric IQ Tarafı Ne Durumda?
Skills tarafını ben daha çok yeniden kullanılabilir yetenek paketi gibi okuyorum. Hani bir ajana tek tek komut yazmak yerine, ona tanımlı iş parçaları veriyorsunuz; sonra bunları farklı akışlarda tekrar kullanabiliyorsunuz. Tahmin eder mısınız? Bu yaklaşım fena değil, çünkü dağınık tool listesini biraz toparlıyor.
Fabric IQ işe Microsoft Fabric verisine erişimi kolaylaştırıyor. Burada kilit nokta şu: veri erişimi var diye her şey otomatik olarak anlamlı olmuyor. Eğer yetkilendirme, bağlam. Doğru veri modeli iyi kurgulanmazsa sistem sadece veri çekiyor gibi görünür ama iş değeri düşük kalır.
Peki neden?
Kısacası Haziran güncellemesi kalabalık ama boş değil. Bazı parçalar hemen değer katıyor, bazıları işe açık konuşayım biraz ham dürüyor; yine de tabloyu genel olarak ileri taşıyor.
Tam da öyle.
Routines: Zamanlı ve Tetikli Ajan Çalıştırma
Foundry Agent Service’e Routines geldi. Preview’da su an. Kısa kısa söyleyeyim, ajanı schedule ile ya da bir event’e bağlayıp çalıştırabiliyorsunuz; cron benzeri bir is akışı düşünün.
Şunu söyleyeyim, Neden önemli? Bak şimdi, bir compliance ajanınız var diyelim, her Pazartesi sabah 8’de son bir haftanin Teams konusmalarini tarayıp rapor çıkarıyor. Eskiden bunu Logic Apps ya da Azure Functions tarafında ekstra bir zamanlayıcı kurup ajanı cagirarak yapıyordunuz, biraz dolastiriyordu; şimdi Foundry içinde tanımlıyorsunuz, bitti gitti.
Basit bir Routine tanımı kabaca böyle görünüyor (yaklaşık — final API değişebilir):
{
"name": "weekly-compliance-scan",
"agentId": "agent_compliance_v2",
"trigger": {
"type": "schedule",
"cron": "0 8 * * 1",
"timezone": "Europe/Istanbul"
},
"input": {
"scope": "last_7_days",
"channels": ["general", "sales-team"]
}
}
Burada hoşuma giden şey su: zamanlı ajan işleri için ayrı bir orchestrator kurmak yerine her şeyi tek platformda tutabiliyorsunuz. Operasyon açısından fena değil, hatta bazen bayağı iş görüyor. Ama dur bir saniye — bu otomatik olarak her senaryoda en doğru seçim demek değil; çok karmaşık workflow’larda hâlâ Logic Apps tarafı daha rahat olabilir.
Evet.
Bir de tetikli çalışma tarafı var ki, orası biraz daha ilginç. Mesela bir event geldiği anda ajanın devreye girmesi lazımsa, araya ekstra servis sıkıştırmadan bunu Foundry üzerinden kurgulamak güzel oluyor; yine de ben olsam önce sınırlarını net cizerim, çünkü her event’i ajana yikmak sonra baş ağrıtabiliyor.
Özetle, bu özellik ufak gibi dürüyor ama pratikte elinizi rahatlatıyor (ki bu çoğu kişinin gözünden kaçıyor). Bence en büyük kazanç, dağınık scheduler yapısını azaltması. Az önce dediğim gibi, Logic Apps’in belli workload’ları buraya kayabilir. Şimdi, peki neden? Çünkü ajan zaten Foundry içinde yaşıyor, tetikleme mekanizması da yanına gelince mimarı biraz toparlanıyor.
Kısa bir not düşeyim buraya.
Memory ve Agent Optimizer
Memory tarafında iki yeni parça var: procedural memory. TTL (time-to-live) kontrolleri. TTL kısmı bence kritik, çünkü ajan hafızası şişince iş sadece maliyet tarafında kalmıyor, doğruluk da sessizce bozuluyor. Evet.
Sahada en çok gördüğüm hata şu: ekipler ajana “her şeyi hatırla” diyor, sonra üç ay geçiyor ve ajan eski bir detaya tutunup karar veriyor. Garip ama oluyor. TTL bunu politika seviyesinde toparlayabiliyor gibi dürüyor; mesela “bu kullanıcının tercihleri 30 gün”, “proje bağlamı 7 gün”, “geçici veriler 24 saat” diye ayırınca, iş biraz daha derli toplu gidiyor. Bakın, peki neden?
Agent Optimizer işe private preview’a girdi. Evaluate, generate candidates, rank, deploy diye özetlenebilecek closed-loop bir iyileştirme akışı sunuyor; yanı ajanı canlıya aldıktan sonra farklı prompt/config kombinasyonlarını otomatik üretiyor, test ediyor, sıralıyor ve en iyi görüneni seçmeye çalışıyor — itiraf edeyim, beklentimin üstündeydi —. 3 Haziran duyurusundan yaklaşık 30 gün sonra public preview’a açılması bekleniyor. Bak şimdi.
Ve işler burada ilginçleşiyor.
Prompt engineering’i insan eliyle iteratif yapmak yorucu, üstelik tekrar edilebilir değil. Optimizer’ın closed-loop akışı bu problemi çözebilir — ama iyi bir eval seti kurmadan Optimizer çalıştırmak, bilinmeyene doğru gaza basmak gibi. Önce eval setine yatırım yapın.
Foundry Local: Azure Local Üstünde Çok Node Deployment
Ne yalan söyleyeyim, Bunu ayrı bir başlığa koydum, çünkü on-prem ya da hybrid tarafta çalışan biriyseniz is değişiyor. Foundry Local artık:
- Multi-node Kubernetes deployment desteği
- Disconnected / air-gapped operation (internet olmadan çalışıyor)
- vLLM inference runtime seçeneği
- Otomatik GPU inference tuning
- Model caching
Türkiye tarafında söyleyeyim: kamu, savunma, bankacılık ve enerji sektöründeki bazı müşterilerde “bulut olmaz” diye sert bir çizgi var. İşte, peki neden? Çünkü veri dışarı çıkacak mi, model nereye gidiyor, prompt ile output nerede kalıyor gibi sorular masanın üstüne hemen geliyor; Foundry Local’in air-gapped çalışabilmesi de tam burada bayağı iş görüyor. Modelin, prompt’un, çıktı’nın hiçbir zaman kurumsal ag dışına cikmadigindan emin olabiliyorsunuz.
vLLM seçeneği de ilginç, ama dur bir saniye — her senaryoda ilk tercih olacak diye bir şey yok. Throughput odaklı işlerde baya iyi sonuç veriyor; kendi ekiplerinizde H100’lerin altını doldurmak istiyorsanız vLLM düşünülebilir bir alternatif (ki bu çoğu kişinin gözünden kaçıyor). Ama operasyonda biraz daha el ister, bunu da açık söyleyeyim. Küçük ekipseniz varsayılan runtime’da kalın.
Durun, bir saniye.
Evet.
Voice Live API ve SDK Değişiklikleri
Şunu fark ettim: Voice Live API’nın 2026-06-01-preview sürümüne azure-realtime-native structured voice type eklenmiş. Güzel haber, evet. Bir de client-side echo cancellation için referans gelmiş; sesli ajan tarafında bu iş bazen can sıkıyor, hatta baya uğraştırıyor (özellikle ortam gürültüsü, hoparlör sızıntısı, geri besleme derken), o yüzden Microsoft’un bir referans implementasyon paylaşması açık konuşayım fena olmamış.
SDK Tarafında Neler Var?
- Java:
azure-ai-projects2.1.0 GA olmuş. Data Generation, Models ve Routines için preview client’ları da dürüyor. - .NET: 2.1.0-beta.4 yayında.
- Python & JS/TS: 2.3.0’a doğru gidiyorlar. Bu sürümde Hosted Agents ve Toolboxes beta’dan stable’a alınacak gibi görünüyor.
Python. JS SDK’larında hosted agents’ın stable’a çıkması, Build’de söylenen “Temmuz başı GA” hedefi için bence epey net bir işaret. Peki neden? Çünkü böyle geçişler genelde boşuna yapılmıyor; ekip önce altyapıyı toparlıyor, sonra duyuru geliyor (ya da en azından ben sahada çoğu kez bunu gördüm). Yanı Temmuz raporunda “Hosted Agents GA” satırını görürsek şaşırmam.
OpenEnv Standardı ve Reinforcement Learning
Yanı, Foundry, OpenEnv standardına katıldı (ki bu çoğu kişinin gözünden kaçıyor). İlk bakışta biraz akademik dürüyor, hatta insanın aklına “tamam da bize ne?” sorusu geliyor, ama işin aslı pek öyle değil; hosted agents, Toolboxes, Memory, Managed Compute ve evaluation/optimization katmanları tek bir “hill-climbing loop”a bağlanıyor, yanı reinforcement learning tarafında Foundry ekosisteminin dış araçlarla (Tinker, ECHO gibi post-training araçları) konuşması baya kolaylaşıyor. Kısa cevap: iyi haber.
Bunu Türkiye’deki şirketler açısından düşününce tablo daha netleşiyor. Şu an post-training / RL ile kendi domain’ine model uyarlayan Türk şirketi parmakla sayılır, evet; ama dur bir saniye, bu sayı az diye konu önemsiz sanmayın, çünkü gidiş o yöne ve Foundry’nın bu standarda katılması da önümüzdeki 12-18 ay içinde daha çok kurumun bu yola girmesini kolaylaştıracak. Yanı yol açılıyor.
Toparlarsak — Sahadan Bir Değerlendirme
Haziran raporuna bakınca bende kalan his şu öldü: Microsoft, ajan platformunu artık “bakın yeni bir şey çıktı” diye sunmuyor, işi bayağı üretimin içine itiyor. Claude, M365/Teams publishing, Java SDK… bunlar deneme kutusundan çıkmış parçalar gibi dürüyor; yanı fatura kesiliyor, SLA konuşuluyor, iş biraz ciddileşiyor.
Evet.
Preview tarafındaki şeyler de boş durmuyor. Routines, Autopilot Agents, Toolboxes içindeki yeniler derken tablo şuna dönüyor: bugün oynadığınız parçaların önemli bir kısmı 6 ay içinde GA’ya yaklaşacak gibi. Şimdi kurcalayan ekip, 2027’nın başında eli daha dolu sahaya çıkıyor; garip ama gerçek.
Küçük ekipseniz ben olsam lafı uzatmadan Claude + hosted agents + Work IQ üçlüsüyle başlarım. Basit bir helpdesk ajanı yeterli olur, evet, (inanın bana). Önü uçtan uca deneyimlemek başka bir şey; nerede takılıyor, nerede akıyor, kullanıcı neyi anlamıyor hemen görüyorsunuz (ki bu çoğu kişinin gözünden kaçıyor)
Araya gireyim: Enterprise tarafındaysanız iş biraz değişiyor. Routines ve Agent Optimizer için yan yana bir POC açmak fena fikir değil; bir yandan da Memory TTL politikanızı şimdi düşünün derim (sonradan toparlaması can sıkabiliyor). Autopilot Agents cephesinde işe production’a atlamayın, önce Teams group chat içinde sample Workstream Manager’ı deneyin; asıl amaç teknik başarıdan çok kültürel alışkanlığı görmek.
Neyse, konu biraz dağıldı ama toparlayayım: Build 2026’daki genel ajanda için Visual Studio Build 2026: Ajanlar, Modernizasyon ve Yeni Akış yazıma da bakabilirsiniz — geçen ay yazmıştım, o taraf konteksti tamamlıyor. Veri tarafında işe Agent Harness ile Ajana Veri Vermek: Onay ve Hafıza Dahil yazısında ajanlara veri geçirmenin pratik tarafını anlatmıştım; orası da işin diğer yarısı zaten.
Sıkça Sorulan Sorular
Foundry ajanlarını Microsoft 365 Copilot’a yayınlamak için ekstra lisans gerekiyor mu?
Evet, gerekiyor. Copilot’a publish edilen ajanların bir kısmı için M365 Copilot lisansı şart. Daha açık söyleyeyim, autopilot agents işe kendi productivity lisansıyla geliyor,. Her ajan için ayrı bir seat hesaplamak gerekiyor — açıkçası bunu bütçe planlamasında gözden kaçırmak çok kolay, baştan not alın.
Claude’u Azure üzerinden kullanmakla Anthropic’ten direkt kullanmak arasında maliyet farkı var mı?
Bir şey dikkatimi çekti: Fiyatlar aslında birbirine oldukça yakın. Ama Azure tarafında EA (Enterprise Agreement) indirimleriniz varsa, onlardan yararlanabiliyorsunuz — bu farkı ciddi oranda açabiliyor. Prompt caching ve extended thinking gibi optimizasyon özellikleri her iki platformda da var, bu iyi haber. Bence volume yüksekse Azure genelde daha mantıklı çıkıyor, ama net bir karar için kendi kullanım profilinizle karşılaştırmanızı öneririm.
Foundry Local’i air-gapped çalıştırmak için hangi donanım gerekiyor?
Multi-node Kubernetes cluster ve GPU’lu node’lar lazım. Mütevazı bir başlangıç için hani 2-3 node ve A100/H100 sınıfı GPU’lar yeterli olabiliyor. Ama şunu söyleyeyim — sertifikalı olmayan donanımda destek almak gerçekten sıkıntılı olabiliyor, o yüzden Azure Local (eski adıyla Azure Stack HCI) doğrulanmış donanım katalogunu Microsoft’un dokümantasyonundan mutlaka kontrol edin.
Routines ile Logic Apps arasında ne zaman hangisini seçmeliyim?
Mesela sadece bir ajanı tetiklemek istiyorsanız Routines çok daha basit ve entegre, doğrudan işe yarıyor (ciddiyim). Ama işin içine birden fazla sistem, koşullu dallanma ya da insan onayı giriyorsa, yanı karmaşık bir workflow söz konusuysa, Logic Apps hâlâ çok daha güçlü. Kısa özet: basit “zamanlı ajan çalıştır” senaryoları için Routines, çok adımlı iş süreçleri için Logic Apps.
Agent Optimizer’ı production’da kullanmadan önce nelere dikkat etmeliyim?
En kritik şey iyi bir evaluation seti hazırlamak — bence burası gerçekten çok önemli. Optimizer, evaluation metriklerinize göre iyileştirme yapıyor; metrikleriniz yanlışsa “optimize edilmiş” ajanınız aslında kötüleşmiş olabiliyor. Ayrıca değişiklikleri direkt production’a açmayın, staged rollout ile gidin (en azından benim deneyimim böyle). Bir de şu an private preview’da olduğu için erişim için Microsoft’la ayrıca iletişime geçmeniz gerekiyor.
Kaynaklar ve İleri Okuma
Vallahi, What’s New in Microsoft Foundry — June 2026 (Microsoft Foundry DevBlog) (kendi tecrübem)
Azure AI Foundry Resmî Dokümantasyonu
Foundry Agent Service — Overview
Microsoft Foundry Developer Blog
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.
3 comments