Microsoft 365 Agents SDK: a channel container for agents you host yourself
The Microsoft 365 Agent SDK simplifies building full stack, multichannel, trusted agents for platforms including M365, Teams, Copilot Studio, and Webchat.
At a glance
- What is it?
- The microsoft/Agents repository is a jumping-off point rather than a library you install. It holds samples, specs and coding-assistant plugins for the C#, JavaScript and Python SDKs that put an agent on Teams, M365 Copilot or Webchat.
- Who is it for?
- Adopt the Microsoft 365 Agents SDK if your agent has to appear inside Teams, Microsoft 365 Copilot or a custom web client and you want the channel plumbing handled for you; the README is explicit that a Microsoft 365 Copilot subscription is not required unless you target that channel. Do not adopt it if you only need an orchestration loop over an LLM inside a single process, because the SDK's value sits in the channel layer and the AI provider stays your choice.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 7 days ago.
- What is it written in?
- Mainly TypeSpec, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What the Microsoft 365 Agents SDK is actually for
The problem this repository addresses is not model orchestration. It is the last mile: getting an agent you already built to answer inside Microsoft Teams, Microsoft 365 Copilot, a custom web app or another channel, with the protocol handling that each of those clients expects. The README describes the goal as creating agents "deployable to channels of your choice" with "scaffolding to handle the required communication".
The audience is therefore a developer who has a working agent and a distribution requirement. The SDK is explicitly agnostic about the AI behind it. The README states that developers "can use the AI Services of their choice" and that the SDK is "agnostic regarding the AI you choose". That is the design bet: the channel layer is the product, and the reasoning layer is yours to pick. If you are still deciding which model to call, this project does not decide for you.
One clarification the README makes directly is worth repeating because it is a common assumption: Microsoft 365 Copilot is "one of many channels supported by this SDK", and a Microsoft 365 Copilot subscription is not required to get started or to use the SDK unless you are working specifically with that channel or another one that requires a subscription.
The repository is a hub, not the client library
This is the single most important structural fact, and it changes how you install anything. The README says the repository "is meant to be a jumping off point into those language specific repositories" and that "the source for the client libraries exists for the most part in repositories for each language". There are separate repositories for C#/.NET, JavaScript and Python.
The practical consequence is about issue routing. The README instructs that "issues related to a specific language should be opened in the corresponding repository but cross cutting issues can be opened in this repository". If you file a JavaScript bug here, expect it to be redirected.
What this repository does carry is visible in its top level entries: a samples/ directory with dotnet, nodejs and python subfolders, a specs/ directory, a docs/ directory, an experimental/ directory, agent-plugins/, and two error code references, AgentErrorCodes.md and AgentErrorCodesJS.md. The primary language of the repository is TypeSpec, which fits a repo whose job is to hold specifications and samples rather than a shipped runtime. The presence of AgentErrorCodes.md alongside a JavaScript-specific variant is a small signal that error taxonomy is treated as shared surface, at least partly documented here.
Installing the coding-assistant plugins that ship with the SDK
The one installation procedure the README spells out is not for the SDK itself but for the agent plugins, which it describes as giving an AI coding assistant "deep knowledge of SDK APIs, patterns, and common mistakes". They are hosted under agent-plugins/ in this repository and are installed through a plugin marketplace command set. The README shows this for GitHub Copilot CLI or Claude Code:
/plugin marketplace add microsoft/Agents
/plugin install agents-sdk-common@microsoft-agents-sdk
/plugin install agents-for-js@microsoft-agents-sdk
/plugin install agents-for-net@microsoft-agents-sdk
/plugin install agents-for-python@microsoft-agents-sdkThe first line registers the marketplace; the rest install individual plugins. The README's guidance is to "install the common plugin and the plugins for the SDKs you use", so you would not normally run all four. The README states that skills activate automatically and that no manual loading is needed, and that you can run `/plugin` to verify installation.
The plugins are not equally deep. According to the README's table, agents-sdk-common covers Azure provisioning, identity credentials and OAuth setup through the `az` CLI for all languages. agents-for-js covers building agents, debugging authentication and startup issues, and configuring OpenTelemetry observability. agents-for-net covers building, debugging, OpenTelemetry, Bot Framework migration and `ActivityHandler`-to-`AgentApplication` migration. agents-for-python covers only OpenTelemetry configuration and troubleshooting. If you write Python, the plugin surface is much thinner than what .NET developers get.
For the SDK itself the README gives no install command. It points you to the samples folder, advises selecting your language and reviewing the samples list, and recommends QuickStart "for fundamentals". Package names and versions for the client libraries are not in this repository's README, so treat the per-language repositories as the place to find them.
What the samples directory tells you before you write code
The repository layout gives samples/README.md plus samples/dotnet/, samples/nodejs/ and samples/python/. The README's get-started instruction is a navigation one: scroll up, click the samples folder, pick your language, review the list, then choose one.
The Copilot Studio path is called out separately. The README says that to integrate an agent into your applications and to create multi-agent patterns with Copilot Studio agents, you go to the samples folder and select the Copilot Studio Client sample in your chosen language. That is the documented route for the Copilot Studio scenario, and it is a sample rather than a documented API surface.
A related note on the development loop: package.json lists @microsoft/m365agentsplayground as a devDependency, under devDependencies alongside eslint, @eslint/js, neostandard and typescript-eslint. The scripts are `lint` (eslint) and `validate-plugin` (claude plugin validate .). So the repository's own automation is linting and plugin validation. It does not run the samples for you, and the README does not describe a local test harness beyond the playground dependency being present.
Where the Microsoft 365 Agents SDK is the wrong tool
The clearest boundary is the one the README draws itself. This SDK is about the agent "container" with state, storage and activity handling, deployed to channels. If your agent never leaves a single process and never talks to Teams, M365 Copilot, Webchat or a comparable client, the channel scaffolding is weight you would carry without using.
A second boundary is documentation depth in this repository. The README does not document rollback, versioning policy or a compatibility matrix for the client libraries, and it does not list package names or versions for any language. Recent releases were not retrieved, so there is no release history here to read. Anyone who needs a pinned, documented upgrade path will have to find it in the per-language repositories.
A third is the migration story. The README's plugin table mentions Bot Framework migration and an `ActivityHandler`-to-`AgentApplication` migration skill, which implies existing Bot Framework code has a path forward. But the migration guidance lives in a coding-assistant plugin, not in a written migration guide in this repository's README. If you are moving a large Bot Framework codebase, that is a gap you should size before starting.
Finally, the repository is not archived and the last push was on 2026-09-08, so it is current. That says nothing about the maturity of any individual language SDK, which is where the actual code lives.
How it relates to Semantic Kernel, Azure AI Foundry and Copilot Studio
The README positions three neighbours, and the split is a real architectural difference rather than a marketing list.
Semantic Kernel is described as an SDK that integrates LLMs such as OpenAI, Azure OpenAI and Hugging Face with conventional languages like C#, Python and Java, by letting you define plugins that can be chained together. That is orchestration and function composition. The Agents SDK does not compete there; it assumes you have your reasoning layer and handles how the result reaches a channel. If your open question is how to chain model calls, Semantic Kernel is the closer fit.
Azure AI Foundry is described as providing "the core backend agent functionality, providing reasoning, retrieval augmentation, observability, among other core functions". The README notes you can use the Azure AI Agent Service or build agent functionality from individual components. So Foundry is a backend option you can pair with this SDK, not a substitute for it.
Copilot Studio is an agent building platform that can be used with the Microsoft 365 Agents SDK to integrate your agent into applications and to create multi-agent patterns with Copilot Studio agents. Here the two are complementary, and the documented entry point is the Copilot Studio Client sample.
The README also carries a note that your use of other services in connection with the SDK is governed by the respective agreements for those services, which may include codes of conduct and other restrictions. That is worth reading literally: the SDK being MIT-licensed does not extend to whatever services you call from it.
Editorial conclusion
Adopt the Microsoft 365 Agents SDK if your agent has to appear inside Teams, Microsoft 365 Copilot or a custom web client and you want the channel plumbing handled for you; the README is explicit that a Microsoft 365 Copilot subscription is not required unless you target that channel. Do not adopt it if you only need an orchestration loop over an LLM inside a single process, because the SDK's value sits in the channel layer and the AI provider stays your choice. Before committing, verify which language repository actually carries the client library you need, since this repo states that the source for the client libraries exists for the most part in the per-language repositories, and confirm the channel you plan to ship to is covered in samples/.
Frequently asked questions
How do you install the Microsoft 365 Agents SDK plugins in Claude Code?
The README gives a four-line sequence for GitHub Copilot CLI or Claude Code: run /plugin marketplace add microsoft/Agents, then /plugin install agents-sdk-common@microsoft-agents-sdk plus the plugin for each SDK you use. It advises installing the common plugin and only the language plugins you need, and says you can run /plugin to verify. Skills are stated to activate automatically with no manual loading.
How do you use the Microsoft 365 Agents SDK with GitHub Copilot?
The README lists the agent plugins as installable through GitHub Copilot CLI, using the same /plugin marketplace add microsoft/Agents command followed by the plugin installs. The plugins supply SDK API and pattern knowledge to the assistant rather than changing the SDK itself.
How do you use agents in Copilot Studio with the Microsoft 365 Agents SDK?
The README says Copilot Studio can be used with the Microsoft 365 Agents SDK to integrate your agent into applications and to create multi-agent patterns with Copilot Studio agents. To start, it directs you to the samples folder and the Copilot Studio Client sample in your chosen language.
How do you use the Microsoft 365 Agents SDK in Visual Studio Code?
The README does not describe a Visual Studio Code workflow for the SDK. Its documented tooling path is the agent plugins installed through GitHub Copilot CLI or Claude Code, with the samples folder as the starting point for code.
How do you use the Microsoft 365 Agents SDK in Claude?
The README covers Claude Code through the plugin marketplace commands: add microsoft/Agents as a marketplace, then install agents-sdk-common and the language plugins you use. It states the skills activate automatically based on the language and task you are working on.
Community notes