Microsoft Foundry Agents vs M365 Agents SDK: Why “Publish to Teams” Isn’t Enough

Here’s a scenario I keep running into. A developer builds a solid agent in Microsoft Foundry, hits the “Publish to Teams” button, and it works. The agent shows up in Teams and in the M365 Copilot app. Users can chat with it. They demo it, everyone nods, and then someone asks: “Can it send an Adaptive Card when the approval is done?” Or: “Can it pull up an interactive form from our other system right inside the chat?” Or: “Can it proactively ping the channel when a document is flagged?”

And the answer, through Foundry’s built-in publish path, is no.

That’s the ceiling. Foundry’s quick publish gets your agent into Teams and Copilot – but it’s a low-fidelity connection. It’s enough for a demo. It’s not enough for a production experience that takes full advantage of what M365 can do. The Microsoft 365 extensibility model – whether you’re building a declarative agent or a full custom engine agent with the M365 Agents SDK – is how you break through that ceiling. And most pro-code developers I talk to haven’t looked at either seriously yet.

What Foundry’s “Publish to Teams” Actually Gives You

To be fair, the quick publish path in Foundry is genuinely useful. With a few clicks, your agent is reachable in Teams channels and in the M365 Copilot app. Users can chat with it. It responds. For simple conversational scenarios – internal Q&A, basic lookups, lightweight automation – that might be all you need.

But the integration is shallow by design. What you’re getting is essentially a pass-through – user sends a message, Foundry processes it, text comes back. The connection goes through Azure Bot Service, but Foundry’s publish path only exposes a slice of what Bot Service can actually do. The rich layer that makes M365 experiences feel native is just not available through that channel:

• No Adaptive Cards – responses are plain text only
• No MCP Apps UI – there’s no way to surface interactive UI from an external app inside the chat experience through Foundry’s publish path
• No proactive messaging – the agent can only respond, it can’t initiate
• No deep Teams-native patterns – things like task modules, message extensions, and channel-level actions are off the table

This applies to both the Teams publish and the Copilot app publish. Same path, same constraints, same ceiling.

What the M365 Agents SDK Unlocks

The M365 Agents SDK is the pro-code framework built specifically for agents that need to be first-class citizens inside Microsoft 365. It handles the channel plumbing – routing activities, managing state, normalizing input from different surfaces – so you can focus on the agent logic itself.

With it, your agent actually gets access to the full M365 integration surface:

• Adaptive Cards – send rich, interactive cards that users can act on directly in Teams or Copilot
• MCP UI apps – when you build a declarative agent via the M365 Agents Toolkit and connect it to an MCP server, you can surface interactive UI from that external app directly inside the Copilot chat. Think expense approval forms, project dashboards, task managers – rendered inline, without the user ever leaving the conversation. Not available through Foundry’s publish path.
• Proactive messaging – initiate conversations, send alerts, update users when background processes complete – without waiting for the user to ask
• Full Teams channel presence – works in channels, group chats, 1:1 conversations, and meetings
• M365 Copilot app integration – a genuine, deep presence in Copilot, not a pass-through
• The Agent Store – publish your agent so it’s discoverable and managed like any other M365 app, with proper admin controls

And importantly: the SDK is AI-agnostic. It handles distribution and channel management. What generates the intelligence is up to you – which means you can absolutely point it at a model you’ve deployed in Foundry. These two tools are complementary, not competing.

What Building With the M365 Agents SDK Actually Looks Like

This is where I think a lot of developers check out – they assume it’s going to be a complicated setup, and they default back to Foundry or Copilot Studio because it feels safer. It’s really not that bad.

The M365 Agents Toolkit in VS Code and Visual Studio does the heavy lifting. You scaffold a new project, pick your agent type (declarative or custom engine), and you get a working structure with local debugging built in. The toolkit also handles sideloading into Teams and the publish flow to the Admin Center when you’re ready to go wider.

Custom engine agents – which is the M365 Agents SDK path specifically – are where you take full control of the AI layer. You bring your own model, your own orchestration, and your own tool integrations. The SDK handles how that agent plugs into Teams channels, manages conversation state, and routes activities from whatever surface the user is on. You deploy it to an Azure App Service or container and that’s your hosting story.

The simplest version of this is a single component – your AI logic and your channel logic living together in the same App Service or container. You wire up your model calls, handle conversation state, and manage the M365 channel integration all in one place. One service, one deployment, done. That’s the right starting point for most teams.

The more complex version – and this is where Foundry enters the picture – is splitting those two concerns apart. Your AI layer runs as a Foundry hosted agent (or any other backend service), and your M365 Agents SDK component is purely the front door: it handles channel routing and hands off to Foundry for the intelligence. You’d go this route when you need what Foundry specifically offers – managed infrastructure, enterprise compliance controls, built-in tools like code interpreter or file search, or complex multi-agent orchestration that benefits from Foundry’s runtime.

But don’t let the two-tier architecture intimidate you out of getting started. If you don’t need all of that, a single well-structured App Service running the M365 Agents SDK with your own AI logic is completely production-worthy.

The Right Mental Model

Think of it in two layers.

The AI layer is where your model runs, where your tools are wired up, where the thinking happens. Foundry Agent Service is excellent at this – managed infrastructure, built-in tools like code interpreter and file search, persistent memory, enterprise security. If you’re doing heavy backend processing, multi-agent orchestration, or need Azure-grade compliance controls, Foundry is doing real work for you here.

The channel layer is how your agent talks to users inside M365 surfaces. Foundry gives you a basic channel layer for free with quick publish. The M365 Agents SDK gives you a full one – deployed as a web service in Azure, handling the rich interaction patterns your users actually expect.

Here’s a concrete example. Say you’re building an IT helpdesk agent. The backend logic – pulling from your ticketing system, reasoning about priority, suggesting resolutions – that could live in Foundry. But when the agent needs to send a user an Adaptive Card showing their ticket status with a “Mark Resolved” button, or proactively ping a channel when a P1 ticket goes unanswered for 30 minutes, that’s the M365 Agents SDK doing work that Foundry’s publish path simply can’t do.

If your use case needs anything beyond simple back-and-forth text responses in Teams or Copilot, you need the channel layer that the M365 Agents SDK provides.

The simpler path is to build it all as one component – AI logic and M365 channel handling together in a single App Service or container. That’s where most teams should start. The more advanced pattern is to separate the two: Foundry running the backend AI layer, the M365 Agents SDK component acting as the front door. You get there when you genuinely need what Foundry’s managed runtime offers – and not before.

What About Copilot Studio?

I’ve been talking about pro-code options this whole article, but it’s worth a quick callout: Copilot Studio is the third lane here, and it’s the right answer for some teams.

If the built-in connectors and actions cover what you need, AND the user experience of authorizing those connections is acceptable (a BIG issue in Copilot Studio) – Copilot Studio is faster and requires far less infrastructure overhead. It also has its own publish path into Teams and Copilot that gives you a reasonable M365 presence.

The gap shows up when you need things Copilot Studio can’t (or can’t easily) do: custom AI models, highly tailored UI, or an ultra-seamless connection experience to your external systems. That’s when the M365 Agents SDK conversation becomes relevant. And to be honest… it shines. I actually WISH Copilot Studio could provide the smooth experience that you can get through the M365 Agents SDK and how it does OAuth behind the scenes. I doubt that’ll ever happen.

Who Should Be Looking at the M365 Agents SDK

If you’re a pro-code developer building agents for M365 and you’re currently doing one of these things, this is for you:

You’ve hit Foundry’s publish ceiling. You built something in Foundry, it’s running, but you can’t get the interaction patterns you need through the publish path. The M365 Agents SDK is the path forward – not a rebuild of your AI logic, just a proper front door into M365 for the agent you’ve already built.

You’re defaulting to Copilot Studio for M365 integration. You know Copilot Studio isn’t really the right fit for your use case – the model limitations or connector gaps are obvious – but you’ve been using it because you assumed it was your only M365-native option. The M365 Agents SDK is the pro-code alternative Microsoft built for exactly this.

You’re building something users will rely on daily. An IT helpdesk agent. A contract review agent. An onboarding assistant. These agents need to feel like real apps – with proper admin deployment, Adaptive Card UIs, and the ability to reach out to users rather than just respond to them. That’s not a Foundry quick-publish story.

The M365 Agents Toolkit makes getting started more approachable than it looks. You bring your own model and orchestration. Microsoft handles the channel infrastructure. And the output is an agent that genuinely behaves like a native M365 app – because it is one.

The Bottom Line

Foundry’s publish-to-Teams path is a good starting point – and for lightweight use cases, it might be all you need. But if you’re building something that users will rely on daily, that needs to feel like a real M365 app, and that takes advantage of the richer interaction patterns M365 supports, quick publish isn’t going to cut it.

The M365 Agents SDK is the pro-code answer to that problem. It’s not widely talked about, it’s not the default recommendation, and a lot of developers are building lower-fidelity agents than they need to be – simply because they don’t know this option exists.

Now you do.

If you want to see what full-fidelity, production-ready Copilot agents look like in practice, check out The Agent Collection – a set of agents I’ve built and maintain for real M365 deployments. They’re built right, and they’re ready to use. With pro-code agents coming soon!

And if you’re working through a specific architecture decision, reach out. This is exactly the kind of thing I love getting into.