Microsoft AI agent: choosing the right building block

This page is for marketing, operations and IT directors whose company already works in Microsoft 365 and who have to choose the building block for a Microsoft AI agent, then hold the fleet those blocks produce. It lets you decide the creation route that fits the need, the identity condition without which an agent does not exist for governance, and the approval rules to set once for the whole fleet.

It relies on the four permission levels and the seven families of agents from our overview of AI agents, which it does not redefine.

Three ways to make an agent at Microsoft, and which one to take

Four product names circulate in meetings, and nobody can say which covers what. At the time of writing, they break down as follows:

• Microsoft 365 Copilot: the suite's assistant, where you switch on or create an agent without building anything;
• Copilot Studio: the low-code workshop for building an agent and publishing it;
• Azure AI Foundry: the development platform for a bespoke agent;
• Agent 365: the control plane that inventories and governs the fleet.

The ecosystem does not offer "an agent": it offers a stack of building blocks, and choosing means placing your need on that stack. If the question arises further upstream, the families of tools are compared on the page devoted to AI agent platforms. Here, Microsoft is already in place: which block to take, and how to hold the fleet? The triptych identity, data, governance separates a demo from a system in production.

"Product" agent or "feature" agent: the question that decides before the tools

Before looking at a tool, ask a simple question: do you need a "product" agent (governed, versioned, operated as a service) or a "feature" agent (created quickly for an internal need)? The answer rules out half the options, because it is about what you will agree to maintain two years from now.

A second framing follows immediately, on ambition and acceptable risk:

• Assistant: advises, summarizes, helps produce, with a human in the loop at every step.
• Automation: runs a marked-out workflow (triggers, rules, approvals).
• Goal-oriented agent: chains steps, chooses actions, learns within a controlled framework (logs, action limits, emergency stop).

The useful boundary between a copilot and an agent reads as a ratio: the copilot augments one user, whereas a fleet of agents is steered several at a time by a single user, with more autonomy and therefore more controls. One last parameter, rarely raised: available skills. A team trained in AI tools makes low-code workable, not agent development sustainable.

Four routes, and what each one assumes at your site

The blocks are not ranked by power: they differ by operational workload. The right-hand column says who will live with the agent once the project's enthusiasm has faded.

A "feature" agent moves towards the first two rows, a "product" agent towards the last two. Choosing the row is the work of this page; walking it to the end is another exercise. Building the agent in Copilot Studio and publishing it belongs to the Copilot AI agent rollout, one block taken end to end. What follows stays at fleet level: what all the blocks share, and what makes them governable together.

Where the agent lives, and what it feeds on

An agent is described in three components:

• "what it knows": data and memory, which depend on your document base;
• "what it processes": reasoning, which also depends on that base;
• "what it can do": actions on applications, which depend on your permissions.

The consequence is blunt: if your sources are outdated, inconsistent or too broad, the agent becomes unpredictable, whatever the block.

Work surfaces decide adoption, not value

To maximize adoption, favour the surfaces where teams already spend time:

• Teams for execution and collaboration;
• email for communication-related actions;
• SharePoint for the document base.

The reduction in friction is the only serious argument in favour of an agent deployed inside the ecosystem rather than alongside it: nobody has to change tool to use it.

But adoption is not value, and that is where many fleets drift. The success criterion is not "the agent answers", but "the agent saves a cycle": a step, a round trip, a ticket. A heavily used agent that removes no step is a cost disguised as a success, and the registry will eventually flag it.

The document base: four verbs before opening access

SharePoint plays the role of source of truth: policies, procedures, offers, materials. An answer based on a controlled corpus is better than an over-permissive agent that mixes the public web with internal documents without rules. On time-bound data, regular updating avoids answers that are unsuitable but perfectly credible.

Four verbs frame that step, and they are set before any access is opened:

• Segment by population (marketing, sales, support) and by sensitivity (public, internal, confidential).
• Version the reference documents and make the update dates visible.
• Narrow the scope at the start (one site, one cluster, one BU) to stabilize the rules.
• Multiply verified sources when an answer has a legal or financial impact.

Identity: the condition that makes an agent exist

This is the point projects discover late, and it governs all the rest. An agent published on the suite's channels and registered under a directory identity appears automatically in the inventory of Agent 365. In other words: identity becomes a structuring condition of governance. It is not a formality settled after the pilot, it is the first link in a chain.

What registration triggers, in order

The chain reads in four stages, and none is skipped:

• the agent receives an identity of its own, distinct from that of the person who created it: it becomes a directory object;
• that identity brings it into the inventory, and therefore into the registry;
• the registry attaches to it an owner, a data scope and a list of authorized actions;
• the life cycle can then apply: you know since when it has existed, who answers for it and whether it is still in use.

The practical consequence is an entry rule, set once and no longer negotiated: an agent is not published as long as it carries no identity and no named owner. This is not a bureaucratic constraint: it is the only way to inherit automatically three mechanisms already in place for your users, rather than reinventing them agent by agent:

• access rights and their revocation in one move;
• the protection policies for sensitive data;
• the audit logs already used by security.

What an agent without an identity costs

An agent created outside that framework works perfectly. That is what makes it dangerous: it is useful, nobody flags it, and it appears in no view. Three moves become impossible for you:

• knowing which data it accesses;
• revoking its rights in one move;
• tying it to an incident when data leaves where it should not.

The day its creator changes team, it keeps running with nobody knowing how to stop it.

The test is simple in a review: ask for the list of active agents, and compare it with the agents the teams name from memory. The gap between the two lists is the share of the fleet that escapes identity, and it is that gap, not the total number of agents, that measures your exposure.

Holding a fleet: registry, map, life cycle

The fleet exists before you decide to govern it: the wave comes from the teams, not from the IT department. Without a control plane, you quickly lose the answer to three simple questions:

• which agents exist, and since when?
• what data do they access, and with which rights?
• what actions do they carry out, and who approved them?

The registry and the integration map

Management at scale rests on three axes, each of which the control plane equips differently:

The registry gives a full view of the agents (Microsoft, partners, company); the agent map visualizes their integrations. The map is often more telling than the list: it shows the agents touching the same source, those calling each other, and those nothing depends on any more.

The registry also serves to measure: performance, quality and impact analyses. That is where the difficulty of demonstrating the return on AI projects gets settled: 7% of EMEA companies create customer value through AI (ITPro, 2026), a benchmark noted in our AI statistics. A fleet where nobody knows which agents save a cycle will never produce that demonstration.

Three life-cycle rules, and taking control of what already exists

The life cycle applies by policy, not by hand. Three rules prevent "ghost agents" active with no business sponsor, invisible until the day one of them answers a customer on the basis of a document withdrawn eight months ago.

Then comes the real case: agents already exist, created without a framework. Taking control does not require stopping production and is done in this order:

• inventory what is registered, then survey the teams for the rest;
• assign an owner to every agent found;
• block those that find none: that is the only moment the discussion happens, and it is quick;
• put the others back through the entry rule: identity, owner, data scope, list of actions.

Whatever does not clear that step within a few days had no sponsor.

Who approves what, and what can be undone

Industrializing while keeping control requires explicit approval rules, which are not decided agent by agent: they are set once, by risk level, and each agent declares its own on entering the registry. On high-stakes processes (legal, finance, compliance), the human check is systematic; on low-risk tasks, you automate, provided you log and sample.

These four risk levels map onto the four permission levels of our AI agents overview: read-only at level 1, low and medium at the controlled writing of level 2, high at levels 3 and 4.

Separating reading from action

Good agent design separates "reading" (knowledge) from "action" (writing or execution). Actions must be minimal, traceable and reversible: that is what makes it possible to open rights gradually instead of granting everything so the pilot works. Least privilege then applies line by line, on users, data and tools.

That separation is a design principle, not a wiring recipe. The actual connection to applications (connectors, authentication, quotas, recovery on error) is a separate project, covered in AI agent integration with the information system. What you have to hold here is simpler: no agent receives a write right as long as its risk level is not declared and its rollback described.

The six-stage workflow

A robust agent does not go straight from request to execution: it passes through six stages, from trigger to post-action check, and two of them, the permissions pre-check and the rollback, are almost always missing from prototypes. That workflow is designed block by block, and the Copilot AI agent page details it. The fleet decides only one thing: no agent enters the registry without declaring where its approval and its rollback sit.

When the agent has to stop: reliability and incidents

A reliable agent is not the one that "always answers", it is the one that knows when to stop. Three reflexes characterize it:

• a clean failure if it finds no authorized source;
• an escalation to a human with full context (logs, attachments, sources);
• a kill switch that cuts it without cutting the suite.

Those rules, the metrics that make them verifiable and incident discipline are built agent by agent: the Copilot AI agent page details them. The fleet only requires that they exist before going to production.

Continue reading

Depending on your situation, the next page is not the same:

• The fleet is framed and the discussion moves to licences and full cost: permissions, indicators and total cost of ownership are covered on the AI agent for business.
• Your priority deployment surface is Teams: use cases, adoption and limits are set out on the Teams AI agent.
• Your working data does not live at Microsoft, or the two ecosystems coexist: multimodality and an agent catalogue are the subject of the Gemini AI agent.
• No block in the ecosystem covers your need: the end-to-end, vendor-independent method is the one to create an AI agent.

And if what your fleet lacks is the agents' document foundation, validated and up-to-date content, that is the task framed by content generation with a personalized AI.

FAQ on AI agents in the Microsoft ecosystem

How do you create an agent with Microsoft?

You create a Microsoft agent by first choosing between a "feature" agent, created quickly for an internal need, and a "product" agent, versioned and operated as a service. The first is created from Microsoft 365 Copilot, the second goes through Copilot Studio or Azure AI Foundry. In every case, start on a pilot scope and set the approval rules before opening access.

How do you integrate agents with Microsoft 365?

Agents integrate with Microsoft 365 through the surfaces where adoption is natural, Teams, email and SharePoint, before you wire actions to your applications. Directory identity and permissions govern access to data, auditing and entry into the inventory. Finally, plan usable logging to measure use and diagnose failures.

What are the differences with Copilot?

Microsoft 365 Copilot assists a user within their workflow: it helps to analyse, write, decide. An agent goes further: it chains steps and triggers actions within a permissions and governance framework, often specialized by domain. The more autonomy you grant, the more numerous the controls must be.

Copilot Studio or Azure AI Foundry: which to choose given your level of control and your skills?

Copilot Studio suits you when you are aiming at quick low-code creation, with integrations and controlled publishing on the suite's surfaces. Azure AI Foundry is called for when you need bespoke development and finer control over orchestration, operations and security. In both cases, the rules on sources, permissions and approval stay the same.

What is Agent 365 for and who should administer it on the company side?

Agent 365 is the fleet's unified control plane, at the time of writing: inventory, logging, auditing and supervision along the three axes of observability, governance and security. It holds whatever the creation tool. Administration belongs to the IT and security teams, with joint business responsibility for the indicators, the scope and the approval rules.

Which use cases should be avoided at the start?

At the start, avoid any irreversible action with no rollback: bulk writing, deletion, automatic external sending. Also set aside subjects with high legal or financial stakes as long as your time-bound data is not up to date, automations on unversioned reference bases, and overly general agents with broad access.

How do you frame an agent's data access and permissions without blocking adoption?

Framing rests on least privilege, widened gradually according to the pilot's results. Segment by role and by sensitivity, and keep committing answers for versioned reference bases. Keep human supervision on risky actions and automate reversible, auditable tasks: it is reversibility, not general caution, that lets you open up quickly.