The Microsoft Agent Ecosystem, Mapped

Newcomers to the Microsoft agent world hit a wall of names on day one: Copilot, Copilot Studio, Agent Builder, Foundry, an SDK or two, an Agent Store, several admin centers. It feels like a crowd. It is not — it is a tidy neighbourhood once you know the three streets it is organised along. This article draws that map so every product name has a place to sit.

1 · Three questions that place any agent tool

Any Microsoft agent tool you encounter is doing one of three jobs. Ask which:

• Build — “where was this agent made?” The workshop where an agent is created and given its instructions, knowledge, and tools.
• Run — “where does this agent do its work and meet people?” The place a user actually talks to the agent and where it takes action.
• Govern — “where is this agent seen, secured, and controlled?” The control plane above the other two. This is Agent 365.

The reason Agent 365 can govern agents from any workshop is exactly that it is a separate layer — it does not care how an agent was built or where it runs, only what it is allowed to be and do. Keep the three streets straight and the crowd of names resolves into a map.

2 · Where agents are built — four surfaces, low-code to pro-code

Microsoft offers a ladder of building tools, from “describe it in a sentence” to “write the code yourself.” Four rungs matter:

• Agent Builder — built into Microsoft 365 Copilot. A businessperson (a “maker”) describes an agent in natural language, or starts from a template, and Copilot builds it. The simplest possible on-ramp.
• Copilot Studio — a low-code tool for more sophisticated agents that connect to outside systems, call application programming interfaces (APIs, ways for software to call other software), and orchestrate multi-step workflows. It brings real engineering discipline: separate development, test, and production environments (called Application Lifecycle Management, or ALM), connector governance, and data-loss-prevention (DLP) policies set at the environment level.
• Azure AI Foundry — the professional, code-first platform where developers build agents with full control over models and orchestration.
• Microsoft 365 Agents SDK — a software development kit (SDK, a toolkit of code libraries) for building custom engine agents using whatever artificial-intelligence stack a developer prefers — Azure Foundry, Semantic Kernel, OpenAI Agents, LangChain, or a custom build — and still surfacing them in Microsoft 365 Copilot and Teams. It is deliberately model- and orchestrator-agnostic.

SharePoint can also produce simple declarative agents. The point is not to memorise all of them, but to see the shape: a ladder from “natural language” up to “full code,” all producing agents that land in the same registry.

3 · The key fork: declarative vs custom engine agents

Cutting across all those build tools is one distinction worth learning now, because it shapes governance later. Microsoft splits agents into two kinds by whose brain they use:

• Declarative agents. These reuse Copilot’s own model and orchestrator — its “brain” — and simply declare instructions, knowledge, and tools on top. Because they run on Copilot’s infrastructure, they automatically inherit its security, compliance, and responsible-AI guardrails. Agent Builder and SharePoint produce these; Copilot Studio can too.
• Custom engine agents. These bring their own model and orchestration — their own brain — built with the Microsoft 365 Agents SDK or Foundry. They are more powerful and flexible, but because they do not run on Copilot’s shared infrastructure, more of the security and governance has to be applied deliberately — which is exactly where Agent 365 earns its keep.

A useful one-liner: declarative agents borrow Copilot’s brain and inherit its guardrails; custom engine agents bring their own brain and need guardrails applied to them. This fork matters most when you actually build agents.

4 · Where agents run — and how people find them

Building an agent is only half of it; people have to be able to reach it. Most Microsoft agents surface inside the everyday apps people already use — Microsoft 365 Copilot, Microsoft Teams, SharePoint, and sometimes public websites. Two details are worth knowing:

• The Agent Store. Inside Microsoft 365 Copilot there is an Agent Store where members of an organisation discover and install agents — the way an app store works for phone apps. Makers publish agents into it (after admin approval), and users install them.
• Pinned Microsoft agents. Some agents, such as Researcher and Analyst, are pre-installed by Microsoft and pinned so everyone can find them.

The run surface matters for governance because it is where an agent actually touches data and takes action on a person’s behalf — which is why the control plane has to reach into these surfaces, not just the workshops where agents are made.

5 · Where agents are governed — Agent 365 above it all

Here is where our subject sits. Agent 365 is the governance layer over the whole map, operated mainly through the Microsoft 365 admin center (the part used for agents is often called the Copilot Control System). From there, administrators discover every agent, approve or block it, deploy it to people, watch what it does, and retire it. For agents built specifically in Copilot Studio, some additional governance — the environments, connectors, and DLP policies mentioned earlier — is managed in the Power Platform admin center, because that is where Copilot Studio’s building blocks live.

The single most important idea on this whole map: Agent 365 does not compete with the build or run tools — it sits above them. Whether an agent was made in a sentence or in ten thousand lines of code, and whether it runs in Teams or on a website, it lands in one registry to be observed, governed, and secured. That is what makes “one control plane, regardless of origin” more than a slogan.

6 · Glossary — every short-form term, spelled out

Agent Builder

A feature inside Microsoft 365 Copilot that lets a maker build a declarative agent from a natural-language description or a template.

Copilot Studio

A low-code tool for building more sophisticated agents that connect to external systems, with development/test/production environments, connector governance, and DLP policies.

Azure AI Foundry

Microsoft’s professional, code-first platform for building agents with full control over models and orchestration.

Microsoft 365 Agents SDK

A software development kit for building custom engine agents with any AI stack (Semantic Kernel, LangChain, OpenAI, Foundry) and surfacing them in Microsoft 365.

SDK (software development kit)

A toolkit of code libraries and tools that developers use to build software on a platform.

Maker

A businessperson or citizen developer who builds agents in low-code tools, as opposed to a professional developer writing code.

Declarative agent

An agent that reuses Copilot’s own model and orchestrator and just declares instructions, knowledge, and tools — inheriting Copilot’s guardrails.

Custom engine agent

An agent that brings its own model and orchestration rather than using Copilot’s, offering more power but needing governance applied deliberately.

Orchestrator

The part of an agent that plans and sequences steps — deciding which tool to call next. Declarative agents use Copilot’s; custom engine agents bring their own.

ALM (Application Lifecycle Management)

The practice of developing software across separate development, test, and production environments; Copilot Studio supports it.

Connector

A pre-built link that lets an agent reach an outside system; administrators govern which connectors agents may use.

DLP (data-loss prevention)

Policies that stop sensitive data from leaving where it should; in Copilot Studio these are set per environment.

Agent Store

The place inside Microsoft 365 Copilot where people discover and install agents, after admin approval.

Copilot Control System

The part of the Microsoft 365 admin center used to manage the lifecycle of Copilot agents — approve, deploy, block, and remove.

Power Platform admin center

The console where Copilot Studio’s environments, connectors, and DLP policies are managed.