Microsoft has Three SDKs for Teams Apps, What Should You Use

If you’re building Microsoft Teams apps in 2025, you face a choice that shouldn’t exist: which of Microsoft’s three SDKs should you use?

The confusion starts with understanding that Teams apps have two distinct parts: client-side experiences (tabs, personal apps, dialogs) and server-side capabilities (bots, message extensions, agents for Microsoft 365 Copilot). For client-side development, there’s one clear choice: the Teams JavaScript SDK. But when you need server-side functionality, Microsoft offers two overlapping options—Teams AI v2 and the Microsoft 365 Agents SDK—with no clear guidance on when to use which one.

I’ve been a Microsoft MVP for over two decades. I’ve watched plenty of strategic pivots and product rebrands. But the current SDK situation represents something new: two simultaneously supported, officially blessed paths to build overlapping server-side functionality, with an opaque and unclear decision tree and unclear documentation from Microsoft to help developers choose.

In this article I will explain how we got here and, more importantly, how you should navigate this mess.

Three SDKs and unclear direction

Teams JavaScript SDK: the client-side foundation

Before we discuss the server-side confusion, let’s clear up the one part that isn’t confusing: if you’re building any client-side Teams experience—tabs, personal apps, or dialogs, you use the Teams JavaScript SDK. Period.

This SDK provides the APIs to interact with Teams as a host platform. It handles authentication, theme detection, navigation, and all the Teams-specific client capabilities you need. There’s no alternative, and there’s no decision to make.

The Teams JavaScript SDK is mature, well-documented, and stable. It’s the foundation for any Teams app with a user interface. Whether you’re building a simple tab or a complex personal app, this SDK is non-negotiable for the client side.

The confusion only begins when you need server-side functionality.

Teams SDK: the misnamed general-purpose SDK

Microsoft originally announced the successor to the Teams AI Library in May 2025 as the Teams AI v2. The way it was pitched at the time in their announcement post, as you can see below, is that this would be the one SDK that would do everything we did before.

The problem with this: it’s wrong. That figure implies that you would’t need anything else to build apps. No other packages for Adaptive Cards, nothing for client-side work (Teams JS)… it’s wrong.

Not only do you need additional packages, but this name they selected implied it was all about AI.

AND IT ISN’T

I wasn’t the only developer that was confused and expressed frustration as evidenced by this discussion I started soon after their v2 announcement and continued on for over six months.

The sad part, in my opinion, it was all rooted in a bad naming decision. The name, Teams AI v2, implied you used this for AI workloads when in fact it was intended for everything server-side involved in creating Teams apps.

Seems Microsoft finally realized it too, because last week they announced they renamed the Teams AI v2 SDK to the Teams SDK.

Even though it’s long overdue, I welcome this rebranding…

But that’s not the only server side SDK.

M365 Agents SDK: for multi-channel bots, not Teams-only apps

The Microsoft 365 Agents SDK was announced in November 2024. Microsoft positions it as the “modern” way to build agents that work across multiple channels supported by the Azure Bot Service—not just Teams, but also Slack, web chat, and other platforms.

Here’s the critical distinction that Microsoft doesn’t make clear: the M365 Agents SDK is for building bots and agents that need to work across multiple channels. If you’re building a bot that only works in Teams, this SDK is the wrong choice. You’d use Teams SDK instead.

The pitch makes sense for the right use case. One codebase that works in Teams, Slack, web chat, and any other Azure Bot Service channel. That’s compelling… until you discover it shipped only with .NET documentation. Even though they were going to have an SDK for Python & Node.js (TypeScript), they didn’t have any docs or hardly any examples for it when they shipped it in May 2025.

For the massive population of non-.NET developers in the Microsoft ecosystem, this SDK simply isn’t an option. When I asked Microsoft’s documentation team about Node.js support, the response was vague references to some form of “we’re working on it.”

The M365 Agents SDK also lacks several features present in Teams SDK or Teams client specific things. The multi-channel promise is real, but you pay for it with reduced flexibility, language limitations, and the added complexity of supporting multiple platforms when you might only need Microsoft Teams.

How we got here: following Microsoft’s pivots

This server-side SDK confusion wasn’t inevitable. It’s the result of Microsoft’s strategic pivots colliding with different teams’ roadmaps.

In 2023, Microsoft went all-in on “AI will change everything.” Every product team scrambled to ship AI features. The Teams platform team built Teams SDK to make it easy to add AI to Teams bots. The broader M365 developer platform team built what became the M365 Agents SDK to support multi-channel bot scenarios.

By mid-2024, Microsoft started talking about “agents” instead of “AI features.” Same technology, new marketing term… they were following what the rest of the AI industry was doing. Each SDK team rebranded accordingly, but nobody consolidated the SDKs themselves or clarified when to use which one.

Starting with the Microsoft Ignite conference in late 2024, multiple teams at Microsoft started building different SDKs. Classic Microsoft playbook: shipping the org chart.

Microsoft’s developer relations teams try to clarify the confusion, but they’re working without official guidance. When I asked some at Microsoft which SDK to recommend for a new Teams bot project, the answer was, “It depends on your requirements,” followed by a list of considerations that basically conveyed the feeling “we don’t know either.”

The real cost: developer paralysis

This confusion isn’t just an inconvenience. It actively harms Teams developer adoption.

On Stack Overflow, questions about “which Teams SDK to use for bots” seem to outnumber questions about how to use the SDKs. Developers spend hours researching options before writing any code. Some give up entirely and build on Slack instead.

GitHub Issues on both server-side SDK repositories contain frustrated developers asking for decision guidance. Microsoft’s responses? Generic reassurances that “all SDKs are supported” with no specifics on when to choose which one.

Fellow MVPs privately express the same frustration I feel. When we recommend the Teams platform, we have to caveat every server-side SDK suggestion with “but this might not be the best choice six months from now.”

New developers to the Teams platform see the two server-side SDKs and assume they must learn both to be effective. Experienced developers who learned the Teams AI Library v1 feel burned by the v2 rewrite and hesitate to commit to any Microsoft SDK.

The opportunity cost is real: developers who could be building Teams apps are instead researching SDK options or choosing simpler platforms.

The path forward: picking your SDK in 2025

Microsoft’s decision matrix is inaccurate and unclear. I had to pull information and statements from the Microsoft 365 Agents SDK and Teams SDK teams by chasing them down for weeks and months in their GitHub repos.

So I will… frankly because I got so frustrated trying to figure it out. You shouldn’t have to.

Based on 20+ years navigating Microsoft’s ecosystem and my direct experience with all three SDKs, here’s how to choose:

Client-side development: no choice required

This one is easy… there’s no decision.

Use the Teams JavaScript SDK (Teams JS) for:

• Tabs (channel, group, personal)
• Personal apps
• Dialogs and task modules
• Any Teams app with a user interface

This isn’t a decision, it’s a requirement. Every Teams app with client-side functionality uses the Teams JavaScript SDK. It’s mature, stable, and the only option for interacting with Teams as a host platform.

If your Teams app has a server-side component, there are parts of the Teams SDK that are useful for your client-side app.

Server-side development: the actual decision

Once you know you need server-side functionality (bots, message extensions, agents), the choice can be confusing, but I’ll be direct:

Choose Teams SDK if:

• You’re building a bot or agent specifically for Teams
• You want the richest feature set and most active community
• You can accept that the old name “Teams AI v2” was a misleading name for what’s actually a general-purpose server-side SDK

This is my default recommendation for Teams-specific bots and agents. It’s the most mature, most capable, and most likely to remain supported.

Choose M365 Agents SDK if:

• You’re building a bot that must work across multiple channels (Teams, Slack, web chat, etc.)
• You can live with a smaller feature set compared to Teams SDK
• You’re willing to handle the complexity of supporting multiple platforms

This SDK only makes sense for multi-channel scenarios. If you’re building exclusively for Teams, choose Teams SDK instead.

What I’m telling my clients

When developers hire me for coaching or take my workshops, here’s what I tell them:

For client-side development, use the Teams JavaScript SDK. No debate, no alternatives.

For server-side development, build on Teams SDK unless you have a specific multi-channel requirement that demands the Microsoft 365 Agents SDK.

Yes, Microsoft might announce Teams AI v3 next year. Yes, they might eventually consolidate these server-side SDKs. It’s the least risky choice right now for Teams-specific bots.

If Microsoft announces a deprecation (and given their track record, they probably will), you’ll have time to migrate. Microsoft typically provides 12-18 months notice. Plan for it. Budget for it. Build with abstraction layers that make migration easier.

The server-side SDK confusion is frustrating, but it’s not fatal. You can succeed with Teams development despite Microsoft’s unclear guidance. You just need to choose pragmatically and plan for change.

That’s what I teach in my courses and workshops—not just how to use the SDKs, but how to build Teams apps that survive Microsoft’s next pivot.

author

Andrew Connell

Microsoft MVP, Full-Stack Developer & Chief Course Artisan - Voitanos LLC.

Andrew Connell is a full stack developer who focuses on Microsoft Azure & Microsoft 365. He’s a 21-year recipient of Microsoft’s MVP award and has helped thousands of developers through the various courses he’s authored & taught. Whether it’s an introduction to the entire ecosystem, or a deep dive into a specific software, his resources, tools, and support help web developers become experts in the Microsoft 365 ecosystem, so they can become irreplaceable in their organization.

Feedback & Questions