Microsoft Foundry’de Ajanları Dağıtmak: Asıl Oyun Şimdi Başlıyor
Asıl mesele artık ajan yapmak değil
Bakın şimdi, son bir yılda herkesin ağzında “ajan” var. Her demo’da bir şeyler planlayan, özetleyen, e-posta yazan, görev açan sistemler gördük. Güzel. Hatta baya iş görüyor. Ama işin aslı şu: kurumsalda en zor kısım çoğu zaman modeli eğitmek ya da workflow’u çizmek değil; o ajanı insanların günlük iş akışına sokmak oluyor.
Ben bunu Logosoft tarafında farklı sektörlerde net gördüm. Bir finans kuruluşunda PoC aşamasında fena olmayan bir ajan vardı; toplantı notlarını çıkarıyor, aksiyonları ayırıyor, hatta takip soruları öneriyordu. Ama kullanıcılar ayrı bir web uygulamasına girmek istemedi (bizzat test ettim). “Teams’te olsun”, dediler. İşte tam orada taşlar yerine oturdu. Çünkü kimse yeni bir kapı daha öğrenmek istemiyor… Neden önemli bu? özellikle de sabah dokuzda Outlook ile Teams arasında koştururken (yanlış duymadınız)
Microsoft Foundry’nın bu duyurusu bana göre tam da bu problemi hedefliyor: ajanı yapmak değil, çalıştırmak. Yanı üretim tarafında “güzel demo”dan “gerçek kullanım”a geçiş. Bence doğru yönde atılmış bir adım ama hâlâ pişmesi gereken yerler var; özellikle yetkilendirme modeli. Yaşam döngüsü yönetimi tarafında bazı detaylar sahada can sıkabilir.
Bir de şu var: kurumsal yapıda başarı bazen teknolojiden çok dağıtım kanalına bağlı oluyor. Kullanıcı alışkanlığı dediğimiz şey küçümsenecek bir konu değil. 2019’da İstanbul’da bir müşteride benzer şekilde portal tabanlı bir otomasyon kurmuştuk; teknik olarak iyiydi ama adoption düşük kaldı. Sonra aynı işi Microsoft 365 dünyaine yaklaştırınca kullanım patladı. E tabi insanın önüne tanıdık ekran gelince direnç düşüyor.
Kısa bir not düşeyim buraya.
Microsoft 365 Copilot ve Teams’e yayınlamak neden kritik?
Foundry’deki yaklaşımın en güçlü yanı, ajanın geliştirildiği yer ile kullanıldığı yer arasındaki mesafeyi kısaltması. Eskiden ekipler önce backend’i kuruyor, sonra ayrı arayüz tasarlıyor, ardından güvenlik onayı alıyor, sonra da “birkaç kişi kullansın bakalım” diye bekliyordu. Şimdi işe agent’ı doğrudan Microsoft 365 Copilot ve Teams içine taşıyabiliyorsunuz.
Bu kulağa küçük gibi geliyor ama operasyonel etkisi büyük. Çünkü çalışanların zaten kullandığı yere gidiyorsunuz: toplantılar, grup sohbetleri, belge paylaşımı, onay süreçleri (ki bu çoğu kişinin gözünden kaçıyor). Yanı ajanı başka yere çağırmıyorsunuz; işi olduğu yere götürüyorsunuz.
Geçen ay Ankara’daki bir üretim firmasında bunun benzerini tartıştık. Satın alma ekibi için tedarikçi evrak kontrolü yapan bir agent düşünülüyordu ama herkes tek tek portal açmayı istemiyordu. Ben de açık konuşayım: böyle senaryolarda Teams entegrasyonu neredeyse altın değerinde oluyor. Kullanıcı için ekstra sürtünme yoksa benimsenme artıyor.
Kullanıcı deneyimi neden değişiyor?
Garip gelecek ama, Klasik AI deneyimi genelde şöyle ilerliyor: soru sor → cevap al → kapat. Güzel mi? Güzel sayılır. Ama iş hayatı böyle işlemiyor ki! Çoğu süreç uzun soluklu oluyor; onay gerekiyor, bekleme var, başkasıyla koordinasyon lazım.
Hani, Foundry’nın sunduğu modelde iş biraz delegasyona dönüyor: hedef veriyorsunuz, ajan işi yürütüyor, checkpoint’lerde size haber veriyor. Gerektiğinde insana devrediyor. Neden önemli bu? Bu fark önemli çünkü insanlar artık sadece sohbet etmek istemiyor; işin yükünü paylaşacak dijital ekip arkadaşı istiyor.
Küçük ekip mi büyük kurum mu?
İşin garibi, Küçük startup iseniz hızlı kazanımlara bakarsınız: tek Teams kanalı içinde çalışan basit otomasyonlar yeterli olabilir. Enterprise tarafta işe hikâye farklıdır; (söylemesi ayıp) denetim izi isteriniz, rol bazlı erişim beklersiniz, veri sınırları önemli. Her şeyin log’u tutulmalı diye bastırırsınız — haklı olarak.
Bunu kendi AZ-305 hazırlık sürecimde de hep düşündüm: mimariyi kağıt üstünde güzel çizmek kolaydı ama gerçek hayatta yönetişim olmadan hiçbir şey yürümüyor. Ajan dağıtımı da aynı kafada ilerliyor; hız kadar kontrol de şart.
Ajanlarla çalışmak: Chat değil delegasyon
Bana göre burada en önemli zihinsel değişim şu: “Bu ajana ne sorabilirim?” yerine “Bu ajana hangi işi verebilirim?” demek gerekiyor. Ufak fark gibi dürüyor ama tasarımı büyük ölçüde değiştiriyor.
Prompt → Response mantığı işe yarar; fakat kurumsal işlerde Goal → Execution → Checkpoint → Human handoff modeli çok daha gerçekçi dürüyor.
Mesela satış ekibinde fırsat takibi yapan bir agent düşünün. Sadece “bu müşteriye mail yaz” demek yetmez; CRM kaydını kontrol etsin, önceki görüşmeleri özetlesin, fiyat teklifini gözden geçirsin. Gerekiyorsa yöneticiden onay alsın… İşte burada klasik chatbot yetersiz kalıyor.
Aslında, Ben geçen sene İzmir’de bir lojistik şirketinde buna benzer akışı test ettim (haziran ayında). İlk denemede sorun çıktı — itiraz edebilirsiniz tabi — çünkü agent gerekli SharePoint dokümanlarına ulaşamıyordu; yetki eksikti. Hata mesajı pek açıklayıcı değildi — sınır bozucuydu açıkçası! Çözüm işe basitti ama önemliydi: veri kaynaklarını net ayırıp erişimi gruplarla düzenledik.
| Konu | Klasik chatbot | Ajan yaklaşımı |
|---|---|---|
| Etkileşim tipi | Soru-cevap | Görev devretme |
| Süreklilik | Anlık yanıt | Uzun süren iş akışı |
| İnsan rolü | Kullanıcı sadece sorar | Kritik noktalarda onay verir |
| Kurumsal uyum | Sınırlı olabilir | Daha doğal entegre olur |
Autopilot agents ne vadediyor?
Ana haberlerden biri de autopilot agents tarafıydı ya hani… Bu bölüm bence oldukça ilginç çünkü ajana neredeyse çalışan statüsü veriliyor diyebiliriz (tabiî mecazi anlamda) (inanın bana). Kendi kimliği olan, lisansla gelen e-posta ve takvim erişimine sahip sistemlerden söz ediyoruz.
Kısa bir not düşeyim buraya.
Böyle bakınca biraz ürkütücü gelebilir mi? Gelebilir! Hele güvenlik ekiplerine anlatırken yüz ifadeleri hemen değişir biliyorum :) Ama doğru kurgulanırsa bu yapı insan-ekip-ajans üçgeninde ciddi rahatlık sağlar.
Nerede işe yarar?
Ekip içi koordinasyon yoğun olduğunda autopilot yaklaşımı baya mantıklı olabilir. En çok da de de proje ofisleri, müşteri başarı ekipleri, operasyon merkezleri ve satış destek gruplarında sürekli devam eden işler var ya — onları toparlamak için birebir olabilir.
- Teslim tarihi yaklaşan işleri hatırlatma
- Toplantılardan çıkan aksiyonları takip etme
- Sohbetlerde bağlam kaybolunca özet geçmeBelli durumlarda insan onayı istemeE-postalar ile takvim arasındaki kopukluğu azaltma
;
E tabi bunun gölge tarafı da var. Agent’a fazla özgürlük verirseniz karmaşa büyür. Bilhassa enterprise ortamda kim ne yaptı, hangi karar nasıl alındı, bunların izlenmesi gerekiyor. Ben bu yüzden autopilot fikrini seviyorum ama temkinle seviyorum.
Maliyet ve pratiklik meselesi
Maliyet tarafını da atlamamak lazım. Azure dünyasında her yeni servis ilk bakışta küçük görünür ama kullanım büyüdükçe fatura sessizce kabarıverir. TL bazında düşündüğünüzde döviz etkisi zaten başlı başına dert; o yüzden pilotu dar kapsamda tutup ölçmeden genişletmemek lazım.
# Basit başlangıç kontrol listesi
1) Tek use case seç
2) Veri kaynaklarını sınırla
3) Yetki modelini netleştir
4) Loglama aç
5) Kullanıcı geri bildirimi topla
6) Sonra yaygınlaştır
# Eğer bütçe kısıtlıysa:
- Önce mevcut M365 yüzeylerini kullan
- Ayrı portal yerine Teams'i tercih et
- Karmaşık orkestrasyonu sonraya bırak
}
Bende bıraktığı his ne öldü?
[p]
Geçmiş projelerde şunu defalarca gördüm: teknoloji güzel olsa da kullanıcı önü yanlış yerde görüyorsa değer düşüyor. Foundry’nın yeni hamlesi bu yüzden kıymetli; ajanları vitrine koymaktan çıkartıp çalışma alanının içine sokuyor.
[p]
Bir de dürüst olayım:her şey hazırmış gibi anlatılıyor bazen,ama pratikte entegrasyon katmanı uğraştırıyor. Kimlik,izinler,veri sınırları,tenant politikaları… Bunlar romantik konular değil,saha konusu. Ve saha bazen acıtıyor.
[p]
Yine de yön doğru. Ben özellikle Microsoft’un delegasyon odaklı dili seviyorum çünkü bu dil kurumsal gerçeğe daha yakın. İnsanlar araç değil sonuç istiyor; hızlı cevap değil sürdürülebilir iş akışı istiyor.
[h2]Mevcut yazılarla bağlantılı birkaç not[/h2]
[p]Ajan mimarisinin temel katmanlarını daha derinden anlamak isterseniz Microsoft Agent Framework’te Asıl Değişim: Harness, Hosted Agents ve CodeAct yazısına da göz atabilirsiniz. Orada orkestrasyon tarafındaki kırılmaları biraz daha teknik açıdan işlemiştim.
[p]Dağıtım kanalı kadar uçta çalışma senaryolarını merak ediyorsanız Foundry Local ile Uçta Yapay Zekâ: Bulut Dışı Hızın Gerçek Yüzü. Oradaki edge perspektifi burada güzel tamamlayıcı oluyor.
[p]Eğer Copilot ekosisteminde kullanıcı davranışının nasıl değiştiğini merak ediyorsanız Copilot kullanımında yeni dönem: Cohort verisi ne anlatıyor? yazısı da iyi eşlik eder. Çünkü benimsenme kısmını rakamlarla okumak bambaşka fikir veriyor.
Sıkça Sorulan Sorular
Ajanları Microsoft 365 Copilot ve Teams’e neden yayınlamalıyım?
Çünkü çalışanlar zaten gün boyu bu araçların içinde yaşıyor. Ayrı bir portal açtırmak yerine ajanı direkt oraya koyduğunuzda, aslında benimseme oranı ciddi şekilde artıyor. Sürtünme de bir anda azalıyor.
Autopilot agent ile normal agent arasındaki fark nedir?
Autopilot agent kendi kimliğiyle çalışıyor, yanı süreklilik gerektiren görevleri üstlenebiliyor. Normal agent işe çoğunlukla belirli tetikleyicilere ya da kullanıcı etkileşimine bağlı kalıyor. Bence bu ayrım, hangi senaryoyu seçeceğinizi belirlemede çok kritik.
Küçük işletmeler için bu yaklaşım mantıklı mı?
Evet, ama açıkçası kapsamı dar tutmak şart. Önce tek bir senaryo seçin, sonucu görün. Her şeyi aynı anda otomatikleştirmeye kalkarsanız işler hızla karışabiliyor — tecrübeme göre bu hatayı yapanların pişman olduğunu çok gördüm.
Kurumsal tarafta en büyük risk ne?
Yetki yönetimi ve veri erişimi. Agent doğru bilgiye ulaşamazsa zaten faydasız oluyor; fazla yetki verirseniz de güvenlik riski kapıya dayanıyor. Hani bu denge, kurumsal tarafta her şeyin merkezinde dürüyor.
Kaynaklar ve İleri Okuma
Orijinal Microsoft Foundry blog yazısı
Microsoft Learn — Azure AI Foundry belgeleri
Microsoft Learn — Copilot Studio dokümantasyonu
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