Foundry Toolboxes: Ajan Araçlarını Toplamak Neden Şart Oldu?
Dağınık araçlar, dağınık operasyon
Şöyle ki, Şunu açık söyleyeyim: ajan tarafında asıl mesele model değil, araç. Model konuşuyor, ama işi yaptıran taraf çoğu zaman entegrasyon katmanı oluyor. İşin aslı şu; bir ajana Entra ID, GitHub, Azure DevOps, Teams ve birkaç iç sistem bağladığınız anda küçük bir prototipten çıkıp mini bir platform kurmaya başlıyorsunuz. Evet, tam orası. Bu noktada proje “AI” olmaktan biraz uzaklaşıp “kim hangi tool’u nasıl çağıracak?” tartışmasına dönüyor (yanlış duymadınız)
Geçen sene Mart 2025’te İstanbul’daki bir finans müşterisinde buna benzer bir tablo gördük (inanın bana). Üç farklı ekip üç farklı framework kullanıyordu; biri.NET üstünde, biri Python’da, biri de hazır bir agent runtime üzerinde ilerliyordu. Hepsinin ortak sorunu aynıydı: aynı tool mantığı üç kere yazılmıştı. Kimlik doğrulama ayrı dertti, loglama ayrı dertti, hata yönetimi ayrı dertti… Hani ilk bakışta “küçük detaylar” gibi dürüyor ya, işte prod’a çıkınca o küçük detaylar koca yangına dönüyor.
Kısa bir not düşeyim buraya.
Microsoft’un Foundry Toolbox yaklaşımı tam burada anlam kazanıyor (yanlış duymadınız). Araçları her ajanın içine tek tek gömmek yerine merkezî olarak paketleyip tekrar kullanılabilir hâle getiriyorsunuz. Bana göre bu fena olmayan, hatta bayağı işe yarayan bir adım. Çünkü kurumsalda ölçek dediğiniz şey sadece kullanıcı sayısı değil; bakım yükü, governance (evet, doğru duydunuz). Görünürlük de işin içine giriyor.
Bir de şu var: Tool’ları doğrudan ajana bağlayınca bağımlılık zinciri uzuyor. Bir gün GitHub token yenileniyor, ertesi gün Teams connector davranışı değişiyor, başka gün MCP sunucusu cevap süresini uzatıyor… Sonra herkes birbirine bakıyor. Bence Foundry’nın önerdiği merkezî yapı bu karmaşayı biraz toparlıyor.
Toolbox tam olarak ne yapıyor?
Toolbox’ı ben şöyle okuyorum: Kurumsal dünyadaki “shared service” mantığının AI ajanlarına uyarlanmış hali. Yanı tek tek ekiplerin kendi küçük tool setlerini üretmesi yerine onaylı. Tanımlı araçları tek yerde topluyorsunuz; sonra ajanlar bunlara ortak bir kapıdan erişiyor.
Bu modelin güzel tarafı basit: yeniden kablolama yok. Bir ajanın içinde authentication kodu yazmak yerine toolbox üzerinden yönetiyorsunuz. Bir agent başka runtime’da çalışsa bile aynı endpoint’e gidiyor. Bu özellikle hibrit yapılarda bayağı işe yarar. Mesela Azure’da çalışan servisle şirket içindeki eski uygulamanın aynı tool setine erişmesi gerektiğinde işler kolaylaşıyor.
Kısa bir not düşeyim buraya.
Kendi AZ-305 hazırlık notlarımda hep şunu yazarım: mimariyi değerli yapan şey bileşen sayısı değil, bileşenlerin nasıl yönetildiği. Toolbox da tam oraya oynuyor. “Araç deposu” gibi düşünmeyin sadece; daha çok denetimli bir kullanım katmanı gibi düşünün (kendi tecrübem)
Neyse uzatmayayım; public preview aşamasında odak Build ve Consume tarafında (buna dikkat edin). Discover ve Govern işe masada dürüyor ama henüz tam ağırlığını hissettirmiyor. Kağıt üstünde güzel tabiî, pratikte ne kadar olgunlaşacak önü zaman gösterecek.
Nerede gerçekten fark yaratır?
Bence en net senaryo onboarding otomasyonu. Yeni mühendis geldiğinde hesap açma, repo yetkisi verme, bulut kaynaklarını hazırlama, Azure DevOps görevleri oluşturma ve Teams mesajı atma gibi işler tek ajan üzerinden akabiliyor (bizzat test ettim). Burada sorun iş akışının kendisi değil; o akışı besleyen tool’ların parçalı olması.
Vallahi, Geçen yıl Eylül 2024’te Ankara’daki bir üretim firmasına yaptığımız danışmanlıkta benzer bir problem vardı ama konu agent değildi; klasik otomasyondu. Aynı entegrasyonun PowerShell script’i vardı, Logic App versiyonu vardı, bir de içeride yazılmış Python servisi vardı. Toolbox gibi merkezî yaklaşım o dönemde elimizde olsaydı muhtemelen operasyon ekibi çok daha az yorulurdu.
Enterprise tarafta bunun faydası daha belirgin çünkü governance baskısı var. Kim hangi aracı kullanıyor? Hangi tool yetkili? Hangi ortamda çalışıyor? Loglar nerede? Bunlar startup için bazen ikinci planda kalabiliyor ama büyük kurumda hiç öyle değil.
| Senaryo | Klasik yaklaşım | Toolbox yaklaşımı |
|---|---|---|
| Küçük startup | Hızlı başlar ama teknik borç çabuk büyür | Daha düzenli başlar fakat ilk kurulum biraz uğraştırır |
| Büyük enterprise | Kopya kod ve tutarsız güvenlik riski artar | Centrally managed yapı ile kontrol kolaylaşır |
| Maliyet | Sürekli yeniden geliştirme maliyeti çıkar | Aynı tool seti tekrar kullanıldığı için toplam maliyet düşebilir |
Küçük ekipler için uyarım şu olur: her şeyi toolbox’a taşımaya çalışmayın hemen. İlk etapta en çok kullanılan 3-5 aracı seçin; mesela ticket açma, kullanıcı oluşturma ve bildirım gönderme gibi basit ama sık çağrılan işler yeterli olur.
Ben olsam nasıl başlardım?
1) Önce tekrar eden işleri bulun
Lafı gevelemeden söyleyeyim: toolbox ancak tekrar varsa anlamlıdır. Tek seferlik özel entegrasyonları sırf havalı dürüyor diye paketlemek bence gereksiz yük yaratır. Önce son üç ayda kaç kez aynı tool kodunun yazıldığını çıkarın (inanın bana)
2) Kimlik ve yetkiyi merkeze alın
MCP server mı kullanıyorsunuz, API mi tüketiyorsunuz ya da connector mı bağlıyorsunuz — fark etmez; auth kısmını dağıtık bırakmayın. Ben bunu ilk defa bir telekom projesinde yaşadım; Kasım 2023’te farklı ekiplerin tuttuğu credential formatları yüzünden gece yarısı incident çıktı. Sorun modelde değildi… sorun erişimin dağınıklığındaydı.
3) Gözlemleme olmadan prod’a çıkmayın
Bak şimdi, E tabi burası hayatı nokta: merkezî toolbox varsa merkezî gözlemleme de olmalı. Kim hangi tool’u çağırdı? Ne kadar sürdü? Nerede patladı? Bunları göremezseniz yeni düzen eski kaosa dönüşür.
{
"toolboxName": "onboarding-tools",
"tools": [
"entra-user-provisioning",
"github-repo-access",
"azure-devops-task-creator",
"teams-welcome-notifier"
],
"policy": {
"authMode": "centralized",
"logging": "enabled",
"approvalRequired": true
}
}
İnanın, Açık konuşayım, ilk denediğimde beklediğim kadar pürüzsüz değildi diyebilirim (preview ürünlerde bu normal). Hele bir de farklı tool tiplerini aynı çatı altında standardize etmek isterken bazı isimlendirme ve sahiplik kararlarının netleşmesi gerekiyor; yanı iş orada bitmiyor çünkü kurumsal gerçeklik devreye giriyor.
Maliyet ve benimsenme açısından Türkiye’de tablo nasıl?
TL bazında bakınca ne değişir?
Ne yalan söyleyeyim, Bunu Türkiye’deki şirketler açısından değerlendirecek olursak mesele sadece Azure faturası değil; ekip zamanı da para ediyor artık bunu kimse inkâr edemez sanırım. Aynı entegrasyonu üç projede yeniden yazmak yerine toolbox ile ortaklaştırırsanız geliştirme süresi düşer; dolayısıyla dolaylı maliyet azalır.
Durun, bir saniye.
Kurum mu startup mı?
Küçük startup’larda hızlı hareket etmek önemli olduğu için basit API wrapper’larla başlamak mantıklı olabilir. Büyümeye başladığınız an kontrol kaybolur.Enterprise yapılarda işe ilk günden standart koymak daha doğru olur çünkü sonradan düzeltmek pahalıya patlıyor — bayağı pahalıya hem de!
Bütçe kısıtlıysa ne yapmalı?
Eğer bütçe sınırlıysa önce Foundry Toolbox’ın tamamını değil yalnızca en can alıcı senaryoyu deneyin: örneğin onboarding veya destek talebi triage akışı gibi net ROI üreten alanlardan başlayın.Alternatif olarak tüm ajan mimarisini dönüştürmek yerine mevcut API gateway’ınızın üstüne hafif bir ortak kullanım katmanı koyabilirsiniz. Illâ büyük patlama yapmanız gerekmiyor.
Kurumsal AI projelerinde başarı çoğu zaman model kalitesinden değil, aracın düzeninden geliyor.
Dağınık araç = dağınık güvenlik = dağınık operasyon.
Bu zinciri kırmadan ölçek beklemek biraz hayalcilik olur.
Bana göre Foundry Toolbox’ın güçlü yanı tam burada ortaya çıkıyor: yeniden kullanılabilirliği teşvik ediyor ama bunu rastgele paylaşım şeklinde yapmıyor; yönetilebilirlik ekliyor.Bu ayrıntı önemli çünkü kurumsalda “paylaşılabilir” olan şey çoğu zaman “kontrolsüz” hâle de gelebiliyor.
Sahada beni heyecanlandıran taraf ne?
Ajan mimarisini yıllardır izleyen biri olarak şunu söyleyebilirim: insanlar genelde modeli tartışıyor ama asıl savaş zemini araç orkestrasyonu oluyor.Ben AZ-104 ve AZ-500 çalışırken bile hep altyapının görünmeyen tarafına takılırdım; kimlikler,network,policy,loglama… Toolbox bana yine o hissi veriyor.
Dürüst olayım, eksik tarafı da var.Preview olması nedeniyle tam olgunluk beklemek doğru olmaz.Discover kısmının gelmesiyle değer ciddi artar ama şu an odak daha çok build/consume ekseninde.Yani iyi başlangıç,henüz ham,biraz daha pişmesi lazım.
- Aynı tool’u tekrar tekrar yazmayı azaltır.
- Ajanlar arasında tutarlılık sağlar.
- Governance ve erişim kontrolünü sadeleştirir. — ciddi fark yaratıyor
- Büyük organizasyonlarda bakım yükünü düşürür.
Eğer bugün böyle bir yapı kuracaksanız ilk işiniz şu olsun:hangi tool’ların gerçekten ortak olduğunu tespit edin,sonra auth modelini standartlaştırın,en sonda gözlemleme ekleyin.Ters sırayla giderseniz kafanız karışır,denedim,olmadı.Bir bankacılık projesinde Temmuz 2024’te tam bunu yaptık;önce logging’i oturtup sonra policy’ye geçince süreç çok daha rahatladı.
Sıkça Sorulan Sorular
Foundry Toolbox nedir?
Foundry Toolbox, ajanların kullandığı araçları tek bir yerde toplamanı sağlayan yeniden kullanılabilir bir yapı. Amaç basit aslında: her ajan için ayrı ayrı entegrasyon yazmaktan kurtulmak.
MCP server ile Toolbox arasındaki fark ne?
MCP server genelde belirli araçlara erişim sunuyor; Toolbox işe bu araçları seçip paketleyerek tek noktadan yönetmeni hedefliyor. Yanı biri taşıma hattı gibiyse, diğeri organize edilmiş bir raf sistemi gibi düşünebilirsin. Bence bu ayrımı kavramak, ikisini de doğru kullanmak için kritik.
Küçük ekipler için uygun mu?
Evet, uygun. Ama açıkçası hemen her şeyi taşımak şart değil. Tecrübeme göre önce sık kullanılan birkaç aracı toplayıp deney yapmak çok daha mantıklı.
Enterprise ortamda neden daha değerli?
Büyük kurumlarda governance, yetki yönetimi, loglama ve standartlaşma gerçekten kritik oluyor. Hani bunlar çözülmezse kaos kaçınılmaz. Toolbox tam da bu karmaşayı azaltmaya yardım ediyor.
Buna geçerken en büyük risk ne?
Şimdi, ne yalan söyleyeyim, Düzensiz sahiplik modeli. Yanı hangi tool’un sahibi kim, kim onay veriyor, hangi policy geçerli — bunlar net değilse, mesela yeni bir sorun üretmiş olursun. Açıkçası bu kısım çoğu zaman göz ardı ediliyor (ki bu çoğu kişinin gözünden kaçıyor)
Kaynaklar ve İleri Okuma
Introducing Toolboxes in Foundry
Şöyle ki, Microsoft Learn — Azure AI Foundry Belgeleri
Model Context Protocol Resmî Sitesi
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