Picture this. You’ve decided to build a Copilot agent – real code, real logic, not just a Copilot Studio click-through. You open a browser, type “which SDK should I use,” and thirty seconds later you’re staring at three different options with names so similar they might as well be the same thing. Microsoft 365 Agents SDK. Teams SDK. Agent 365 SDK.
You close the tab. You open it again. You wonder if maybe just using Copilot Studio wasn’t such a bad idea after all.
If that sounds familiar, this post is for you. These three SDKs are genuinely different tools that do genuinely different things – and once you understand what each one is actually for, the choice gets a lot simpler. Let me walk you through it.
The Naming Problem Nobody Talks About
Before we get into the SDKs themselves, I have to say something: Microsoft named these things in the most confusing way possible, and I think it’s worth acknowledging that out loud.
Agent 365 SDK sounds like it might be related to Microsoft 365 Agents SDK. The Teams SDK used to be called the Teams AI Library. The M365 Agents SDK toolkit used to live inside the Teams Toolkit. It’s a lot.
The good news is that underneath all the naming chaos, there’s actually a clean mental model here. Think of it this way:
- The Microsoft 365 Agents SDK is the channel layer – it handles how your agent talks to platforms.
- The Teams SDK is the Teams specialist – it’s a purpose-built framework for agents that live in Teams.
- The Agent 365 SDK is the enterprise layer – it’s what you bolt on when you need identity, compliance, and governed access to M365 data.
They’re not competing options. Two of them are actually complementary. Let me explain.
Microsoft 365 Agents SDK: The Multichannel Backbone
The Microsoft 365 Agents SDK is what you use when you want to build a custom engine agent that works beyond just Teams. Think of it as the plumbing. It handles the translation between your agent logic and whatever channel the user is sending messages from – Teams, Microsoft 365 Copilot, a website, Slack, Twilio, you name it.
Here’s what that means practically: you write your agent logic once. The SDK normalizes the incoming message into a common format, routes it to your handler, and then translates your response back into whatever format the destination channel expects. You’re not writing Teams-specific code. You’re not writing web-specific code. You’re just writing agent code.
This is the right SDK if you need your agent in more than one place.
The Microsoft 365 Agents SDK is also AI-agnostic by design. It doesn’t care whether you’re using Azure OpenAI, a local model, or something else entirely. It’s purely the message routing and channel abstraction layer. What you plug into it for the actual intelligence is entirely up to you.
Fair warning: this one has a steeper learning curve. You’re not going to get a pretty scaffold and a few config options. There’s real infrastructure involved. But it’s the recommended path for any serious enterprise agent deployment – especially if Copilot or multi-channel reach is part of your roadmap.
Teams SDK: When Your Agent Lives in Teams and That’s Enough
The Teams SDK – formerly called the Teams AI Library, renamed in late 2025 to better reflect what it actually is – is what you reach for when Teams is your world and you want a clean, modern development experience specifically built for it.
The Teams SDK is generally available in C# and JavaScript (and in public preview for Python as of this writing). It’s purpose-built for Teams-only agents, and the tradeoff is a good one: you give up the multichannel flexibility of the M365 Agents SDK, and in exchange you get a cleaner developer experience with some built-in AI orchestration that the M365 Agents SDK doesn’t include out of the box.
What makes the Teams SDK interesting right now is what got added in the v2 release: MCP and A2A support.
MCP (Model Context Protocol) lets your agent share memory and tools with other agents through a common interface. A2A (Agent-to-Agent communication) is exactly what it sounds like – secure peer-to-peer messaging between agents without relying on a centralized middleman. If you’re building in a world where agents need to coordinate, hand off tasks, or share context, these aren’t nice-to-haves. They’re the whole point.
So if you’re building specifically for Teams and you want a framework that thinks the same way you do about agentic workflows – without the overhead of a multichannel architecture you don’t need – the Teams SDK is a solid choice.
Agent 365 SDK: The Enterprise Layer You Bolt On Top
Here’s where I see the most confusion, so let me be direct: the Agent 365 SDK is not a replacement for either of the above. It’s not a framework for building agents from scratch. It’s an extension layer you add to an agent you’ve already built – with any SDK, including non-Microsoft ones.
What does it give you? Four things, and they all matter for enterprise deployments:
Entra-backed agent identity. Your agent gets its own identity – its own mailbox, its own presence – backed by Microsoft Entra. That means it can participate in M365 workloads as a first-class principal, not just a service account workaround.
Notifications. Your agent can receive and respond to notifications from Teams, Outlook, Word comments, and emails. Like a human participant. This is a big deal for use cases where an agent needs to act on things that happen in the M365 ecosystem – not just wait to be messaged.
Full observability. Agent 365 SDK integrates with OpenTelemetry, so you get audited, traceable logs of your agent’s interactions, inference events, and tool usage. If you’re deploying in a regulated environment, this is the difference between a proof of concept and something legal will actually sign off on.
Governed MCP access to M365 data. Your agent can invoke MCP servers to access Mail, Calendar, SharePoint, and Teams – but under admin control, not wild-west API calls. IT can see what the agent is accessing. Admins can restrict it. That’s enterprise-grade.
Agent 365 hit general availability on May 1, 2026, and it’s bundled inside Microsoft 365 E7. If your org is already there, you’ve got access. If you’re building agents that will touch sensitive M365 data in a compliance-conscious environment, this is worth the conversation with your licensing team.
So Which One Do You Use?
Here’s the honest decision tree:
Building only for Teams? Use the Teams SDK. Cleaner, simpler, great AI orchestration primitives.
Building for multiple channels or Copilot? Use the Microsoft 365 Agents SDK. It’s more complex, but it’s the right foundation for anything with real reach.
Need enterprise identity, compliance, observability, or governed M365 data access? Add the Agent 365 SDK on top of whichever of the above you chose.
You’ll notice that last one isn’t “instead of” – it’s “on top of.” That’s the key insight. The Agent 365 SDK doesn’t replace your agent framework. It makes your agent enterprise-ready.
And if you’re not sure where you land yet – start with the Teams SDK, understand how agent development actually works, and then revisit the multichannel and governance questions once you know what you’re building.
Don’t Start from Scratch
One more thing before you go open seventeen documentation tabs.
I’ve spent a lot of time building production-ready Copilot agents, and the hardest part is almost never the SDK. It’s figuring out the patterns – what the agent should do, how it should be structured, how to make it actually useful instead of just technically functional.
That’s why I built The Agent Collection – a curated set of production-ready Copilot agents I’ve built and maintain. If you want to skip the “figure it out from scratch” phase and start from something that already works, that’s where to go.
Check it out at modernworkmastery.com.
FAQ
Can I use all three SDKs together? Yes, and in an enterprise scenario you probably will. Teams SDK or M365 Agents SDK for the agent framework, Agent 365 SDK on top for identity and governance.
Is the Teams AI Library still supported? It was renamed to the Teams SDK in late 2025. The v2 architecture is what you should be building on – if you’re on the old Teams AI Library v1, migration is worth planning for.
Do I need Agent 365 SDK if I’m not in a regulated industry? Not necessarily. But if your agent is accessing M365 data on behalf of users, the observability and governed access are worth considering even outside heavily regulated environments. Audit logs have a way of mattering more than you expect.
What happened to the Bot Framework SDK? The Microsoft 365 Agents SDK is the spiritual successor to the Bot Framework SDK. If you’ve got existing Bot Framework solutions, the M365 Agents SDK is where Microsoft wants you to go.
