Continuing my recent posts about Microsoft shooting themselves in the foot with Microsoft Teams development, today I’m diving into the Microsoft 365 Agents Toolkit (M365 ATK).
My assessment?
I genuinely appreciate what Microsoft built technically, while being incredibly frustrated with how the team responsible for the M365 ATK constantly frustrates developers and sabotage any momentum they have for Teams app development adoption.
My frustration isn’t with the engineers who built this—they created solid technology. My issue is with how Microsoft’s management treats their developer customers through poor release processes and communication.
The M365 ATK represents both the best and worst of Microsoft’s developer tools strategy. It’s technically capable, architecturally sound, while at the same time is delivered sloppily with releases that fundamentally lack empathy for developers.
TL;DR
M365 ATK has great tech (YAML pipelines, Bicep, flexible architecture) but the execution is maddeningly frustrating. Microsoft resets all project templates without warning, removes features without migration paths, scatters docs everywhere, and treats developer workflow stability as an afterthought.
The September 2025 template overhaul exemplifies this perfectly: working templates replaced overnight with stripped-down versions, zero notice, no guidance. Good tech, terrible developer empathy.
Andrew Connell
Microsoft MVP, Full-Stack Developer & Chief Course Artisan - Voitanos LLC.
This is one of a multi-part series on Microsoft Teams application development frustrations. The other parts of this series include:
- Microsoft's Own Goals in Teams Development
- Microsoft Teams development SDK Guidance - Fall 2025
- Microsoft has Three SDKs for Teams Apps, What Should You Use
- M365 Agents Toolkit: Great tech but lacks developer empathy (this article)
Understanding the M365 Agents Toolkit
The Microsoft 365 Agents Toolkit is simply the next iteration of what we called the Teams Toolkit for VS Code. Microsoft renamed it at the Build conference in May 2025, but under the hood, it’s the exact same tool… just with a fresh name.
Microsoft 365 Agents Toolkit
The M365 ATK consists of two main components:
- an extension for both VS Code and Visual Studio
- a command-line interface (CLI)
Its primary purpose is enabling developers to create Teams apps and agents for Microsoft 365 Copilot using a specific project structure.
Projects include an m365agents[.*].yaml file in the root that defines the build toolchain and manages provisioning in local, development, production environments. You’ll also find an appPackage folder containing everything that gets packaged into the Teams app ZIP file, an infra folder with Bicep files for Azure resource provisioning, and an env folder storing environment-specific variables.
Typical Microsoft 365 Agents Toolkit project
To understand why the M365 ATK matters, and why its execution is so frustrating, let’s look at how we got here.
The evolution from community solutions to Microsoft’s toolkit
The journey here tells an interesting story about Microsoft’s approach to developer tools. Originally, Microsoft provided zero developer tools for Teams apps. The community filled this gap with Yo Teams, a Yeoman generator created by Wictor Wilen, then a Microsoft MVP and now a Microsoft employee.
Microsoft’s first attempt came in July 2020 with Teams Toolkit v1 for VS Code. It was rough, unpopular, and largely ignored. Version 2 arrived in May 2021 with similar reception. Even v3 in November 2021 failed to match developer expectations. Yo Teams remained the dominant choice.
Even Microsoft Didn’t Trust the Teams Toolkit V1-V3!
At the time the Teams Toolkit (TTK) was released, I was writing Teams developer learning modules for the Microsoft Learn site… even Microsoft told me not to use v3 of the TTK! They told me to write the modules using Yo Teams!
The TTK didn’t find its footing until v4 released in May 2022 — the first genuinely good version. Version 5 followed in June 2023, and what we now call the M365 ATK launched in May 2025 as essentially v6 with new branding.
Yeah… I know it’s shocking that Microsoft had to throw the word Agents in the name, even though it was still the tool you used to create Teams apps that had nothing to do with agents or AI.
What the Agents Toolkit gets right
The m365agents.yaml files are genuinely excellent. They provide granular control over the build toolchain, from Azure provisioning to Teams app creation, dependency validation, and manifest checking. If you’re familiar with GitHub Actions or Azure DevOps Pipelines, you’ll feel right at home.
The environment concept works well too. You get separate environments for provisioning (creating resources), deployment (handling things like npm install), and publishing (production scenarios). These building blocks, called actions, let you assemble custom pipelines with impressive flexibility.
I also appreciate that Azure resources for Teams apps default to Bicep files, Microsoft’s domain-specific language (DSL) for ARM templates. This makes repeatable deployments straightforward and version-controllable.
So if the technology is this good, where’s the problem? It’s in how Microsoft manages and delivers these capabilities to developers
Where Microsoft fails developers
Despite these technical strengths, the Agents Toolkit, or more specifically the way it’s released and managed, demonstrates a fundamental lack of developer empathy that undermines Teams development as a whole.
Project templates: A masterclass in poor execution
Microsoft bakes project templates directly into extension releases, meaning any template issues require waiting for a full toolkit update. There’s no separate versioning, no changelog explaining changes to the templates, and no warning when templates undergo complete overhauls.
The September 2025 releases exemplified this problem perfectly. Microsoft completely reset all templates for Teams apps… tabs, bots, message extensions… everything. They introduced brand-new SDKs, the Teams SDK (formerly the Teams AI v2) that developers weren’t familiar with, backed by documentation that remains inaccurate, incomplete, and scattered across multiple sites.
They simultaneously removed all the old, working templates. Developers creating a new tab project suddenly lost Fluent UI integration, Azure Function projects for server-side code, and single sign-on configuration. The replacement?
Nothing.
No migration guidance, no feature parity, just confusion.
Template quality is inconsistent. Different files use different indentation… tabs versus spaces, 2 spaces versus 4. Some templates place source code in a src subfolder; others dump everything in the root. Some provide bare-bones starting points while others overflow with comments, sample code, and documentation artifacts that should’ve been removed.
That’s what happened in September 2025 when the M365 ATK v6.2.0 was released. Here’s a real-world experience:
- Let’s say you were used to creating Microsoft Teams tab project and you used the React with Fluent UI template. It included a starting point that was confused with SSO, theme support using the Fluent UI React
<FluentProvider>, wired up to listen for the user to change the Teams client theme, and included an Azure Function for server-side calls. If you created that project on September 17, 2025… that’s what you got. - Then the M365 ATK v6.2.0 was released on September 18, 2025…a minor release that didn’t indicate anything huge changed… so you blindly updated the extension.
- On Friday, September 19, 2025, you go to create a tab project… but that React with Fluent UI tab project template is gone. After a minute you find the tab template, buried in the menu under Teams Agents and Apps ▶ Other Teams Capabilities ▶ Tab. But to your surprise, everything you were looking for is gone. No Fluent UI React library, no theme support, no SSO, no Azure Functions project… nothing.
Dig in and you’ll find this in the changelog:
Microsoft
Updated? No… let me help you write that to be more accurate and honest:
We’re thrilled to announce that in this release, we’ve thrown away all the prior Teams project templates and have replaced them with entirely new templates that use the and modern Teams SDK!
Documentation scattered like breadcrumbs
Finding documentation requires a treasure hunt across learn.microsoft.com, various wikis in GitHub, and source code repositories. Changelogs exist but hide deep in subfolder structures. Pre-release announcements? Practically non-existent.
When Microsoft shipped the Teams SDK (formerly Teams AI v2) in September 2025, they provided zero advance notice unless you obsessively monitored pre-release changelogs. Developers discovered the complete template overhaul only when creating new projects.
The real cost of poor developer experience
Microsoft’s approach to the Agents Toolkit reveals a deeper problem: they don’t understand or prioritize developer workflow stability. The drastic project template resets, breaking changes without warning, and documentation that never matches reality create a hostile development environment.
I’m not opposed to new SDKs or updated templates. But completely refactoring everything, essentially performing a code reset, with most releases is inexcusable. It’s disruptive, disrespectful of developers’ time, and explains why many developers and companies don’t adopt and stick with Teams as an app development platform entirely.
Conclusion
The Microsoft 365 Agents Toolkit embodies a frustrating paradox. Technically, it’s well-architected with powerful features that streamline Teams and Copilot development. Practically, project templates are sloppy, just be careful installing the latest version of the M365 ATK when it’s released… you might regret it and find yourself wanting to go back.
Microsoft needs to prioritize stability, communication, and developer experience over change. Like I said before, I’m not against change, new SDKs, updated project templates. All I ask is to keep in mind that your customers aren’t ready to make the change right when you make the change.
So… what would good look like? here’s what I’d start with:
- There needs to be a solid effort to go over all the project templates with a consistency and quality mindset. The project templates should follow one of the following patterns rather than an inconsistent mix of them:
- Bare bones to get started and let developers build out the solution.
- Include lots of comments to guide developers on what to do.
- A full scenario example.
- When updating the project templates, don’t delete the old templates. Instead, deprecate them with a notice that they’ll be removed by a set date.
- Single source of accurate and current documentation.
- The Teams SDK docs should be in
learn.microsoft.comwhere the other Teams dev docs are. - ALL the Teams developer docs on
learn.microsoft.comneed to get updated. Old & inaccurate parts need to be removed, retired, or it needs to be clear it no longer applies.
- The Teams SDK docs should be in
What’s your experience with the M365 ATK? Have you been burned by a template change? Let me know in the comments. Am I being too harsh on Microsoft here, or do you share these frustrations?
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.
