The Agent Ecosystem Map — Agent 365: Foundations

The Microsoft agent landscape looks crowded until you sort it by job. Some tools are workshops where agents are made. Some are places where people meet and use agents. One layer sits above both to discover, secure, approve, observe, and retire agents. That layer is Agent 365. Once you can place each product name on this simple map, the rest of the ecosystem becomes much easier to reason about.

The three questions that locate any agent tool

Every agent tool in this ecosystem answers one of three questions: where is the agent built, where does it run, and where is it governed. Build is the workshop. Run is the surface where the agent meets people and systems. Govern is the control plane that sees agents across those workshops and surfaces.

This distinction matters because an enterprise agent is not just a piece of software. It has instructions, knowledge, tools, permissions, owners, users, logs, and risk. Those concerns do not all live in the same place. A maker may create an agent in a low-code tool, a user may invoke it in Microsoft Teams, and an administrator may approve or block it from the Microsoft 365 admin center.

Agent 365 belongs in the third category. It does not replace the places where agents are built, and it does not become the chat interface where people use them. It is the governance layer above those places.

📌

The map in one line. Build tools create agents, run surfaces expose them to people, and Agent 365 governs them across origins.

Every agent tool answers one of three questions: where is it built, where does it run, and where is it governed.

Where agents are built: from natural language to code

Microsoft provides several ways to build agents, arranged roughly from simplest to most programmable. The right tool depends on who is building, how much control they need, and what systems the agent must reach.

Agent Builder is built into Microsoft 365 Copilot. It lets a business maker describe an agent in natural language or start from a template. It is designed for the simplest class of agents, where the main job is to package instructions and knowledge in a form that people can use.

Copilot Studio is the low-code step up. It supports more capable agents that connect to external systems, call application programming interfaces, or APIs, and coordinate multi-step work. It also brings operational discipline: separate development, test, and production environments, application lifecycle management, or ALM, connector governance, and data loss prevention, or DLP, policies at the environment level.

Microsoft Foundry is the professional code-first platform. It is for developers who want deeper control over models, orchestration, evaluation, and integration. The Microsoft 365 Agents software development kit, or SDK, spans this professional end of the stack by letting developers build custom agents with their preferred artificial intelligence, or AI, framework and still bring those agents into Microsoft 365 experiences.

Use Agent Builder when a maker needs a fast, simple agent inside Microsoft 365 Copilot.
Use Copilot Studio when the agent needs low-code workflows, connectors, environments, and policy controls.
Use Microsoft Foundry when developers need code-first control over models and orchestration.
Use the Microsoft 365 Agents SDK when a custom agent built with a preferred AI stack must appear in Microsoft 365 Copilot or Teams.

Microsoft's build tools run from simplest to most programmable, chosen by who builds and how much control they need.

The important fork: declarative and custom engine agents

Across the build tools, there is a more important distinction than the tool name: whose reasoning engine does the agent use? Microsoft describes two broad kinds of agents.

A declarative agent reuses the model and orchestrator behind Microsoft 365 Copilot. The maker declares what the agent should know, what instructions it should follow, and which tools it can use. Because it runs on Copilot infrastructure, it inherits Copilot security, compliance, and responsible AI guardrails.

A custom engine agent brings its own model, orchestration, or execution logic. It may be built with Microsoft Foundry, the Microsoft 365 Agents SDK, Semantic Kernel, LangChain, OpenAI tooling, or a custom stack. This gives developers more freedom, but it also means governance must be applied more deliberately because the agent is not simply borrowing Copilot’s shared runtime.

The practical shorthand is useful: declarative agents borrow Copilot’s brain; custom engine agents bring their own.

⚠️

Do not govern them alike. A custom engine agent usually needs closer review because its model, tools, and orchestration may sit outside Copilot’s shared guardrails.

A declarative agent reuses Copilot's runtime and inherits its guardrails; a custom engine agent brings its own and must be governed deliberately.

Where agents run: the places people actually meet them

An agent becomes real to the organization when someone can use it. In the Microsoft ecosystem, agents most often surface in Microsoft 365 Copilot, Microsoft Teams, SharePoint, or a website. SharePoint can also produce simple declarative agents tied to content and collaboration scenarios.

Microsoft 365 Copilot includes an Agent Store where people in an organization can discover and install approved agents. The idea is similar to an application store: makers publish agents, administrators approve them according to policy, and users install the agents they are allowed to use.

Some Microsoft-provided agents are handled differently. Agents such as Researcher and Analyst can be pinned by Microsoft so that users can find them without the same discovery path as a custom internal agent.

The run surface is not a cosmetic detail. It affects which users can reach the agent, what data it may encounter, which actions it can take, and what signals are available for monitoring.

Where agents are governed: Agent 365 above the map

Agent 365 is the control plane for the agent estate. Administrators use it mainly through the Microsoft 365 admin center, including the area commonly described as the Copilot Control System. From there they can discover agents, review them, approve or block them, deploy them to users, monitor activity, and retire agents that should no longer be available.

This is why the layer model matters. A company may have agents created by a business maker in Agent Builder, a process owner in Copilot Studio, and a developer using the Microsoft 365 Agents SDK. Those agents may run in Copilot, Teams, SharePoint, or on a website. Agent 365 is intended to give administrators one governance view across that variety.

There is one important boundary. For agents built in Copilot Studio, some governance remains in the Power Platform admin center because Copilot Studio uses Power Platform building blocks. Environment setup, connector rules, and DLP policies are managed there. Agent 365 does not erase that responsibility; it sits above it and connects agent-level governance across the estate.

✅

The key boundary. Agent 365 governs agents; it does not become the tool that builds them or the surface where users chat with them.

What lands in the registry and why it matters

A governance layer needs an inventory. Without one, administrators are left chasing agents across separate tools, teams, and environments. Agent 365’s value depends on bringing agents into a common registry so they can be identified, owned, reviewed, secured, and eventually retired.

The registry is more than a list of names. It is where the organization begins to answer operational questions: who owns this agent, who can use it, what type of agent is it, what tools can it call, where does it run, and what risk does it introduce?

This inventory view is especially important as agents move beyond simple question answering. An agent that summarizes a document is one kind of risk. An agent that can call an external system, update a record, or act on behalf of a user is another. The registry gives those differences a place to be recorded and governed.

Ownership: who is accountable for the agent.
Origin: which build tool or development path produced it.
Type: whether it is declarative or custom engine.
Reach: where it runs and which users can access it.
Capability: what data, tools, connectors, or APIs it can use.
Lifecycle state: whether it is proposed, approved, deployed, monitored, or retired.

The decisions this map helps leaders make

The ecosystem map is not just a naming exercise. It helps leaders and practitioners make concrete choices without treating all agents as the same thing.

A business leader deciding how to encourage adoption should know which teams can safely use Agent Builder and which need Copilot Studio or professional development support. An enterprise architect should decide when a declarative agent is enough and when a custom engine agent is justified. A security leader should ask where guardrails are inherited and where they must be designed, tested, and monitored.

Administrators face a different set of decisions: which agents may enter the Agent Store, which should be pinned or promoted, which should be restricted to a group, and which should be blocked. Platform owners must also decide how Microsoft 365 admin center governance and Power Platform admin center governance divide the work, especially for Copilot Studio agents.

A good rule is to choose the simplest build surface that can meet the need, then apply governance based on the agent’s capabilities rather than the prestige of the tool used to build it.

📌

A practical rule. Govern by what the agent can access and do, not only by who built it or which tool produced it.

A quick placement test for any new name

When a new Microsoft agent product name appears, place it before trying to memorize it. Ask first whether it helps someone build an agent. If not, ask whether it is where a user runs or discovers an agent. If neither is true, it is probably part of governance, administration, identity, security, or observability.

This test keeps the ecosystem understandable as it grows. Agent Builder, Copilot Studio, Microsoft Foundry, and the Microsoft 365 Agents SDK belong mostly to build. Microsoft 365 Copilot, Teams, SharePoint, websites, and the Agent Store belong mostly to run and discovery. Agent 365, the Microsoft 365 admin center, and related policy surfaces belong to govern.

Some tools touch more than one layer, but each still has a center of gravity. Find that center, and the map stays usable.

Key takeaways

Every Microsoft agent tool can be placed by asking whether it builds, runs, or governs agents.
Agent 365 is the governance control plane; it does not replace build tools or user-facing run surfaces.
Agent Builder, Copilot Studio, Microsoft Foundry, and the Microsoft 365 Agents SDK form a ladder from simple creation to professional code-first development.
Declarative agents reuse Copilot’s model and orchestration, while custom engine agents bring their own model or orchestration.
Agents commonly run in Microsoft 365 Copilot, Teams, SharePoint, websites, or through discovery in the Agent Store.
Copilot Studio agents may require governance in both Agent 365 and the Power Platform admin center.

To place any new agent product, ask first whether it helps someone build; if not, it belongs to run or govern.

Glossary

Agent 365: Microsoft’s governance control plane for discovering, approving, securing, monitoring, and retiring agents across build and run surfaces.
Agent Builder: A feature inside Microsoft 365 Copilot that lets makers create simple declarative agents from natural-language prompts or templates.
Copilot Studio: Microsoft’s low-code tool for building agents that can use workflows, connectors, environments, and governance policies.
Microsoft Foundry: Microsoft’s code-first platform for developers who need more control over AI models, orchestration, evaluation, and integration.
Microsoft 365 Agents SDK: A software development kit that helps developers build custom engine agents with a preferred AI stack and surface them in Microsoft 365 experiences.
Declarative agent: An agent that reuses Microsoft 365 Copilot’s model and orchestration while adding declared instructions, knowledge, and tools.
Custom engine agent: An agent that brings its own model, orchestration, or execution logic rather than relying entirely on Copilot’s shared runtime.
Agent Store: The discovery and installation area inside Microsoft 365 Copilot where users can find approved agents for their organization.
Data loss prevention: A set of policies that controls how data can move between connectors, systems, and environments to reduce unintended exposure.