The Microsoft 365 Agents SDK — Agent 365: Building Agents

The best agent is usually the one that appears where the work is already happening. A person may start in Microsoft Teams, switch to email, edit a document, and then return to chat before lunch. If an agent is available in only one of those places, its usefulness depends on the user remembering to go back to that one place. The Microsoft 365 Agents software development kit (SDK) is meant for a different model: build the agent once, keep its core behavior coherent, and let it appear across multiple Microsoft 365 channels where the person is doing the work.

The problem is not intelligence; it is availability

Many agent projects begin by asking what the agent can reason about, which tools it can call, or how accurate its responses are. Those questions matter, but they are not the whole problem. A useful agent also has to be reachable at the moment of need.

Modern work is fragmented across surfaces. A question may arrive in chat, the answer may live in a document, the approval may happen in email, and the follow-up may return to a team workspace. An agent that lives in only one surface forces the user to adapt to the software. A multi-channel agent adapts to the work pattern instead.

This is the practical reason the Microsoft 365 Agents SDK exists. It is not just another way to write a bot. It is a framework for building agents whose core logic can be reused across more than one place in Microsoft 365, so the agent does not become a set of disconnected clones.

📌

The availability test. If users must remember where the agent lives before they can use it, the channel strategy is already part of the product problem.

What the Microsoft 365 Agents SDK is

A software development kit is a set of libraries, patterns, and developer-facing components that help engineers build on a platform without starting from raw plumbing. The Microsoft 365 Agents SDK is the Microsoft 365 framework for building full-stack, multi-channel agents.

Full-stack means the SDK is designed to support the end-to-end build of an agent, from the behavior and orchestration of the agent through to how the experience is exposed in user-facing surfaces. Multi-channel means the same agent logic can appear in multiple places instead of being rewritten separately for each channel.

The SDK is used inside the Microsoft 365 Agents Toolkit, the professional developer environment for building agents. Within that toolkit, developers choose between the Microsoft 365 Agents SDK and the Teams software development kit (Teams SDK), depending on whether the agent needs breadth across channels or depth inside Microsoft Teams.

Full-stack means the SDK supports the agent end to end, from behavior and orchestration through to user-facing surfaces.

Full-stack does not mean magic

The phrase full-stack can sound larger than it is. In this context, it does not mean the SDK designs the product, secures the data, or decides what the agent should be allowed to do. It means the developer is not handed only one isolated fragment, such as a message handler, and then left to assemble the rest from unrelated pieces.

A full-stack agent framework helps connect the parts that usually have to work together: the agent behavior, the user interaction model, the channel integration, the local development experience, and the path toward deployment. That matters because agents are not just prompts. They are applications with state, permissions, user expectations, and operational responsibilities.

The engineering benefit is consistency. When the same framework shapes the agent across its build path, teams are less likely to create one version of the agent for chat, another for a productivity surface, and a third for a later channel, each with slightly different behavior and maintenance needs.

⚠️

Do not confuse scope with governance. A full-stack SDK can simplify construction, but it does not replace identity, access control, data protection, review, or operational ownership.

Multi-channel means one agent, not many lookalikes

The main architectural idea is simple: keep the agent’s core behavior in one place and expose it through more than one supported surface. The user may experience the agent in chat, email, or another productivity context, but the team should not have to maintain a different brain for each one.

This does not mean every channel is identical. Channels have different interaction patterns, screen sizes, notification models, and user expectations. A Teams conversation is not the same as an email thread. The SDK helps with the multi-channel approach, but the product team still has to design channel-appropriate experiences.

A good multi-channel agent therefore separates durable behavior from surface-specific presentation. The durable behavior includes what the agent knows how to do and the rules it must follow. The presentation layer adapts that behavior to the place where the user is working.

A multi-channel agent keeps its core behavior in one place and appears across chat, email, Teams, and documents.

Agents SDK or Teams SDK: the real trade-off

Inside the Microsoft 365 Agents Toolkit, the choice between the Microsoft 365 Agents SDK and the Teams SDK is not a choice between modern and legacy, or serious and lightweight. It is a choice between breadth and depth.

Choose the Microsoft 365 Agents SDK when the agent needs to follow work across multiple Microsoft 365 surfaces. This is the better fit when the same capability should be available in more than one place and the team wants to avoid rebuilding the agent separately for each channel.

Choose the Teams SDK when the agent’s purpose is centered on Microsoft Teams and the team wants to lean deeply into the Teams experience. If the agent is fundamentally a Teams application, depth in that channel may matter more than broad reach.

Both options plug into the same professional development environment, including the same local testing playground and the same deployment pipelines. The decision is therefore not mainly about tooling comfort. It is about where the agent must show up to be useful.

Use the Microsoft 365 Agents SDK when the agent needs to appear across several work surfaces.
Use the Teams SDK when the agent’s entire value is concentrated inside Microsoft Teams.
Treat the choice as a product and architecture decision, not as a preference for one developer toolchain over another.

Choose the Agents SDK for reach across Microsoft 365 surfaces; choose the Teams SDK for a deep Teams-centered experience.

How the SDK fits into the developer workflow

The Microsoft 365 Agents SDK is not a standalone island. It sits inside the Microsoft 365 Agents Toolkit, which gives developers a professional environment for creating, testing, and deploying agents.

That shared tooling matters in real teams. A group can choose the SDK that fits the agent’s channel strategy without having to reinvent its local testing model or deployment process. The same toolkit path also makes it easier for organizations to standardize how agent projects are started and moved toward production.

This separation is useful: the toolkit is the workbench, while the SDK choice shapes what kind of agent is being built. The workbench stays familiar; the architecture changes based on whether the agent needs broad Microsoft 365 reach or a deep Teams experience.

The leadership decision: where should the agent live?

For leaders and architects, the important question is not which SDK sounds more capable. The important question is where the agent must be present for the business process to work naturally.

If the process crosses chat, messages, and productivity work, a single-channel agent may create friction even if it is technically impressive. Users will either ignore it when they are outside that channel or create informal workarounds. In that case, the Microsoft 365 Agents SDK is usually the more natural starting point.

If the process is truly centered on Microsoft Teams, such as a team workflow that begins, continues, and ends in Teams, then a Teams-first build may be cleaner. The team can focus on the interaction model that matters most instead of designing for channels that add little value.

The choice should also account for ownership. A multi-channel agent may touch more user journeys, which means more stakeholders, more testing contexts, and a stronger need for consistent policy. Breadth is powerful, but it is not free.

Where does the user first need the agent?
Where does the work continue after the first interaction?
Would separate channel-specific agents drift in behavior over time?
Does the team need broad availability or deep channel-specific integration?
Who owns the agent experience across every surface where it appears?

If the process crosses multiple surfaces, start with the Agents SDK; if it is Teams-centered, a Teams-first build is cleaner.

Build for consistency before expansion

Multi-channel reach is valuable only when the agent remains consistent. If the agent gives different answers, follows different rules, or exposes different capabilities in each channel without a clear reason, users will stop trusting it.

A practical pattern is to define the agent’s stable core first: what it is allowed to do, what it should refuse, what data it can use, and what outcomes it is responsible for. Then adapt that core to each channel’s interaction style.

The Microsoft 365 Agents SDK helps reduce the cost of reaching multiple surfaces, but it does not remove the need for product discipline. A well-built agent should feel familiar wherever it appears, while still respecting the shape and limits of each channel.

✅

Good reuse. Reuse the agent’s behavior and rules, but adapt the conversation shape to the channel where the user is working.

Key takeaways

The Microsoft 365 Agents SDK is for building full-stack, multi-channel agents across Microsoft 365 surfaces.
Full-stack means the SDK supports the broader build journey, not just one isolated technical component.
Multi-channel means the same agent logic can be exposed through several places where people work.
Inside the Microsoft 365 Agents Toolkit, the Microsoft 365 Agents SDK favors breadth, while the Teams SDK favors depth inside Microsoft Teams.
Both SDK choices use the same professional toolkit, local testing playground, and deployment pipelines.
The right choice depends on the user journey, the channel strategy, and the organization’s ability to govern a broader agent experience.

Glossary

Software development kit: A set of libraries, tools, and patterns that developers use to build applications on a platform.
Microsoft 365 Agents SDK: A Microsoft 365 software development kit for building full-stack, multi-channel agents.
Agent: A software assistant that can interact with users, apply logic, and help complete tasks.
Full-stack: An approach that covers the broader build path from underlying behavior to user-facing experience.
Multi-channel: A design in which the same agent capability can appear in more than one application or work surface.
Channel: A place where a user interacts with an agent, such as chat, email, or a productivity surface.
Microsoft 365 Agents Toolkit: The professional developer environment where builders can create, test, and deploy Microsoft 365 agents.
Teams SDK: The software development kit focused on building agent experiences specifically for Microsoft Teams.