Teams’te Çalışan Ajanlar: İşin Olduğu Yerde Başlamak
Hani, Geçen hafta bir müşteride tam olarak şu cümleyi duydum: “Ajan yaptık ama kim kullanacak, nerede çalışacak, nasıl iş yapacak?” İşin aslı şu ki, çoğu ekip ajanı ayrı bir köşeye koyuyor; sonra da kullanıcıdan o köşeye gidip hayatını değiştirmesini bekliyor. Olmuyor. İnsanlar işi Teams’te konuşuyor, toplantıda karar veriyor, kanalda dosya paylaşıyor, kısacası iş orada akıyor. Ajan da oraya girmeyince biraz vitrin ürünü gibi kalıyor.
Microsoft’un Teams tarafında anlattığı yeni yönelim tam da bu yüzden dikkat çekici. Ben bunu sadece “yeni özellikler geldi” diye okumuyorum. Bence asıl mesele, ajanı bir demo nesnesi olmaktan çıkarıp takımın doğal parçası hâline getirmek. Hani masada oturan biri varmış gibi… soruya cevap veriyor, not alıyor, işi takip ediyor, gerekirse aksiyon çıkarıyor. Kağıt üstünde güzel dürüyor; pratikte işe doğru tasarlanmazsa hayal kırıklığı da yaratabilir.
Ajanı neden Teams’in içine koymak gerekiyor?
Ne yalan söyleyeyim, Ben 2019’da benzer bir yaklaşımı kendi lab ortamımda denemiştim. O zamanlar amaç basitti: destek ekibinin Slack/Teams dışına çıkmadan bazı rutin işleri tetiklemesi. Sonuç? Ayrı portal açtırdığınız her senaryo yarıda kalıyor. Kullanıcı “sonra bakarım” diyor ve konu bitiyor. Bu yüzden bugün ajanların çalışma alanının içine gömülmesi bana çok mantıklı geliyor.
Teams’in gücü sadece mesajlaşma değil; bağlam taşıması. Bir toplantıda söylenen şeyle aynı konunun kanaldaki devamı arasında kopukluk olmaması lazım. Ajanın burada rolü şu: konuşmayı anlamak değil sadece, konuşmadan iş çıkarmak. Mesela görev açmak, özet üretmek, aksiyonları sıralamak… Basit görünüyor ama ekip disiplini açısından baya iş görüyor.
Durun, bir saniye.
Bir de şu var: Kurumsal tarafta kullanıcı davranışı startup’tan farklı oluyor. Küçük ekiplerde insanlar yeni şeyi dener; hatta bazen sırf meraktan kurcalarlar. Büyük yapılarda işe güvenlik onayı, — ki bu tartışılır — tenant politikası, veri sınıflandırması derken iş uzar. Yanı “ajanımız var” demek yetmiyor; nerede çalışacağına kadar düşünmek gerekiyor.
Evet.
Work IQ neden önemli?
Work IQ kısmını ben şöyle okudum: ajanın tek başına zeki olması yetmiyor, işin ritmini de anlaması lazım. Toplantıda başka davranırız, kanalda başka konuşuruz, direkt mesajda bambaşka oluruz. Aynı ajan her yerde aynı tonda davranırsa mekanik kalır. İnsanlar da bunu hemen hissediyor… robot gibi.
Bilhassa Microsoft 365 ekosisteminde bu bağlam farkı hayatı çünkü belgeye erişimle sohbet geçmişi aynı şey değil. Bir ajan bunları ayırabiliyorsa daha güven veren bir yardımcı oluyor.
Geliştirici tarafında ne değişiyor?
Bi saniye — Lafı gevelemeden söyleyeyim: Bugün ajan geliştirmede en yorucu kısım çoğu zaman model değil; çevresel işlerdir. Kayıt açma, credential yönetimi, manifest hazırlama, dağıtım adımları… Bunların hepsi tek tek yapılınca enerji tüketiyor. Sonra gerçek problem için motivasyon kalmıyor.
Şöyle söyleyeyim, Teams SDK’nın iyi yanı burada devreye giriyor. Tek platform hissi veriyor ve prototipten çalışan uygulamaya geçişi hızlandırıyor. Ben AZ-305. AZ-104 hazırlıkları sırasında bile şunu çok gördüm: mimariyi sadeleştiren her araç uzun vadede daha değerli oluyor çünkü ekiplerin düşünme yükünü azaltıyor (ciddiyim)
Bir dakika — bununla bitmedi.
// Basit bir akış örneği
1) Teams içinde kullanıcı mesaj atar
2) Ajan bağlamı okur
3) Gerekirse toplantı notlarını çeker
4) Aksiyon maddesi oluşturur
5) Sonucu kanala geri yazarBu arada açık konuşayım; araç seti ne kadar kolaylaşsa da iyi tasarım otomatik gelmiyor. İlk denediğimde ben de gereksiz fazla yetki verdim ve sonuçta izin matrisi karıştı. Hata şuydu: her şeyi tek seferde çözmeye çalıştım. Doğru yaklaşım önce dar kapsamla başlamak öldü — yalnızca chat içindeki birkaç senaryoyu açtık, sonra kanal ve toplantıya genişlettik.
| Yaklaşım | Küçük ekip | Büyük kurum |
|---|---|---|
| Kapsam | Tek use-case ile başla | Rol bazlı senaryolar planla |
| Yönetim | Hızlı pilot yeter | Onay akışı şart |
| Teslimat | Sürüm hızlı çıkar | DLP ve uyumluluk kontrolü gerekir |
| Maliyet | Düşük başlangıç maliyeti | Daha fazla operasyon yükü olur |
Sovereign cloud meselesi niye kıymetli?
Neyse uzatmayalım… Sovereign cloud desteği bence yazının en stratejik taraflarından biri olabilir mi? Evet olabilir. Çünkü kamuya yakın sektörlerde ya da regülasyonu ağır kurumlarda “globalde çalışıyor” cümlesi pek bir şey ifade etmiyor. GCC High veya DoD gibi ortamlarda kimlik doğrulama uçları, token scope’ları ve servis yönlendirmeleri düzgün ele alınmazsa proje duvara tosluyor.
Hmm, bunu nasıl anlatsamdı…
Şöyle söyleyeyim, Bunu Türkiye’deki şirketler açısından değerlendirirsek durum biraz ilginçleşiyor. Bizde bankalar, savunma sanayii firmaları ve büyük holdingler zaten veri sınırı konusunda hassas davranıyor. Kurumsal müşterilerimde gördüğüm kadarıyla benimsenme hızı teknik kapasiteden çok onay süreçlerine bağlı oluyor;. Teknoloji hazır olsa bile güvenlik ekibi ikna olmadan hiçbir şey ilerlemiyor.
Açıkçası bu konuda Microsoft’un cloud-aware yaklaşımı hoşuma gitti. Henüz büyük ölçüde pürüzsüz değilmiş gibi dürüyor (benim hissiyatım bu) (ki bu çoğu kişinin gözünden kaçıyor). En çok da test ortamıyla prod arasındaki farklar büyüdükçe geliştiricinin kafası karışabiliyor. O yüzden ilk gün “her tenant’ta aynı davranır” diye düşünmemek lazım.
İşte tam da bu noktada devreye giriyor.
Maliyet tarafını unutmayın
Maliyet kısmını TL bazında düşündüğünüzde küçük görünen farklar yıl sonunda can sıkabiliyor.
Yanı, Bir pilot projede üç kişiyle ilerlemek başka şeydir; yüzlerce kullanıcılı dağıtımda sürekli test etmek bambaşka.
Bütçesi kısıtlı ekipler için önerim şu: önce sadece Teams içinde belirli bir departmana kapalı pilot yapın.
Peki, ne yalan söyleyeyim, Sonra ölçün.
İtiraf edeyim, Gerçekten kullanım var mı? Yoksa herkes iki gün bakıp bırakmış mı?
Eh, Eğer bütçe sınırlıysa pahalı entegrasyonlara hemen abanmayın; önce standart Teams SDK akışıyla ilerleyin.
Kurumsal yapıda işe baştan audit log’u, yetkilendirme modeli ve lifecycle yönetimini planlayın.
Biri size “sonradan ekleriz” derse biraz temkinli olun… sonradan eklemek genelde daha pahalıya çıkıyor.
Ajanın değeri modelden çok konuma bağlıdır; doğru yerde duran orta seviye bir ajan, yanlış yerde duran parlak bir demodan daha faydalıdır.
Kullanıcıyı harekete geçirmek için ne yapmak lazım?
Ajanın işi sadece cevap vermek değil; işi ileri taşımak olmalı.
Mesela toplantıda çıkan kararları otomatik göreve dönüştürmek ya da kanal tartışmasını aksiyon listesine çevirmek…
Araya gireyim: Burada ince çizgi şu: aşırı agresif olmak istemezsiniz.
Kullanıcıya sormadan her şeyi yapan ajan kısa sürede rahatsız eder.
İnanın, Emin değilim ama sanırım en kilit nokta bu.
İnanın, 2024 Kasım’da İstanbul’daki bir müşteri projesinde buna çok benzeyen bir durum yaşadık.
Ajan ilk sürümde fazla hevesliydi ve kanala gereksiz bildirım yağdırıyordu.
İnsanlar şikayet etti tabi.
Sonra frekansı düşürdük, yalnızca gerçekten eylem gerektiren noktaları bıraktık — kullanım memnuniyeti bariz arttı.
- Kanal içi özet: Uzun tartışmaları kısa hâle getirir.
- Toplantı aksiyonu: Kararları görev listesine çevirir.
- Soru-cevap: Sık sorulan kurumsal bilgileri anında verir.
- Döküman yönlendirme: İlgili belgeyi bulup önüne koyar.
Peki nereden başlanır?
- Tek bir senaryo seçin: örneğin toplantı özeti ya da görev çıkarma.
- Erişim alanını dar tutun; mümkünse tek ekipte pilot yapın.
- Tepki süresini ölçün; yavaşsa kullanıcı affetmez.
- Daha sonra kanal ve meeting deneyimine genişletin.
Bence en kritik konu güvenilirlik
Sıkça Sorulan Sorular
Teams içinde çalışan ajan ile bağımsız chatbot arasındaki fark ne?
Bağımsız chatbot hani ayrı bir yerde dürüyor, kullanıcının oraya gitmesi gerekiyor. Teams içindeki ajan işe doğrudan iş akışının içine giriyor — yanı kullanıcı zaten orada, ekstra bir adım yok. Bence bu yüzden benimsenme oranı çoğu senaryoda çok daha yüksek çıkıyor.
Teams SDK hangi dillerle kullanılabiliyor?
Aslında ana destek Python, JavaScript ve C# tarafında geliyor. Tecrübeme göre ekibinizin zaten bildiği dilden başlamak en mantıklısı. Sırf moda diye dil değiştirmeye gerek yok.
Sovereign cloud ortamlarında geliştirme zor mu?
Zor olabiliyor, ama imkânsız değil (kendi tecrübem). Kimlik uçları, token scope’ları. Servis yönlendirmeleri dikkat istiyor — mesela bunlardan birini atlarsanız sonradan düzeltmesi can sıkıcı oluyor. Açıkçası başta düzgün plan yapılırsa sonradan çıkan maliyetler ciddi ölçüde azalıyor.
Küçük ekipler bu yaklaşımdan nasıl faydalanır?
Küçük ekiplerde hızlı pilot yapmak çok kolay. Tek bir use-case seçip doğrudan Teams’e gömmek yeterli. Bence en büyük avantajınız zaten hız — büyük ekiplerin onay süreçleriyle boğuştuğu sürede sız çıktı alabilirsiniz.
Kaynaklar ve İleri Okuma
Microsoft Dev Blog — Build collaborative agents where work happens
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