Foundry Toolboxes: Agent’ları Üretime Taşımanın Yeni Yolu

Açık konuşayım: bir agent prototipini laboratuvarda çalıştırmak başka, aynı agent’ı 200 kullanıcılı bir operasyon ekibinin önüne koymak başka. Geçen ay Logosoft’ta bir sigorta müşterimizde tam olarak buna tosladık. POC aşamasında 7-8 tool ile gayet sakın çalışan hasar dosyası agent’ı, prod’a yakın testlerde tool sayısı 60’a çıkınca dağıldı; yanlış API’yi çağırdı, bazen de “uygun tool bulamadım” deyip kenara çekildi.

İşte Microsoft’un Build 2026’da duyurduğu Toolboxes in Foundry güncellemesi tam da bu derdi hedefliyor. Tool Search, Skills, Work IQ, Fabric IQ, Browser Automation ve Routines. Liste uzun, evet. Siz hiç denediniz mi? Ama sahada hangisi ne işe yarıyor, önü tek tek anlatacağım — kuru spec sayfası gıbı okumayacaksınız burada.

Bir dakika — bununla bitmedi.

Önce sorunu doğru koyalım: Tooling neden ölçekte patlıyor?

Bak şimdi, Şöyle bir başlangıç düşünün: ekip 5 tool ile yola çıkıyor. CRM’den müşteri çek, fatura sorgula, e-posta gönder, takvim oku, bilet aç. Temiz. Agent doğru cevap veriyor. İş bitmiş gıbı duruyor.

Sonra iş büyüyor. Pazarlama ekibi geliyor, “biz de kullanalım” diyor — 12 tool oluyor. Ardından operasyon katılıyor — 30 tool. Partner API’ları, eski sistemler, edge-case entegrasyonları derken bir bakmışsınız 180 tool var. Her turn’de bunların tamamının JSON şeması modele gidiyor. Hmm, orada işler biraz bozuluyor işte.

Üç somut sorun çıkıyor karşınıza:

• Maliyet tool sayısıyla şişiyor: Her tool tanımı input token yiyor. 200 tool varsa her turn’de binlerce token sadece şemalar için gidiyor. Model bunları kullansa da kullanmasa da siz ödüyorsunuz.
• Context window dolup taşıyor: Konuşma geçmişi, sistem prompt’u ve kullanıcı verisi için yer kalmıyor; sonra model nefes alamıyor gıbı davranıyor.
• Model kararsız kalıyor: 180 benzer tool arasında “müşteri bilgisi çek” diye dört farklı seçenek varsa, hangisini seçeceğini şaşırıyor.

“Tooling küçük ölçekte değil, üretime geçişte kırılır.” Bu cümleyi Microsoft’un blog yazısında görünce “evet ya, aynen bu” dedim. Bizim sigorta müşterisinde de tablo buydu.

Tool Search: Önce arat, sonra çağır

Tool Search’ün yaptığı şey aslında basit ama etkili. Toolbox’ta 200 tool olabilir; yine de modele her turn’de sadece iki meta-tool gösteriliyor:

• tool_search — “Şuna benzer bir şeye ihtiyacım var” diye tarif ediyorsun, sana en uygun tool’ları getiriyor.
• call_tool — Aradığını bulunca ismiyle çağırıp çalıştırıyorsun.

Yanı agent artık koça listeyi ezberlemeye çalışmıyor. İhtiyacını söylüyor, semantik arama uygun adayları getiriyor, sonra çağırıyor. İnsanın Google’da arama yapmasına benziyor; her web sayfasını bilmiyorsunuz ki zaten, lazım olunca bakıyorsunuz.

Pratikte ne kazandırıyor?

Doğrusu, Geçen hafta küçük bir hesap yaptım — bankacılık projesinde 140 tool’lu bir toolbox için. Şuna bakın:

Senaryo	Klasik yöntem	Tool Search ile
Turn başına gönderilen tool tanımı	140 tool	2 meta-tool + ~5 arama sonucu
Tahmini token (sadece şemalar)	~28.000	~1.500
Yanlış tool seçimi (10 testte)	3 kez	0 kez
Cevap süresi (ortalama)	4.2 sn	2.8 sn

Sayılar projeden projeye değişir, garanti vermiyorum tabi (buna dikkat edin). Ama yön belli: tool sayısı arttıkça Tool Search’ün farkı iyice açılıyor.

Skills: Yeniden kullanılabilir yeteneklerin kataloğu

Burası biraz sessiz kalmış ama bana kalırsa işin en kıymetli taraflarından biri Skills (preview). Düşünün; şirkette 4 farklı agent var ve hepsi “müşteri kimliğini doğrula” işini yapıyor. Ama biri iki faktörlü doğrulama kullanıyor, biri kullanmıyor, biri log atmıyor… yanı aynı işin dört ayrı yorumu var.

Eh, Peki neden bunu aynı yerde toplamıyoruz? Skills tam burada devreye giriyor: bir kez yazıyorsunuz, version’luyorsunuz ve project-scoped katalogda tutuyorsunuz. Sonra toolbox üzerinden neredeyse tüm agent’lar erişiyor. Bir tool gıbı davranıyor ama aslında compose edilmiş bir yetenek; içinde birkaç API çağrısı, koşullu mantık ve hata yönetimi birlikte yaşayabiliyor.

Peki neden?

Bana azure-functions-skills: AI Çağı için Functions Workspace’i yazımdaki yaklaşımı hatırlattı — aynı fikir yanı: tekrar eden işleri merkezde tutun ki her ajan kendi tekerleğini yeniden icat etmesin.

Work IQ ve Fabric IQ: Kurumsal bağlam custom entegrasyon olmadan geliyor

Doğrusu, Burada iş biraz daha ilginçleşiyor doğrusu. Work IQ agent’ı Microsoft 365 verisine bağlıyor; Teams, SharePoint ve Outlook tarafına dokunuyor. Fabric IQ işe Microsoft Fabric içindeki data warehouse, lakehouse ve semantic model katmanına uzanıyor.

Bunun pratik anlamı ne? Şimdiye kadar bir agent’ın “geçen çeyrekteki satış raporundan X bölgesindeki düşüşü açıklar mısın?” sorusuna cevap vermesi için birkaç ayrı entegrasyon kurmanız gerekiyordu. Power BI bağlantısı ayrı dertti, SharePoint yetkileri ayrı dertti, Graph API çağrıları ayrı koddu… epey uğraştırıyordu açıkçası. Cosmos DB Güvenliği: Yeni Projede İlk Gün Kararları yazımızda bu konuya da değinmiştik.

Fabric IQ ile agent semantic model’i doğrudan sorgulayabiliyor. Yanı sadece SQL değil; “bölge”, “çeyrek”, “ürün ailesi” gıbı iş kavramlarını da kavrıyor gıbı davranıyor. Güzel tarafı bu; ama dür bir saniye — önemli bir not var: preview’da. Yetki modelinin nasıl işlediğini test ortamında iyice anlamadan production verisine bağlamayın derim.

Türkiye perspektifinden bir not

Emin değilim ama bizim Türkiye’deki kurumsal müşterilerde Work IQ ve Fabric IQ adaptasyonu biraz daha yavaş ilerler gıbı duruyor. Sebep veri lokasyonu hassasiyeti. KVKK kapsamında veri Türkiye’de tutuluyorsa bu servislerin hangı region’da çalıştığını. Veri akışının nereden geçtiğini netleştirmek gerekiyor; yoksa konu teknik olmaktan çıkıp uyum meselesine dönüyor. Kubernetes AI Gateway Working Group: Sahadan İlk Notlar yazımızda bu konuya da değinmiştik.

Bir dakika — bununla bitmedi.

Ayrıca Microsoft Foundry henüz Türkiye region’ında yok; çoğunlukla North Europe veya West Europe üzerinden ilerliyoruz. Bankacılık ve sigorta tarafındaki müşterilere önerim şu öldü hep: önce hassas olmayan veriyle POC yapın — pazarlama dashboard’ları, public dataset’ler ya da HR’ın anonim raporları gıbı şeylerle başlayın. Risk profilini görün, sonra hassas veriye geçin.

Browser Automation: MCP-native web otomasyonu

Açık konuşayım, Beni en çok heyecanlandıran parça burasıydı diyebilirim. Playwright workspace’leri üzerinden çalışan MCP (Model Context Protocol) native browser automation var burada; yanı agent gerçek tarayıcıyı gerçek zamanlı sürüyor ve siz de ne yaptığını görebiliyorsunuz.

Neyi değiştiriyor bu? Eski yaklaşımda — hani şu RPA dünyasında — form doldurma akışını adım adım scriptliyordunuz. UI değişince script patlıyordu. Burada işe agent siteyi “görüyor”, mantığını çıkarıyor ve gezinebiliyor; UI değişse bile tamamen afallamadan adapte olmaya çalışıyor.

E-ticaret tarafında çalışan bir arkadaşım geçen ay benzer yapıyı kendi sunucularında Playwright + custom agent ile kurmuştu; üç hafta uğraşmıştı açıkçası. Her köşe başında başka sürpriz çıkıyordu. Browser Automation hosted gelince bunu muhtemelen 1-2 günde toparlayabileceksiniz. Edge case olursa canlı görünürlük de var. Agent takılırsa siz devralabiliyorsunuz ya da en azından neye takıldığını görüyorsunuz.

Routines: Agent çalışma kontrolü

İşin garibi, Routines (preview), Toolboxes değil Foundry Agent Service‘in parçası olduğu için biraz ayrı yerde duruyor. Konusu da başka zaten: agent ne zaman çalışmalı, kim tetiklemeli, paralel mi gitsin, hata olursa retry mantığı nasıl olsun?

Bunu şimdiye kadar çoğunlukla kendiniz yazıyordunuz aslında. Azure Functions ile timer trigger koyuyordunuz, Service Bus queue bağlıyordunuz, retry policy ekliyordunuz (inanın bana). parça parça manuel işti hepsi. Routines bu katmanı sizden alıp sadeleştiriyor gıbı düşünün; “Her sabah 09:00’da müşteri şikayet kuyruğundaki yeni kayıtlar için bu agent’ı çalıştır, en fazla 10 paralel olsun, başarısız olursa exponential backoff ile 3 kez dene” diyorsunuz ve gerisini Foundry hallediyor. Foundry Agent Optimizer: Prompt’u Makine Yazsın Devri yazımızda bu konuya da değinmiştik.

This kısmını Microsoft Foundry Build 2026: Agent’ları Ölçekte Çalıştırmak yazımda daha geniş işlemiştim — orada Routines’in queue management tarafına da girmiştim zaten.

Hangı senaryoda hangisi? Pratik bir rehber

Sık gelen soru şu oluyor: “Bütün bunların hepsine ihtiyacım var mı?” Kısa cevap büyük ihtimalle hayır fakat detay biraz değişiyor tabii ki:

1. Küçük ekipseniz (1-3 agent, <20 tool): Şimdilik sadece Skills’i kullanın derim. Tool Search’e henüz gerek olmayabilir; Routines işe biraz fazla kaçabilir.
2. Orta ölçekteyseniz (5-15 agent, 20-80 tool): Tool Search’ü kesin açın kıymeti orada ortaya çıkıyor. Skills ile tekrar eden yetenekleri standardize edin. M365 entegrasyonu varsa Work IQ’ya göz atın. (bu kritik)
3. Enterprise ölçekteyseniz (15+ agent,100+tool): Hepsini ciddi şekilde değerlendirin. En çok da Routines, manuel orchestration size zaten pahalıya patlıyordur.

Bütçe açısından bir uyarı

Preview’da olan özelliklerin fiyatlandırması GA’ya kadar değişebiliyor. Şu an “bedava” görünen — ki bu tartışılır — şeyler bile sonra kullanım bazlı hâle gelebilir. TL bazında bakınca Tool Search’ün token tasarrufu muhtemelen kendini hızlıca amorti eder. Fabric IQ gıbı servisler için ayrı bütçe planlayın. Müşterilere hep şunu söylüyorum: FinOps disiplini olmadan AI projeleri bütçeyi çok çabuk yakar. Tahmin eder mısınız?

Kurulumda sık yapılan hatalar

Bizim sigorta müşterisinde Tool Search ‘ü ilk açtığımda ilginç bir sorun yaşadım (ki bu çoğu kişinin gözünden kaçıyor). Tool isimleri çok jenerikti; “get_data”, “fetch_record”, (söylemesi ayıp) “load_info” gıbı. Siz ne dersiniz? Semantik arama doğru çalışmadı çünkü bu isimlerin birbirinden anlamlı farkı yoktu. Daha fazla bilgi için Microsoft Repolarını GitHub’a Taşıyor: Sahadan Notlar yazımıza bakabilirsiniz.

Durun, bir saniye.

Çözüm mü? Tool isimlerini ve description ‘larını ciddiye almak gerekiyor (yanlış duymadınız). Şöyle: Daha fazla bilgi için PostgreSQL’in Geleceği: Microsoft’tan Commit’ten Bulut’a yazımıza bakabilirsiniz.

// Kötü
{
"name": "get_data",
"description": "Returns data"
}
// İyi 
{
"name": "get_policy_holder_claim_history",
"description": "Retrieves the last 24 months of insurance 
claim history for a specific policy holder, including 
claim status, amount, and resolution date."
}

İtiraf edeyim, Semantik arama, description ‘ın kalitesine göre çalışıyor. Açıklamayı baştan savma yazarsanız Tool Search’ten beklediğiniz performansı alamazsınız. Küçük detay gıbı duruyor ama sahada insanın canını baya yakabiliyor.

Genel değerlendirmem

Bakın açık olayım: bu duyurunun her parçası aynı seviyede olgun değil. Tool Search ve Skills — bunlar hemen kullanmaya değer fikirler. Browser Automation heyecan verici ama edge case ‘lerde nasıl davrandığını sahada görmek lazım. Work IQ / Fabric IQ — vaat büyük, fakat yetki modeli ve veri lokasyonu tarafında preview döneminde dikkat etmek şart.

Şimdi gelelim işin can alıcı noktasına.

Routines… Routines bence sessiz kahraman. Kimse çok konuşmuyor ama agent ‘ı production’a alırken en çok ihtiyaç duyacağınız parça bu olabilir. Gösterişli değil belki, ama temel bir eksiği kapatıyor.

Garip gelecek ama, Bir de Foundry Agent Memory: Procedural Bellek ile Üretime Hazır yazımda anlattığım memory yapısıyla birleşince, Foundry artık gerçekten “agent platformu” lafını hak ediyor diyebilirim. Bir yıl önce bana bunu sorsaydınız aynı rahatlıkla söylemezdim açıkçası.

Sıkça Sorulan Sorular

Tool Search’ü açınca mevcut agent’larım bozulur mu?

İşte, garip gelecek ama, Hayır, geriye dönük uyumlu yanı mevcut tool çağrıların çalışmaya devam ediyor. Aslında sadece agent’ın “tool listesini görme” şekli değişiyor. Ama bence yine de preview ortamında bir test agent’ıyla deneyip öyle geçiş yapman daha sağlıklı — özellikle çok özelleşmiş bir prompt’un varsa.

Skills ile normal tool arasındaki fark nedir?

Tool, hani tek bir API çağrısı ya da fonksiyon. Skill işe biraz daha kapsamlı — birden fazla tool’u, koşullu mantığı, hata yönetimini içerebiliyor ve versiyonlanabiliyor. Yanı mesela Skill’i bir tür “uygulama mantığı paketi” gıbı düşün. Açıkçası bu ayrımı kavrayınca ikisini nerede kullanacağın da netleşiyor.

Fabric IQ Türkiye’deki veri merkezlerinde çalışıyor mu?

Şu an Foundry’nın Türkiye region desteği biraz sınırlı. Fabric IQ genellikle Avrupa region’ları (West Europe, North Europe) üzerinden çalışıyor. KVKK kapsamındaki veriler için region seçimi. Veri akış analizini mutlaka yapman gerekiyor — bence bu kısmı atlamak pek akıllıca olmaz.

Routines, AKS üzerindeki mevcut orchestration’ımı değiştirir mi?

Şart değil. Argo Workflows, Airflow gıbı olgun bir orchestration’ın varsa önü tutabilirsin. Routines daha çok agent’a özel tetikleme ve queue yönetimi için, yanı birebir rakip değil. Tecrübeme göre hybrid kullanım gayet mantıklı — kritik iş akışlarını mevcut platformda bırakıp agent-spesifik run’ları Routines’e devredebilirsin.

Browser Automation güvenlik açısından riskli mi?

Şunu söyleyeyim, Açıkçası evet, dikkat edilmesi gereken bir alan. Agent’ın hangı sitelere erişebileceğini whitelist ile sınırlamak, credential yönetimini Key Vault üzerinden yapmak ve session log’larını saklamak şart. Hani preview olduğu için güvenlik dokümantasyonunu sık sık kontrol etmeni öneririm — bu tür şeyler sık güncelleniyor.

Kaynaklar ve İleri Okuma

Microsoft Foundry Blog: Discovery to Execution — Scaling Agents with Toolboxes and Routines

Doğrusu, Azure AI Foundry Resmî Dokümantasyonu

Model Context Protocol (MCP) Spesifikasyonu

Playwright Resmî Dokümantasyonu (Browser Automation altyapısı)