Foundry’de Agent Dağıtımı: Teams ve M365 Copilot Devri

Geçen sene agent kurma yılıydı. Bu sene işe agent çalıştırma yılı olacak gıbı duruyor, hatta açık konuşayım, öyle olmak zorunda. Çünkü son 12 ayda pilotta kalıp üretime çıkamayan yüzlerce agent projesi gördüm. Sebep de çoğu zaman aynıydı: agent’ı yapıyorsun, demoda fena değil, ama “bunu kullanıcının önüne nasıl koyacağız?” sorusunda bir anda duvara tosluyorsun.

Bu hafta Microsoft Foundry tarafında duyurulan üç şey, işte tam o tıkanıklığa biraz nefes aldıracak gıbı görünüyor. Hemen söyleyeyim, şüpheciyim — ama umutluyum da. Detayına girelim.

Önce kısa özet: Ne duyuruldu?

Bir şey dikkatimi çekti: Üç başlık var (buna dikkat edin). Birbirini tamamlıyorlar, yanı ayrı ayrı bakınca eksik kalıyorlar:

• Microsoft 365 Copilot ve Teams’e doğrudan publish — gelecek ay genel kullanıma açılıyor (GA)
• Autopilot agents — kamuya açık önizlemede. Kendi kullanıcı hesabı, kendi maili, kendi takvimi olan agent’lar. Yanı organizasyon şemasında “yer” alıyorlar.
• Agent-to-Agent (A2A) — yine önizlemede. Agent’ların birbiriyle konuşması için ortak protokol.

Size bir şey söyleyeyim, Üçü bir arada düşünülünce Microsoft’un aslında bir “agent dağıtım kanalı” kurmaya çalıştığı netleşiyor. Daha önce yazdığım A2A v1 Geldi: Agent’lar Artık Aynı Dili Konuşuyor yazısında da bu protokolün niye önemli olduğunu anlatmıştım; şimdi parçalar yavaş yavaş yerine oturuyor, şaşırdım açıkçası.

Publish to Microsoft 365 Copilot ve Teams: “Son mil” sorunu

Şimdiye kadar en çok duyduğum şikayetlerden biri buydu: Foundry’de güzel bir agent kuruyorsun, ama kullanıcıya ulaştırmak için ya ayrı bir web app yazıyorsun ya da Teams için bot framework ile yeniden uğraşıyorsun (bizzat test ettim). İki kod tabanı. İki deployment. İki ayrı baş ağrısı. Hani insanın canı sıkılıyor.

Yeni model bunu toparlıyor gıbı duruyor. Foundry’deki bir agent’ı birkaç tıkla — kendi adıma konuşayım — hem M365 Copilot içine hem Teams kanallarına publish edebiliyorsun. Yetenekler aynı kalıyor — kullandığın tool’lar, memory, knowledge base — ne varsa taşınıyor (şaşırtıcı ama gerçek). Üstelik yönetişim katmanı da tek yerden gidiyor; kim publish edebilir, hangı grup kullanabilir, hangı veriye erişebilir gıbı şeyleri ayrı ayrı kovalamıyorsun.

Açık konuşayım: Bu fikrin kendisi yeni değil. Power Platform tarafında Copilot Studio ile benzer işleri zaten yapıyorduk. Ama orada agent’ların kapsamı daha dar kalıyordu. Foundry tarafında inşa ettiğin ciddi, çok-tool’lu, memory’li agent’ları doğrudan iş akışının içine sokmak — işte asıl fark burada. Siz ne dersiniz? Baya iş görüyor.

Etkileşim modeli değişiyor: Sohbet değil, delegasyon

Burası kafamı en çok kurcalayan yerlerden biri öldü, ama bir yandan da heyecan verici. Klasik AI deneyimi şöyle çalışır:

Prompt → Yanıt.

Bitti gıbı görünür.

Foundry agent’ları M365 ve Teams içinde başka bir model öneriyor:

Hedef → Süregelen yürütme → Kontrol noktaları → İş birliği.

Yanı agent’a soru sormuyorsun aslında. Ona hedef veriyorsun. “Şu müşteri hesabını takıp et, sözleşme yenileme tarihî yaklaşınca beni uyar, gerekli dokümanları hazırla.” Sonra agent kendi başına çalışmaya devam ediyor, ilerleme bildiriyor, onay istiyor, gerekirse insana eskale ediyor. Hepsi Teams chat’i içinde oluyor; doğal geliyor ama arkada epey sistem var. Bu konuyla ilgili Foundry Agent Memory: Procedural Bellek ile Üretime Hazır yazımıza da göz atmanızı tavsiye ederim.

Bu modelin enterprise danışmanlığı yapan bizler için anlamı şu: Müşterilere “AI’ı nasıl pratik kullanabiliriz?” diye anlattığımda artık daha somut örnekler verebileceğim (buna dikkat edin). Çünkü kullanıcıya yeni bir araç öğretmek gerekmiyor; zaten Teams’i biliyorlar. E sonra? İşin yarısı çözülmüş oluyor.

Autopilot Agents: Kendi e-postası olan agent

Açıkçası, Bu kısım ilk duyduğumda biraz garip geldi doğrusu. Agent’a productivity license veriyorsun, kendi e-postası oluyor, kendi takvimi oluyor, org şemasında yer alıyor; yanı neredeyse işe yeni başlamış biri gıbı davranıyor. agent ile ilgili önceki yazımız yazımızda bu konuya da değinmiştik. Bu konuyla ilgili PostgreSQL’in Geleceği: Microsoft’tan Commit’ten Bulut’a yazımıza da göz atmanızı tavsiye ederim.

Araya gireyim: Ama biraz deşince mantıklı geliyor. Çünkü kurumsal işlerin çoğu tek kişilik değil ki. Bir kampanya başlatmak, bir feature ship etmek ya da müşteri hesabını yönetmek; bunların hepsi grup chat’leri, toplantılar. Dokümanlar üzerinden dönüyor (biraz yorucu ama gerçek bu). Eğer agent bu ekosisteme katılamıyorsa, orada sadece kişisel asistan seviyesinde takılı kalıyor demektir.

Autopilot agent’ların gerçek değeri “kişisel asistan” olmaları değil, “ekibin üyesi” olabilmeleri. Teams grup chat’ine eklediğin, toplantıya çağırdığın, görev verdiğin bir varlık gıbı düşününce taşlar yerine oturuyor. Kağıt üstünde güzel duruyor; pratikte nasıl olacak bakalım.

Geçen hafta bir bankada yaşadığımız sahne

Logosoft’ta danışmanlık verdiğim bir bankada operasyon ekibi şöyle bir şey istedi: Her gece Service Bus üzerinden gelen istisna işlemleri inceleyen, raporlayan. Sabah ekibe brifing veren bir yapı olsun istediler. Şu an bunu Logic Apps + Azure Functions + üst üste binmiş tetikleyicilerle kuruyoruz; karmaşık mı? Evet. Çalışıyor mu? Çalışıyor.

Autopilot agent modeli bu senaryo için baya uygun duruyor. Agent’a “operasyon analisti” rolü veriyorsun; kendi takvimi olsun diyorsun; sabah 08:30’da brifing toplantısı planlayıp Teams kanalına raporu düşsün diyorsun. Şu an bunun yarısı bile net olmayabilir ama yön doğru gıbı geliyor bana. Yalnız kilit soru şu: permission ve identity tarafı ne kadar olgun? Banka için esas mesele orası.

Kimlik ve güvenlik tarafı: Acaba?

İşte burada AZ-500 çalışırken beynime kazınan refleks devreye giriyor biraz da hâliyle. Agent’a kullanıcı hesabı veriyorsan, yaptığı her şey o kullanıcının yetkisiyle yapılıyor demek oluyor mu? Conditional Access politikaları nasıl işleyecek? MFA gereken senaryoda agent ne yapacak? Audit log’larda bu eylemler net biçimde “non-human” diye işaretlenecek mi?

Peki neden? Bu konuyla ilgili Cosmos Conf 2026: AI Çağında Veritabanı Nereye Gidiyor? yazımıza da göz atmanızı tavsiye ederim.

Bunların cevabı henüz tam oturmuş değil gıbı görünüyor. Microsoft Entra tarafında workload identity için zaten yapılan işler var ama agent’lar bunun üst katmanı sayılır bence. Önümüzdeki birkaç ayda GA sürecinde bu konuların daha netleşmesi lazım yoksa iş karışır. Cosmos DB tarafında da benzer kimlik tartışmaları yaşamıştık; hatta Cosmos DB Güvenliği: Yeni Projede İlk Gün Kararları yazısında bunu epey açmıştım.

Agent-to-Agent (A2A): Asıl işleri değiştiren bu

Üç duyuru arasında en az konuşulan şey olabilir ama bence en kilit olan bu. A2A protokolü farklı satıcıların. Farklı framework’lerin agent’larının birbirleriyle konuşmasını sağlıyor; yanı Foundry’de yaptığım bir agent başka sistemde çalışan başka bir agent’a görev paslayabiliyor. Daha fazla bilgi için azure-functions-skills: AI Çağı için Functions Workspace’i yazımıza bakabilirsiniz.

Doğrusu, Neden önemli? Çünkü hiçbir kurum tek bir AI platformuna kilitlenmek istemiyor, olay bu kadar basit aslında. Pazarlama ekibi Salesforce’un Agentforce’unu kullanıyor olabilir; finans Workday’in agent’larıyla çalışıyor olabilir; IT işe Foundry’de kendi şeylerini kuruyordur (evet biraz dağınık ama gerçek hayat böyle). Eğer bunlar konuşamıyorsa herkes kendi adasında kalıyor.

Ve işler burada ilginçleşiyor.

Pratik bir akış örneği

// Sözde-kod: A2A akışı
SalesAgent (Foundry)
├─> hedef tanımla: "ABC firmasına teklif hazırla"
├─> PricingAgent'a sor (A2A çağrısı)
│ └─> fiyatlandırma kuralları döndür
├─> LegalAgent'a sor (A2A çağrısı)
│ └─> sözleşme şablonu döndür
├─> İnsana eskale et: "Onayınıza sunuldu"
└─> Teams kanalına özet düş

Bu akışın güzel yanı şu: Her agent kendi uzmanlık alanında kalabiliyor (yanı her şeyi tek kafaya yığmıyorsun). Tek bir “süper agent” yaratmaya uğraşmıyorsun; onun yerine küçük küçük uzmanlaşmış ve birbirleriyle konuşabilen parçalar kullanıyorsun.

Türkiye perspektifi: Hangı şirket nasıl kullanmalı?

İşte, bir şey dikkatimi çekti: Peki Türkiye’de şirketler bunu nasıl değerlendirmeli? Tek cevap yok tabii; ölçeğe göre değişiyor biraz da işin doğrusu.

Şirket Tipi	Öncelik	Ílχi adım
Startup (10-50 kişi)	Publish to Teams	Tek bir agent yapın, Teams’e koyun, ölçün
Orta ölçek (50-500)	Autopilot + Publish	1-2 departmana özel agent, kontrollü pilot
Kurumsal (500+)	Governance + A2A	Önce policy framework, sonra agent’lar

Sıkça Sorulan Sorular

Foundry agent’ı Teams’e publish etmek için ekstra lisans lazım mı?

Aslında publish işlemi için Foundry geliştirici lisansın yeterli. Ama agent’ı kullanacak son kullanıcıların Teams lisansı olması gerekiyor — yanı M365 E3/E5 ya da benzeri bir şey. Bir de M365 Copilot’a publish ediyorsan, kullanıcının ayrıca Copilot lisansı da olmalı.

Autopilot agent ile normal agent arasında ne fark var?

Normal agent kullanıcı tetikleyince çalışıyor ve kullanıcının kimliğini kullanıyor. Autopilot agent işe bambaşka bir şey — hani ekibe yeni biri katılmış gıbı düşün. Kendi kimliği, e-postası, takvimi, OneDrive’ı var. Otonom çalışıyor, grup chat’lerine de eklenebiliyor. Bence bu fark, hangı senaryoya uygun olduğunu belirleyen en kritik nokta.

İşte tam da bu noktada devreye giriyor.

A2A protokolü sadece Microsoft’a mı özel?

Hayır, açık bir protokol olarak tasarlanmış. Microsoft dışında mesela Google da dahil birkaç büyük oyuncu destekliyor. Yanı uzun vadede farklı satıcılar arası interop için gerçek bir zemin oluşturuyor. Açıkçası şu an hâlâ erken aşamada, ama yönelim umut verici.

Copilot Studio agent’larımı Foundry’ye nasıl taşıyabilirim?

Microsoft iki platform arasında köprü mekanizmaları sunuyor (bizzat test ettim). Basit agent’lar için doğrudan import işe yarıyor. Ama tool entegrasyonları olan karmaşık agent’larda manuel yeniden yapılandırma gerekebilir — tecrübeme göre bu kısmı hafife almamak lazım. Foundry’nın sunduğu yetenekler zaten çok daha geniş, o yüzden taşıma zahmetine değiyor.

Agent’ların yaptıkları audit log’a düşüyor mu?

Evet, her şey loglanıyor. Microsoft Purview ve Entra üzerinden — en azından ben öyle düşünüyorum — tüm agent eylemleri takıp edilebiliyor. Autopilot agent’lar için ayrıca “non-human identity” etiketi var — bu sayede compliance ekibi insan mı yaptı, agent mı diye kolayca ayırt edebiliyor. Finans veya sağlık sektöründeysen bu özellik gerçekten kritik.

Durun, bir saniye.

Kaynaklar ve İleri Okuma

Microsoft Foundry Blog: Enterprise Agent Distribution

Yanı, Azure AI Foundry Resmî Dokümantasyonu

Şunu fark ettim: Microsoft 365 Copilot Extensibility Docs (ciddiyim)