Discovery to Execution: Foundry’de Ajanları Toolbox ile Ölçeklemek
Asıl mesele tool sayısı değil, karmaşa
Yapay zekâ ajanlarıyla ilk kez uğraşan ekipler genelde şunu düşünüyor: “Birkaç tool ekleriz, biter.” Keşke öyle olsaydı. İşin aslı şu ki, küçük pilotlarda gayet rahat görünen yapı, üretime çıkınca bir anda dağılabiliyor. Tool sayısı artıyor, entegrasyonlar çoğalıyor, üstüne bir de güvenlik. Maliyet baskısı binince tablo biraz çamurlaşıyor.
Hani, Ben bu durumu 2024 Kasım’ında bir finans müşterisinde net gördüm. Ekip önce 12 tool ile başlamıştı; iki ay sonra sayı 70’e çıktı. Müşteri temsilcisi için ayrı, raporlama için ayrı, iç onay akışı için ayrı derken model her turda gereksiz şema bilgisi taşıyordu. Sonuç? Hem gecikme arttı hem de model bazen yakın ama yanlış tool seçmeye başladı. Hani “iyi gidiyorduk” dediğiniz yer var ya… tam orada fren yiyorsunuz.
Peki neden?
Microsoft Foundry’nın yeni yaklaşımı burada baya iş görüyor (buna dikkat edin). Çünkü mesele sadece araç sunmak değil; aracın doğru zamanda bulunması, doğru bağlamla çağrılması. Gerekiyorsa kontrol altında çalıştırılması. Benim bakış açıma göre bu ayrım kritik: demo dünyasında tool listesi gösterirsiniz, üretimde işe tool keşfi ve yürütme disiplini gerekir.
Gel gelelim küçük ekiplerle büyük kurumsal yapılar aynı şekilde düşünmüyor. Startup tarafında hız önemli; kurumsalda işe hız kadar izlenebilirlik de lazım. Büyük organizasyonda tek bir yanlış tool çağrısı bile güvenlik ekibinin kapısını çaldırabiliyor. Mantıklı değil mi? O yüzden Foundry’deki Toolbox yaklaşımı kağıt üstünde iyi dürüyor; pratikteyse doğru tasarlanmazsa yine karmaşa üretebilir.
Tool Search: Modeli kalabalıktan kurtarmak
Tool Search’in fikri basit ama etkisi ciddi: Her turda yüzlerce tool tanımını modele yığmak yerine önce niyetini söylüyorsun, sonra sistem sana en alakalı seçenekleri getiriyor. Yanı model artık rafların tamamını ezberlemeye çalışmıyor; önce danışıyor, sonra seçiyor. Bu bana eski veri merkezlerinde “her sunucuya her paketi yükleyelim” mantığını hatırlatıyor — çalışır mı? Çalışır. Verimli mi? Pek değil.
İlginç olan şu ki, Burada en sevdiğim nokta context ekonomisi. Modelin önüne 200 tool koyduğunuzda token maliyeti sessiz sedasız şişiyor. Üstelik problem sadece para değil; bağlam penceresi daralınca konuşma akışı da bozuluyor. Geçen yıl Mart ayında Logosoft tarafında bir perakende projesinde benzer bir durum yaşadık; araç sayısı arttıkça cevap kalitesi düşmeye başlamıştı (ciddiyim). Sonradan araçları sınıflandırıp arama mantığı ekleyince işler toparladı.
Şöyle söyleyeyim, tool_search ve call_tool ayrımı bu yüzden kıymetli. İlki keşif yapıyor, ikincisi uyguluyor (bizzat test ettim). Açık konuşayım, bu ayrım başta fazla sade gibi gelebilir ama üretimde sadelik altın değerinde oluyor. Mesela agent akışlarında “hangi aracı ne zaman göstereceğim?” sorusu çoğu zaman asıl mimarı sorudur. Daha fazla bilgi için Azure DevOps’tan GitHub’a Kesintisiz Geçiş: ELM ile Yeni Dönem yazımıza bakabilirsiniz.
Durun, bir saniye.
Küçük ekip vs enterprise
Küçük ekipteyseniz Tool Search’i hemen her yere yaymak zorunda değilsiniz. Önce sık kullanılan 10-15 aracı toparlayın, isimlendirmeyi düzeltin, açıklamaları sadeleştirin. Böylece sistem daha az sürpriz çıkarır. Daha fazla bilgi için Kubernetes’te Doğrulama Artık Kod Değil: v1.36’da Ne Değişti? yazımıza bakabilirsiniz. Bu konuyla ilgili .NET 11 ve Build 2026: Kaçırmamanız Gereken Oturumlar yazımıza da göz atmanızı tavsiye ederim.
Büyük kurumsal yapılarda işe iş değişiyor. Orada yetkilendirme katmanı, audit kaydı ve versiyonlama olmadan ilerlemek mümkün değil gibi düşünün (en azından benim deneyimim böyle). Bir bankacılık müşterisinde 2025 Şubat’ında gördüğüm şey şuydu: aynı işlevi yapan üç farklı API vardı. Agent hangisini seçeceğini şaşırıyordu.
| Senaryo | Daha mantıklı yaklaşım | Neden? |
|---|---|---|
| Küçük startup | Sade toolbox + iyi açıklamalar | Düşük operasyon yükü |
| Büyük enterprise | Tool Search + RBAC + audit | Karmaşıklık ve uyum ihtiyacı yüksek |
| Maliyet baskısı olan ekip | Sadece gerekli araçları yüzeye çıkarma | Token tüketimi düşer |
| Sık değişen süreçler | Sürüm kontrollü toolbox yönetimi | Kırılganlık azalır |
Skills ve tekrar kullanılabilir yetenekler neden önemli?
Bence Skills preview özelliği yazının en stratejik parçalarından biri olabilir çünkü yeniden kullanılabilirliği ciddiye alıyor. Tek tek custom integration yazmak yerine beceriyi katalog gibi saklamak fikri bana baya mantıklı geliyor — dürüst olayım, biraz hayal kırıklığı —. Mantıklı değil mi? Bir capability’yi bir projede hazırlayıp başka ajanlara açabiliyorsanız — işte orada tekrar kullanım başlıyor.
Bunu 2019’da kendi sunucularımla yaptığım eski otomasyon düzenlerine benzetiyorum biraz (o zamanlar Azure’a geçiş süreçlerini de yönetiyorduk). Aynı script’in kopyalarını farklı klasörlerde tutar dururduk; biri güncellenince diğeri unutulurdu… klasik bela! Skills yaklaşımı o dağınıklığı azaltabilecek türden bir şey. Teams’te Çalışan Ajanlar: İşin Olduğu Yerde Başlamak yazımızda bu konuya da değinmiştik. Azure Cosmos DB’de Vektörler Kendini Güncelliyor: AI Uygulamalarda Yeni Dönem yazımızda bu konuya da değinmiştik.
E tabi eksik tarafı yok mu? Var tabiî ki var: preview aşamasındaki özelliklerde olgunluk her zaman soru işaretidir. Sürümleme disiplininiz zayıfsa reusable capability güzel fikir olmaktan çıkıp bakım yüküne dönüşebilir (kendi tecrübem)
Nerede işe yarar?
- Müşteri hizmetlerinde ortak işlem adımları varsa
- Tekrar eden onay akışları varsa
- Aynı veri erişim mantığı birçok ajan tarafından kullanılıyorsa — bunu es geçmeyin
- Ekipler arasında ortak standart gerekiyorsa
- Kod kopyalamadan büyümek istiyorsanız
Browser Automation ve Work IQ / Fabric IQ: gerçek dünya bağlamı işi değiştirir
Ajanların güzel yanı teoride çok şey yapabilmeleri… ama gerçek dünya bazen web formu demek oluyor, bazen login ekranı demek oluyor, bazen de insan müdahalesi gerektiren garip edge case’ler çıkıyor karşınıza. Browser Automation’ın Playwright tabanlı yapısı burada — kendi adıma konuşayım — bayağı iş görüyor. Hosted agent ile web görevlerini daha doğal hâle getiriyor.Bunu ilk duyduğumda “tamam güzel de gözle görülür kontrol nerede?” diye düşündüm açıkçası. Sonra demo senaryolarını inceleyince fikir netleşti: canlı görünürlük ve kontrol mekanizması özellikle kurumsalda değerli. Geçen sene Eylül ayında bir lojistik firmasındaki POC’de benzer otomasyonları manuel fallback ile yönetmiştik; hata anında operatör devreye girmediğinde süreç kilitleniyordu. Burada o boşluk biraz kapanmış gibi dürüyor.
Ajan otomasyonu hızlı olsun diye kontrolü bırakmayın; üretimde hız kadar geri alma kabiliyeti de lazım.
Maliyet tarafına dürüst bakalım”
”
Açık konuşayım, Tool Search gibi özellikler token maliyetini azaltarak tasarruf sağlayabilir ama bu sihir değildir. Yanlış mimariyle kurarsanız başka yerde masraf çıkarırsınız. Mesela sürekli yeniden denenen web otomasyonları ya da aşırı detaylı skill tanımları bütçeyi sessizce yer.Tl bazında düşündüğünüzde küçük farklar ilk bakışta önemsiz görünüyor olabilir… fakat ay sonunda rapora bakınca can sıkabiliyor: En çok da çok ajansal sistemlerde her turdaki ufak optimizasyonun toplam etkisi büyüyor. Benim önerim şu olurdu: önce ölçün, sonra genişletin; aksi hâlde FinOps toplantısında garip bakışlar kaçınılmaz olur.
Routines ile yürütmeyi rayına oturtmak”>
”
Yanı, Routines preview kısmı diğerlerinden biraz ayrılıyor çünkü doğrudan agent run control”” üzerine gidiyor: Bence burası daha az gösterişli ama daha kritik alanlardan biri. Çünkü agent’in ne yapacağını bilmek kadar ne zaman koşacağını bilmek de önemli.Kendi deneyimimde production sorunlarının yarısı “yanlış zamanda çalışan doğru job” veya “doğru zamanda çalışmayan job” kaynaklı oluyor. Haziran 2024’te bir telekom müşterisinde bunu acı şekilde yaşamıştık; queue dolmuştu, servis ayakta görünüyordu ama iş ilerlemiyordu. Routines tarzı yapıların amacı tam da bu tür akışlara disiplin getirmek.Dikkat etmeniz gerekenler””
- ”
- Ajanın tetikleme koşullarını net tanımlayın”
- İstisna senaryolarına fallback koyun” (bence en önemlisi)
- Audit log’u baştan planlayın”
- Yetki sınırlarını role göre ayarlayın”
- Canary yaklaşımıyla başlayın”
Bunu Türkiye’de nasıl okurum?
‘
‘Bir de entegrasyon maliyeti var. Azure servisleri güçlü, evet ; ama TL bazında bakınca plansız kullanım çabuk hissediliyor. O yüzden ben hep şunu söylüyorum : küçük ekipseniz düşük riskli pilotla başlayın, büyük kurumsalsanız governance katmanını ilk günden koyun. Yoksa sonradan düzeltmek, yeni kurmaktan daha yorucu oluyor.’
‘
‘Az önce söylediklerimi biraz sert bulabilirsiniz… aslında haklısınız. Ama saha gerçeği böyle. Bir projede “önce çalışan versiyon çıksın” diyerek başladığınız şey, üç ay sonra kimsenin dokunamadığı bir kara kutuya dönüşebiliyor.’
‘
Sıkça Sorulan Sorular
Toolboxes in Foundry ne oluyor?
Aslında şöyle düşün: Toolboxes, ajanların çalışma anında araç bulup kullanabildiği bir katman gibi. Yanı araç keşfi, erişim ve çağrı düzeni — hepsi burada toplanıyor.
Tool Search ne işe yarıyor?
Tool Search, modele tüm araç listesini yüklemek yerine sadece ilgili olanları getiriyor. Bence bu çok akıllıca bir yaklaşım — context küçülüyor, maliyet azalıyor ve seçim kalitesi de bir hayli artıyor.
Routines ile normal workflow arasındaki fark ne?
Routines, agent run control odağında çalışıyor. Yanı mesela sadece işi yapmak değil, o işi ne zaman koşturacağını yönetmek istiyor. Açıkçası bu ayrım başta ince görünüyor ama pratikte çok fark yaratıyor.
Küçük ekipler için bu özellikler fazla mı karmaşık?
Bakın, Hayır, doğru başlanırsa değil. Tecrübeme göre önce az sayıda tool, net açıklama ve basit bir yetki modeliyle ilerlemek yeterli oluyor. Hani her şeyi aynı anda kurmak zorunda değilsin.
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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder