Teams SDK Python Desteği GA: Pythoncular İçin Yeni Kapı

Şöyle söyleyeyim, Açık konuşayım: Microsoft’un Teams tarafında uzun zamandır.NET. TypeScript biraz daha önde gidiyor gıbı hissediyordum. Python ekibi işe çoğu zaman ikinci plana itiliyordu; Bot Framework’ün eski SDK’sını hatırlayanlar vardır, biraz tozlu, biraz dağınık bir deneyimdi, hatta insanın “buna şimdi mi uğraşacağım?” dediği anlar bile ölüyordu. Neyse, geçtik önü.

Bu hafta gelen duyuruyla birlikte Microsoft Teams SDK‘nın Python desteği artık resmî olarak GA öldü — yanı Generally Available. Bu da “bir bakın bakalım” seviyesinden çıkıp “production’a koyabilirsiniz” çizgisine geldiği anlamına geliyor. Küçük bir detay gıbı duruyor ama değil; böyle şeyler bazen ekibin önünü açıyor, bazen de beklenmedik biçimde işleri sadeleştiriyor. Evet.

Ben de bu hafta sonu birkaç saat ayırıp microsoft-teams-apps paketini kurcaladım. Şimdi yazacaklarım hem duyurudan çıkardıklarım hem de kendi denemelerimden notlar olacak; yanı düz metin değil, biraz da “şurada ne oluyor?” diye baktığım yerlerin karışımı. Lafı uzatmadan gireyim konuya,. Şunu da söyleyeyim: ilk bakışta beklediğimden az uğraştırdı, bu da açıkçası şaşırttı beni.

Neden Python? Neden şimdi?

Soru basit görünüyor, ama cevabı biraz dallı budaklı. Bugün AI. Agent dünyasının tam ortasında Python var, bunu yok saymak zor; LangChain, LlamaIndex, Semantic Kernel’in Python tarafı, Hugging Face, OpenAI SDK… İşin reasoning ve orchestration kısmına bakınca, nereye dönseniz bir şekilde Python’a çarpıyorsunuz (bu beni çok şaşırttı)

Bak şimdi, şirket içinde çalışan bir LangChain agent’ınız olduğunu düşünün. Vektör veritabanına bağlı, RAG — kendi adıma konuşayım — yapıyor, domain bilgisini de fena olmayan bir şekilde sindirmiş. Peki bunu kullanıcıya nasıl vereceksiniz? Çoğu yerde gördüğüm şey şu: bir Streamlit arayüzü, bir Slack botu ya da biraz daha can sıkıcı olanı, “şuradaki internal portala gir” cümlesi. Evet, işte o an iş uzuyor.

Durun, bir saniye.

Halbuki Türkiye’deki büyük kurumların neredeyse tamamı Microsoft 365 üzerinde dönüyor. Banka var, holding var, kamu var; çalışan zaten gün boyu Teams’in içinde takılıyor. Agent’ı oraya taşımak varken ayrı uygulama yükletmek pek mantıklı gelmiyor açıkçası (buna dikkat edin). Siz ne dersiniz? Python desteği de bu köprüyü baya doğal hâle getiriyor (bizzat test ettim)

Bence asıl mesele şu: Python ekibinin artık.NET ve TypeScript geliştiricilerle aynı SDK yüzeyini paylaşabiliyor olması. Yanı feature parity diyelim buna. Bu da Microsoft’un Python’u sadece kenardan desteklemediğini, ciddi şekilde masaya koyduğunu gösteren ilk somut adım gıbı duruyor.

İlk Bakışta SDK: Ne Geliyor?

Kurulum tarafı baya düz. Terminale şunu yazıyorsunuz:

pip install microsoft-teams-apps

Sonrası da fazla uzamıyor. Bir App nesnesi oluşturuyorsunuz, sonra decorator’larla event handler’ları bağlıyorsunuz; Flask ya da FastAPI kullanmış biriyseniz, gözünüz hiç yabancılık çekmiyor (hatta biraz rahatlıyorsunuz), çünkü ortada gereksiz bir katman, uzatılmış bir kurgu, ezberletilmiş bir akış yok.

from microsoft_teams.apps import App, ActivityContext
from microsoft_teams.api import MessageActivity
app = App()
@app.on_message
async def handle_message(ctx: ActivityContext[MessageActivity]):
# Burada LangChain chain'inizi, OpenAI çağrınızı, ne varsa çağırın
user_text = ctx.activity.text
response = await your_agent.invoke(user_text)
await ctx.send(response)
await app.start()

Bu kadar. Cidden. Eski Bot Framework ile boğuşmuş biri için bu sadelik biraz şaşırtıcı geliyor; çünkü önceden ActivityHandler sınıfını extend et, turn_context parametrelerini doğru sıraya köy, dispatcher yaz derken iş uzayıp gidiyordu, şimdi işe akış daha net ve daha az yorucu görünüyor — dürüst olayım, biraz hayal kırıklığı —

Evet, doğru duydunuz.

Evet.

Kutudan Çıkan Özellikler

SDK’da bana en çok “iş görüyor” dedirten şeyler bunlar öldü. Bazıları ilk bakışta sıradan duruyor,. Detayına girince elinizi baya rahatlatıyor; özellikle bot tarafında her şeyi tek tek elle bağlamaya alıştıysanız, farkı hemen hissediyorsunuz.

• Decorator-based routing: Flask’ta @app.route ne işe yarıyorsa burada @app.on_message aynı mantığı taşıyor. Zaten bildiğiniz kalıp bu; o yüzden öğrenme eğrisi de dikleşmiyor.
• Built-in OAuth: Token plumbing işi — yanı access token alma, refresh etme, cache’leme — SDK’nın içinde hallediliyor. Açık konuşayım, eskiden bu parçanın kendisi bile günün yarısını yutabiliyordu.
• Type-safe Microsoft Graph: user_graph ve app_graph property’leriyle delegated/application çağrılarını ayırıyorsunuz. Type hint desteği de var; IDE size yol gösteriyor ama bazen ufak bir hata yapınca hemen yakalıyor. (bu kritik)
• Plugin mimarisi: Middleware, telemetri, custom davranışlar… Bunları core’a dokunmadan ekleyebiliyorsunuz. Güzel tarafı şu: ana yapıyı dağıtmadan yan özellikleri takıp çıkarabiliyorsunuz.
• Streaming: LLM cevaplarını token token akıtmak mümkün. Bence agent UX tarafında kritik nokta bu; kullanıcı beklerken boş boş bakmıyor.
• Proactive messaging: Kullanıcı mesaj atmadan da siz ona mesaj gönderebiliyorsunuz. Bildirim botu yapacaksanız zaten başka türlü pek yürümüyor.

Neyse, çok dağıtmadan söyleyeyim: SDK’nın olayı “her şeyi sihir gıbı çözmek” değil, daha çok sık kullanılan işleri sadeleştirip sızı o eski tökezleyen adımlardan kurtarmak. Tam da öyle.

Stack’leri Karşılaştıralım: Python mu,.NET mi, TypeScript mi?

Şimdi gelin, lafı gevelemeden somut bir tabloya bakalım. Müşterilere danışmanlık verirken en sık duyduğum soru bu oluyor: “Hangı dilde gidelim?” Evet, mesele çoğu zaman tam da buraya geliyor.

Not:

Kriter	Python	TypeScript	.NET
AI/Agent ekosistemi	En zengin	Orta (LangChain.js var)	Semantic Kernel güçlü
Kurumsal entegrasyon	İdare eder	İyi	En iyi (özellikle TR’de)
Geliştirme hızı	Çok hızlı	Hızlı	Orta
Performans (yoğun yük)	Orta

“?

Türkiye Perspektifinden: Kim Bunu Nasıl Kullanmalı?

Türkiye tarafına bakınca tablo biraz netleşiyor, hatta fazla netleşiyor. Büyük kurumların çoğu hâlâ.NET çizgisinde gidiyor; bankacılıkta, sigortada, telekomda backend deyince akla ilk C# geliyor. Bu yüzden Teams agent yazılacaksa, doğal tercih çoğu zaman yine.NET oluyor, çünkü DevOps pipeline’ları da orada, security review akışı da orada, internal NuGet feed’leri de zaten yıllardır aynı zeminde dönüyor.

Ama bir dakika, iş burada bitmiyor. Son 2-3 yılda ben şunu baya fark ettim: veri ve AI ekipleri sessiz sedasız Python’a kayıyor. Hatta bazı bankalarda artık ayrı “AI Engineering” ekipleri kurulmuş durumda, bunların neredeyse tamamı Python yazıyor; işte bu noktada Python desteği ciddi rahatlık sağlıyor (çünkü data science ekibi agent’ı doğrudan Teams’e taşıyabiliyor, araya.NET ekibinden wrapper API yazdırma derdi girmiyor).

Aslında, Startup tarafında işe durum daha da farklı. Orada Python zaten baskın; birkaç ay önce Logosoft’ta İstanbul’daki bir fintech ile konuşuyorduk, kendi RAG yapılarını LangChain üstünde kurmuşlar ve vector store olarak Cosmos DB kullanıyorlardı. Soruyorum: “Bunu kullanıcıya nasıl sunacaksınız?” Cevap geliyor: “Bir React frontend yazacağız.” E sonra? Şirket zaten Microsoft 365 müşterisiysa, şimdi bu Python GA ile o frontend adımı baya gereksiz hâle gelebilir.

Pratik Senaryo: HR Agent

Mesela klasik bir örnek düşünün. İK departmanı için bir agent yazıyorsunuz; kullanıcı “izin bakiyem ne kadar?” diye soruyor ve agent SAP SuccessFactors’a bağlanıp cevap dönüyor. Eskiden akış şöyleydi:

1. Python’da SAP entegrasyonu yaz
2. FastAPI ile bir REST endpoint açar
3. .NET veya TypeScript ile Teams bot yaz
4. Bot’tan FastAPI’ye HTTP çağrısı yap
5. İki ayrı projeyi iki ayrı pipeline’da deploy et

Açık konuşayım, Şimdi işe tek proje yeterli oluyor. Hem entegrasyon hem bot aynı yerde duruyor; (belki yanılıyorum ama) bakım işi de hafifliyor, açık konuşayım yarıya yakın düşüyor gıbı hissediyorum. Tabii %100 doğru olmayabilir ama pratikte insanın omzundan ciddi yük alıyor.

Neyse uzatmayalım. Bu tür senaryolarda asıl kazanç sadece kod azaltmak değil; ekipler arası sürtünmeyi de azaltmak oluyor.

Maliyet Tarafı: Azure’da Bunu Çalıştırmak Ne Tutar?

Paraya gelince iş biraz değişiyor. Bir Teams agent çalıştırmak için temel tarafta birkaç parça gerekiyor, ama hani en çok can yakan kısım genelde compute değil, başka bir yer oluyor.

• Compute: Azure App Service (Linux, Python runtime) veya Container Apps. Küçük bir agent için B1 plan ayda ~50 USD civarı, TL bazında 1700-1800 TL gıbı düşünebilirsiniz. (bence en önemlisi)
• Bot Service registration: Free tier var, küçük ölçekte yetiyor.
• LLM çağrıları: Işte asıl masraf burası. Azure OpenAI üzerinden GPT-4o-mini bile yoğun kullanımda ayda binlerce dolara çıkabilir. (bence en önemlisi)
• Storage/State: Cosmos DB veya Azure Storage — birkaç dolar.

FinOps gözünden bakınca olay netleşiyor aslında: LLM token tüketimini kontrol altında tutmak, agent’in kendisini host etmekten çok daha kritik. Ben müşterilere su şeyi söylüyorum — prompt-level caching ekleyin, sık sorulan soruları semantic cache’leyin, response uzunluğunu da kisitin; yoksa production’a ciktigimiz gün fatura sızı ters köşe yapar, sonra “bu kadar mi?” dersiniz.

İlk Denememdeki Tuzaklar

Hani, Şimdi pratik konuşalım. Kurulum dokümanını takıp ederken birkaç yerde takıldım. Ufak şeylerdi, ama insanı baya oyalıyor.

Tuzak 1: Local development için devtunnel veya ngrok şart. Çünkü Teams platformu botunuza HTTPS üzerinden çağrı atıyor, localhost direkt iş görmüyor (evet, ilk başta bunu ben de kaçırdım). İlk anda “neden mesajım gelmiyor?” diye 20 dakika kafa patlattım, sonra tunnel’ı hiç başlatmadığımı fark ettim. Klasik. Bu konuyla ilgili azd Nisan 2026: Multi-Language Hooks ve Sessiz Devrim yazımıza da göz atmanızı tavsiye ederim.

Tuzak 2: Bot Framework registration hâlâ Azure portalı üzerinden yapılıyor. Yanı SDK Python, ama setup tarafı biraz karışık gidiyor; burada Microsoft Entra app registration kısmı da ilk kez yapan biri için epey kafa yoruyor (ben de ilk duyduğumda şaşırmıştım). Daha önce Teams Agent Kurulumu: Prompt’tan Production’a Sade Yol yazımda detaylı anlatmıştım, ona da bir göz atın. Bu konuyla ilgili GPT-5.2 ve GPT-5.2-Codex Emekli Oluyor: Geçiş Notları yazımıza da göz atmanızı tavsiye ederim.

Tuzak 3: Async/await disiplini şart. Eğer agent’ınız içinde senkron bir kütüphane çağırıyorsanız (mesela bazı eski ORM’ler), event loop’u bloklayıp uygulamanın tamamını ağırlaştırabilirsiniz; açık konuşayım, bu tarz hata production’da can sıkıyor. Yayına çıkmadan önce asyncio.to_thread ya da thread pool kullanımını mutlaka düşünün. Cosmos DB Azure RBAC Entegrasyonu: İki Dünya Birleşti yazımızda bu konuya da değinmiştik.

Authentication Tarafı

İnanın, OAuth akışı SDK’da kutudan çıkıyor demiştim. Doğru, ama küçük bir not var: User (belki yanılıyorum ama) context’te Graph çağırmak istiyorsanız (yanı user_graph), kullanıcının ilk seferde consent vermesi gerekiyor. Bu consent diyaloğunu Teams içinde adaptive card olarak gösteriyorsunuz; SDK işi kolaylaştırıyor,. Yine de UX tarafını sizin kurmanız lazım. Sadece “kuruldu, çalıştı” diye bakmayın. Azure Cosmos DB Conf 2026: Notlarım, İzlenimlerim ve yazımızda bu konuya da değinmiştik.

Size bir şey söyleyeyim, Bazen insan burada gereksiz rahatlıyor. Sonra pat diye izin ekranında kalıyor. .NET’in Composable AI Stack’i: ConferencePulse Vakası yazımızda bu konuya da değinmiştik.

Bunu özellikle Entra Agent ID GA: Sponsor Grup Tipi Kısıtlaması Geldi yazımdaki kısıtlamalarla birlikte okumanızı öneririm; özellikle kurumsal tenant’larda işin rengi değişiyor, yanı aynı akış her yerde aynı rahatlıkta yürümüyor (evet, doğru duydunuz)

İlk Adımlar: Bugün Ne Yapmalisiniz?

Eğer Python ekibiyseniz ve Teams entegrasyonu kafanızı kurcalıyorsa, ben olsam işi fazla dallandırmadan şöyle giderim:

1. Bir test Microsoft 365 tenant’i açın (Developer Program üyeliği bedava, yanı alın kullanın).
2. pip install microsoft-teams-apps ile başlayın, önce “echo bot” örneğini çalıştırın.
3. Elinizdeki basit bir Python fonksiyonunuza bakın; mesela internal API cagirisi yapıyorsa, önü bu echo bot’a bağlayın.
4. Sonra asıl LLM/agent katmanını ekleyin. Streaming response’u da atlamayın, çünkü UX tarafında farkı baya hissediliyor.
5. OAuth + Graph entegrasyonunu deneyin (kullanıcının takvimine bakan sade bir senaryo, açıkçası iyi bir başlangıç oluyor).
6. Container Apps’e deploy edin, sonra gerçek tenant’ta iki üç kişiye test ettirin.

Küçük bir detay: Bunu sırayla yaparsanız, bir hafta içinde çalışan bir POC çıkarma ihtimaliniz var. Bu kadar hızlı ölür mu? Evet, ama sadece işi gereksiz yere buyutmezseniz; yoksa konu hemen şişiyor ve elde yine yarım kalmış bir demo kalıyor.

Neyse uzatmayalım. Buradaki mesele kusursuz mimarı kurmak değil, önce çalışan bir şey görmek.

Eksik Olanlar ve Beklentiler

Her şey toz pembe değil tabi. Açık konuşayım, burada birkaç eksik var; SDK fena değil ama bazı yerlerde insanın kaşı kalkıyor, hele ki ilk kez kurcalıyorsanız biraz “hmm, bu niye böyle?” dedirtiyor.

Birinçisi, dokümantasyon henüz.NET ve TypeScript kadar zengin değil. Bazı edge case’ler için GitHub repo’sundaki sample’lara bakmak zorunda kalıyorsunuz; yanı elinizde kılavuz var gıbı duruyor ama bazı sayfalarda yön tabelası eksik kalıyor, bu da yeni GA olmuş bir SDK için çok da şaşırtıcı değil aslında, yine de insan daha dolu bir anlatım bekliyor (bu beni çok şaşırttı)

İkincisi, bazı gelişmiş Teams özellikleri (örneğin meeting extensions, tab apps) henüz Python tarafında ya yok ya da deneysel. Eğer bot’tan öteye geçen bir Teams uygulaması yazıyorsanız, hâlâ TypeScript daha güvenli liman; bak şimdi, burada iş değişiyor çünkü basit senaryoda Python baya iş görüyor ama uygulama büyüyünce tablo biraz kayıyor.

Üçüncüsü — bu kişisel kanaatim — Python tarafında performans tuning konusu hâlâ zor. Yüksek yüklü senaryolarda.NET’in bir adım önde olduğu açık; uzun uzun benchmark konuşmaya gerek yok gıbı geliyor bana, (ben de ilk duyduğumda şaşırmıştım). Agent senaryolarında genellikle bottleneck LLM tarafında olduğu için bu fark çoğu zaman hissedilmiyor bile.

İşte tam da bu noktada devreye giriyor.

Şöyle söyleyeyim, Evet.

Sıkça Sorulan Sorular

Eski Bot Framework SDK ile yazdığım botları yeni SDK’ya taşımak zorunda mıyım?

Şahsen, Hayır, zorunda değilsiniz. Eski SDK hâlâ çalışıyor. Ama yeni projelerde yeni SDK’yı tercih etmenizi öneririm — yanı kod daha temiz, boilerplate çok daha az ve gelecekteki Teams özellikleri öncelikli olarak buraya geliyor. Migration için resmî rehberi bekliyorsanız da sorun değil, acelesi yok aslında.

Sadece Azure’da mı host edebilirim?

Hayır, SDK host-agnostic. Yanı container’ize edip AWS’de, GCP’de, kendi VM’inizde, hatta Kubernetes cluster’ınızda çalıştırabilirsiniz. Tek şart şu: Teams’ten gelen webhook’lara HTTPS üzerinden erişilebilir bir endpoint’ınız olsun. Ama Azure Bot Service registration kısmı Azure’a bağımlı — bunu atlayamazsınız.

Bir dakika — bununla bitmedi.

Hangı Python sürümüyle çalışıyor?

Python 3.10 ve üzeri öneriliyor. Async/await ve modern type hints kullandığı için eski sürümlerde, açıkçası, ciddi sorunlarla karşılaşabilirsiniz. Hani ne farkı var diyorsunuz, değil mi? Production’da bence 3.11 veya 3.12 gitmeniz en mantıklısı — performans farkı da var.

LangChain veya LlamaIndex ile kullanabilir mıyım?

Bir şey dikkatimi çekti: Evet, gayet sorunsuz çalışıyor. SDK sadece Teams tarafını hallediyor, içeride istediğiniz framework’ü kullanabilirsiniz. Mesela ben kendi POC’umda LangChain agent executor’ını doğrudan on_message handler’ı içinde çağırıyorum — hiçbir problem çıkmadı.

Streaming response için özel bir şey yapmam gerekiyor mu?

Şöyle ki, SDK’nın bunun için ayrı bir API’si var. Async generator pattern’i ile token token gönderiyorsunuz. Ama şunu söyleyeyim: Teams’in kendi rate limit’leri olduğu için çok hızlı stream ederseniz “throttling” hatasıyla karşılaşabilirsiniz. Tecrübeme göre her 100-200ms’de bir batch göndermek en dengeli yaklaşım oluyor.

Kaynaklar ve İleri Okuma

Konuyu daha derinlemesine incelemek isteyenler için topladığım birkaç kaynak:

• Microsoft 365 Developer Blog: Python GA Duyurusu
• Microsoft Teams Platform Resmî Dokümantasyonu (bu kritik)
• Teams SDK GitHub Repository (issue ve sample’lar için)
• Microsoft Graph API Genel Bakış

Sorularınız olursa ya da kendi denemelerinizden ilginç sonuçlar çıkarırsanız, bana ulaşmaktan çekinmeyin. Bu SDK’nın önümüzdeki aylarda nasıl olgunlaşacağını — özellikle meeting. Channel senaryoları açısından — yakından takıp edeceğim. Hayırlı olsun.