Teams için Ajan Geliştirme: Sohbeti Sonuca Çeviren Mimari
Şunu itiraf edeyim: Ajan (agent) kelimesini son bir yılda öyle çok duyduk ki, artık çoğumuz duyunca içimizden “yine mi” diyoruz. Evet, biraz yorucu. Ama Microsoft’un geçtiğimiz günlerde başlattığı Building Agents for Teams blog serisini görünce, işin aslında bambaşka bir yere kaydığını fark ettim; çünkü standalone bir chatbot yazmakla, insanların sabah 9’da zaten açtığı Teams penceresinin içine yerleşen bir ajan yazmak arasında bayağı fark var, hem teknik tarafta hem de kullanım alışkanlığında.
Bu yazıda hem Microsoft’un ilan ettiği yeni yön haritasını hem de sahada gördüğüm şeyleri karıştırıp anlatacağım,. Lafı gevelemeden söyleyeyim: Teams platformunda ajan geliştirmek bugün farklı bir denklem. Kısacası, peki neden? Çünkü kullanıcıyı yeni bir yere sürüklemiyorsunuz, tam tersine onun halihazırda yaşadığı akışın içine giriyorsunuz; Türkiye’deki kurumsal müşterilerin buna nasıl baktığını da araya serpiştireceğim, bazısı “iş görür” diyor, bazısı da önce güvenlik duvarına bakıyor.
Standalone ajan çağı bitti, kolektif ajan çağı başladı
Bugün piyasadaki ajanların çoğu ne yapıyor? Kendi ayrı uygulamasında dürüyor, ayrı tab’de bekliyor, ayrı web arayüzünde sessizce oturuyor. Bir şey soracaksanız oraya gidiyorsunuz. Kullanıcı ajanı buluyor, açıyor, bir de ona alışmaya çalışıyor (şaşırtıcı ama gerçek). Yanı iş akışı ajana doğru kıvrılıyor; halbuki olması gereken tam tersi. Kısa olan bu.
Çok konuştum, örnekle göstereyim.
Microsoft’un burada işaret ettiği yer bence baya yerinde. Kod yazmak ya da uzun araştırma yapmak gibi ağır işler için o ekstra sürtünme çok da batmıyor, tamam. Ama günün büyük kısmı öyle geçmiyor ki; onay verme, “şu rapor nerede?” diye sorma, “kim ilgileniyor bununla?” diye yoklama yapma, statü kontrol etme… Bunlar için sohbet penceresini kapatıp başka uygulamaya zıplamak biraz fazla uğraş oluyor, açık konuşayım. Evet.
Bir ajan Teams’de tıpkı bir iş arkadaşınız gibi davranır. @mention edersiniz, kanala eklersiniz, düz Türkçe (veya İngilizce) bir görev verirsiniz, o da aynı thread’de cevap verir. Toplantıya çağırmak isterseniz önü da yaparsınız. Eğitim yok, kılavuz yok — çünkü insanlar zaten birbirleriyle nasıl çalışıldığını biliyor.
Bu fikir kötü değil, hatta şaşırtıcı biçimde kullanışlı dürüyor. Ama dur bir saniye — asıl mesele modelin akıllılığı falan değil; geliştirici tarafında dağıtım derdi hafifliyor — itiraf edeyim, beklentimin üstündeydi —. Kurumsal bir SaaS çıkarıp sonra müşteriye “hadi bunu kullanın” demenin ne kadar yorucu olduğunu bilenler bilir, hele adoption kısmı bazen ürünün kendisinden daha inatçı olur. Teams içindeki ajan işe kullanıcının önüne kendiliğinden çıkıyor; kullanıcı da ekstra öğrenme yapmadan işine bakıyor.
Peki neden tam da şimdi?
Bir yıl önce ajan demek çoğu zaman gösterişli demo demekti. Bugün işe gerçekten iş bitiren bir şey ship edebiliyorsunuz. Üç şey aynı anda hizaya girdi:
- LLM’lerin kapasitesi ciddi biçimde büyüdü — geçen sene tökezlediği işi şimdi gayet üstlenebiliyor.
- Gecikme (latency) artık blocker değil; GPT-5 sınıfı modeller bile saniyeler içinde cevap veriyor.
- Token maliyetleri düşmeye devam ediyor. Yanı “her mesaja LLM çağırsam batarım” korkusu eskisi kadar sert gelmiyor. — ciddi fark yaratıyor
Bir de standartlar tarafında işler toparlandı diyebilirim. Model Context Protocol (MCP), ajanlara tool, skill. Memory erişimi için ortak bir dil veriyor; agent-to-agent iletişim protokolleri de ajanların birbirleriyle konuşmasını sağlıyor. Bunlar Microsoft’a özel numaralar değil, sektörün yavaş yavaş ortaklaştığı parçalar (kendi tecrübem). Ve Teams platformu bu dilleri native konuşuyor;. Sistemin içine gömülü geliyorlar, sonradan yamalanmış gibi durmuyorlar.
Teams platformu ne sunuyor teknik olarak?
Açık konuşayım, İşin teknik tarafına girelim. Teams’de bir ajan geliştirince elinize ne geçiyor, biraz ona bakalım.
Etkileşim yuzeyleri
Bir Teams ajanı üç ana yerde nefes alıyor: 1:1 sohbetler, grup kanalları ve toplantılar. Her birinin davranışı ayrı, hatta bazen biraz huysuz bile diyebilirim; mesela toplantı ajanı transkripti dinleyip aksiyon maddesi çıkarabiliyor, kanal ajanı işe proaktif biçimde (adaptive card ile) bilgi itebiliyor (ben de ilk duyduğumda şaşırmıştım). Aynı ajan, ama üç farklı karakter gibi.
Evet.
Kimlik ve yetkilendirme
Burada Türkiye’deki kurumsal ekiplerin en çok uğraştığı yere geliyoruz. Bir ajan sadece cevap veren bir şey değil, aynı zamanda kullanıcı adına iş yapan bir bileşen;. SSO (Single Sign-On), Entra ID entegrasyonu, on-behalf-of (OBO) akışları… Bunları sağlam kurmadan production’a çıkarsanız güvenlik ekibi kapıda belirir, haklı olarak soru sorar (ve soruları da kısa olmaz) (şaşırtıcı ama gerçek). Doğru kurgulandığında işe ajanınız kullanıcının yetkileriyle SharePoint’e, Graph’a ve üçüncü parti API’lere erişebiliyor.
Bir bakıma, peki neden?
Depolama ve hafıza
Ajanların hafızası deyince akla hemen “her şeyi hatırlasın” fikri geliyor, ama iş öyle değil; daha önce yazdığım Eve + Azure Cosmos DB: Unutmayan Ajan Nasıl Kurulur yazısında anlattığım pattern’ler burada da geçerli. Konuşma bağlamını kısa vadeli hafızada tutmak gerekiyor, kullanıcıya özel tercihleri işe uzun vadeli bir store’da saklamak lazım; Teams SDK’sı bunun için bazı primitive’ler veriyor ama gerçek üretim senaryolarında altına bir Cosmos DB ya da Azure AI Search koymak çoğu zaman şart oluyor.
Maalesef.
Türkiye’deki kurumsal manzara: adopsiyonun gerçek hali
Şimdi kağıttan sahaya inelim. Türkiye’de kurumsal müşterilerin bu işte nerede durduğunu konuşalım, çünkü Microsoft blog’unda okuduklarınız ile İstanbul’daki bir sigorta şirketinin gündelik hali arasında baya bir mesafe var (yanlış duymadınız)
Sahada gördüğüm tablo şu: büyük ölçekli kurumlarda Teams ajanı denemeleri genelde iki yerden başlıyor, biri IT servis masası tarafı, diğeri de bilgi arama tarafı. İlkinde iş daha net, ikincisinde işe işler biraz kayıyor.
- IT servis masası ajanı: “Şifremi unuttum”, “VPN bağlanmıyor”, “Yeni yazılım talebi” gibi klasik ITSM işlemlerini Teams içinde halleden ajanlar. ROI’si kolay ölçüldüğü için CIO onayı almak daha rahat oluyor.
- Bilgi (knowledge) ajanı: Şirket içi politika, prosedür, İK belgesi, satış kataloğu gibi doküman havuzunu RAG mimarisiyle sorgulayan ajanlar.
Bak şimdi, Neyse, lafı gevelemeden söyleyeyim: Türkiye’de en büyük engel teknik taraftan çok veri sınıflandırma ve KVKK konusu. “Ajan hangi belgeye erişebilir, hangisine erişemez?” sorusunun cevabı çoğu kurumda tam oturmamış durumda; hatta bazen kimse net konuşmak istemiyor. Bu netleşmeden ajan production’a çıkarsa, bir ay sonra “İK’nın gizli maaş dokümanı ajan cevabına düştü” gibi bir olay patlıyor. Gerçekten oluyor. Sıkça.
Küçük ekip vs enterprise: hangi yol size uygun?
Bunu yaşayan biri olarak söyleyeyim, Bu ayrımı net yapmak gerekiyor ama işin içinde biraz gri alan da var. Küçük ekiplerde hız öne çıkıyor, enterprise tarafında işe governance ve denetim baskın geliyor; yanı aynı problem iki farklı dünyada bambaşka davranıyor.
| Kriter | Küçük ekip / Startup | Enterprise |
|---|---|---|
| Başlangıç noktası | Teams Toolkit + VS Code, hazır template | Copilot Studio + custom pro-code katmanı |
| LLM seçimi | Azure OpenAI shared endpoint yeterli | Dedicated PTU veya provisioned throughput |
| Hafıza | Cosmos DB serverless | Cosmos DB + Azure AI Search hibrit |
| Dağıtım | Sideload / kişisel app | Teams Admin Center üzerinden org-wide policy |
| Öncelik | Hız, MVP, kullanıcı feedback’i | Governance, audit, KVKK/GDPR uyumu |
Küçük ekipseniz benim tavsiyem net: Copilot Studio ile başlayın. Low-code arayüz sizi ilk günden production’a yaklaştırıyor; sonra ihtiyaç büyüyünce kod tarafına geçersiniz. Kod yazma ihtiyacı doğduğunda Teams AI Library devreye girer. Enterprise tarafındaysanız — özellikle 5000+ kullanıcılı bir yapıdaysanız — doğrudan pro-code yolunu tutun derim (Teams AI Library + Azure Functions ya da Azure Container Apps). Çünkü bir noktadan sonra custom auth lazım oluyor, logging ayrı dert açıyor, rate limiting başka yerden vuruyor; low-code katmanı da sizi sıkıştırmaya başlıyor.
Durun, bir saniye.
Evet.
Peki, peki neden? Çünkü ilk gün kolay görünen şeyler, üçüncü ayda operasyon yüküne dönüşebiliyor.
Açık konuşayım; doğru başlangıç modeli seçilmezse ekip sonradan mimariyi yamaya çalışıyor ve bu hiç hoş olmuyor.
Basit bir başlangıç: minimal Teams ajanı
Konuyu havada bırakmayalım. Teams AI Library ile bir ajanın ana iskeleti aşağı yukarı şöyle dürüyor (TypeScript, biraz sadeleştirilmiş hâliyle):
import { Application, TurnState } from "@microsoft/teams-ai";
import { OpenAIModel, PromptManager, ActionPlanner } from "@microsoft/teams-ai";
const model = new OpenAIModel({
azureApiKey: process.env.AZURE_OPENAI_KEY!,
azureEndpoint: process.env.AZURE_OPENAI_ENDPOINT!,
azureDefaultDeployment: "gpt-4o",
useSystemMessages: true,
});
const planner = new ActionPlanner({
model,
prompts: new PromptManager({ promptsFolder: "./prompts" }),
defaultPrompt: "chat",
});
const app = new Application<TurnState>({
storage,
ai: { planner },
});
// Basit bir action: onay isteme
app.ai.action("requestApproval", async (context, state, params) => {
await context.sendActivity(`Onay isteği gönderildi: ${params.title}`);
return "onay akışı başlatıldı";
});
export default app;İşte mesele burada. Bu yapı ilk bakışta küçük görünüyor, ama aslında işi baya toparlıyor; çünkü model seçimi, prompt yönetimi ve aksiyon akışı tek yerde toplanıyor, sız de her şeyi elle örmeye çalışıp boğulmuyorsunuz (en azından benim deneyimim böyle)
Tabi bir de şu var: bu sadece çıplak iskelet. Gerçek hayatta bunun yanına telemetri koyarsınız, hata yakalama eklersiniz, tool tanımlarını netleştirirsiniz, MCP entegrasyonunu da iliştirirsiniz (yoksa iş yarım kalıyor gibi oluyor), ama yine de başlangıç noktası fena değil.
Az önce “küçük” dedim ama aslında küçük falan değil. Çünkü sıfırdan chatbot yazma derdini ciddi biçimde azaltıyor; framework zaten birçok ayrıntıyı üstleniyor ve size daha çok davranış tasarlama tarafı kalıyor.
Bir şey dikkatimi çekti: Evet.
Maliyet tarafı: TL bazında ne bekleyelim?
Size bir şey söyleyeyim, Bu kısmı çoğu yazıda geçiştiriyorlar, ama işin aslı karar masasında ilk soru buradan geliyor. Kaba bir hesap yapayım, çünkü rakamı görmeden kimse rahat etmiyor.
Araya gireyim: Diyelim 500 kişilik bir organizasyonda IT servis masası ajanı çalıştırıyorsunuz. Kullanıcı başına günde ortalama 3 etkileşim var, her etkileşim de yaklaşık 2000 input. 500 output token yiyor; GPT-4o-mini seviyesinde bir model işinizi görüyorsa aylık token maliyeti açık konuşayım şaşırtıcı derecede düşük kalıyor, birkaç yüz dolar bandında dolaşıyor. Ama GPT-4o’ya çıkarsanız tablo değişiyor, orada kabaca 10-15 katını konuşuyoruz;. Model seçimi küçük detay değil, direkt fatura kalemi.
Gel gelelim, çoğu senaryoda asıl para LLM’e gitmiyor. Cosmos DB (hafıza), Azure AI Search (RAG index), App Service veya Container Apps (host), Application Insights (telemetri) derken toplam maliyet bazen model ücretini geçip önüne bile geçebiliyor; hani insan önce “LLM pahalı” diyor. Sonra altyapı faturası tokadı atıyor. Kurumsal bir Teams ajanının aylık altyapı maliyetini 800-2500 USD bandında tutmak bence makul bir hedef, tabi bu tamamen kullanım profiline, sorgu yoğunluğuna. Sakladığınız veri miktarına bağlı.
Ve işler burada ilginçleşiyor.
Bütçeniz sıkışıksa şunu deneyin: GPT-4o-mini + Azure AI Search Basic tier + Cosmos DB serverless + Azure Functions Consumption plan. Bu kombinasyonla 100-500 kullanıcılı bir PoC’yi aylık 300-500 USD altında çıkarabilirsiniz; sonra kullanıcıdan feedback alırsınız, işe yarıyorsa da yavaş yavaş ölçeklendirirsiniz. Evet, bu kadar basit.
Nereden başlamalı? Somut ilk adımlar
Teams ajanı geliştirmek isteyen bir ekipseniz, ben olsam işi şöyle açardım: önce tek bir senaryo seçerim, sonra da önü didik didik ederim; çünkü “her şeyi yapan ajan” fikri kulağa havalı geliyor ama pratikte çoğu zaman dağılıp gidiyor.
- Kullanım senaryosunu daralt. “Her şeyi yapan ajan” yazmayın. Tek bir iş — onay, arama, statü — üzerine yoğunlaşın. Yoksa iş çorba oluyor. (bence en önemlisi)
- Teams Toolkit’i VS Code’a kurun. Hazır template’lerden biriyle 10 dakikada “hello world” seviyesinde bir ajan ayağa kaldırın. Hani bazen küçük başlamak daha iyi olur ya, tam öyle. — ciddi fark yaratıyor
- Azure OpenAI kaynağı açın. Kotanız yoksa Azure AI Foundry Kota Başvurusu Otomasyonu: Ücretsiz Web Aracıyla Hızlı Çözüm yazımdaki aracı kullanabilirsiniz. Şey, burada kritik nokta şu: önce erişimi çözün, model kısmı sonra da gelir. — ciddi fark yaratıyor
- MCP sunucusu hazırlayın. Ajanınızın erişeceği tool’ları MCP protokolü üzerinden tanımlamak, ileride ajanlar arası iş birliği için sizi hazırlıklı tutar. Azure Functions’ta MCP Apps: TypeScript ile Hızlı Başlangıç yazımda bu tarafın detayı var. Bak şimdi, ilk bakışta ekstra yük gibi dürüyor ama sonra elinizi baya rahatlatıyor. — ciddi fark yaratıyor
- 10 kişilik pilot grup seçin. Sideload edin, iki hafta gerçek kullanım verisi toplayın. Ardından iterasyon. Evet, bu kadar basit değil; ama basit görünen işler genelde en çok öğretenler oluyor.
- Orchestration ihtiyacı çıkarsa tek ajanı büyütmek yerine çoklu ajan mimarisine geçin. Bu konuda Agent Framework Orchestration 1.0: Çoklu Ajan Koordinasyonu Yetişkin yazıma bakabilirsiniz. Açık konuşayım, her sorun orchestration istemiyor; bazen tek ajanın sınırını kabul etmek daha doğru oluyor. (bence en önemlisi)
Neyse, çok uzatmayayım; ilk hedefiniz çalışan bir şey görmek olsun. Sonra ince ayar yaparsınız. Peki neden? Çünkü Teams tarafında asıl mesele modelden çok akış tasarımı ve kullanıcı alışkanlığıdır.
Bunu biraz açayım.
Eksik olan ne? Dürüst bir değerlendirme
Her şey tozpembe değil, önü baştan söyleyeyim. Teams tarafında ajan deneyimi hâlâ yer yer takılıyor; adaptive card’lar mobilde bazen yamuluyor, streaming response’lar client içinde beklediğiniz kadar pürüzsüz akmıyor, bir de production’da debug ederken insanın eli kolu biraz bağlanıyor.
İşin garibi şu: Microsoft ekosistemi hızlı gidiyor, buna laf yok. Ama hızın bir faturası da oluyor; altı ay önce yazdığınız Bot Framework kodu bir bakıyorsunuz deprecated olmuş,. Bugün “tamamdır” dediğiniz şey yarın küçük bir sürpriz çıkarabiliyor. O yüzden ben ajan mimarisini framework’e çivilemek yerine iş mantığını dışarıda tutmayı, framework’ü de ince bir adaptör gibi kullanmayı daha doğru buluyorum.
Bunu biraz açayım.
Neyse, çok dağıtmadan devam edeyim. Bugün Teams için ajan geliştirmek adına fena olmayan bir noktadayız; standartlar oturmuş durumda, model kalitesi iş görüyor, maliyetler de artık uçuk kaçık değil. Hatta dürüst olayım, şu anda bir ajan yazıp bunu 1000 kişinin günlük akışına sokmak gayet mümkün görünüyor — üç yıl önce böyle bir cümle kursaydınız size biraz fazla iyimser derlerdi.
Sıkça Sorulan Sorular
Teams ajanı geliştirmek için Copilot Studio mu, Teams AI Library mi?
Aslında bu karar ekibinizin teknik profiline ve ihtiyacın ne kadar karmaşık olduğuna göre şekilleniyor. Hani iş kullanıcıları veya küçük ekipler söz konusuysa Copilot Studio çok daha hızlı bir başlangıç sağlıyor. Ama custom auth, karmaşık — itiraz edebilirsiniz tabi — orchestration ya da harici sistem entegrasyonu gerekiyorsa o zaman Teams AI Library (pro-code) çok daha uygun. Bence çoğu kurumsal senaryoda en dengeli çözüm hibrit yaklaşım — yanı Copilot Studio üzerinde pro-code plugin.
Model Context Protocol (MCP) Teams ajanları için gerçekten şart mı?
Bugün için zorunlu değil. Ama açıkçası yakın gelecekte fiili standart olacağı çok belli. Ajanınızın tool’larını MCP üzerinden tanımlamak, mesela ileride başka ajanlarla iş birliği yapmasını ve farklı platformlarda tekrar kullanılmasını epey kolaylaştırıyor. Yeni bir projede baştan MCP ile gitmek, sonradan her şeyi refactor etmekten çok daha az maliyetli — tecrübeme göre bu farkı küçümsememelisiniz.
Teams ajanım şirket verilerine erişecek, KVKK açısından nelere dikkat etmeliyim?
Aslında üç ana konu var. Birincisi veri ikametgahı (data residency) — Azure OpenAI kaynağınızı doğru bölgede, mümkünse EU’da açın. İkincisi izin yönetimi — hani on-behalf-of akışıyla ajan sadece kullanıcının yetkili olduğu veriye ulaşsın. Üçüncüsü denetlenebilirlik — her ajan etkileşimini Application Insights veya Purview’da loglayın. Bu üçünü halledebilirseniz, bence KVKK denetimlerinde ciddi bir sıkıntı yaşamazsınız.
Ajanımın hafızasını nasıl yönetmeliyim, her mesajda tüm geçmişi mi göndereyim?
Hayır, o yol hem pahalı hem de context window’u çok hızlı dolduruyor. En sağlıklısı katmanlı hafıza: son 5-10 mesaj için short-term (session storage), kullanıcı tercihleri ve önemli olaylar için long-term (Cosmos DB veya vektör store). Gerektiğinde de retrieval ile ilgili geçmişi geri çekiyorsunuz. Yanı sistem hem hafif kalıyor hem de önemli bir şeyi unutmuyor. Bu yaklaşımın detaylı bir örneğini blog’daki Eve + Cosmos DB yazısında bulabilirsiniz.
Ajan kullanıcıya yanlış veya uydurma cevap verirse ne yapmalıyım?
Tuhaf ama, Bu her LLM tabanlı sistemin gerçeği. Tamamen ortadan kaldıramazsınız ama açıkçası ciddi biçimde azaltmak mümkün. RAG (retrieval augmented generation) ile cevapları belgelere sabitleyin, prompt’ta “bilmiyorum diyebilirsin” iznini mutlaka verin. Kritik aksiyonlarda — mesela onay, ödeme, silme — kullanıcı konfirmasyonu isteyin. Bir de düzenli olarak “red teaming” yapın, yanı ajanı bilinçli olarak yanıltmaya çalışan test senaryoları hazırlayın. Bence bu son adım çoğu ekibin atladığı ama en önemli adım.
Kaynaklar ve İleri Okuma
Building Agents for Teams: Turning conversations into outcomes (Microsoft 365 Dev Blog)
Teams AI Library — Resmî Dokümantasyon
Model Context Protocol — Resmî Spesifikasyon
Microsoft 365 Copilot Extensibility Overview
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