Holger Imbery - fieldnotes and insights

Multi-Agent Orchestration with Copilot Studio — Part 3: The Build 2026 Rebuild

Sat, 18 Jul 2026 00:00:00 +0000

Summary lede. This is the third of three articles in the multi-agent orchestration series. Where Parts 1 and 2 cover the released, generally available Copilot Studio — the classic model built on generative orchestration — Part 3 turns to the rebuilt experience Microsoft introduced at Build 2026. At Build 2026 (June 2–3) and in the “Meet the new Copilot Studio” post that followed on June 9, Microsoft shipped a rebuilt Copilot Studio: a streamlined four-surface agent model (Skills, Tools, Knowledge, Connected agents) plus a Memory surface, a new agentic orchestrator built on a coding-harness and CLI layer, a redesigned workflow designer, and a deeper convergence with Microsoft Foundry under a shared knowledge layer called Microsoft IQ. Parts 1 and 2 describe the classic model — the five surfaces, child agents, the four patterns — which still ships and is fully supported. Part 3 describes what replaces it as the default forward path, what is genuinely new, and what carries over unchanged.

About this series. This is Part 3 of three. Part 1 — Foundations establishes the vocabulary, when to split a single agent, the five configuration surfaces, the four orchestration patterns, and how MCP and A2A are configured. Part 2 — In Practice turns those decisions into four end-to-end scenarios, a starter MCP server inventory, and ten production anti-patterns. Parts 1 and 2 describe the released, generally available feature set — the “classic” Copilot Studio experience, built on generative orchestration, which is GA and fully supported. Part 3 — The Build 2026 Rebuild (this article) describes the new four-surface model (Skills, Memory, a new orchestrator); those features are in public preview and subject to change before general availability. Read Part 3 as forward-looking: surface names, behaviors, and availability may be adjusted before GA, so verify the current status before committing a production design to it.

Status, stated plainly. The new experience is in public preview. It is available in production environments worldwide, and Microsoft’s own post says it is “ready to create agents for production use.” Still, the same post includes an explicit correction: the features are in public preview, not generally available. The new and classic experiences coexist — you opt into the new one with “Try now” on the Copilot Studio homepage, and your classic agents keep working. Treat everything in this article as a preview unless noted, and re-check the status before committing a production design to it.

Update since Parts 1 & 2 were published. A few developments since those articles went out, re-verified against Microsoft Learn as of mid-July 2026. The Windows 365 for Agents MCP server is now generally available, giving an agent full operational control over a Windows 365 cloud PC — desktop interaction, browser automation, and semantic UI inspection — extending the Computer Use / computer-using-agent thread from Part 2’s IT-triage scenario. The classic experience remains fully supported, and nothing in the rebuild is deprecated, so Parts 1 and 2 remain the accurate reference for classic agents. And the two time-sensitive facts those articles turn on still hold: A2A reached general availability in April 2026, and CVE-2026-21520 (“ShareLeak,” CVSS 7.5) remains the relevant indirect-prompt-injection disclosure — patched in January 2026, publicly disclosed in April 2026 — with no newer CVE superseding it.

Why read this Read this if you read Parts 1 and 2, opened Copilot Studio, and found a different product than the one those articles described — four tabs instead of nine, “Skills” where you expected child agents, a “Memory” surface that wasn’t there before, and a chat that references Markdown files. Nothing in Parts 1 and 2 is wrong for the classic experience, but the vocabulary has moved. This article reconciles the two: it maps the classic five surfaces onto the new four-plus-Memory model, explains what “Skills” now means (and the naming trap that comes with it), and shows that the four orchestration patterns survive the change intact. Read it before you start a new build in the new experience, so you pick the right surface for each piece from the start.

1. What changed, in one paragraph

Copilot Studio used to present an agent as nine configuration tabs and a mental model of five surfaces — Instructions, Knowledge, Tools, Topics, Triggers — with child agents and connected agents as the two ways to compose with it. The rebuilt experience collapses that to four surfaces — Skills, Tools, Knowledge, Connected agents — plus a Memory surface in preview, driven by a new orchestrator that behaves much more like a coding agent than a dialog engine. “Skills” is the headline change: agent behavior is now authored as reusable Markdown that loads on demand, in the same SKILL.md style used by GitHub Copilot and Claude Code — and Copilot Studio can import those existing skills directly. Child agents, as a distinct surface, are absent from the new model; their two jobs are absorbed by Skills (factoring behavior into a single agent) and Connected agents (collaboration across agents). Underneath, Copilot Studio and Microsoft Foundry are converging on a single runtime and knowledge layer (Microsoft IQ), so a low-code Copilot Studio agent and a pro-code Foundry agent can act as peers.

The rest of this article unpacks each of those, with the classic-to-new mapping made explicit.

2. From nine tabs to four surfaces

The most visible change is the reduction from nine configuration tabs to four, with the essential configuration brought to the front. The new agent surfaces are:

Skills — define behaviors through structured instructions, authored as Markdown and loaded on demand. (This is new; see §3.)
Tools — connect the agent to external systems and actions: connectors, Power Automate flows, MCP servers, and now Work IQ MCP tools.
Knowledge — provide trusted context to guide decisions: SharePoint, Dataverse, files, Graph connectors, and so on. In the new experience, Microsoft IQ sources plug in here too — Work IQ (Microsoft 365 org data), Fabric IQ (Fabric business data and analytics), and Foundry IQ (preview), which ground the agent on enterprise knowledge bases indexed by Azure AI Search in Azure AI Foundry. (See §5.)
Connected agents — collaborate across agents to complete work (Copilot Studio agents, plus external agents over A2A, and Microsoft Foundry / Fabric / M365 Agents SDK agents in preview).

Plus, in preview, a fifth surface:

Memory (preview) — remember interactions, workflows, and context for improved results across sessions. (See §5.)

Mapping this back to the classic five surfaces from Part 1:

Classic surface (Parts 1–2)	Where it lives in the new model
Instructions	Largely subsumed by Skills — base instructions remain, but reusable behavior moves into load-on-demand markdown skills
Knowledge	Knowledge — unchanged in concept
Tools	Tools — unchanged in concept, now including Work IQ MCP tools
Topics	De-emphasized — the new orchestrator reduces the need for hand-authored topic trees; deterministic logic moves into workflows (see §6). Topics remain in the classic experience
Triggers	Still present for autonomous/event-driven runs; less prominent in the streamlined surface set
Child agents	Removed as a surface — folded into Skills (in-agent behavior) and Connected agents (cross-agent)
Connected agents	Connected agents — unchanged in concept
(new)	Memory (preview) — persistent cross-session understanding

The practical effect is that the new model pushes you toward two clean compositional choices — Skills for what one agent should know how to do, and Connected agents for handing work to another agent — instead of the older three-way split that included child agents.

3. Skills: behavior as load-on-demand markdown

In the rebuilt experience, Skills are “reusable instructions in Markdown that can load on demand for completing specific tasks,” and — importantly — you can “import skills you already have, including existing GitHub Copilot or Claude Code skills.” That single sentence is the most consequential change in the release.

What this actually is

A skill in this sense is the SKILL.md pattern: a Markdown file with light frontmatter (a name and a description of when to use it) and a Markdown body of instructions, examples, and guidelines. The orchestrator reads the descriptions and loads the full skill body only when a task needs it — progressive disclosure, rather than stuffing every rule into one always-on instruction block. This is the same convention that GitHub Copilot and Claude Code use for agent skills, and Copilot Studio now supports it natively, including the ability to import skills authored for those tools. You author a skill once, add it to multiple agents, and can export it as a Markdown file or package to share — the reusable-library model those coding tools already use.

Why it matters for everything in Parts 1 and 2

Two of the recurring lessons in the earlier articles were “keep the instruction block small” (Part 1’s 8,000-character limit) and “factor complexity into child agents.” Skills address both more directly:

The instruction-bloat problem. Instead of one monolithic instruction block bumping the 8,000-character ceiling, behavior is split into focused skills that load only when relevant. The “god agent” anti-pattern (Part 2, anti-pattern 1) gets a native remedy at the instruction layer, not only at the agent layer.
The child-agent use case. Part 1 used child agents to “factor complexity inside one parent.” That job is now a skill, not a sub-agent. You no longer create a child agent named “Validate Expense Code”; you write a validate-expense-code skill that loads when needed.

The naming trap — two different “skills”

Be careful: Copilot Studio now has two unrelated things called “skills.” ** **

Classic skills (still on Microsoft Learn) — a deployed Bot Framework / Microsoft 365 Agents SDK bot, registered as an agent via a manifest URL, used for complex multi-turn server-side scenarios. Pro-code, registered under Settings → Skills.
New skills (the rebuilt experience) — ** Markdown instruction modules** (SKILL.md style) that load on demand—Low-code, authored or imported as files.

These are different concepts with the same name. When you read “skills” in the documentation, check whether it means a manifest-registered bot or a Markdown behavior module. This article uses the new markdown format unless it says otherwise.

Design guidance for skills

The Part 1 guidance about tool descriptions transfers almost verbatim to skill descriptions: the description is what the orchestrator routes on. A skill described as “Expense logic” will be loaded unpredictably; a skill described as “Validates an expense code against the FY26 policy matrix; use when the user submits or questions an expense line” will load when it should. Keep each skill narrow, name it for one job, and write the description for the router, not for a human reader.

4. The new agentic orchestrator

The surface changes sit atop a new engine. Microsoft describes a new agentic orchestrator “built on a new coding harness and CLI layer,” with:

Stronger instruction adherence — agents follow their instructions and skills more reliably.
Long-horizon task execution and recursive task execution — the orchestrator can work through multi-step, dynamic problems that decompose into sub-tasks, rather than a single planning pass.
Large-content handling and rich file outputs — it can process large volumes of content and produce documents and data files, opening up document-generation and data scenarios that were awkward before.

For readers of Part 2, this matters in two concrete ways. First, the sequential pipeline and hierarchical patterns get easier, because the orchestrator itself now does long-horizon, recursive decomposition — some of what you previously assembled out of multiple agents and a Dataverse state table, the orchestrator can carry within a single agent’s run. Second, the “specialists are boring” principle still holds, but the threshold for when you need to split shifts: a single new-orchestrator agent can reliably do more before it hits the limits that forced decomposition in the classic model. The Part 1 signals for splitting (tool count, owners, conflicting knowledge, divergent SLAs) remain the right criteria; the tool-count number is just less likely to be the first wall you hit.

The harness-and-CLI framing is deliberate. It is the same shape as a modern coding agent — which is also why importing GitHub Copilot and Claude Code skills works at all: the runtime is built to consume that ecosystem’s conventions.

On the model side, the new experience lets you pick the orchestrator’s primary model directly: Claude Sonnet 5 and GPT-5.5 Chat are now generally available choices. Hence, the instruction-adherence gains come from both the new harness and a current-generation model underneath it.

5. Memory and Microsoft IQ

The new Memory surface (preview) — “remember interactions, workflows and context for improved results” — is the agent-facing edge of a larger platform layer.

Work IQ and its three layers

On Microsoft Learn, Work IQ (preview) is described as “the intelligence layer that grounds Microsoft 365 Copilot and your agents in real-time, shared context across your organization.” It is built on three layers:

Data — unifies signals from files, emails, meetings, chats, and business systems across Microsoft 365 to capture how work actually happens.
Memory — “builds persistent understanding of how people and teams work, enabling Agent 365–managed agents to stay aligned to priorities and remain consistent across tasks, apps, and sessions.” This is the layer behind the agent Memory surface.
Inference — brings together models, skills, and tools so agents can reason and act, using Work IQ MCP tools, under the Agent 365 control plane.

You add Work IQ to an agent as Work IQ MCP tools (Tools → Add tool → Model Context Protocol → e.g., Work IQ Mail, Work IQ Calendar, Work IQ Teams). It requires a Microsoft 365 Copilot license. Work IQ in Copilot Studio is preview-only today, with general availability “coming soon”; Microsoft’s documentation states that once Work IQ reaches GA, the Work IQ API transitions to a usage-based (consumptive) billing model — so that billing is not yet in effect. Governance runs through Agent 365 and the Microsoft 365 admin center (admins allow or block servers tenant-wide), with tool-call tracing in Microsoft Defender Advanced Hunting.

Microsoft IQ — the umbrella

Work IQ is one of three “IQ” layers under the broader Microsoft IQ banner introduced around Build 2026. In the new Copilot Studio experience, Microsoft Learn documents Microsoft IQ as a context layer with three sources: Work IQ (Microsoft 365 org data — emails, chats, files, calendar, people — routed through the Agent 365 MCP gateway), Fabric IQ (business data and analytics in Microsoft Fabric), and Foundry IQ (preview), which grounds the agent on enterprise knowledge bases indexed by Azure AI Search in Azure AI Foundry. Turning on a Microsoft IQ source gives the agent both read access (knowledge) and actions (tools), always within the signed-in user’s permissions. Both Copilot Studio and Foundry draw on the same Microsoft IQ layer, which is part of what enables the convergence in §7. (Some Build 2026 community write-ups group the family differently — e.g., Work IQ / Foundry IQ / Web IQ; the Copilot Studio documentation itself lists Work IQ / Fabric IQ / Foundry IQ.)

How Memory changes the hierarchical pattern

Part 2’s employee-onboarding scenario leaned on a Dataverse OnboardingCase table because “if the process outlives the conversation, so should the state.” Memory does not replace that — durable, queryable business state still belongs in Dataverse — but it changes what you have to encode by hand. Memory carries understanding of how people and teams work across sessions, so the agent retains continuity (priorities, prior interactions) without you modeling every bit of it as a table column. The rule of thumb: structured process state → Dataverse; learned context and continuity → Memory.

6. The new workflow designer

Part 2 built its pipeline and fan-out scenarios on agent flows. The rebuilt experience replaces that with a new workflow designer: a single, unified visual canvas with node-by-node testing and robust versioning, intended to combine deterministic steps with agent intelligence in one place.

The pieces that matter for the orchestration patterns:

Agent nodes — call an existing agent directly inside a workflow, so you get deterministic workflow execution for the predictable parts and hand off to an agent for the open-ended parts. This is the cleanest expression yet of Part 2’s “structured where needed, adaptive where valuable.”
MCP servers in workflows (preview) — workflows can call MCP-server tools directly, staying within Microsoft security, permission, and compliance boundaries.
AI-powered actions — classification, content generation, and decision-support actions drop into a workflow as nodes, alongside a Microsoft 365 Copilot action node (send a prompt to Microsoft 365 Copilot or a specific agent) and human review/approval actions.

In practice, the four patterns from Part 2 now have a more direct home:

Router-worker → a workflow that classifies (classification action) and routes to agent nodes.
Sequential pipeline → a workflow with ordered nodes, each an agent node or AI action, with human-review nodes at decision points.
Parallel fan-out / fan-in → parallel branches of agent nodes joined by an aggregation step.
Hierarchical → a supervisor workflow that invokes agent nodes and persists durable state in Dataverse, now with Memory carrying cross-session continuity.

The patterns did not change. The surface you build them on did.

7. Foundry and Copilot Studio converge

The strategic frame from Build 2026 is that Microsoft Foundry and Copilot Studio are two front doors over one agent runtime — Foundry, the pro-code platform (Python/.NET, SDKs, managed runtime); Copilot Studio, the low-code platform (visual designer, same governance and protocols underneath). They share three things:

The A2A protocol, so a Foundry agent and a Copilot Studio agent can talk to each other as peers (exactly the cross-platform case Part 1 introduced A2A for).
The Microsoft IQ knowledge layer (Work IQ, Foundry IQ, Web IQ).
The Microsoft Agent Framework (MAF) — the unification of Semantic Kernel and AutoGen into one agent harness — which can host agents that either front door builds.

For a platform team, the takeaway is the one Part 1 hinted at and this release makes literal: standardize on the protocol and the knowledge layer, not the build tool. Let pro-code teams use Foundry and low-code teams use Copilot Studio, knowing the agents interoperate over A2A and share Microsoft IQ. The multi-agent architecture you designed in Parts 1 and 2 does not need to be re-decided for each tool; it is decided once at the protocol and knowledge layers.

A sourcing note: The new-experience surfaces, Skills-as-markdown, the new orchestrator, the workflow designer, and Work IQ/Memory are documented on first-party Microsoft sources (the Copilot Studio Blog and Microsoft Learn). The broader Foundry⇄Copilot Studio convergence details — Foundry IQ, Web IQ, and the Microsoft Agent Framework’s role — are drawn from Build 2026 engineering analysis, citing Microsoft DevBlogs and Learn; treat the specific convergence mechanics as directionally confirmed and verify the parts that matter to your design. Since first drafting, two of those pieces firmed up: Microsoft IQ and Foundry IQ now have their own Microsoft Learn pages (Microsoft IQ overview for agents (preview) and Connect to Foundry IQ from an agent (preview)), which document Microsoft IQ’s sources as Work IQ, Fabric IQ, and Foundry IQ — so the Web IQ grouping and the Microsoft Agent Framework’s exact role are the parts that still rest on the community analysis.

8. What to do now

The new experience is a preview and coexists with the classic, which makes the right posture straightforward:

New builds you intend to keep: start in the new experience and the four-surface model. Author behavior as Skills (narrow, well-described markdown), use Connected agents for cross-agent work, reserve Tools/Knowledge for actions and context, and turn on Memory where cross-session continuity helps. Build orchestration in the new workflow designer with agent nodes.
Existing classic agents: leave them. They keep working, and Parts 1 and 2 remain the accurate reference for them. Migrate when you have a reason — a redesign, a new requirement, or the new orchestrator’s reliability gains — not reflexively.
Skills you already have for GitHub Copilot or Claude Code: you can import them, which makes the new model a low-friction on-ramp if your teams already author SKILL.md files.
Governance: the Part 2 disciplines do not change — Entra Agent ID per agent, least privilege, audit through Purview/Defender, idempotency on writes, structured contracts. Work IQ and the new tools route through Agent 365 governance in the Microsoft 365 admin center; fold that into the same review process.
Watch the status. This is preview. Reconfirm GA timing and any surface renames before you bet on a production rollout on the new model, and keep classic as the fallback until the new experience reaches GA for the capabilities you depend on.

Conclusion

Parts 1 and 2 settled the architecture of multi-agent systems in Copilot Studio and showed it in execution. Part 3 is the reminder that the platform underneath an architecture moves, and that the durable parts are the ideas, not the tabs. The Build 2026 rebuild changes the surfaces — Skills instead of sprawling instructions and child agents, a Memory surface, a new orchestrator, a new workflow designer — but it does not change the load-bearing decisions: narrow agents with clear ownership, behavior factored into small, well-described units, structured contracts between components, state that outlives the conversation, and least-privilege governance. Skills are the new home for “factor the complexity”; Connected agents and A2A are still how agents collaborate; the four patterns still cover the work. The names on the tabs changed. The discipline did not.

Sources

Microsoft Copilot Studio Blog — Meet the new Copilot Studio: rebuilt for more complex, multi-step work (June 9, 2026) — four-surface model, nine-to-four tabs, new agentic orchestrator, Skills as markdown (import GitHub Copilot / Claude Code skills), new workflow designer with agent nodes and MCP servers; public preview, coexisting with classic
Microsoft Learn — Work IQ MCP overview (preview) — Work IQ’s Data / Memory / Inference layers, Work IQ MCP tools, Agent 365 governance; Work IQ is in preview with GA “coming soon” and usage-based Work IQ API billing taking effect at GA
Microsoft Learn — Microsoft IQ overview for agents (preview) — Microsoft IQ as a context layer with three sources (Work IQ, Fabric IQ, Foundry IQ (preview)); see also Connect to Foundry IQ from an agent (preview) and Turn on Microsoft IQ for an agent (preview)
Microsoft Learn — What’s new in Copilot Studio — the new agent experience as “Production-ready preview” (June 2026); Windows 365 for Agents MCP server (GA); Foundry IQ knowledge source (preview); Claude Sonnet 5 / GPT-5.5 Chat primary models (GA); workflow nodes (Microsoft 365 Copilot node, prompt node, classification); Computer Use GA (May 2026); A2A GA (April 2026)
Microsoft Copilot Studio Blog — What’s new in Copilot Studio: May 2026 — redesigned workflows experience, agent nodes, AI-powered actions
Microsoft Learn — Use skills in Copilot Studio and Configure skills — the classic (manifest-registered) meaning of “skills,” for disambiguation
GitHub Docs — Adding agent skills for GitHub Copilot and Custom skills (Copilot SDK) — the SKILL.md Markdown skill format Copilot Studio now imports
Redmond Magazine — Microsoft Unveils Redesigned Copilot Studio for Complex AI Agent Workflows (June 9, 2026) — independent coverage of the rebuild
Build 2026 engineering analysis (community, citing Microsoft DevBlogs/Learn) — Microsoft Foundry & Copilot Studio at Build 2026 — one-runtime / two-front-doors convergence, Microsoft IQ (Work IQ / Foundry IQ / Web IQ), Microsoft Agent Framework; treat convergence mechanics as directionally confirmed
Parts 1 and 2 of this series — the classic five-surface model and the four orchestration patterns this article maps forward

Multi-Agent Orchestration with Copilot Studio — Part 2: In Practice

Sat, 11 Jul 2026 00:00:00 +0000

Summary lede. This is the second of three articles on multi-agent orchestration in Microsoft Copilot Studio. Part 1 settled the architecture: when to split a single agent, what a Copilot Studio agent is composed of, which orchestration patterns exist, and how the Model Context Protocol (MCP) and Agent2Agent (A2A) protocol keep the system composable. Part 2 — In Practice — takes those decisions and works through what they look like in production. Four end-to-end scenarios, each built on a different orchestration pattern, show how the architectural pieces fit together. A starter MCP server inventory makes the platform team’s role explicit. The article closes with ten anti-patterns from real deployments and the corrections that teams have actually applied.

About this series. This is Part 2 of three. Part 1 — Foundations establishes the vocabulary, when to split a single agent, the five configuration surfaces, the four orchestration patterns, and how MCP and A2A are configured. Part 2 — In Practice (this article) turns those decisions into four end-to-end scenarios, a starter MCP server inventory, and ten production anti-patterns. Parts 1 and 2 describe the released, generally available feature set — the “classic” Copilot Studio experience, built on generative orchestration, which is GA and fully supported. Part 3 — The Build 2026 Rebuild describes the new four-surface model (Skills, Memory, a new orchestrator); those features are in public preview and subject to change before general availability, so treat Part 3 as forward-looking and re-check status before relying on it.

Every scenario uses features documented on Microsoft Learn and either generally available or in public preview as of mid-2026: connected agents, autonomous triggers, agent flows with parallel branches and approval gates, Dataverse as a state store, MCP integration with Streamable transport, and Purview audit logging. Where a capability is in preview (for example, connecting to Microsoft Foundry, Fabric, or Microsoft 365 Agents SDK agents), this article says so. The scenarios pair with named, published case studies — T-Mobile, Nexi Group, Dunaway, Holland America Line, Signetic, Singapore Civil Defense Force, La Trobe University — whose architectural shape matches the patterns described.

Capability status at publication Two capabilities directly reinforce these scenarios. A2A connections are generally available, so cross-platform delegation is not a preview dependency. Computer Use (computer-using agents) is generally available — the CUA extension mentioned in Scenario 1 is a shipping capability, with embedding into multi-step workflows in preview. A redesigned Workflows experience (early release) introduces a unified visual canvas with agent nodes that drop existing agents into a flow, plus AI-powered actions for classification and content generation; asynchronous responses (preview) let agent-flow steps exceed the two-minute limit, which the onboarding scenario benefits from. And per-agent Microsoft Entra agent identities can be auto-created (preview), which is the concrete mechanism behind the “Entra Agent ID per agent” recommendation in the anti-patterns section.

Why read this Read this if Part 1 left you convinced that multi-agent orchestration is the right response to scope drift, and you now need to see four working shapes. The four scenarios — IT incident triage, contract review, field service dispatch, employee onboarding — are not picked for variety; they are picked because they map cleanly onto the four orchestration patterns introduced in Part 1, and because each exposes a different production failure mode that teams are most likely to encounter. Read it if you have ever drawn a multi-agent architecture on a whiteboard, sent it to a senior maker, and watched them rebuild it in a way you did not expect. The MCP inventory section exists to answer the most common follow-up question — “okay, but who owns what?” — with a starting catalog. The anti-patterns section exists to answer the second-most-common follow-up — “what is most likely to bite us first?” — with ten patterns that recur often enough to be predictable.

Read Part 1 if you need the vocabulary; read Part 2 if you have the vocabulary and need the working examples. Each scenario is small enough to read in one sitting and concrete enough to reproduce in your own tenant. The point is not that any of these scenarios is the right one for your organization — the point is that the patterns underneath them are.

1. The four scenarios and what they exercise

Four scenarios appear below. They are deliberately ordered by complexity, from the simplest pattern (router-worker) to the most demanding (hierarchical with persistent state). Each builds on the surfaces introduced in Part 1 — instructions, knowledge, tools, topics, triggers — and uses one of the four orchestration patterns.

Scenario	Pattern	What it exercises
IT incident triage	Router-worker	Classification, delegation, structured outputs between agents
Contract review	Parallel fan-out / fan-in	Concurrent specialists, scoped knowledge, merged outputs
Field service dispatch	Router-worker with autonomous trigger	Event-driven autonomy, bounded decision trees, no user in the loop
Employee onboarding	Hierarchical with persistent state	Long-running supervision, Dataverse as state store, SLA monitoring

The scenarios are sized to be read end to end. Each one names the agents, provides instructions, walks through the expected runtime behavior, and points to a published case study whose architectural shape matches. The published shape — not the exact numbers — is the part to import.

2. Scenario one — IT incident triage (router-worker)

The first scenario takes a concrete, widespread problem — tier-one IT service desk volume — and shows how a multi-agent design resolves it using only features available in Copilot Studio today.

The problem

A large share of tier-one service desk tickets are mechanical: password resets, VPN issues, access requests, known application errors. In many IT organizations, this mechanical work accounts for a substantial fraction of the total ticket volume. Each of these tickets, when routed to a human analyst, consumes several minutes — read the ticket, look up the user, open the runbook, apply the fix, update the record.

The pattern is tedious for analysts and slow for users. It is also unnecessary: the runbooks already exist, the ticketing system already has APIs, and the retrieval work is well inside the capability of current language models.

The design

Three agents, with clear responsibilities.

Triage Orchestrator (user-facing). Classifies the incoming ticket into one of a small set of categories, delegates to the appropriate specialist, and returns the response to the user.

Runbook Specialist (connected agent). Retrieves the matching runbook from the IT knowledge base (SharePoint) and returns resolution steps or a “not found” result.

Ticket Writer (connected agent). Writes outcomes back to the ticketing system (ServiceNow, via the existing connector). Idempotent — retries do not create duplicates.

The split is deliberate. The Runbook Specialist is read-only; it never writes. The Ticket Writer writes but does not reason about runbooks. The Orchestrator owns the conversation and the classification but has no direct access to connectors.

Agent configurations

Triage Orchestrator — instructions:

You are the IT service desk triage agent. When a user
describes a technical problem; your job is to classify it
And route it to the correct specialist.

Classify the request into exactly one of:
  password_reset, vpn, hardware, application, other

Then:
  1. Call RunbookSpecialist with the classification and the
     user's original message.
  2. If RunbookSpecialist returns resolution_steps, present
     the steps to the user in a numbered list and ask if
     they want the ticket closed as resolved.
  3. If the user confirms, call TicketWriter with
     status="resolved" and the applied steps.
  4. If RunbookSpecialist returns no match, call
     TicketWriter with status="routed" and
     assignment_group derived from classification.

Never attempt to resolve a problem yourself.
Never write to the ticketing system directly.
Never mention specialist agents to the user.

Runbook Specialist — instructions:

You look up runbooks from the internal IT knowledge base
and return resolution steps.

Inputs:
  classification (string)
  problem_statement (string)

Behavior:
  Search the IT knowledge base scoped to the given
  classification. Return the single best-matching runbook.

Output (structured):
  { runbook_id: string | null,
    resolution_steps: string[] | null,
    confidence: number }

You do not create, update, or delete tickets.
You do not reason about user intent beyond runbook matching.

Knowledge source: a specific SharePoint library, IT Knowledge Base / Runbooks. Nothing else.

Ticket Writer — instructions:

You write outcomes to the ticketing system.

Inputs:
  ticket_id (string)
  status (enum: "resolved", "routed", "escalated")
  applied_steps (string[], optional)
  assignment_group (string, optional)
  idempotency_key (string)

Behavior:
  Call the ServiceNow Update Incident action with the
  mapped fields. Use idempotency_key to deduplicate.

Output (structured):
  { ok: boolean, ticket_url: string }

You do not reason about whether the status is correct.
You do not retrieve runbooks.

Tools: the ServiceNow connector’s Update Incident action. Nothing else.

Orchestration pattern

Router-worker. The Orchestrator routes; specialists execute. No parallelism, no hierarchy, no callbacks from specialists to the Orchestrator.

Expected runtime behavior

A user writes: “I can’t connect to the VPN from home since this morning.”

The Orchestrator classifies the request as vpn.
It calls the Runbook Specialist with {classification: "vpn", problem_statement: "..."}.
The Runbook Specialist searches the runbook library, finds a match, returns {runbook_id: "RB-0187", resolution_steps: ["Verify your network...", "Re-register the VPN client...", ...], confidence: 0.91}.
The Orchestrator presents the steps to the user.
The user replies that the steps worked.
The Orchestrator calls the Ticket Writer with status: "resolved".
The Ticket Writer updates ServiceNow and returns {ok: true, ticket_url: "..."}.

If the Runbook Specialist had returned no match, the Orchestrator would have called the Ticket Writer with status: "routed" and an assignment group derived from the classification.

Expected outcomes

The scenario mirrors the shape of several published Copilot Studio case studies. T-Mobile equipped customer service representatives with a Power Apps + Copilot Studio agent that provides accurate device information and improves customer experiences. Nexi Group modernized card-service customer support with Copilot Studio, with the explicit outcome of reduced contact-center workload. A1 Inteligência em Viagens used Power Automate and Copilot Studio to boost team efficiency and customer experience.

The exact numbers depend on ticket mix and runbook quality, but the shape is consistent across published reports: a meaningful share of tier-one volume auto-resolves, a larger share auto-routes with enriched context, and escalation volume drops.

What this scenario makes obvious

The value of the split is not the number of agents. It is the clarity of ownership. When the knowledge base team updates a runbook, only the Runbook Specialist is affected. When the ticketing team rotates a credential, only the Ticket Writer is affected. When the user experience changes, only the Orchestrator is affected. Each change is small and independent, which is what allows the overall system to be maintained over time.

The extensions to consider once the base is working: add an autonomous trigger (a Dataverse row-change event that fires when a new ticket is written to a queue table) so the Orchestrator runs on new tickets, not only when a user chats. Replace the ServiceNow connector with an MCP server to share ticketing tools across multiple agents in your tenant. Add a Computer-Using Agent (CUA) specialist — now generally available in Copilot Studio (May 2026) — for the narrow set of cases where the fix requires clicking through a legacy admin UI without an API.

3. Scenario two — Contract review pipeline (parallel fan-out)

The second scenario exercises a different orchestration pattern — parallel fan-out — and a different kind of specialist agent. Contract review is a good test because the work splits cleanly across independent review domains, each domain has its own policy library, and the outcome is a merged memo rather than a single-agent response.

The problem

Inbound vendor contracts typically pass through three gates before signature: legal review (indemnity, liability cap, governing law, dispute resolution), finance review (payment terms, auto-renewal clauses, price escalators), and risk review (data processing, subprocessors, breach notification, subcontracting). Each review is conducted by email serially, and the combined cycle frequently spans two weeks for contracts that are not particularly complex.

The serial nature is the problem. Each reviewer waits for the previous one. Each reviewer reads the full contract, even though their concerns are narrow. The end state — signature — is delayed by the sum of the waits, not the sum of the work.

The design

Five agents, one parallel step.

Intake Orchestrator (user-facing). Receives the contract PDF, extracts clauses into a structured clause map, triggers the review fan-out, composes the final memo.

Clause Extractor (tool, not a separate agent). A PDF extraction action backed by an MCP server or Power Automate flow. Returns clauses as a structured list.

Legal Reviewer (connected agent). Reviews the clause map against a legal policy library. Returns legal issues with severity and citations.

Finance Reviewer (connected agent). Reviews the clause map against finance policy. Returns finance issues with severity and citations.

Risk Reviewer (connected agent). Reviews the clause map against risk and data-protection policy. Returns risk issues with severity and citations.

The three Reviewers run in parallel. Each has a narrow, owned knowledge source. None of them depends on the others’ output.

Agent configurations

Intake Orchestrator — instructions:

You own the contract review process.

When a user uploads a contract:
  1. Call the Clause Extractor to get a structured clause
     map from the document.
  2. In parallel, call LegalReviewer, FinanceReviewer, and
     RiskReviewer with the full clause map.
  3. When all three return, aggregate findings into a single
     review memo organized by severity.
  4. Present the memo to the user with the contract
     reference, the number of issues found, and a link to
     the full findings.

Do not perform legal, financial, or risk analysis yourself.
Do not reformulate reviewer findings; present them verbatim.

Legal Reviewer — instructions:

You review contracts for legal risk.

Inputs:
  clause_map (structured list of clauses with text and type)

Behavior:
  Check each clause against the Legal Policy library.
  Flag issues only where the clause conflicts with policy
  or is missing from a required category.

Output (structured):
  { issues: [{ clause_type: string,
               severity: "high" | "medium" | "low",
               citation: string,
               suggested_redline: string }] }

Knowledge source: SharePoint "Legal Policy Library" only.
You do not review payment terms, pricing, or data
processing — those belong to Finance and Risk Reviewers.

Finance Reviewer and Risk Reviewer follow the same shape, each scoped to its own policy library.

Orchestration pattern

Parallel fan-out / fan-in. The Intake Orchestrator fires three calls at once and joins when all three return. In Copilot Studio, this is typically built as an agent flow with parallel branches — one branch per reviewer — followed by an aggregation step. (In the redesigned Workflows experience now in early release, those reviewer agents can be dropped onto the canvas as agent nodes.)

Human-in-the-loop

Copilot Studio agent flows support approval gates. In this design, the memo is delivered to a human reviewer (usually the deal owner or general counsel) who decides what to act on. The system does not automatically redline the contract; it surfaces issues and suggests redlines for human judgment.

This is the right default for regulated workflows. The published case study from Dunaway — a firm that uses Copilot Studio for city-code research — is explicit that the value of the agent is surfacing accurate information quickly, with the compliance professional retaining decision authority.

Expected runtime behavior

A user uploads a vendor agreement to the Intake Orchestrator.

The Orchestrator calls the Clause Extractor, which returns {clauses: [{type: "indemnity", text: "..."}, {type: "payment_terms", text: "..."}, ...]}.
The Orchestrator triggers three parallel branches:
- Legal Reviewer returns two issues (one high, one medium).
- Finance Reviewer returns one issue (medium: auto-renewal without notification).
- Risk Reviewer returns three issues (one high: subprocessor not listed; two medium).
The Orchestrator aggregates the six issues into a memo organized by severity.
The user receives the memo and decides what to negotiate.

The time from upload to memo is effectively the slowest of the three parallel branches plus the extractor and the aggregator — in practice, single-digit minutes, versus single-digit business days in the serial model.

What makes this work reliably

Scoped knowledge. Each Reviewer’s knowledge source is its own policy library and nothing else. Cross-contamination — a Legal Reviewer surfacing finance concerns — produces noisy memos and erodes trust. The narrower the library, the sharper the output.

Structured outputs. Every reviewer returns the same issue shape. The aggregator does not have to parse three different prose styles.

Citations. Every issue includes a citation back to the policy passage that grounds it. Reviewers without citations are not trusted by their human counterparts, and correctly so. (Bear in mind Part 1’s caveat: citations are not always preserved when outputs pass back from a connected agent, so carry the citation explicitly as a field in the structured output rather than relying on the platform to thread it through.)

Explicit severity. Three levels (high, medium, low), defined in each reviewer’s instructions. The aggregator can sort consistently across reviewers.

What to watch out for

Partial failure. If the Finance Reviewer times out, what does the memo say? Decide before you build: a “partial review” memo that notes the missing section is more useful than a failed run.

Policy drift. The quality of the reviewers depends on the currency of the policy. Assign ownership of each policy library to a named team and review quarterly.

Scope creep. It is tempting, once the Legal Reviewer works, to add “intellectual property” and “export control” to its scope. Resist. New domains are new reviewers.

Two published case studies anchor this shape. Dunaway transformed compliance workflows with a conversational agent that delivers instant, accurate regulatory answers from scoped knowledge — the scoping makes the answers trustworthy. Signetic uses Power Platform and Copilot Studio across healthcare operational workflows, including review-style patterns that merge multiple specialist inputs into operational decisions. Neither describes this pipeline exactly, but the architectural pattern — bounded specialists over scoped knowledge, merged by an orchestrator — is what both rely on.

4. Scenario three — Field service dispatch (autonomous trigger)

The third scenario exercises an autonomous trigger — the system reacts to an event from the field, not to a user typing into a chat window. This is where Copilot Studio’s March 2025 autonomous-agents GA materially changes what is buildable.

The problem

A field technician arrives at a customer site to service equipment and finds that a required part is missing from the van stock. The resolution today is a phone call. The technician calls dispatch. Dispatch puts the customer call on hold, checks inventory in SAP, calls a nearby warehouse, reschedules the appointment in Dynamics 365 Field Service, calls the customer back, and notifies the technician. The technician waits through all of it — often 30 to 45 minutes of paid idle time, per incident, multiplied by however many incidents happen that day.

The problem has obvious parts that should be automatic: inventory lookup, rescheduling, and customer notification. None of it is novel; the delay is the cost of humans doing mechanical work.

The design

Four agents. Three are called on-demand; one is autonomous.

Dispatch Orchestrator (autonomous). Triggered by an event from the field app — “technician reports missing part.” Drives the resolution. In Copilot Studio, this is implemented as a Dataverse row-change trigger: the field app writes a row to a FieldIncident table, and the trigger wakes the agent. Where the source system does not write directly to Dataverse, a Power Automate cloud flow subscribes to the source and writes to Dataverse on its behalf.

Inventory Specialist (connected agent). Queries SAP for part availability at the current site and at nearby warehouses.

Scheduler Specialist (connected agent). Proposes and books appointment slots in Dynamics 365 Field Service.

Notification Specialist (connected agent). Sends an SMS and an email to the customer and a Teams message to the technician.

The Dispatch Orchestrator does almost no reasoning about parts, scheduling, or customer preference. Its job is to call the three specialists in the correct order and handle the cases.

Agent configurations

Dispatch Orchestrator — instructions (autonomous):

You run automatically when the field app emits a
"missing_part" event (written to the FieldIncident table).

Event payload includes:
  technician_id, customer_site_id, part_number,
  appointment_id, current_time

Behavior:
  1. Call InventorySpecialist with part_number and
     customer_site_id. You get back either:
     - available_locally: true, eta_minutes
     - available_nearby: true, warehouse_id,
       eta_minutes
     - available: false, earliest_date

  2. If available_locally within 30 minutes:
       Call NotificationSpecialist with mode="wait" and
       eta_minutes. Exit.

  3. If available_nearby and eta_minutes <= 120:
       Call NotificationSpecialist with mode="delay".
       Exit.

  4. Otherwise:
       Call SchedulerSpecialist to propose a new
       appointment at or after earliest_date.
       Call NotificationSpecialist with mode="reschedule"
       and the new appointment.
       Exit.

You never book inventory or rearrange stock yourself.
You never modify appointments directly.

Inventory Specialist — instructions:

You check SAP inventory for parts.

Inputs:
  part_number (string)
  site_id (string)

Behavior:
  Query the SAP connector for stock at the given site and
  at warehouses within the configured proximity radius.

Output (structured):
  { available_locally: bool, eta_minutes: number?,
    available_nearby: bool, warehouse_id: string?,
    available: bool, earliest_date: date? }

You do not reserve parts. You do not reschedule.

Scheduler Specialist and Notification Specialist follow the same shape, each with its own scoped tools.

Orchestration pattern

Router-worker with an autonomous trigger. The Orchestrator is event-driven, not user-driven. The specialists are standard connected agents. Microsoft Learn’s Event trigger overview documents Dataverse row-change, SharePoint, OneDrive, Planner, and Recurrence triggers — exactly the surfaces an event-driven agent runs on (an HTTP request trigger and Power Automate flows extend the catalog where a native trigger does not exist).

Expected runtime behavior

The field app emits a missing_part event at 10:15 AM, written as a row to the FieldIncident table.

The row-change trigger wakes the Orchestrator. It calls the Inventory Specialist.
Inventory returns {available_locally: false, available_nearby: true, warehouse_id: "WH-17", eta_minutes: 75}.
The Orchestrator calls the Notification Specialist with mode: "delay", eta_minutes: 75.
The technician receives a Teams message; the customer receives an SMS and an email: “Your technician has been delayed 75 minutes to retrieve a part. New estimated arrival: 11:30 AM.”
Everything above happens in under a minute.

If inventory had been unavailable for two days, step three would have called the Scheduler Specialist instead, who would have proposed a slot and booked it in Dynamics 365 Field Service, followed by the notifications.

What makes the autonomous trigger the right shape

Three properties justify autonomy here:

The signal is clean. The field app writes a well-defined row with a known schema. There is no ambiguity to clarify with a human.
The reasoning is bounded. The decision tree is small. Nothing about the workflow requires open-ended judgment.
The latency matters. A human-in-the-loop step would defeat the point. The whole value is in removing the 30-minute phone call.

Where any of those is not true, a conversational trigger with a human in the loop is in a better shape.

A trigger-security note

Autonomous triggers run with the agent maker’s credentials, and the payload that wakes the agent is untrusted input that is then added to the agent’s context. This is precisely the surface that CVE-2026-21520 exploited: an indirect prompt injection inserted into a SharePoint form field was concatenated into a Copilot Studio agent’s instructions, which then exfiltrated data via a legitimate Outlook action (Microsoft patched it in January 2026; it was publicly disclosed in April 2026). For a FieldIncident row, the practical lessons are the same as Microsoft’s autonomous-agent guidance: validate required fields before acting, narrow the conditions that trigger the action, and never let free-text payload fields override the agent’s instructions.

Real anchor points

Several published Copilot Studio case studies touch adjacent patterns. The Holland America Line virtual concierge uses Copilot Studio to resolve customer requests with backend integrations without requiring a human operator for standard cases. Signetic uses Power Platform and Copilot Studio to automate healthcare operational workflows that would otherwise require coordination calls between departments. Singapore Civil Defence Force reports automating manual processes that previously required significant staff time, with savings described as multi-million-dollar in the published case study. Field service dispatch fits the same mold: a bounded workflow with clear inputs and a clear success state.

Safeguards for autonomous agents

Microsoft’s guidance on autonomous agents is explicit about the safeguards that matter, and they apply directly here:

Least-privileged access. The Inventory Specialist should have read-only access to SAP. The Scheduler Specialist should have write access only to the specific entities it books. Neither has broader scope. Per-agent Entra agent identities — now auto-creatable in Copilot Studio (preview) — make this scoping concrete.
Input validation. The field app’s row write is authenticated; the Orchestrator validates required fields before acting, and treats free-text fields as data, not instructions.
Audit logging. Every decision and every action is logged to Purview. Field Service dispatch is a regulated area in some industries (medical device servicing, for example), and auditable logs are non-negotiable there.
Human escalation path. If the Orchestrator cannot resolve the event — for example, the customer has no contact method on file — it escalates to a human dispatcher rather than failing silently.

5. Scenario four — Employee onboarding (hierarchical with persistent state)

The fourth and final scenario exercises the hierarchical pattern: a long-running process that spans departments, persists state over days, and requires coordination across multiple specialist agents. Employee onboarding is a good example because the work is well-defined, the owners are clear, and the measurable outcome — day-one readiness — is something every HR organization already tracks.

The problem

Between a candidate accepting an offer and their first day, a long list of things must happen: HR creates the employment record, legal sends contracts for signature, IT provisions the Entra account and assigns licenses, procurement orders hardware, facilities allocates a desk and issues a badge request, the hiring manager drafts a 30-day plan and sets up 1:1s, the new hire is added to Teams channels and mailing lists.

None of this is intellectually hard. It is coordination work across four or five systems and three or four departments, and it often fails. In many organizations, a meaningful share of new hires arrive on day one with at least one blocker — a missing laptop, no email account, no desk assignment. Each blocker creates friction that is remembered long after it is resolved.

The design

One supervisor agent, four specialists, and one shared state store. All live in Copilot Studio, using connected agents and autonomous triggers.

Onboarding Supervisor (autonomous). Owns the case from offer acceptance to day 30. Orchestrates the specialists. Escalates when any step is overdue.

HR Specialist (connected agent). Creates the Workday record and sends the contract through DocuSign.

IT Specialist (connected agent). Provisions the Entra ID account, assigns licenses, orders hardware.

Facilities Specialist (connected agent). Allocates a desk and issues a badge request.

Manager Specialist (connected agent). Drafts the 30-day plan from a template, schedules 1:1s, and adds the new hire to Teams channels.

Shared state. A Dataverse table, OnboardingCase, with one row per new hire and columns for each step’s status, timestamps, and artifact links.

Why Dataverse and not conversation history

The process spans days or weeks. Conversation history in Copilot Studio is not the right place for state that must outlive a session. The durable design principle is the same: persistent state for a long-running process belongs in Dataverse, not in conversation history, which truncates.

Every specialist updates its own step’s status in the OnboardingCase row when it completes. The Supervisor reads the row periodically (or reacts to Dataverse row-change events) to decide what to do next. Where a specialist step legitimately runs long, asynchronous responses for agent flows (preview) let it exceed the two-minute limit and return its result when it finishes.

Agent configurations

Onboarding Supervisor — instructions (autonomous):

You run when a new row is created in the OnboardingCase
table (status = "offer_accepted") or when a row is updated
(status changes).

For each case:
  1. If no HR step has started, call HRSpecialist.
  2. When HR step completes, call IT and Facilities in
     parallel.
  3. When IT step completes, call ManagerSpecialist to
     draft the 30-day plan and schedule 1:1s.
  4. If any step exceeds its SLA (HR: 1 business day, IT:
     3 business days, Facilities: 2 business days,
     Manager: 5 business days), post a Teams message to
     the HR coordinator channel with the overdue step
     and the case ID.

Update OnboardingCase.overall_status after every change.

Never perform steps yourself. Always delegate.

IT Specialist — instructions:

You handle IT provisioning for a new hire.

Inputs:
  case_id (string)
  first_name, last_name, start_date, job_title, cost_center

Behavior:
  1. Create the Entra ID user via the Microsoft Graph
     connector.
  2. Assign licenses based on job_title via the configured
     license-mapping table.
  3. Order standard hardware via the IT procurement
     connector (the specific package is determined by
     job_title).
  4. Update OnboardingCase.it_status = "complete" when
     all three succeed.

Output (structured):
  { ok: boolean, entra_user_id: string,
    hardware_order_id: string }

You do not create HR records.
You do not draft the 30-day plan.

Other specialists follow the same shape — each scoped to its own domain, each writing only to its own columns in OnboardingCase.

Orchestration pattern

Hierarchical. The Supervisor runs autonomously, triggered by changes to Dataverse rows. It invokes specialists in a documented order with some parallelism (IT and Facilities can happen concurrently). Each specialist’s work is bounded, owned, and auditable. Agent flows provide the mechanism for the Supervisor. Triggers on Dataverse table changes are a first-class feature.

Expected runtime behavior

Day 0: HR enters a new row in OnboardingCase with status = "offer_accepted".

The Supervisor wakes and calls the HR Specialist. HR Specialist creates the Workday record and initiates the DocuSign flow. hr_status moves to in_progress, then to complete when the contract is signed.
On HR completion, the Supervisor calls IT and Facilities in parallel. IT provisions Entra, licenses, and hardware. Facilities allocates a desk and issues a badge request.
On IT completion, the Supervisor calls the Manager Specialist, who schedules 1:1s in the hiring manager’s calendar, generates a 30-day plan draft in Word, saves it to the manager’s OneDrive, and adds the new hire to the appropriate Teams channels.
On day 1, the overall_status column reflects the readiness of the new hire. If any step is overdue, the HR coordinator’s Teams channel has been notified.

Expected outcomes

Publicly available data on Copilot Studio onboarding use cases points in a consistent direction. Pragmatiq’s published use-case list identifies “Guiding employee onboarding” as one of the top Copilot Studio patterns: “HR teams use Copilot Studio to guide new hires through IT setup, policies, and training materials, helping them get up to speed faster.” La Trobe University’s published case study describes academic onboarding and student-facing processes handled with Copilot Studio; the pattern generalizes to employee onboarding in its coordination shape.

Organizations measuring before-and-after on this pattern commonly report day-one readiness improving substantially, with the remaining gap being cases with unusual requirements that still need human routing. The gains come from the coordination being mechanical, not from any single step being faster. (Treat any specific percentage as illustrative unless your own baseline supports it — the published case studies describe the shape of the improvement, not a universal number.)

What this scenario makes obvious

Three things stand out in the hierarchical pattern.

State is the architecture. The OnboardingCase Dataverse table is not an implementation detail; it is the source of truth. Every decision the Supervisor makes depends on the state it reads. Every specialist writes back to it. If that table is modeled carelessly, the whole system is fragile.

Specialists are boring. None of the specialists does anything clever. They do one thing each, reliably. That is the point. Cleverness in the wrong place is a reliability problem.

The Supervisor is small. The instruction block is short. The logic is explicit. There is no “decide the best onboarding strategy” reasoning — there is a process, and the Supervisor executes it.

Where the pattern commonly goes wrong

Treating the Supervisor as a chatbot. Someone wants to “ask the onboarding agent how things are going.” Don’t. Build a report on top of the Dataverse table instead. The Supervisor’s job is execution, not Q&A.
Overloading OnboardingCase. Adding every possible detail to the row makes it slower and harder to change. Keep it to status, timestamps, and references; put the details in the relevant specialist’s own storage.
Missing the SLA side of the Supervisor. Without the overdue logic, the system looks like it is working until someone realizes a specific step has been stuck for a week. The SLA rule is not optional.

6. A practical MCP inventory for enterprise Copilot Studio deployments

The four scenarios above all assume the existence of well-described tools. In Part 1, MCP was introduced as the standard that lets those tools be defined once and consumed by many agents. This section proposes a starter catalog of MCP servers and tools that most enterprises need. Everything listed here is either a real, shipping MCP server from Microsoft or a major vendor, or a thin wrapper around an existing, documented enterprise API that any team can build using the official MCP SDK.

Why start from an inventory

Makers tend to build MCP servers reactively — one per immediate need — and end up with an ecosystem that overlaps, duplicates, and ages unevenly. An inventory, maintained by the platform team, makes the design choices explicit: what domains exist, who owns each, and where a new capability should go.

A practical inventory answers three questions for every proposed tool:

Which domain does it belong to? (Only one.)
Who owns the server that hosts it?
Is it read-only or does it write, and if it writes, is it idempotent?

Microsoft-published MCP servers

Microsoft Learn MCP server. Exposes Microsoft documentation as searchable tools. Useful for internal developer agents and customer support agents who need up-to-date Microsoft product guidance.
Microsoft Dataverse MCP — platform-level surfaces that expose Dataverse queries to agents, documented in the Microsoft Copilot Studio sample repositories.
Azure MCP servers from the Microsoft Azure organization on GitHub, exposing administrative surfaces for Azure resources.

The Microsoft Copilot Acceleration Team publishes working samples in the CopilotStudioSamples repository on GitHub, including the dynamic MCP routing sample referenced in Part 1. Remember that Copilot Studio also supports registering an existing MCP server as a bring-your-own asset through Agents 365, for organizations that want central governance of servers.

Third-party MCP servers with public presence

GitHub MCP server — official server from GitHub for repository, issue, and pull-request operations.
Atlassian MCP servers — for Jira and Confluence.
Notion, Linear, Asana — community- and vendor-provided servers for common SaaS work.

For many enterprises, these third-party servers are the starting point because the backend APIs are stable and the servers are maintained by the vendors.

Enterprise-internal domains that typically need an MCP server

The categories below are ones most enterprises either build themselves or expect to. Each can be implemented as a thin MCP wrapper over the existing backend’s REST API using the official MCP SDKs (available in TypeScript, Python, C#, and others).

Domain	Typical tools exposed	Owner
IT service management	search_incidents, get_incident, create_incident, update_incident, search_knowledge	IT Operations
Inventory / ERP	check_stock, list_warehouses, get_material	Supply Chain
HR / workforce	get_employee, list_open_requisitions, create_hire_record	HR Tech
Field service	list_slots, book_appointment, cancel_appointment	Field Service
Policy / knowledge	search_policy, get_policy, list_policy_versions	Legal / Compliance
Identity	create_user, assign_license, add_to_group	IT Security
Procurement	order_hardware, get_order_status, list_catalog	IT Procurement
Digital signature	send_envelope, get_envelope_status	Legal Operations
Document operations	extract_text, extract_tables, split, merge	Shared Services
Collaboration	create_channel, add_member, post_message	Collaboration / M365

Each row is a server, not a tool. The reason is ownership: when the ServiceNow team rotates credentials, they do it once in the ITSM server, and every agent continues to work.

For domains that already have excellent Power Platform connectors (many of these do — ServiceNow, SAP, Workday, Dynamics 365 Field Service, DocuSign, Microsoft Graph), the decision between “use the connector directly” and “wrap it in an MCP server” comes down to reuse. If only one agent needs these tools, the connector is simpler. If three or more agents need them, an MCP server is usually the right investment.

Cross-cutting concerns

A few principles apply to every server in the inventory.

Read-only versus write separation. When a single server mixes read and write tools, a broader scope of credentials is required to use it. A cleaner pattern is to split — itsm-read and itsm-write — and to grant the write server’s credentials only to agents that actually need them.

Idempotency on every write. Retries happen. Every write tool should accept an idempotency key and use it on the backend to deduplicate.

Structured outputs. Tools should return structured data with explicit schemas. The MCP protocol supports this natively; use it. An agent parsing prose is a fragile agent.

Tool descriptions as products. The description is what the orchestrator reads to decide whether to call a tool. Treat tool descriptions like API documentation — specific, accurate, and up to date. Include: what the tool does, when to use it, what it returns, and any side effects.

Authentication. OAuth 2.0 with Entra ID is the default for enterprise tenants. API keys are acceptable for internal network-scoped servers; the connection manager in Copilot Studio encrypts them at rest. Unauthenticated MCP endpoints should not exist in a business tenant. (Because MCP connectivity rides on Power Platform connectors, connector-level data policies also govern MCP access.)

Audit and observability. Every MCP server should log every call with the calling agent identity, the tool name, the inputs, the outputs, and the latency. Emit these logs to Sentinel or your SIEM of choice. Purview already captures the agent-side record.

Governance at the tenant level

The Power Platform Admin Center’s Copilot Hub and the agent inventory (now queryable as a schema from the admin center, API, or Azure Resource Graph (preview)) provide the tenant-level surface for seeing which agents use which MCP servers; Microsoft Agent 365 with the Entra agent registry (Ignite 2025) extends that view across platforms. Combine that with:

Environment strategy. Development, test, and production environments for MCP servers and their consuming agents. Pipelines promote both together.
DLP policies. Apply Data Loss Prevention policies to the connectors backing MCP servers. A write-capable MCP server is business data; treat it that way.
Entra Agent ID. Each agent gets a first-class identity, and permissions are scoped per identity (auto-creatable per agent in Copilot Studio (preview)). An IT triage agent does not need credentials to create employment records.
Global Secure Access for agent traffic. Where available, routing agent outbound calls through Microsoft’s network security enforcement layer is worth considering for regulated tenants.

A starter prioritization

If an organization is beginning from zero, the order that tends to work:

Stand up one read-only domain MCP server first — usually policy or knowledge. Let agents consume it. Prove the integration pattern works.
Add one write-capable server (ITSM or HR). Impose idempotency and audit discipline from day one.
Adopt the vendor-provided servers (GitHub, Atlassian, etc.) for domains you already use.
Expand to the rest of the inventory as agent demand justifies.

Trying to build all 10 servers at once results in an inventory with no consumers. Each server should exist because a specific agent needs it.

What to resist

Mega-servers that expose everything. A single MCP server with 200 tools recreates the god-agent problem at the tool layer. Split by domain.

Servers that replicate connector logic that already exists. If the Power Platform connector is already good and only one agent needs it, skip the MCP wrapper. MCP is a sharing mechanism; sharing is only worth it when there is something to share.

Custom protocols on top of MCP. If a team is tempted to add their own message shapes or non-standard tool conventions, they have probably drifted from the standard. MCP-compliant clients will not understand them, and the portability value is lost.

7. Ten anti-patterns that recur in production

The previous sections have covered the architecture, the scenarios, and the inventory. This last section collects what does not fit neatly into any of those categories: the patterns that look reasonable on paper and fail in production, and the corresponding lessons that stick. Each anti-pattern reflects a failure mode teams report in real Copilot Studio deployments, and the corrections are the ones teams have actually applied.

Anti-pattern 1 — The god agent

A single agent acquires, over months, fifty tools, nine knowledge sources, and an instruction block that bumps up against the 8,000-character limit and that nobody can fully read in one sitting. Orchestration quality degrades: the agent selects the wrong tools, cites the wrong documents, and occasionally rejects valid requests. The team adds more rules to the instructions to patch the symptoms.

Why it happens. Each addition seemed small at the time. Ownership was never explicit. Nobody had the authority to say no.

Correction. Split by domain into specialists. Apply the criteria in Part 1: tool count approaching 30-40, instruction length relative to the 8,000-character ceiling, number of owners, and SLA variance. The first split is the hardest; subsequent ones are routine.

Lesson. One agent, one domain, one owner. Enforce it at design review.

Anti-pattern 2 — Prose contracts between agents

The Orchestrator calls the Ticket Writer, which returns “I created ticket INC-12345 for you.” The Orchestrator then tries to extract the ticket ID with string matching. For six months, it works. Then someone rewrites the Ticket Writer’s output to be more conversational, and every downstream integration breaks quietly.

Correction. Every called agent returns structured data. Copilot Studio supports this natively; both connected and A2A agents allow structured outputs. Make this mandatory at the design-review stage.

Lesson. Structured in, structured out. Prose is for users, not for agents.

Anti-pattern 3 — Silent retries

The calling agent retries a failed call after a timeout. The called agent had actually succeeded; the failure was a network blip. The result: two tickets, two emails, two meeting invitations. Over a quarter, thousands of duplicate issues accumulate, and nobody notices until the project management tool begins to degrade under the volume.

Correction. Every write-capable tool accepts an idempotency key, and the backend uses it to deduplicate. The calling agent generates a stable key per logical operation (typically based on the conversation ID and the step name) and passes it on retries.

Lesson. Retries are a first-class design concern. Idempotency is not optional for writes.

Anti-pattern 4 — Unscoped credentials

Every MCP server, every connector, and every agent uses the same service principal. First breach compromises everything. Rotation is impossible without downtime.

Correction. Entra Agent ID (introduced May 2025; expanded to public preview at Ignite 2025) gives each agent a first-class identity, and Copilot Studio can now auto-create one per agent (preview). Grant permissions per agent, scoped to exactly what that agent needs. Use managed identities where supported. Rotate credentials per connection, not per tenant.

Lesson. Least privilege is a design input, not a post-deployment cleanup.

Anti-pattern 5 — No state store

A multi-step orchestration relies on conversation history to remember where it is. Conversation history truncates. The orchestration loses its place, and the Orchestrator either restarts the process (producing duplicates) or abandons it (producing incomplete work).

Correction. Persist state in Dataverse. The OnboardingCase pattern from scenario four is the generalization: one row per case, columns for each step’s status, with row-change events driving the Supervisor. Every specialist writes in their own columns.

Lesson. If the process outlives the conversation, so should the state.

Anti-pattern 6 — Knowledge source overload

An agent is attached to 12 SharePoint sites, 6 uploaded files, 2 website URLs, and a Graph connector. Retrieval produces irrelevant passages. Cited answers are confidently wrong. Adding more sources makes it worse, not better. (Generative orchestration also caps SharePoint knowledge at 25 site URLs per agent, which is a hard reminder that more is not better.)

Correction. Scope knowledge tightly. One domain, one library. The case studies that cite retrieval quality as the winning factor — Dunaway, ABN AMRO, La Trobe University — all scoped narrowly. Where a second domain matters, that is usually a second specialist with their own knowledge.

Lesson. Retrieval quality is a function of signal-to-noise, not of source count.

Anti-pattern 7 — Circular delegation

Agent A calls Agent B, who calls Agent A, who calls Agent B. The orchestrator executes until a timeout or token exhaustion. The bill arrives.

Correction. Specialists never call their parents back. If a specialist appears to need something the parent has, the parent should pass it down as an input. (Copilot Studio’s one-level nesting rule — an agent with connected agents can’t itself be a connected agent — limits but does not eliminate the risk.)

Lesson. Delegation is a tree, not a graph. Trees have no cycles.

Anti-pattern 8 — Conversational autonomy

An autonomous agent is built as a chatbot that also runs on a schedule. The chatbot surface and the autonomous surface have different failure modes, and the team maintains both. When a user interrupts the autonomous run through chat, the state becomes inconsistent.

Correction. Autonomous agents have no chat surface. If users want visibility, build a report on top of the state store. Chat is a separate agent if it is needed at all.

Lesson. Autonomy is a different product shape from conversation. Do not combine them in one agent.

Anti-pattern 9 — Ignoring the security posture of inputs and called agents

Two failure modes share one root cause: trusting content the agent did not author. In the first, an A2A agent from a partner is added to the tool list; six months later, a vulnerability in the partner’s agent lets its conversation context leak through its outputs. In the second — the one Microsoft assigned a CVE to — an attacker placed instructions in a SharePoint form field that an autonomous agent ingested as authoritative context. Microsoft assigned CVE-2026-21520 (CVSS 7.5) to that indirect prompt-injection issue, patched it in January 2026, and publicly disclosed it in April 2026. Notably, the injected instruction exfiltrated data through a legitimate Outlook action, so DLP never fired. Both cases prove the same point: every input an agent trusts — a partner agent’s output, a form field, a retrieved document — expands the attack surface.

Correction. Treat external agents as supply chain dependencies: review their security posture, scope their access narrowly, log their calls, and rotate credentials. Treat trigger and retrieval inputs as untrusted: validate payloads, and never let free-text content override the agent’s instructions.

Lesson: Defense-in-depth is necessary; agent composition is not safe by default. The LLM cannot reliably tell trusted instructions from untrusted data — so the boundary has to be enforced around it.

Anti-pattern 10 — Measuring the wrong thing

A team reports “the agent answered 10,000 questions this month.” That is a count, not an outcome. The team does not know how many answers were correct, how many resolved the user’s underlying need, or how many caused follow-up work.

Correction. Measure outcomes: auto-resolution rate, user confirmation of correctness, downstream ticket creation, time-to-resolution. Copilot Studio’s analytics surface, combined with data in the relevant business systems, supports these measurements.

Lesson. Volume is not value.

Recommendations that follow

Pulling the corrections together:

Architecture. One agent per domain. Separate read from write. Tree, not graph.
Contracts. Structured inputs and outputs. Explicit error contracts. Idempotency keys on writes.
Security. Scoped credentials. Entra Agent ID per agent. Validate untrusted inputs. Audit everything. Review external agents like you review external vendors.
Operations. State in Dataverse. Outcome metrics, not volume metrics. Ownership per agent, reviewed quarterly.
Standards. MCP for tools. A2A for agents across platforms (GA since April 2026). Connected agents for Copilot Studio–native specialists. Child agents for subroutines inside a parent.

8. What Copilot Studio gives you today, one more time

Every capability used across Parts 1 and 2 of this series is available now, with preview status noted where it applies:

Generative orchestration with tool selection.
Child, connected, and A2A agents (A2A generally available since April 2026; connections to Microsoft Foundry, Fabric, and M365 Agents SDK agents in public preview).
MCP server integration with Streamable transport (SSE no longer supported after August 2025).
Autonomous agents with documented Dataverse, SharePoint, OneDrive, Planner, and Recurrence triggers; an HTTP request trigger and cloud flows extend the catalog where a native trigger does not yet exist.
Agent flows with parallel branches and approval gates — and a redesigned Workflows experience in early release, with agent nodes and asynchronous responses (preview).
Computer Use (computer-using agents), generally available since May 2026.
Dataverse as a governed state store.
Entra Agent ID (per-agent auto-creation in preview), Copilot Hub, the agent inventory schema (preview), Microsoft Agent 365, and the Copilot Control System for governance.
Purview audit across agent activity.

Nothing in this series required features that do not exist. The gap between “possible today” and “in production somewhere” is smaller than the marketing noise suggests. The gap between “possible” and “in production well” is larger — and the anti-patterns above are the ones that close it.

Conclusion

If you take five things away from this article, they are these.

First, the four patterns are not abstractions; they have concrete shapes you can copy. Router-worker is the IT triage scenario: classification, delegation, structured returns. Parallel fan-out is the contract review scenario: independent specialists with scoped knowledge, merged outputs. Router-worker with an autonomous trigger is the field service scenario: a clean event, a bounded decision tree, no human in the loop. Hierarchical with persistent state is the employee onboarding scenario: a supervisor that reads from a Dataverse table, specialists that update their own columns, and SLA monitoring that escalates when work is stuck.

Second, state is the architecture for anything long-running. Dataverse is the right place for it. Conversation history is not. Every hierarchical and event-driven design in this article depends on a state table whose columns are the contract between the agents. Model it carelessly, and the whole system is fragile; model it well, and the supervisor becomes trivial.

Third, MCP is a platform decision, not an agent decision. The inventory in section 6 is a starting point because the question of which server owns which domain must be answered once by the platform team, with the consuming agents in mind. Mega-servers and one-off wrappers both recreate the problems MCP exists to solve. Domain ownership and read/write separation are the load-bearing rules.

Fourth, the ten anti-patterns are observations, not predictions. Each reflects a failure mode teams hit in shipping deployments. The god agent, prose contracts, silent retries, unscoped credentials, no state store, knowledge overload, circular delegation, conversational autonomy, ignored security posture, and measuring volume instead of outcomes — these are the failure modes a design review should explicitly check for.

Fifth, the measure of a multi-agent system is not how clever any single agent is — it is how boring each agent can become. Boring agents — narrow, owned, tested, well-described — compose into systems that deliver outcomes reliably. The four scenarios above each succeed because their specialists do one thing, do it well, and stop. The inventory and the anti-patterns exist to keep them that way.

Multi-agent orchestration is not a novelty. It is the shape enterprise AI takes when it grows beyond a single use case. Copilot Studio is one of the platforms where that shape is now routine to build, with two open standards (MCP and A2A) that keep it composable and a governance surface that keeps it safe to operate. Part 1 settled the architectural decisions; Part 2 worked through what they look like when executed. The rest is the discipline of doing it well — and that, as it turns out, is the part that takes practice.

Sources

Microsoft Learn — Explore multi-agent orchestration patterns
Microsoft Learn — Add other agents (overview) — child vs connected agents; preview status of Foundry/Fabric/M365 Agents SDK connections
Microsoft Learn — Quotas and limits — 8,000-character instruction limit; 25 SharePoint sites under generative orchestration
Microsoft Learn — Design autonomous agent capabilities — autonomous agents GA, March 2025
Microsoft Learn — Event trigger overview — documented event triggers (SharePoint, OneDrive, Planner, Recurrence, Dataverse row-change)
Microsoft Learn — What’s new in Copilot Studio — A2A GA (April 2026), Computer Use GA (May 2026), new Workflows experience, async agent-flow responses (preview), per-agent Entra identities (preview), agent inventory schema (preview)
Microsoft Learn — Connect your agent to an existing Model Context Protocol (MCP) server
Microsoft Learn — Connect an agent available over the Agent2Agent (A2A) protocol
Microsoft Learn — Copilot Studio real-world transformation stories — T-Mobile, Nexi Group, A1 Inteligência em Viagens, Dunaway, Signetic, Holland America Line, Singapore Civil Defence Force, La Trobe University, ABN AMRO, Rabobank
Microsoft Learn — ServiceNow connector reference
Microsoft Learn — Power Platform connectors reference
Microsoft Learn — Copilot Hub in the Power Platform Admin Center
Microsoft Learn — Copilot Control System overview
Microsoft CopilotStudioSamples — Dynamic MCP Routing in Copilot Studio
Model Context Protocol — Official specification and SDKs
Agent2Agent protocol — Open specification
VentureBeat — Microsoft patched a Copilot Studio prompt injection. The data exfiltrated anyway. — CVE-2026-21520 (CVSS 7.5, “ShareLeak”), patched January 2026, disclosed April 2026
Pragmatiq — 12 Practical Use Cases for Microsoft Copilot Studio
Holger Imbery — Copilot Studio Multi-Agent Orchestration (original 14-part series)

Multi-Agent Orchestration with Copilot Studio — Part 1: Foundations

Sat, 04 Jul 2026 00:00:00 +0000

Summary lede. This is the first of three articles on multi-agent orchestration in Microsoft Copilot Studio. Part 1 — Foundations — establishes the vocabulary, the decision criteria, and the configuration mechanics that every team needs before it touches a production design. It walks through five questions in order: why split a single agent into several, what a Copilot Studio agent is actually composed of, which orchestration patterns exist, how the Model Context Protocol (MCP) lets agents share tools, and how the Agent2Agent (A2A) protocol lets agents talk to other agents across platforms. The article closes with the concrete configuration steps for both standards as they exist in the product today, with the correct UI paths.

About this series. This is Part 1 of three. Part 1 — Foundations (this article) covers the vocabulary, when to split a single agent, the five configuration surfaces, the four orchestration patterns, and how MCP and A2A are configured. Part 2 — In Practice turns those decisions into four end-to-end scenarios, a starter MCP server inventory, and ten production anti-patterns. Parts 1 and 2 describe the released, generally available feature set — the “classic” Copilot Studio experience, built on generative orchestration, which is GA and fully supported. Part 3 — The Build 2026 Rebuild describes the new four-surface model (Skills, Memory, a new orchestrator); those features are in public preview and subject to change before general availability, so treat Part 3 as forward-looking and re-check status before relying on it.

Every capability described in this article — connected agents, child agents, MCP integration with Streamable transport, A2A integration, autonomous triggers, Entra Agent ID, Copilot Hub, the Microsoft Foundry Agent Service — is documented on Microsoft Learn and is either generally available or in public preview, with the status called out where it matters. Three of the connected-agent types (Microsoft Foundry agents, Fabric Data agents, and agents built with the Microsoft 365 Agents SDK) are public preview at the time of writing; connected Copilot Studio agents, MCP, and A2A are generally available. Where a feature is preview, this article says so.

Capability status at publication Copilot Studio moves quickly, so the architecture below is anchored to current capability status. As of publication: A2A connections are generally available; Computer Use (computer-using agents) is generally available, with embedding into workflows in preview; a redesigned Workflows experience is in early release; per-agent Microsoft Entra agent identities can be auto-created (preview); and an agent inventory schema (preview) exposes every agent to the admin center, API, and Azure Resource Graph. These capabilities support the architecture in this article — they are noted inline where relevant.

Why read this Read this if you are responsible for the shape of an AI build that has either started to misbehave or is about to. The single-agent-with-everything pattern looks fine for the first quarter of a project and fails predictably in the second. The terms in this article are the ones a solution architect, platform owner, or senior maker needs to discuss the failure with the team and pick a better shape. Read it if you have heard “we will just add another tool” three times in the same week, if your instruction block now scrolls, or if two different teams are editing the same agent without coordinating. Read it especially if a vendor or an article elsewhere has promised that MCP or A2A will “solve” multi-agent work — they will not, but they do remove enough integration duplication that the architectural decisions become the bottleneck again, which is where this article picks up.

The Foundations article is also where the corrections from the original series are applied: the correct UI path for adding A2A agents (the Agents page, not the Tools page), the current name and preview status of the connected-agent types, and the actual list of autonomous trigger types supported on Microsoft Learn. If you have been following the series and want the canonical version, this is it.

1. The drift that produces multi-agent work

Most enterprise AI projects start with a single agent and end with a support ticket. The agent grows, picks up more tools, more instructions, more knowledge sources, and eventually starts choosing the wrong action, citing the wrong document, or refusing perfectly valid requests. Teams add prompt fragments to patch individual failures, the instruction block runs up against Copilot Studio’s documented 8,000-character limit for agent instructions, and nobody on the team can say with confidence why a specific response came out the way it did.

Multi-agent orchestration is the architectural response to that drift. Instead of one general-purpose agent, the work is split across a small set of narrow agents, each with a clear scope, its own knowledge, and its own tools. An orchestrator chooses which specialist to call. This pattern is not new in distributed systems, but the tooling to apply it cleanly to conversational AI is new — and Microsoft Copilot Studio now provides it as a first-class capability.

Five capabilities make multi-agent orchestration practical in Copilot Studio today:

Connected agents — a separately published agent added to another agent as a callable capability. This can be another Copilot Studio agent in the same environment (generally available), or an external agent: an agent on the Microsoft Foundry Agent Service (preview), a Fabric Data Agent (preview), an agent built with the Microsoft 365 Agents SDK (preview), or any agent that speaks the A2A protocol. Each connected agent has its own lifecycle, authentication, owner, and can be reused across multiple calling agents.
Child agents — lightweight sub-agents that live inside a parent agent and share its environment, tools, and knowledge. They are not independently published and are not intended for reuse outside the parent. (Earlier drafts of this series called these “inline agents”; Microsoft’s term is child agents, and that is what this article uses.)
MCP integration — since 2025, Copilot Studio exposes a “Tools → Add a tool → New tool → Model Context Protocol” flow that takes a server URL, authentication settings, and automatically discovers the tools the server publishes.
A2A protocol support — Copilot Studio can connect to any agent that speaks the open Agent2Agent protocol, enabling orchestration with agents hosted on other frameworks. A2A connections went generally available in April 2026.
Autonomous agents — event-triggered agents that act without a user turn, generally available since March 2025.

These capabilities are documented, configurable, and in production use at organizations including ABN AMRO, Rabobank, Holland America Line, T-Mobile, the City of Montréal, La Trobe University, Nexi Group, and Singapore Civil Defence Force.

2. When to split a single agent

The question is not whether multi-agent systems are better. The question is at what point a single agent stops being the right shape for the work.

Copilot Studio gives makers a lot of room before that point is reached. A single agent can hold a substantial instruction block (up to the 8,000-character limit), hundreds of knowledge sources, and a growing list of actions. For many use cases — an FAQ bot over a policy library, a contained IT assistant with five connectors — one agent is the correct answer and will stay the correct answer for the life of the deployment.

The problems begin when the agent’s scope expands informally. A new department asks if the existing agent can “also” handle their intake. A manager attaches another SharePoint site “for context.” An action is added because it was convenient. Each change is small; the cumulative effect is an agent with blurred responsibilities, inconsistent tone, and orchestration quality that degrades in ways that are hard to diagnose.

Signals an agent has outgrown itself

Microsoft’s guidance on multi-agent orchestration is explicit about the thresholds where quality starts to slip. The clearest signal is tool count. The orchestrator ranks candidate tools at each turn; as the list grows, the probability of selecting the right one falls. Microsoft Learn’s Add other agents overview states this directly: “this degradation in performance can happen when your main agent has more than 30-40 choices of action (tools, topics, and other agents).” Other signals are softer but equally real:

The instruction block contains rules that contradict each other because different requirements were bolted on over time.
Knowledge sources cover unrelated domains, and retrieval surfaces HR articles to IT questions.
Response latency varies wildly because one path calls a millisecond lookup and another generates a multi-page report.
Multiple owners now edit the same agent, each with different mental models.
Testing one change risks regressing a behavior owned by a different team.

When three or more of these are true, the agent is doing the work of what should be multiple agents.

What splitting actually buys you

Decomposing an agent is not free. It introduces a second artifact to maintain, an orchestration layer, and a contract between components. The benefits must be worth that cost, and they usually are in three ways.

First, bounded context. Each specialist agent can have a short instruction block, a small number of tools, and a knowledge base scoped to one domain. The orchestrator’s job is routing, not execution. Testing becomes possible because each agent has a well-defined input and output.

Second, independent ownership. HR owns the HR agent; IT owns the IT agent; Finance owns the invoice agent. When HR needs to change the parental-leave policy, they update one knowledge source and one agent, with no risk to the IT triage behavior.

Third, reuse. A connected “Knowledge Base Lookup” agent can serve the Service Desk, the Sales Assistant, and the Field Technician agent without three teams each rebuilding the same tool integrations, prompts, and error handling.

A decision checklist

A practical rule for deciding whether to split:

Split when the agent has multiple distinct owners, or the tool count is approaching 30, or two knowledge bases are pulling retrieval in conflicting directions, or SLA expectations differ between tasks.
Do not split when the problem is really that one knowledge source is outdated, or when the instructions simply need rewriting, or when the “additional” use case is a one-off topic that belongs in a Power Automate flow rather than a new agent.

The cheapest intervention should always be tried first. A clean-up of instructions, a re-scoping of knowledge sources, or moving an over-loaded action into a Power Automate agent flow will often resolve what looked like a multi-agent problem.

Child or connected: a second decision

Once the decision to split is made, Copilot Studio offers two options, and they serve different purposes.

Child agents are the right choice when the sub-agent exists only to factor complexity inside one parent. They share the parent’s environment, tools, and authentication. They are a first-class sub-agent type — you create them, give them their own instructions, and can define input and output variables — but they do not need to be reused, do not need to be independently owned, and simply make the parent easier to reason about.

Connected agents are the right choice when the specialist is an independent unit: it has its own owner, its own release cadence, its own authentication model, its own model selection, or it will be called from more than one calling agent. Connected agents can be other Copilot Studio agents, Fabric Data Agents for governed analytics (preview), agents on the Microsoft Foundry Agent Service (preview), or agents built with the Microsoft 365 Agents SDK (preview).

The two are grounded in Microsoft’s own guidance. The table below summarizes the trade-offs that matter most — control, context, latency, and reuse.

Dimension	Child agent	Connected agent
What it is	A lightweight sub-agent inside the parent agent	A separately published agent — another Copilot Studio agent, or an external agent over A2A, Microsoft Foundry (preview), Fabric (preview), or the M365 Agents SDK (preview)
Context / orchestration	Shares the parent’s environment, authentication, and orchestration context	Runs its own orchestration layer — its own reasoning pass over its own tools and knowledge. The parent hands off; the connected agent decides independently
Context window	Logic lives inside the parent’s boundary; use child agents to split a long instruction set into focused pieces under the 8,000-character ceiling	Each connected agent carries its own instructions, knowledge, tools — and can use a different model — so it has its own context budget and strong isolation
Control	Tight coupling; the parent owns config, auth, and lifecycle. Supports input/output variables and can be referenced in instructions with `/`	Loose coupling; the connected agent owns its settings, model, ALM, and channels. You steer delegation only through its description and input contract
Latency	Lower — no extra orchestration hop	Higher — each delegation adds an orchestration hop (Microsoft explicitly flags the added latency)
Reuse	Not reusable outside the parent; not independently published	Reusable across many parents; independently published and owned
Governance surface	Minimal extra surface	Larger testing, management, and governance surface; each connection is an inventoried dependency
Use when	Single use case, one team or developer, you just want to group tools/instructions/knowledge cleanly, no separate auth/deploy/reuse	Multiple teams own different agents, separate publishing/ALM, dedicated settings such as a different model, or you want the agent reusable across more than one parent
Remove via	“Delete”	“Disconnect agent”

Two caveats from the documentation are worth keeping in mind. First, an agent that already has connected agents cannot itself be added as a connected agent — nesting is one level deep. Second, citations are not always preserved when outputs pass back from a called agent to the caller, which is one more reason to prefer structured returns over prose (a theme that recurs throughout Part 2).

ABN AMRO’s published Copilot Studio work is consistent with this discipline: the case study describes enhancing customer and employee interactions using Copilot Studio together with Azure services. The architectural lesson to import — bounded agents plus governed data access — is the kind of pattern that makes outcomes reproducible across customer and employee scenarios, even though the case study reports the outcome rather than the internal decomposition. The City of Montréal’s citizen-engagement work points the same way: Copilot Studio used to improve information access and citizen engagement, the kind of scenario where a public-facing agent benefits from delegating to a specialist rather than holding every city process inside one prompt.

3. Agent anatomy: the five configuration surfaces

Before multi-agent work begins, it helps to be precise about what a single Copilot Studio agent actually contains. Makers who started with Power Virtual Agents sometimes carry forward a mental model built around topics and dialogs; makers who came from Azure OpenAI Studio sometimes carry forward a mental model built around system prompts and function calls. A modern Copilot Studio agent is neither of those alone. It is a composition of five distinct surfaces, each with different runtime behavior and different design trade-offs.

Instructions — the natural-language description of the agent’s role, constraints, tone, and output preferences. Instructions are injected into every turn, up to a documented limit of 8,000 characters.
Knowledge — the structured and unstructured data the agent can retrieve from, including SharePoint sites, Dataverse tables, uploaded files, public websites, Microsoft 365 Graph connectors, enterprise search sources, and — newly — the Work IQ service (preview) for real-time Microsoft 365 work context.
Tools — the executable capabilities the agent can invoke: connector actions, Power Automate flows, Dataverse actions, MCP-exposed tools, and other agents (child or connected) used as tools.
Topics — deterministic, authored conversation paths triggered by phrases, events, or redirections from other topics. Topics are where you place behavior that must be reproducible.
Triggers — what causes the agent to run at all. Beyond user messages, Copilot Studio’s documented event triggers include SharePoint, OneDrive, Planner, Recurrence (schedule), and Dataverse row-change triggers; an HTTP request trigger and Power Automate cloud flows can extend the catalog where a native trigger does not yet exist.

Instructions: judgment-based behavior

Instructions are the place for behavior that depends on context and cannot be fully specified in advance. Good instructions describe the agent’s purpose, its refusal rules, its preferred output format, and any constraints it must honor. They should not contain large tables of if-this-then-that logic; that is what topics are for.

A healthy instruction block is rarely more than a page, and Copilot Studio enforces an 8,000-character ceiling regardless. Once instructions grow toward that limit, two things happen: the probability that the agent follows any individual rule drops, and the cost per turn rises. Copilot Studio’s generative orchestration picks up the instructions automatically; no separate system prompt editing is required. When a single instruction block genuinely needs more structure, splitting focused pieces into child agents (each referenced from the parent’s instructions with /) is the documented way to stay under the ceiling.

Knowledge: scoped retrieval beats wide retrieval

Copilot Studio supports a long list of knowledge sources. The mistake that repeats in production is attaching too many. Retrieval quality on a tightly scoped SharePoint library is almost always better than retrieval across an entire tenant, because the signal-to-noise ratio is higher and ranking works against fewer near-duplicates.

A documented example is Dunaway, a firm whose Copilot Studio agent answers city-code questions. The published case study is explicit that they scoped knowledge to the specific regulatory libraries that mattered, rather than pointing the agent at every document the firm could access. The outcome — fast, accurate regulatory answers — depended on that scoping.

Graph connectors are the right choice when the source is not already in SharePoint or Dataverse. Websites work, but are best reserved for public reference material where currency matters more than precision. Uploaded files are fine for stable documents but awkward for anything that changes; preferable to store those in SharePoint and let the agent retrieve them from there.

Tools: the surface that most affects orchestration quality

Every tool you add to an agent is a candidate the orchestrator must consider at every turn. Tools fall into several categories in Copilot Studio today:

Prebuilt connector actions — from Microsoft’s catalog of 1,000+ connectors, including Microsoft 365 services and major SaaS platforms.
Power Automate cloud flows — any existing flow can be promoted to a tool, which keeps complex orchestration logic out of the agent.
Agent flows — a visual, AI-assisted workflow designer that blends deterministic steps with generative reasoning, triggered by Dataverse events, schedules, or HTTP calls. (A redesigned Workflows experience, in early release, is the evolution of this surface — see the “What’s new” note above.)
MCP tools — tools exposed by an MCP server, discovered automatically once the server is connected.
Other agents as tools — child or connected agents added to the agent’s list of callable specialists.

The practical guidance is to treat tool descriptions as first-class design artifacts. The orchestrator selects tools largely from their descriptions; a vague description produces vague routing. A one-sentence description that explains when to use this tool, what it returns, and any side effects is worth more than a long paragraph that describes the implementation.

Topics: the place for reproducibility

Topics are the most under-used surface in modern Copilot Studio builds. Makers arriving from the LLM side sometimes treat everything as an instruction, and then are surprised when behavior they need to be deterministic — an escalation path, a compliance disclosure, a specific regulatory script — varies between conversations.

Topics execute as authored. They can include message nodes, condition nodes, generative AI nodes, and action calls. If a behavior must be reproducible for audit or compliance reasons, put it in a topic. Rabobank’s published conversational banking work — text and voice-enabled conversational AI in a regulated banking context — is the kind of scenario where authored flows for regulated interactions sit alongside generative handling of the softer surrounding conversation.

Triggers: what makes an agent autonomous

The default trigger is a user message. Since March 2025, Copilot Studio supports autonomous triggers — an agent can be woken by a Dataverse row change, a SharePoint document event, a OneDrive event, a Planner change, a scheduled (Recurrence) trigger, or an HTTP call. Where a native trigger does not exist for the desired source, a Power Automate cloud flow that subscribes to that source can write into Dataverse and let the Dataverse row-change trigger wake the agent. These triggers are what make “autonomous agents” possible: the agent is still described by the same five surfaces, but it does not need a user to start it.

A security note that Part 2 develops further: event triggers run with the agent maker’s credentials, and trigger payloads can carry untrusted content into the agent’s context. This is exactly the surface that CVE-2026-21520 (a SharePoint-form indirect prompt-injection issue patched in January 2026) exploited. Validate payloads and scope what a trigger can activate.

Singapore Civil Defence Force’s published case study includes autonomous processes that run without user interaction. The savings reported in that case study — described as multi-million-dollar — come from that automation running continuously against existing business events, not from a human chatting with a bot.

How these surfaces interact in a multi-agent system

When you split an agent, you are really deciding how each surface gets redistributed:

Instructions shrink, because each specialist has a narrower role.
Knowledge separates by domain, so retrieval becomes sharper.
Tools concentrate in the specialists; the orchestrator holds few direct tools beyond the ability to call its agents.
Topics tend to live in specialists, where reproducibility matters for specific business flows.
Triggers vary: the orchestrator is typically user-triggered, while specialists are often called-only; autonomous triggers live on individual specialists.

4. The four orchestration patterns

With the building blocks clear, the next question is how to arrange them. There are four patterns that cover the vast majority of enterprise multi-agent work, and all four can be implemented today in Copilot Studio using generative orchestration together with connected agents, child agents, and agent flows.

Pattern 1 — Router-worker

A thin parent agent classifies each incoming request and delegates to a specialist. The parent does almost no execution itself; its job is routing. The specialists do the work and return results. The parent optionally reformulates the response into the conversational style the user expects.

Router-worker is the default pattern for internal service desks, multi-tenant assistants, and any situation where requests fall into a small, stable set of categories. The strength of this pattern is operational: each specialist is small enough to debug, and changes to one specialist do not risk regressing the others.

In Copilot Studio, the router is a standard agent with connected agents added on the Agents page. The orchestrator’s built-in tool selection handles the routing, provided each connected agent has a clear, narrow description. No custom code is required.

Nexi Group’s published case study describes exactly this shape: a front-end agent that delegates card-service queries to specialists, reducing contact-center workload while keeping the interaction consistent for the customer.

Pattern 2 — Sequential pipeline

Agent A’s output becomes Agent B’s input, which becomes Agent C’s input, and so on. Each stage applies a transformation that depends on the previous one.

Sequential pipelines are the natural shape for review workflows: intake → analysis → recommendation → approval. They are also common in content-generation workflows, where one agent drafts, another edits, and a third formats.

In Copilot Studio, sequential pipelines are typically built with agent flows, because agent flows give you explicit control over step order, conditional branching, and error handling. Individual steps can call connected agents, generative prompts, or deterministic actions. Agent flows also support human-in-the-loop approvals, which sequential pipelines frequently need at the decision point.

Sequential work is where the discipline of structured outputs matters most. If step three has to parse prose from step two, the pipeline breaks quietly the first time the phrasing changes. Each step should return a structured object — JSON or a typed record — rather than a narrative.

Pattern 3 — Parallel fan-out / fan-in

The parent calls N specialists concurrently, waits for all of them, and then merges the results. This pattern is used when a single request needs enrichment from several independent sources, none of which depends on another.

Typical enterprise examples: enriching a customer record by calling a CRM lookup, an ERP balance check, and a support history lookup at the same time; running legal, finance, and risk review of a contract in parallel; pulling inventory, shipping, and pricing in parallel for a quoting workflow.

Agent flows in Copilot Studio support parallel branches explicitly. For cases where the parallelism is between full agents rather than actions, Power Automate remains a direct alternative: each branch calls an agent, and a final step aggregates the results. The parent agent then presents the merged output.

The complexity to watch for is timeout and partial-failure behavior. Parallel patterns fail well only if you decide, before the first implementation, what happens when one of the N branches times out or errors. “Return what we have and note what is missing” is a more robust default than “fail the whole request.”

Pattern 4 — Hierarchical (supervisor / sub-orchestrators)

A supervisor agent decomposes a goal into subgoals and delegates each to a sub-orchestrator, which in turn delegates to its own specialists. This pattern is used for long-running processes that span departments, such as employee onboarding, incident post-mortems, or multi-step audits.

The supervisor tracks state across time — usually in Dataverse — and is often an autonomous agent rather than a conversational one. Each sub-orchestrator updates its own step on completion, and the supervisor polls for progress or reacts to Dataverse events.

Copilot Studio supports the hierarchical pattern through the combination of connected agents (for delegation), autonomous triggers (for event-driven progress), and Dataverse tables (for shared state). The durable choice for a long-running process is to store orchestration state in Dataverse rather than in conversation history, which truncates — persist state outside the conversation, not inside it. For agent-flow steps that genuinely run long, asynchronous responses (preview) now let a flow exceed the two-minute limit and return results when it completes.

Choosing between the patterns

A short checklist:

If requests split cleanly into categories and there is little cross-dependency, use router-worker.
If work must happen in a specific order with each step depending on the previous, use sequential pipeline (agent flows).
If several independent lookups or reviews can happen at once, use parallel fan-out / fan-in.
If the process spans days, involves multiple departments, and needs state that outlives any single conversation, use hierarchical.

It is common for a real system to use more than one pattern. A customer-service agent might use router-worker at the top level, then have a sequential pipeline for complaint handling as one of its specialists, with a parallel enrichment step inside that pipeline. The goal is not architectural purity; it is picking the simplest pattern for each piece.

Three pattern anti-patterns

Circular delegation. Agent A calls Agent B, which calls Agent A back. Copilot Studio does not prevent this structurally, and it leads to long, expensive conversations that loop until a timeout. Rule: child agents never call back into their parents.
Fan-out without merge. The parent fires five parallel requests but does not wait for all results before responding, so the conversation becomes out-of-order. In agent flows, always use a “join” step before the aggregation.
Hierarchical without state. A supervisor that tracks state in the conversation window will lose it the moment the conversation is truncated. Long-running processes must persist state outside the conversation.

Copilot Studio provides the runtime — generative orchestration, tool selection, topic execution, agent-flow execution, autonomous triggers. It does not choose the pattern for you. The choice of pattern, the decision of which agent owns which responsibility, the contract between steps, and the handling of partial failures are all design decisions.

5. The Model Context Protocol (MCP) in plain terms

Two problems surface in any organization that has built more than a few agents. First, every agent builder reimplements the same integrations — Jira search, SharePoint lookup, ticket creation — in their own style, with their own error handling. Second, when a backend API changes, every agent that depends on it has to be updated individually. These are not AI problems; they are classic enterprise integration problems that the rise of agents has made more visible.

MCP is the open standard that addresses both. It was originally published by Anthropic in late 2024, is now adopted by multiple agent platforms, and is supported natively in Microsoft Copilot Studio since 2025. For Copilot Studio makers, understanding MCP is less about protocol details and more about what the standard allows you to do.

What MCP actually is

MCP is a specification for how an AI client (an agent) discovers and calls tools hosted on a separate server. The specification defines:

A uniform way for the server to describe the tools it offers (name, description, input schema, output schema).
A uniform way for the client to invoke a tool and receive a structured response.
Support for authentication, including OAuth 2.0 flows.
Support for streaming responses, which matters for long-running tools.

The practical consequence is that a single MCP server can expose a set of tools — search, create, update, delete against whatever backend — and any MCP-aware client can consume those tools without bespoke integration work.

Copilot Studio today supports the Streamable transport for MCP. (SSE, an earlier transport, was deprecated and is no longer supported after August 2025.) Authentication options include none, API key (either in a header or a query parameter), and OAuth 2.0 with three configuration modes: dynamic discovery, dynamic client registration, and manual.

Why MCP matters for Copilot Studio

Before MCP, extending an agent with a custom backend required building a Power Platform custom connector — writing an OpenAPI definition, handling authentication, registering the connector, and then adding individual actions to the agent. Each action was defined at the connector level, which meant versioning, deprecation, and permissions were all managed per connector.

With MCP, the server owns the tool catalog. When you connect an MCP server to a Copilot Studio agent, the server’s tools are discovered automatically. When the server adds a new tool, it becomes available to the agent without any change in Copilot Studio. When the server deprecates a tool, the change is visible server-side rather than scattered across agents.

For enterprises with many agents and many backends, this inverts a maintenance problem. Integration code moves to one server per domain, owned by the team that owns the backend. The agents consume it; they do not redefine it.

What MCP is not

MCP is not an agent-to-agent protocol. It describes how agents call tools, not how agents call each other. For agent-to-agent communication, the relevant standard is A2A.

MCP is also not a replacement for Power Platform connectors. Connectors remain the right choice when the backend requires complex per-user licensing, deep Dataverse integration, or features that benefit from the Power Platform management surface. MCP is the right choice when the backend is a discrete service with a stable API surface that multiple agents need to share. (Note that in Copilot Studio, MCP connectivity itself rides on Power Platform connectors, so connector-level data policies still govern MCP access.)

Finally, MCP is not, by itself, a security model. Any MCP server you connect must still enforce authentication and authorization; MCP defines the envelope, not the access rules. Recent public reporting on prompt-injection classes of vulnerability in agent platforms — including CVE-2026-21520, an indirect prompt-injection issue patched in Copilot Studio in January 2026 — underlines that adding tools of any kind, MCP or otherwise, expands an agent’s attack surface. Tools that write data deserve particular scrutiny.

A common pattern: the shared knowledge MCP

A frequent pattern in enterprise Copilot Studio deployments is a shared “knowledge retrieval” MCP server. It exposes tools such as:

search_policy(query, domain) — returns matching policy passages with citations.
get_policy(policy_id) — returns the full text of a policy.
list_policy_versions(policy_id) — returns version history.

Each of the organization’s agents — HR assistant, IT assistant, customer service assistant, compliance assistant — connects to this one MCP server and uses whichever tools it needs. When a new policy domain is added, it appears in all agents at once. When authentication is rotated, it rotates in one place. When a tool description is improved, every agent benefits.

Configuring an MCP server in Copilot Studio — the wizard path

Microsoft Copilot Studio offers more than one path to connect an MCP server. The native onboarding wizard, introduced in 2025, is the recommended path for most cases.

Open the Tools page of your agent. Every agent has a Tools tab alongside Knowledge, Topics, Instructions, and Agents.
Select Add a tool → New tool → Model Context Protocol. This opens the MCP onboarding wizard.
Provide the server details.
- Server name — a short name; this is what makers see when they browse tools.
- Server description — important. The description is what the orchestrator uses at runtime to decide whether to call this server. Be specific about what the server is for and what kinds of requests it handles.
- Server URL — the base HTTPS endpoint of the MCP server. The Streamable transport is current; SSE is no longer supported after August 2025.
Configure authentication. Three options:
- None — for read-only servers on trusted networks only.
- API key — in a request header or as a query parameter. The agent includes it in requests to the MCP server.
- OAuth 2.0 — preferred for anything involving identity. Three sub-options: dynamic discovery (simplest; works when the server supports OAuth 2.0 dynamic client registration with discovery), dynamic (DCR without discovery; you supply the authorization and token URLs), and manual (you supply client ID, client secret, authorization, token, and refresh endpoints explicitly).
Create the connection. The wizard validates the server, pulls the tool catalog, and registers the tools as available to the agent. Each tool appears in the agent’s tool list with its declared schema.

That is the entire configuration path for the common case. The effort goes into writing good tool descriptions on the server side, not into configuring the client.

Configuring an MCP server — the custom connector path

Before the native MCP integration, makers built a Power Apps custom connector with a specific x-ms-agentic-protocol: mcp-streamable-1.0 annotation. This path still works and is the right choice when you need:

Dynamic value lookups that feed MCP parameters from another API.
Custom URL rewriting (for example, to route one connector to multiple regional MCP endpoints based on a catalog service).
Fine-grained policy controls expressed at the Power Platform connector level, such as per-environment availability.

A Microsoft sample published in March 2026, “Dynamic MCP Routing in Copilot Studio,” uses exactly this approach: a single connector that resolves an instance dropdown via a catalog service and rewrites the URL at runtime. It is a useful reference for multi-tenant or multi-region requirements.

Configuring an MCP server — the Agents 365 (BYO MCP) path

A third path now exists for organizations standardizing on tenant-wide agent management: you can register an existing MCP server in Agents 365 using the Agents 365 CLI and the Microsoft 365 Admin Center. Once the server is registered and approved, it becomes available for use in Copilot Studio. This is the right path when MCP servers need to be governed centrally as bring-your-own (BYO) assets rather than connected ad hoc per agent.

Unless one of the custom-connector requirements applies — or you specifically want centralized Agents 365 governance — the wizard path is simpler and has fewer moving parts.

Tool descriptions are the production variable

One thing deserves emphasis, because it determines success in production more than any configuration detail: the description of each MCP tool, authored on the server. A tool description in MCP should state, clearly and concisely:

What the tool does.
When the agent should use it (which kinds of requests).
What it returns.
Any side effects (writes data, sends messages, charges money).

A description like “Search items” is nearly useless to the orchestrator. “Searches the internal policy library for HR, IT, and compliance policies; returns matching passages with citations; read-only” is specific enough that the orchestrator will route appropriately. When orchestration quality feels off — the agent is calling the wrong tool, or no tool at all — the first place to look is usually the descriptions.

6. The Agent2Agent (A2A) protocol

If MCP is how agents talk to tools, A2A is how agents talk to other agents. It is a separate open standard with its own specification, and — like MCP — it is supported natively in Microsoft Copilot Studio. A2A connections went generally available in April 2026. For multi-agent architectures that span platforms, teams, or vendors, A2A is the piece of the puzzle that keeps the system composable.

When A2A is relevant

A Copilot Studio agent can already call another Copilot Studio agent as a connected agent — that works entirely inside the Microsoft stack. A2A becomes relevant when the other agent is not a Copilot Studio agent. For example:

An agent built with the Microsoft 365 Agents SDK in code.
An agent hosted on the Microsoft Foundry Agent Service.
An agent built on a non-Microsoft framework (LangGraph, CrewAI, Google’s own A2A-compliant agents).
A partner’s agent exposed to your organization as a service.

Before A2A, connecting to such an agent meant writing a custom HTTP integration — handling the request shape, interpreting streaming responses, mapping authentication, and dealing with session state. A2A standardizes the contract so that any A2A-compliant client can talk to any A2A-compliant agent with no custom code.

What the protocol defines

Microsoft Learn describes A2A as “an open standard for communication and collaboration between agents.” The specification covers:

A standard contract for sending tasks to an external agent.
A mechanism for providing rich, structured metadata with the request — context, user identity, task parameters.
A predictable response format, including support for multi-turn interactions.
Interoperability across frameworks, so an agent built on any A2A-compliant platform can be called the same way.

Compared to a traditional HTTP connector — which is generic and was not designed for agent workflows — A2A is explicitly designed for the shape of agent interactions: multi-turn interactions and rich contextual metadata work natively, where an HTTP connector requires you to build those capabilities yourself.

Configuring an A2A agent in Copilot Studio — the correct path

External agents, including A2A-compliant agents, are added on the Agents page of the calling agent — not the Tools page. The Tools page is for MCP servers and connector-backed tools; the Agents page is where connected agents (Copilot Studio, Fabric Data Agent, Microsoft Foundry Agent Service, Microsoft 365 Agents SDK) and external A2A agents are registered.

The configuration steps:

Obtain the target agent’s A2A endpoint URL and authentication requirements from whoever owns it.
In the calling agent, open the Agents page.
Select Add an agent → Connect to an external agent → Agent2Agent.
Provide the A2A endpoint URL. If the agent publishes a valid agent card at the standard .well-known URL, Copilot Studio auto-populates the name and description; otherwise enter them manually. The description tells the orchestrator when to delegate to this agent.
Configure authentication. The options are None, API key (header or query parameter), and OAuth 2.0 (client ID, client secret, authorization URL, token URL, refresh URL). For enterprise scenarios, OAuth 2.0 paired with Entra ID is the sensible choice.
Create the connection and save.

Once registered, the A2A agent appears in the Agents list alongside connected Copilot Studio agents. The orchestrator invokes both kinds through the same delegation mechanism at runtime; only the configuration differs.

When to use A2A versus connected agents

A useful rule:

If both agents live in your Copilot Studio tenant, connected agents is the simpler choice. Lifecycle, authentication, and governance are all inside Power Platform.
If the other agent is built outside Copilot Studio — in code with the Microsoft 365 Agents SDK, on the Microsoft Foundry Agent Service, on another platform, or by a partner — A2A is the way to call it without custom plumbing.
If you want the same agent to be callable from Copilot Studio, from a custom app, and from another vendor’s agent, publishing it as an A2A agent turns it into a reusable unit across clients.

The two are not mutually exclusive. Many production systems mix: the orchestrator in Copilot Studio calls connected agents for Copilot-native specialists and A2A agents for specialists hosted elsewhere.

Three rules for robust agent-to-agent calls

These apply equally to connected agents and A2A agents.

Return structured data, not prose. The calling agent should not parse “I created ticket INC-12345 for you” to extract the ID. Design the called agent to return a structured result. Agent flows, connected agents, and A2A agents in Copilot Studio all support structured return types; use them.
Make the called agent idempotent. Retries must not create duplicate records. Every agent-to-agent call that writes data should accept an idempotency key and use it to deduplicate on the server side. This is particularly important for agents that create tickets, send email, or post messages, because retries are common under load.
Bound the conversation. A called agent should not call back into the calling agent. Structurally it is possible; in practice it produces loops that are expensive and hard to debug. Design the contract so the called agent has everything it needs as inputs, does its work, and returns.

Multi-turn versus single-turn

A2A supports both. Some tasks are single-turn — “look up this policy and return the passage.” Others are genuinely multi-turn — “help this user configure their integration, with clarifying questions as needed.” The A2A payload Copilot Studio sends includes a context ID, message IDs, locale, and full chat history, which makes multi-turn continuity possible.

Single-turn is the default and should be preferred when it applies. Multi-turn introduces state, which then has to be tracked somewhere — usually by the caller. For long-running processes, the hierarchical pattern with state stored in Dataverse is usually a better fit than keeping multi-turn state inside the A2A exchange.

Security considerations for A2A

The security model for A2A is the same concern that applies to any tool: the called agent is now part of your system’s trust boundary. A few practical implications:

The called agent’s identity matters. In Entra-governed tenants, use Entra Agent ID — first introduced in May 2025 and expanded to public preview at Ignite 2025 — to give each agent a first-class identity with scoped permissions. Copilot Studio can now auto-create a per-agent Entra identity (preview).
Scopes should be narrow. An agent that exists to summarize documents does not need write access to email.
Audit everything. Purview audit logs cover Copilot Studio activity; treat calls to external A2A agents the same way you would treat any outbound API call — logged, reviewed, and alertable. You are explicitly responsible for the data flows, quality, and security posture of agents you connect outside Copilot Studio.

7. Wiring child, connected, and A2A agents — all three configuration paths

Agent-to-agent delegation in Copilot Studio uses one of three mechanisms depending on where the called agent lives. Getting the mechanism right is what keeps the design from leaking through the architecture.

Configuring a child agent

Child agents are authored inside the parent agent. In current Copilot Studio they are a first-class sub-agent type — not merely topics — with their own instructions and, optionally, their own input and output variables.

In the parent agent, open the Agents page and create a child agent named after its responsibility (e.g., “Translate Text,” “Validate Expense Code,” “Summarize Ticket”).
Author its instructions and, where useful, define input and output variables so the parent can pass values in and read results out.
Give it a clear description so the orchestrator can route to it. You can also reference it directly in the parent’s instructions by typing / and selecting it.
Save; the child agent is immediately available within the parent.

Child agents share the parent’s tools, knowledge, and authentication, and there is no separate lifecycle. If you later need to reuse the child agent elsewhere, promote its logic into a connected agent. (You can also explicitly redirect to a child agent from within a topic using the Redirect node, which resumes the originating topic when the child agent finishes.)

Configuring a connected agent

A connected agent is a separately-published Copilot Studio agent (or a Fabric Data Agent (preview), an agent on the Microsoft Foundry Agent Service (preview), or one built with the Microsoft 365 Agents SDK (preview)) that this agent calls.

Ensure the target agent is published in the same environment and that you have permissions to use it.
In the calling agent, open the Agents page → Add an agent.
Select the target agent from the list of available agents in the environment.
Provide a short description of when the calling agent should delegate to this agent. This description, distinct from the target agent’s own description, is what the orchestrator uses to decide.
Define the input contract: what the calling agent will pass. Keep this to the minimum needed.
Define the expected return shape. Connected agents that return structured data are easier to compose; prefer structured returns to prose.
Save.

A typical example: a “master” agent that routes HR questions to an HR agent and IT questions to an IT agent. Each specialist is a connected agent in its own right. The master holds only routing logic and a short “what I am” instruction. Each specialist holds its own knowledge (HR policies versus IT runbooks), its own tools (Workday connector versus ServiceNow connector), and its own owner.

Remember the one-level nesting rule: an agent that already has connected agents can be a main agent, but cannot itself be added as a connected agent to another main agent.

Connecting to a Fabric Data Agent

Fabric Data Agents (preview) are a specific type of connected agent that brings governed, schema-aware analytics into a conversational flow. They are configured the same way as any other connected agent, but the target is a Fabric Data Agent published in your Fabric environment.

The practical value is that the agent can answer data questions with governed retrieval — row-level security, sensitivity labels, and column-level policies all apply — without the calling agent having to reimplement those controls. (Note a current limitation: Fabric Data agents can’t be reached via the topic Redirect node or referenced directly in instructions.)

Configuring an A2A agent

A2A is used when the target agent is hosted outside Copilot Studio. The configuration steps:

Obtain the target agent’s A2A endpoint URL and authentication requirements from whoever owns it.
In the calling agent, open the Agents page.
Select Add an agent → Connect to an external agent → Agent2Agent.
Provide the endpoint URL (the communication endpoint, not the agent-card URL) and a description that tells the orchestrator when to use this agent.
Configure authentication — None, API key, or OAuth 2.0 (with Entra ID the sensible choice for enterprise scenarios).
Create the connection and save.

Once registered, the A2A agent appears in the Agents list alongside connected and child agents. The orchestrator invokes all three through the same delegation mechanism at runtime; only the configuration differs.

Contracts between agents

Whichever mechanism you use, the contract between the calling and called agent is where production reliability is won or lost.

Input contract. Pass only what the child needs, and only structured values where possible. Passing the entire conversation history “in case it helps” reliably produces slower, less predictable calls.
Output contract. Structured returns — typed records or JSON — are dramatically easier to compose than prose. Copilot Studio supports structured outputs from connected agents natively; define them explicitly rather than relying on the orchestrator to parse text. (Be aware that citations are not always preserved when outputs pass back to the caller.)
Error contract. Decide in advance what the called agent returns when it cannot complete the task. A common convention: return {status: "not_found"}, {status: "unauthorized"}, or {status: "error", message: "..."} rather than conversational refusals.
Idempotency. Any called agent that writes data should accept an idempotency key from the caller. Retries, which happen under load more often than teams expect, must not create duplicate tickets, emails, calendar events, or database rows.

Avoiding loops

Because Copilot Studio allows any agent to call any other agent, circular delegation is structurally possible: Agent A calls Agent B, which calls Agent A. The orchestrator will happily execute this until timeout or token exhaustion.

The architectural rule: child agents do not call back into their parents. If the specialist needs something the parent has, design the parent to pass it down as an input. If the specialist truly needs to coordinate with the parent, the design is not yet right — usually the work belongs in the parent, or the responsibility split is incorrect.

Governance: who owns which connection

When the graph of agents grows beyond a handful, ownership matters. The Power Platform Admin Center’s Copilot Hub gives admins usage, cost, and governance insight for Copilot Studio agents; the agent inventory — now exposed as a schema you can query from the admin center, API, or Azure Resource Graph (preview) — lists every agent and the features it uses. At the tenant level, Microsoft Agent 365 (early access, Ignite 2025) and the Microsoft Entra agent registry provide cross-platform agent identity and observability.

Practical governance steps:

Assign a primary owner to every agent. Ownership is a Dataverse attribute; it also answers the question “who gets paged when this breaks.”
Use Entra Agent ID (introduced May 2025; expanded to public preview at Ignite 2025) to give each agent a first-class identity. Scoped permissions then apply per agent rather than per maker — and per-agent identities can now be auto-created in Copilot Studio (preview).
Treat A2A connections to external agents as supply-chain dependencies. Document who operates them, review their security posture, and log calls through Purview.

8. What the combination of MCP and A2A enables

With MCP for tools and A2A for agents, a Copilot Studio tenant becomes a composition layer rather than a monolith. An orchestrator can call:

Its own child agents for low-complexity sub-routines inside the parent.
Copilot Studio connected agents for specialists owned inside the tenant.
MCP servers for shared tool catalogs owned by backend teams.
A2A agents for specialists built in code or hosted on other platforms (with Microsoft Foundry, Fabric, and M365 Agents SDK connections in public preview).

All four mechanisms are available today, documented on Microsoft Learn, and — where generally available — in production use; the preview connections are usable now with the usual preview caveats.

This is the meaningful change MCP and A2A introduce: integration work moves from being duplicated per agent to being centralized per domain (for tools) and per agent (for cross-platform agents). The remaining decisions — what the specialists are, who owns them, how they are described, what contracts they expose — become the visible bottleneck again. That is a healthy state, because those decisions are the ones that actually determine whether a multi-agent system works.

Conclusion

If you take five things away from this article, they are these.

First, multi-agent orchestration is an architectural response to scope drift, not a fashion. Splitting an agent is a decision with cost. Make it when you see the documented signals — tool counts approaching 30 to 40, multiple owners, conflicting knowledge, divergent SLAs — and avoid it when the cheaper fix (tighter instructions, scoped knowledge, a Power Automate flow) would do.

Second, the five surfaces are not interchangeable. Instructions hold judgment (within an 8,000-character limit). Knowledge holds retrievable text. Tools hold actions. Topics hold reproducible flows. Triggers hold the answer to “when does this agent run.” Putting behavior on the wrong surface — large rule tables in instructions, deterministic compliance flows in generative nodes — is the most common cause of unreliable agents.

Third, the four patterns cover the work. Router-worker, sequential pipeline, parallel fan-out, hierarchical. Most production systems mix two or three. None of them require features that do not exist in Copilot Studio today.

Fourth, MCP and A2A are the two open standards that keep the system composable. MCP centralizes tool integration per domain. A2A makes cross-platform agent calls portable. Neither is a replacement for the other, and neither is a security model on its own. Both expand the trust boundary; treat them accordingly.

Fifth, the configuration paths are not interchangeable either. MCP servers are added on the Tools page via the MCP wizard. Child agents are created on the Agents page inside the parent. Connected agents and A2A agents are also added on the Agents page — connected agents from the available agents in the environment, A2A agents via Add an agent → Connect to an external agent → Agent2Agent. Getting the path right is mechanical, but it is also where teams lose hours when they assume the wrong starting point in the UI.

Part 2 picks up from here and works through the practical side: four end-to-end scenarios — IT incident triage, contract review, field service dispatch, employee onboarding — each on a different orchestration pattern, followed by a starter MCP server inventory and the ten anti-patterns that recur in production deployments. Read Part 1 to settle the architectural decisions; read Part 2 to see them executed.

Sources

Microsoft Learn — Explore multi-agent orchestration patterns
Microsoft Learn — Add other agents (overview) — source of the documented 30–40 choices-of-action threshold, child-agent definition, and preview status of Foundry/Fabric/M365 Agents SDK connections
Microsoft Learn — Quotas and limits — 8,000-character instruction limit
Microsoft Learn — Power Platform connectors reference — the 1,000+ connector catalog
Microsoft Learn — Connect your agent to an existing Model Context Protocol (MCP) server — wizard path, Streamable transport, SSE no longer supported after August 2025, BYO MCP via Agents 365
Microsoft Learn — Connect an agent available over the Agent2Agent (A2A) protocol
Microsoft Learn — What’s new in Copilot Studio — A2A GA (April 2026), Computer Use GA (May 2026), per-agent Entra identities (preview), agent inventory schema (preview)
Microsoft Copilot Studio blog — What’s new in Copilot Studio: March 2025 — autonomous agents and generative orchestration GA
Microsoft Learn — Event trigger overview — documented event triggers
Microsoft Learn — Copilot Studio real-world transformation stories — ABN AMRO, Rabobank, Dunaway, Nexi Group, City of Montréal, Singapore Civil Defence Force, T-Mobile, Holland America Line, La Trobe University, Signetic, A1 Inteligência em Viagens
Microsoft Learn — What’s new at Ignite 2025 for Microsoft Entra — Entra Agent ID
Microsoft Learn — Copilot Hub in the Power Platform Admin Center
Microsoft Learn — Copilot Control System overview
Microsoft CopilotStudioSamples — Dynamic MCP Routing in Copilot Studio
Model Context Protocol — Official specification and SDKs
Agent2Agent protocol — Open specification
VentureBeat — Microsoft patched a Copilot Studio prompt injection. The data exfiltrated anyway. — CVE-2026-21520 coverage, April 2026

Teams Phone Agent and Custom Voice Agents in Copilot Studio: A Practitioner's Guide

Sat, 27 Jun 2026 00:00:00 +0000

Summary lede: Microsoft Teams Phone now has a conversational AI front door. Teams Phone Agent is a new, configurable out-of-the-box experience that greets callers in natural language and resolves common requests — questions and answers, appointment scheduling, and conversational routing across 60+ languages — without any custom code. When a request is specific to your business, a custom voice agent built in Microsoft Copilot Studio takes over, either through a seamless hand-off or by direct dial to a phone number. Both capabilities arrived through Microsoft’s Frontier program in June 2026, are tenant-gated, and the custom-agent path is billed by consumption.

Why read this article Teams Phone has always routed calls with auto attendants and call queues. What changed is that the routing layer can now understand spoken intent and act on it — answering questions from a knowledge base, booking an appointment, or completing a business-specific workflow such as a prescription refill or an outage report. This is not a forced change for every Teams user. It is a deliberate capability for Teams Phone administrators, contact-center-style teams, Copilot Studio makers, and finance and compliance stakeholders who need to review, preview, gate, bill, route calls, manage data sources, and define fallback paths before AI ever answers a live customer call. This guide ties those decisions to the configuration steps.

Three things define the current state of this feature set:

Two layers, one call flow. Teams Phone Agent provides built-in skills you configure (Q&A, Appointments, conversational routing). Copilot Studio voice agents provide custom workflows you build. They are designed to work together inside a single call flow.
Frontier Public Preview, tenant-gated. Both capabilities entered Frontier Public Preview in mid-June 2026. The Copilot Studio integration is explicitly gated — Microsoft support must enable your tenant before the Teams Phone channel option appears.
Consumption billing for custom agents. Copilot Studio voice agent experiences are billed consumptively at a rate based on the orchestration type selected when the agent is built. Billing rolls out by early July 2026; no usage will be charged before then.

Confidence and currency note. This article describes a preview feature set as documented in June 2026. Preview features are not intended for production use, may have restricted functionality, and are subject to change. Capabilities, gating, regional support, and especially pricing and service limits will change at general availability. Re-verify every commercial and technical detail against the current Microsoft Learn documentation and the Teams admin center before committing to a rollout.

Scope. This article covers Teams Phone Agent’s built-in skills, custom Copilot Studio voice agents (hand-off and direct-dial patterns), the supporting auto-attendant/call-queue model, setup in the Teams admin center and Copilot Studio, preview gating, and consumption billing. Detailed Power Platform / Copilot Studio licensing economics, contact-center seat licensing, and third-party agent SDKs are out of scope and referenced only where they intersect with setup.

Where this fits — use cases, and why it doesn’t cannibalize Dynamics 365 Contact Center

Possible use cases. Teams Phone Agent and Copilot Studio voice agents are aimed at organizations whose phone system is Teams Phone, and that want to add conversational self-service to their existing call flows. The natural fits are front-door deflection and after-hours coverage:

a clinic answering hours, location, and insurance questions and handling appointment reschedules;
a bank branch understanding intent and routing a mortgage caller to the right team with context;
a pharmacy taking prescription-refill and order-status requests;
a utility letting customers report an outage or get billing help at 2 a.m.;
a home-services firm confirming or moving a booking without staff. Inside larger enterprises that already have Teams Phone, the same pattern serves internal lines:
IT helpdesk, HR, facilities — and acts as an overflow or out-of-hours tier in front of human queues that would otherwise drop to voicemail. The common thread is high-volume, repetitive, rules- or knowledge-driven calls that don’t require a trained agent.

Why this isn’t cannibalizing Dynamics 365 Contact Center.

The two products serve different operating models, and Microsoft has deliberately built them as a continuum rather than competitors. Teams Phone Agent is an extension of the telephony layer — it modernizes auto attendants and call queues for businesses that don’t run, and don’t want to run, a dedicated contact center. Dynamics 365 Contact Center is a full CCaaS platform: unified omnichannel routing across voice, chat, email, and social; a managed agent desktop with Copilot assist; queue and workforce management; quality and compliance tooling; CRM-agnostic system-of-record integration; and the operational analytics a supervised contact-center team depends on. Teams Phone Agent delivers none of those agent-operations capabilities, and it isn’t trying to — so it can’t displace the customers who need them. Crucially, both rest on the same Copilot Studio agent foundation: the custom voice agents you attach to Teams Phone are built in Copilot Studio, and the AI agents inside Dynamics 365 Contact Center draw on that same agentic platform and consumption model. That shared base means an organization grows along the curve — start with a Teams Phone Agent front door, and when call volume, omnichannel scope, or staffed-agent operations outgrow it, step up to Contact Center without abandoning the agent investment. The commercial models reinforce the split: Teams Phone Agent is a consumption-billed add-on to existing Teams Phone, while Contact Center is a per-seat CCaaS subscription. Different problem, different buyer, different price shape — complementary tiers of one Microsoft voice-AI story, not overlapping bets.

1. What changed and why it matters

It is often difficult for businesses to serve every customer immediately during surges in call volume. Callers sit on hold while staff work through the backlog. Meanwhile, agentic voice AI is opening new ways to serve customers — answering questions, scheduling appointments, or even completing transactions over the phone, including after hours and on weekends.

Teams Phone Agent and the ability to bring custom Copilot Studio voice agents to Teams Phone address this directly. For customer-facing organizations using Teams Phone — healthcare clinics, bank branches, utilities, pharmacies, service businesses — these agents take repetitive calls off employees’ plates, so people can focus on the conversations that genuinely need a human touch, and customers reach resolution faster.

The goal is not to remove humans from every call. It is to reduce repetitive call handling so staff can focus on complex or sensitive conversations. Instead of relying solely on traditional auto-attendants, keypad menus, and human staff, organizations can now offer conversational phone experiences that understand spoken requests and respond naturally.

The design principle that matters most. Teams Phone Agent sits inside your call flow. It should be designed as a business process — greeting, knowledge sources, routing rules, escalation, after-hours behavior — rather than switched on as a generic AI receptionist. Every flow needs a deliberate happy path, escalation path, and after-hours path.

2. The out-of-the-box experience — Teams Phone Agent

Teams Phone Agent greets callers and resolves common requests using a set of built-in skills you configure rather than build. This is the new, preview, out-of-the-box layer: administrators enable it in the Teams admin center and point it at content and routing targets. Four capabilities ship in the box.

Capability	What it does	Example use case
Questions & Answers	Answers caller questions from configured knowledge bases that support file uploads and URLs, in natural conversation.	A clinic answers questions about hours, locations, accepted insurance, and appointment preparation.
Appointment scheduling	Lets callers book, reschedule, or cancel appointments and look up upcoming appointment details.	A home-services company lets a customer change a plumbing or electrical repair booking without waiting for staff.
Conversational routing	The same tried-and-tested routing as traditional auto attendants — user or extension lookup, transfer to a user or call queue, and more — driven by what the caller says.	A bank caller asking about a mortgage application is understood and sent to the right team.
Context-aware transfer	When a human is needed, the caller is passed along with the full conversation context.	The customer does not have to repeat the entire issue after the transfer.
Multilingual	Supports conversations across 60+ languages, so callers interact naturally in their preferred language.	A branch or service desk supports callers in multiple languages at scale.

The decisive practical point: callers skip cumbersome phone menus and do not have to repeat themselves, while the organization keeps the proven routing model underneath.

A regional clinic’s old line opens with “Press 1 for appointments, press 2 for billing, press 3 for hours and location…”. Most calls are about hours, directions, and appointment changes.

Before: every caller navigates the menu; appointment changes route to a front-desk queue that is busy at peak.
After (Teams Phone Agent): the agent answers hours and directions instantly from a knowledge base (uploaded files + the clinic website URL), handles reschedules and cancellations directly, and only conversationally transfers genuine billing questions to staff — with context attached.

Rule of thumb: if a question is answered from published content or a task is a structured booking change, it belongs in the built-in skills. If it requires a system of record (billing balances, prescription records), it belongs in a custom Copilot Studio agent — see §3.

3. The custom layer — Copilot Studio voice agents

The built-in Q&A and appointment tools cover common ground. When you need to automate processes unique to your business — letting a patient fill a prescription over the phone, a customer pay or query a bill, or a caller check order status — custom voice agents built in Microsoft Copilot Studio step in. This functionality is beyond what the built-in Appointments and Q&A tools provide.

There are two ways to bring a Copilot Studio voice agent into Teams Phone.

Pattern	How it works	When to use it
Hand-off	Teams Phone Agent handles greeting and routine requests, then seamlessly hands the call to a custom Copilot Studio agent when a specialized skill is needed. You want a single conversational front door that escalates to specialized workflows.
Direct dial	A Copilot Studio voice agent is attached directly to a phone number via a Teams Phone resource account, so callers reach it as the first point of contact.	You are upgrading an existing IVR or want a dedicated line for a specific workflow.

3.1 What you can build

Copilot Studio is a platform for building custom workflows tailored to your business:

Custom workflows — specialized voice topics and conversational logic (billing, refills, order/inventory status, and more).
Extensible integrations — connect the agent to CRM systems, internal knowledge bases, and other line-of-business systems.
Routing via Tags — pass dynamic transfer information from Teams to Copilot Studio so the agent can route to call queues, auto attendants, specific users, and more, without hardcoding values. Tags are what let one agent scale across many departments and transfer targets.

By front-ending a call flow with a Copilot Studio voice agent, the agent acts as an intelligent first point of contact, resolving issues independently before routing to a human using traditional Teams Phone routing if needed.

Supported agent types and one-way settings. Only basic voice agents are supported on this channel — real-time voice agents are not supported. Changing an agent’s voice type is an irreversible action. Under Settings → Generative AI → Orchestration, select classic orchestration; generative orchestration is not supported here and can introduce heavy latency (reported 5–6 second delays) and unexpected charges.

3.2 Real-world examples

Pharmacy. A custom voice agent lets customers request a prescription refill by phone and check order status — a simpler way to manage routine needs without waiting for staff.
Utility provider. A custom agent connected to Teams Phone lets customers report an outage or get billing help outside normal business hours.

4. The foundation — auto attendants, call queues, and “Agents and Queues”

None of this replaces the planning discipline Teams Phone already requires. Teams Phone Agent, auto attendants, and call queues are planned and licensed together as one family, and the classic building blocks still apply.

Auto attendants redirect calls immediately or by dial option, allow dial-by-name or extension, route to voicemail / external numbers / other voice apps, and handle off-hours and holiday routing separately.
Call queues hold callers until an agent is free and redirect on overflow, timeout, or agent availability — to other queues, attendants, voicemail, or external destinations.

Teams Phone Agent adds a conversational layer on top of and alongside these. Custom Copilot Studio agents that are published to the Teams Phone channel automatically appear in the Agents and Queues list in the Teams admin center, ready to be wired into a call flow.

4.1 Business decisions to settle first

Microsoft’s planning guidance asks you to document the same business decisions up front, now extended for AI voice. Capture the answers and hand them to whoever does the configuration:

How do callers reach you? Internal only, external, or click-to-call on the web?
Which languages are needed, and for which department or group?
Voice or dial input — Do you allow spoken input, or keypad only?
Off-hours and holiday routing — what are the hours and holidays?
Knowledge sources — which files and URLs feed the Q&A tool?
Fallback and escalation — where does an unresolved call go, and does the human handoff carry context?
Compliance — are there call-recording or other regulatory requirements?

Authorized users. Day-to-day operational changes — business, after-hours, and holiday greetings; call routing; queue membership; reporting — can be delegated to authorized users who do not need Teams admin center access or a Teams Administrator role, with no extra licensing required.

5. Setup at a glance

5.1 Built-in Teams Phone Agent

Teams Phone admins configure Teams Phone Agent in the Teams admin center under Voice → Templates & resources → Agents and Queues, setting up the Q&A and Appointments tools, conversational routing, holidays, and greetings. Standard Teams Phone prerequisites apply, including a properly configured Teams Phone resource account.

5.2 Custom Copilot Studio agent — hand-off pattern

Build the voice agent in Copilot Studio.
Settings → Generative AI → Orchestration → Classic orchestration (generative is not supported here).
Settings → Security → Authentication → No authentication (required so callers can reach the agent), then Save.
Channels → Teams Phone Agent → Add channel, wait for confirmation, then Publish. (If the channel option is not visible, your environment is not enabled — see §6.)
In the Teams admin center, open your Teams Phone Agent call flow, Assign a dial key → destination: Agents and Queues, enter a voice command and description, optionally link a Tag template, and select your published agent.
Call in to confirm the hand-off works.

5.3 Custom Copilot Studio agent — direct-dial pattern

Teams admin center → Voice → Resource accounts → Add. Create a resource account with type AI Agent, with a display name, username, and domain.
License the resource account. In the Microsoft 365 admin center, assign the Teams Phone Resource Account license to that account and let the change propagate.
Link the agent. Back in Resource accounts → Edit, set the Agent Source to your Copilot Studio voice agent. Optionally set a voice routing policy and assign a phone number (Calling Plans, Operator Connect, or Direct Routing). Optionally attach a Tag template.
PowerShell cmdlets are available for scripted setup.

No phone number? If you do not assign a phone number to the resource account, only users in your tenant can reach the agent over VoIP via the Teams client.

5.4 Using Tags for Transfers

After attaching a tag template in the Teams admin center, configure the Copilot Studio agent to act on the tag values: add a topic with a “User says a phrase” trigger (for example, “transfer” or “escalate”), ask the caller to choose a department using the tag names as options, then use Topic Management → Transfer conversation → Transfer to agent, passing the caller’s choice as the transfer target. Publish the agent again. The agent can now transfer to the targets defined in your tag template.

Environment and regional constraints (Copilot Studio). Create the Copilot Studio environment in a supported region (for example, US, UK, Europe, Canada, Australia, Asia, Korea, Norway, Sweden, Switzerland, UAE). Voice agents are not supported in environments in France, Germany, India, Japan, or South Africa — though tenants based in those countries can still use voice agents hosted in a supported region. The Power Platform environment must have “Get new features early” = No and “Add a Dataverse data store” = Yes. Choose the region closest to your callers to minimize latency.

6. Availability, gating, and licensing

This is firmly a preview, and the access and commercial model matter before any pilot.

Item	Current state (June 2026)
Program	Frontier Public Preview. Both Teams Phone Agent and the Copilot Studio integration entered Frontier Public Preview in mid-June 2026.
Gating	The Copilot Studio ↔ Teams Phone integration is explicitly enabled per tenant. Contact Microsoft support to enable it; until then, the Teams Phone channel option does not appear in Copilot Studio.
Teams Phone prerequisites	Standard Teams Phone prerequisites, including a properly configured resource account and the relevant Teams Phone licenses for your scenario.
Copilot Studio licenses	A Copilot Studio tenant license (to run and publish agents) and a Copilot Studio user license (to build them).
Built-in Teams Phone Agent	Available via the Frontier program; service limitations may apply.

6.1 How custom agents are billed

Custom Copilot Studio voice agent experiences — whether reached through a Teams Phone Agent handoff or by direct dial — are billed consumptively, at a rate based on the orchestration type your organization selects when building the agent in Copilot Studio.

Billing timeline. Billing for Copilot Studio voice agent experiences in Teams Phone was set to roll out by early July 2026, and usage is not charged before that rollout. When billing goes live, all Frontier preview users must set up billing to keep using Copilot Studio voice agents for Teams Phone. All licensing, pricing, and service limits are subject to change, with more details expected at general availability.

6.2 Cost-control practices

Use classic orchestration to avoid unexpected charges and reduce latency.
Scope each agent narrowly to the processes it supports — overly broad agents produce unexpected responses and unpredictable costs.
Test thoroughly with proper guardrails before exposing an agent to callers; how you build the agent significantly shapes the customer experience.

7. An expanding ecosystem

Microsoft is positioning this as a platform with choice across first- and third-party voice agents. Alongside first-party Teams Phone Agent and Copilot Studio agents, Microsoft is working with select solution developers to integrate their voice agents with Teams Phone. AudioCodes announced general availability of its voice agent for Teams Phone at launch, with additional solutions expected. Organizations can mix the built-in experience, custom Copilot Studio agents, and certified third-party agents within the same Teams Phone call flows.

8. Real-world example — a phased pilot

A 40-branch bank wants to reduce hold times on its retail support line without risking a poor first AI experience.

Phase 1 — out-of-the-box only. Enable Teams Phone Agent on a single non-critical line. Configure Q&A from published FAQs (hours, locations, card-replacement steps) and conversational routing to existing queues, with context-aware transfer to a human for anything unresolved. No custom build, no consumption billing.
Phase 2 — one custom workflow. Once the front door is proven, build a single, narrowly scoped Copilot Studio agent for one high-volume task (for example, “report a lost card”) integrated to the system of record, using classic orchestration. Validate the cost against the consumption meter before widening.
Phase 3 — scale and route. Use Tags so one agent serves multiple departments, and add after-hours coverage where a human queue previously sent callers to voicemail.

Why this order: It separates the zero-cost, no-code value (Phase 1) from the consumption-billed custom value (Phase 2+), so the organization can prove customer experience and measure cost before committing.

9. Conclusion

Teams Phone Agent turns Teams Phone from a routing-and-queueing system into a conversational AI front door. The out-of-the-box experience — Q&A, appointment scheduling, conversational routing, context-aware handoff, and 60+ languages — covers routine calls with no code. Custom Copilot Studio voice agents extend it to the workflows unique to your business, accessible via handoff or direct dial. Underneath, the classic auto attendant and call queue model keeps escalation and after-hours paths intact.

For now, this is a gated Frontier preview with consumption-based billing for custom agents. The disciplined move is a scoped pilot: pick one high-volume, low-risk flow; deliberately design the happy, escalation, and after-hours paths; confirm the human handoff carries context; and validate cost with classic orchestration before widening. The technology is ready to trial — the discipline is in treating every voice agent as a designed business process, not a switch you flip.

This article will be revised as the feature set moves toward general availability. Expect changes to gating, regional support, supported agent types, and especially pricing and service limits.

Glossary - for those new to Teams Phone and Copilot Studio

Term	Expansion
AI Agent (resource account type)	A Teams Phone resource account type used to attach a Copilot Studio voice agent directly to a phone number for direct dial.
Auto Attendant (AA)	A Teams Phone voice application that greets callers and routes them by menu, dial-by-name, or extension, with separate off-hours and holiday handling.
Call Queue (CQ)	A Teams Phone voice application that holds callers until an agent is available and redirects on overflow, timeout, or agent availability.
Classic orchestration	The Copilot Studio orchestration mode required for the Teams Phone channel; uses deterministic topic flows. Generative orchestration is not supported here.
Direct dial	Pattern where a Copilot Studio voice agent is attached directly to a phone number via a resource account, acting as the first point of contact.
Frontier program	Microsoft’s early-access program through which Teams Phone Agent and the Copilot Studio integration are currently delivered.
Handoff	Pattern where Teams Phone Agent passes a call to a custom Copilot Studio voice agent for a specialized workflow.
IVR	Interactive Voice Response — the automated voice menu or bot at the start of a call.
MCS	Microsoft Copilot Studio — the platform for building custom voice and chat agents.
Resource account	A licensed, non-user account in Teams Phone to which voice applications (auto attendants, call queues, voice agents) and phone numbers are assigned.
Tags	A mechanism to pass dynamic transfer information from Teams to a Copilot Studio agent, identifying next steps and transfer targets without hardcoding values.
Teams Phone Agent	The configurable, out-of-the-box conversational AI experience for Teams Phone, providing built-in Q&A, appointment, and routing skills.

Sources and Links (primary)

Understanding Microsoft Power Platform Licensing: A Practitioner's Reference

Sat, 30 May 2026 00:00:00 +0000

Summary lede: Power Platform licensing is now a hybrid of seat-based user licenses, pooled consumption credits, and MAU-based web access, and small architecture choices can materially change total cost. This guide maps the recent changes — Copilot Credits replacing messages, the April 2026 Dataverse accrual figures in the licensing guides, and the expansion of Dynamics 365 Contact Center / Customer Service bundles — into practical sizing and purchasing decisions with source-backed pricing.

Why read this article Microsoft’s business-application licensing surface is a three-pillar commercial design that nobody encounters as a single coherent story: per-user subscriptions for the seat-based products (Power Apps, Power Automate, Dynamics 365 apps, Contact Center), capacity-based consumption metering for Dataverse and Copilot Studio Copilot Credits, and monthly-active-user packs for citizen-facing Power Pages portals. The result is that two near-identical projects can land on wildly different invoices depending on a handful of design decisions made by an architect who may never have read a licensing guide.

The last twelve months changed the math in three places that matter:

Dataverse per-user accrual reporting (April 2026 licensing guides). The April 2026 Power Platform and Dynamics 365 Licensing Guide PDFs report meaningfully higher per-license accrued storage for Power Apps Premium and several Dynamics 365 SKUs than prior revisions did. Microsoft’s live pricing pages still display the previous per-user figures (e.g., 250 MB DB / 2 GB File for Power Apps Premium) — meaning the guide PDF and the marketing page disagree at the time of writing. This article cites the live pricing page as the conservative number and flags the guide-PDF uplift where it appears. Verify against the current PPLG PDF before sizing.
Late 2025 — Copilot Studio “messages” became “Copilot Credits.” The meter was renamed and the per-event rates revised. Copilot Credits now pool across Copilot Studio agents AND the AI agents shipped inside Dynamics 365 Contact Center, Customer Service, and (per Microsoft messaging at the time of the rebrand) Sales-side AI agents.
2024–2026 — Dynamics 365 Contact Center as a standalone, CRM-agnostic CCaaS SKU, plus the Customer Service Premium bundle ($195/user/month = Customer Service Enterprise + Contact Center).

This article is the reference that ties the structural decisions to the line items. Every numeric claim has a source URL. Every section closes with a real-world example that shows why a customer would choose one option over another. Read this before sizing a Power Platform deployment, scoping a Copilot Studio agent, or negotiating a Dynamics 365 renewal.

Confidence note. Prices and entitlements published on Microsoft’s own public pricing pages are HIGH confidence at the time of writing. The following are MODERATE confidence and should be re-verified against the current Microsoft Licensing Guide PDFs before any commercial commitment:
(a) per-user Dataverse accrual figures from the April 2026 Power Platform / Dynamics 365 Licensing Guides where they exceed the live pricing-page figures;
(b) Copilot Studio Copilot Credit per-event billing rates (the meter was rebranded in late 2025 and the published rates have moved);
(c) Customer Service Enterprise omnichannel add-in USD list prices — confirmed via Microsoft community channels and partner aggregators, not the public pricing page;
(d) the Premium step-up SKU reported as introduced in March 2026. Treat MODERATE-confidence items as anchors for a discussion with your Microsoft account team or CSP partner, not as final quoted prices.

Scope. This article covers Power Apps, Power Automate, Power Pages, Microsoft Copilot Studio, Microsoft Dataverse, Dynamics 365 Contact Center, and Dynamics 365 Customer Service. The following are deliberately out of scope and are NOT addressed: Power BI (separate Pro / PPU / Premium licensing model), Dynamics 365 Sales, Field Service, Business Central, Finance, Supply Chain Management, Project Operations, Commerce, Customer Insights – Data, Customer Insights – Journeys, Industry Clouds, and Microsoft Fabric. Government cloud SKUs (GCC, GCC High, DoD), Education (A-SKUs), and Nonprofit pricing are referenced only briefly in §6.

1. Power Platform (Core)

1.1 Power Apps

Power Apps in 2026 has three commercial purchase paths and one free developer path.

SKU	List price (USD)	Entitlement
Power Apps Premium (per user)	$20 / user / month	Unlimited custom canvas + model-driven apps and Power Pages portals (run-time). Includes Premium connectors, custom connectors, on-prem data gateway, and 250 MB Dataverse database + 2 GB Dataverse file accrued capacity per user as displayed on the live Power Apps pricing page. The April 2026 Power Platform Licensing Guide PDF reports a higher figure — see §3.2 for the discrepancy and how to read it.
Power Apps per App (per user per app)	$5 / user / app / month	One app or one portal per “pass.” Dataverse is limited to that app’s scope: 50 MB DB / 400 MB file per user per pass. 5-pack minimum has been removed.
Power Apps Pay-as-you-go	$10 per active user per app / month	Consumption-billed through an Azure subscription. An “active user” is any user who launches the app within a calendar month.
Power Apps Developer Plan	Free	Build/test against a personal developer environment; no production rights.

Sources: Power Apps pricing, Power Platform Licensing Guide April 2026 (PDF).

Per-App SKU status flag. Microsoft announced end-of-sale of the Power Apps per App SKU on January 2, 2026 for new commercial customers. In early April 2026, Microsoft reversed and reinstated the per-App SKU on the public price list. The April 2026 licensing guide reflects per-App as a current offer. This is the kind of change a future revision of this article will capture in the changelog.

Standard vs Premium connectors — the core licensing fault line

Microsoft splits its 1,500+ certified connectors into two classes, enforced both at the connection-add step and at runtime (connector reference):

Standard connectors — included with any Microsoft 365 / Office 365 commercial plan. Examples: SharePoint, Outlook 365, OneDrive for Business, Teams, Excel Online Business, Planner, Dataverse for Teams.
Premium connectors — require a paid Power Apps / Power Automate license, a per-app pass, or PAYG. Examples: SQL Server, Azure SQL, Dataverse (full), HTTP, all custom connectors, all third-party SaaS connectors (Salesforce, SAP, Oracle, ServiceNow, Workday, Zendesk).

The moment an app or a flow touches one Premium connector, every user of that app or flow needs a Premium license. There is no “occasional use” carve-out.

Seeded Microsoft 365 / Office 365 entitlements

Every commercial M365 plan (Business Basic/Standard/Premium, E3, E5, F3, A3, A5, G3, G5) grants:

Power Apps for Office 365 — build/run canvas apps using Standard connectors only; no access to full Dataverse.
Power Automate for Office 365 — cloud flows using Standard connectors only, with 6,000 API requests per user per 24 hours (API request limits and allocations).

These rights specifically exclude full Dataverse, all Premium and custom connectors, the on-prem data gateway, and AI Builder.

Microsoft 365 F-series caveat. F1 and F3 (Frontline) plans grant reduced seeded Power Platform rights compared with E3/E5: F1 has effectively no app-authoring entitlement, and F3 includes canvas + Standard connectors with tighter API limits. Architects planning frontline-worker deployments cannot assume the same entitlements that appear in E-series guidance.

Real-world example — Premium vs per App

A 500-employee manufacturer deploys three line-of-business Power Apps (HSE incident reporting, plant visitor management, asset-walk inspection), each connecting to Dataverse and Azure SQL.

Premium path: 500 × $20 = $10,000 / month. Every user can run all three apps and any future apps.
Per-App path: Three apps × $5 × 500 = $7,500 / month — only if every user uses every app. If usage is segmented — 200 users on HSE, 300 on visitor management, 100 on asset-walk — the math becomes (200 + 300 + 100) × $5 = $3,000 / month.

Rule of thumb: Premium wins when most users run most apps. Per-App wins when usage is role-segmented and the user count per app is well below the total workforce.

1.2 Power Automate

SKU	List price (USD)	Entitlement
Power Automate Premium (per user)	$15 / user / month	Unlimited cloud flows with Premium connectors, one attended RPA bot (desktop flow in attended mode), Process Mining (basic), AI Builder credits pool access (until November 2026). 40,000 API requests / user / 24 h.
Power Automate Process (per flow / per bot)	$150 / bot or flow / month	One unattended RPA bot OR one cloud flow that any user in the org may trigger. Service-account license for shared automations.
Power Automate Hosted Process	$215 / bot / month	Microsoft-hosted Windows VM for unattended desktop flows — no on-prem machine required. Includes one Process license.
Power Automate Pay-as-you-go	$0.60 per cloud flow run	Azure-billed. Suitable for low-frequency, high-variance workloads.
Process Mining add-on	$5,000 / tenant / month	Enterprise Process Mining for >5 process maps or unlimited records.

Sources: Power Automate pricing, Power Platform Licensing Guide April 2026.

Real-world example — Process vs Hosted Process

A finance team runs an unattended nightly bot that reconciles bank statements with ERP entries. The bot runs on a corporate VDI that is patched weekly, resulting in 1–2 missed runs per month. Moving to Hosted Process at $215 / bot / month eliminates the VDI dependency and adds Microsoft-managed patching, RDP brokering, and elastic capacity. ROI breaks even at one prevented missed reconciliation per month.

1.3 Power Pages

Power Pages (the renamed Power Apps Portals) is licensed by monthly active users (MAU) per site. A MAU is a unique identity that loads any Power Pages page within a calendar month. Authenticated MAUs sign in (Entra ID, Entra External ID / B2C, Microsoft account, LinkedIn, etc.); anonymous MAUs are unauthenticated public visitors. Search-engine crawlers are not counted (Power Pages capacity licensing).

SKU	List price (USD)	Entitlement
Authenticated Users capacity pack	$200 / site / month	100 authenticated MAUs / site / month. Overage: $2 / MAU.
Anonymous Users capacity pack	$75 / site / month	500 anonymous MAUs / site / month. Overage: $0.30 / MAU.
Power Pages PAYG	$2 / authenticated MAU; $0.30 / anonymous MAU	Azure-billed; no monthly minimum.

Source: Power Pages pricing.

Real-world example — Power Pages MAU math

A municipality launches a citizen-permit portal expected to draw 8,000 anonymous monthly active users (unique visitors who load any page in the month) and 2,400 authenticated MAUs (unique citizens who sign in to file a permit application).

Capacity packs: 16 × Anonymous (16 × 500 = 8,000 anon MAU, $75 × 16 = $1,200) + 24 × Authenticated (24 × 100 = 2,400 auth MAU, $200 × 24 = $4,800) = $6,000 / month.
PAYG: 8,000 × $0.30 + 2,400 × $2 = $7,200 / month.

Capacity packs win at steady volumes; PAYG wins for unpredictable spikes. Note that an authenticated MAU is a unique signed-in identity per month, not a session or a page view — repeat visits by the same citizen do not increment the count.

1.4 Tenant environment and API entitlements

Default environment. Each tenant receives one default environment provisioned with 3 GB Dataverse database, 3 GB file, and 1 GB log capacity (Dataverse capacity storage). Production and sandbox environments draw from the tenant Dataverse pool. No hard cap on environment count, but each consumes from the shared pool (environments overview).
Developer environment. Every user with any seeded or paid license automatically receives a personal developer environment.
API request entitlements (per user per 24h, with overage pooled at tenant level): Premium Power Apps / Premium Power Automate / D365 Enterprise users get 40,000 requests / user / 24 h; per-App users get 6,000; Microsoft 365–seeded users get 6,000 / user / 24 h for Standard-connector usage. Excess returns HTTP 429 but does not auto-bill; the Power Platform Requests add-on raises the tenant limit by 50,000 requests / 24 h (the $50 / month figure is widely partner-quoted but is not on the public allocations page — confirm before quoting) (API request limits and allocations).

When the Requests add-on actually matters. High-volume Power Automate scenarios are typically triggered by child-flow fan-out patterns, integration flows polling HTTP endpoints on a short cadence, large-scale Dataverse data movement, and any flow making many connector calls per run. If your monitoring shows users approaching the daily cap or HTTP 429s in the flow run history, the add-on is the supported answer.

1.5 Managed Environments and Governance Licensing

Managed Environments is Microsoft’s governance overlay for Power Platform environments — it surfaces DLP enforcement, sharing limits, weekly digests, Power Platform Pipelines, solution checker enforcement, and “Maker welcome content.” Managed Environments has no separate SKU price, but it gates feature access by user-license type: every user accessing a Managed Environment must hold a Power Apps Premium, Power Automate Premium, Power Pages, or qualifying Dynamics 365 license (about Managed Environments).

The practical consequence: a tenant that adopted Managed Environments for governance reasons cannot mix-and-match M365-seeded users into the same environment. This is the most common reason a sizing exercise sized for “Premium for makers, M365 seeded for everyone else” needs to be re-priced upward.

1.6 Trial, Developer, and non-production licenses

30-day trials are available for Power Apps Premium and Power Automate Premium. Trials convert to paid via the Microsoft 365 admin center or your CSP / EA channel.
Power Apps Developer Plan (free) replaces the retired Power Apps Community Plan. It provides a personal developer environment for build/test, with no production rights and no commercial use. Each user with any paid or seeded license is automatically entitled to a developer environment (Developer Plan).
Dynamics 365 30-day trials are available for each base SKU. Customer Service Premium and Contact Center trials are tenant-bound; voice channel usage during trial incurs ACS pass-through charges if a phone number is provisioned.

2. Microsoft Copilot Studio

Copilot Studio is licensed by Copilot Credit consumption, which replaced the legacy “message” terminology in late 2025. Credits pool at the tenant level and are consumed FIFO across all Copilot Studio agents, all environments, and bundled Dynamics 365 AI agents. Microsoft documentation consistently references the Contact Center and Customer Service AI agents (Customer Intent, Customer Knowledge, Quality Evaluation) as drawing from the same credit pool. Sales-side AI agents are referenced in Microsoft messaging as participating in the pooled meter (MODERATE confidence — verify on the Dynamics 365 Sales pricing page).

2.1 Commercial models

SKU	List price (USD)	Entitlement
Copilot Studio Pre-Purchase Plan (Tenant Message Pack)	$200 / month for 25,000 Copilot Credits (≈ $0.008 / credit)	Annual commitment; up to 20% discount vs PAYG.
Copilot Studio Pay-as-you-go (Azure-billed)	$0.01 / Copilot Credit	No commitment; Azure subscription required.
M365 Copilot included usage	Zero-rated for licensed M365 Copilot users	When agents are invoked through M365 Copilot Chat or Teams by a user holding the $30 / user / month M365 Copilot license, no tenant credits are drawn (“B2E zero-rated path”).
Agent Pre-Purchase Plan (Azure Reservation)	Up to 20% off PAYG	Credits apply across all Copilot Studio agents AND Dynamics 365 agents.

Sources: Copilot Studio pricing, Copilot Credits pre-purchase, M365 Copilot included entitlement.

2.2 Copilot Credit billing rates

Per the April 2026 Copilot Studio Licensing Guide and the Copilot Studio billing-rates page:

Event	Credits consumed
Classic answer (deterministic topic flow, no LLM)	1
Generative answer (RAG over indexed knowledge sources)	2
Agent action / tool call (Power Automate flow, REST connector)	5
Tenant Microsoft Graph grounding (employee context)	10 (reported reduced from 30 before the rebrand)
Voice (per minute)	13
Autonomous action (event-triggered, no user prompt)	25

Confidence note. Per-event credit rates were revised when Microsoft rebranded “messages” to “Copilot Credits” in late 2025; the table above reflects the rates reported in the April 2026 licensing guide but has not been independently verified at the time of writing. The Microsoft Learn billing-rates page is authoritative — confirm before sizing a deployment.

Capacity pooling. All credits pool at the tenant level. Overage on the Pre-Purchase Plan rolls onto PAYG automatically unless the admin disables overflow.

2.2.1 AI Builder — current state and sunset

While AI Builder remains on price lists, it serves form processing / document automation, prediction models, sentiment analysis, and category classification scenarios — distinct from Copilot Studio agent invocations. Legacy AI Builder credits at $500 per 1 million service credits are scheduled to be retired in November 2026 and consolidated under the Copilot Credit meter. Customers with active AI Builder add-ons can use them until renewal; net-new deployments after the retirement date will provision Copilot Credits instead.

During the transition (now through November 2026): if a workload is predominantly document processing, AI Builder may still be the more economical SKU. If it mixes document processing with conversational agents, Copilot Credits are the forward-compatible path. Re-check the current Copilot Studio Licensing Guide before committing to either (Copilot Studio Licensing Guide April 2026 (PDF)).

2.3 What’s included with Microsoft 365 Copilot vs what requires Copilot Studio

There are three distinct user-license states that affect how a Copilot Studio agent is billed:

Capability	M365 Copilot ($30 / user / month)	M365 Copilot Chat (free tier)	Copilot Studio (credits)
Out-of-box Copilot Chat in Word/Excel/PowerPoint/Outlook/Teams	Included	Limited (web grounding only; no tenant data)	n/a
Microsoft Graph grounding for the user’s own M365 content	Included	Not included	n/a
Invoking a custom agent published in M365 Copilot / Teams (B2E)	Zero-rated (no tenant credits drawn)	Metered to tenant Copilot Credits	n/a
Building a custom agent in Copilot Studio	Not included	Not included	Required
Publishing a custom agent to a custom channel (web embed, Direct Line, WhatsApp, Slack, etc.)	Not included	Not included	Required — credits consumed
Anonymous public web chat (B2C)	Not included	Not included	Required — credits consumed regardless of user M365 Copilot status

The free-tier surprise. A tenant that rolls out Microsoft 365 Copilot Chat broadly without buying the $30 M365 Copilot license will see agent invocations from those users draw against tenant Copilot Credits rather than being zero-rated. The economics flip at the M365 Copilot license boundary, not at the Copilot Chat boundary. Plan B2E credit budgets accordingly.

2.4 Role-specific Copilots — Sales and Service

Distinct from Copilot Studio agents and from the in-Customer-Service Copilot, Microsoft also sells two role-overlay Copilot SKUs:

Microsoft 365 Copilot for Sales — overlays M365 Copilot with a Sales-side experience that surfaces CRM context in Outlook and Teams, supports both Dynamics 365 Sales and Salesforce as the system of record.
Microsoft 365 Copilot for Service — equivalent for Service scenarios, integrating with Dynamics 365 Customer Service and ServiceNow.

Each is a per-user seat license with pricing reported around the $50 / user / month range (MODERATE confidence — verify against the current Microsoft 365 Copilot pricing page). These SKUs are not the same as Copilot Studio credits and are not consumed from the tenant credit pool — they are flat per-user subscriptions.

2.5 Real-world example — Pre-Purchase vs PAYG break-even

A retail customer expects 50,000 generative answers and 5,000 agent actions per month.

Credits required: 50,000 × 2 + 5,000 × 5 = 125,000 credits / month.
PAYG cost: 125,000 × $0.01 = $1,250 / month.
Pre-Purchase: 5 × $200 packs = $1,000 / month for 125,000 credits — exactly the advertised 20% discount.

Rule of thumb: Above ~25,000 credits / month, Pre-Purchase always wins.

3. Microsoft Dataverse

Dataverse is the relational data backbone behind model-driven Power Apps and Dynamics 365. It is licensed as a shared, tenant-level capacity pool measured in three buckets — Database (relational rows), File (attachments / images / blobs), and Log (audit trail). Every Power Apps / Power Automate / Dynamics 365 license contributes per-user accrued capacity to the same shared pool, on top of a one-time tenant default.

3.1 Default tenant entitlement

The first eligible subscription provisioned in a tenant grants a one-time tenant-level default (long-standing licensing-guide figure: 10 GB Database, 20 GB File, 2 GB Log). This is not per subscription — purchasing a second Power Apps Premium or Dynamics 365 SKU does NOT double the default. The per-environment default (3 GB DB / 3 GB File / 1 GB Log for the default environment) is separate. Verify both figures against the current licensing guide (Dataverse capacity storage).

3.2 Per-license accrued capacity

Dataverse per-user accrual is reported in two places that currently disagree at the time of writing: Microsoft’s live pricing pages (the conservative numbers below) and the April 2026 Power Platform / Dynamics 365 Licensing Guide PDFs (which report larger figures for several SKUs, attributed to a late-2025 uplift). The table below shows the live pricing-page values with the licensing-guide PDF figure noted where it differs.

License	DB accrued (live pricing page)	File accrued (live pricing page)	Licensing Guide PDF reports
Power Apps Premium	250 MB / user	2 GB / user	Reported as substantially higher in the April 2026 PPLG PDF (figures circulating in partner channels reference 20 GB DB / user as the post-uplift number) — verify against current PPLG PDF before sizing.
Power Apps per App pass	50 MB / user / pass	400 MB / user / pass	Per the April 2026 PPLG.
Power Automate Premium	250 MB / user	2 GB / user	Per the live Power Automate pricing page.
Power Automate Process / Hosted Process	50 MB / flow or bot	200 MB / flow or bot	Per the live Power Automate pricing page.
Dynamics 365 Sales / Customer Service / Field Service / Contact Center Enterprise	Live pages show entitlement; PPLG reports up to 30 GB / user DB (uplift)	Up to 30 GB / user File (uplift)	MODERATE confidence; verify against current PPLG PDF.
Dynamics 365 Finance / SCM / Project Operations / Commerce	PPLG reports up to 90 GB / user DB (uplift)	Up to 80 GB / user File (uplift)	MODERATE confidence; verify against current PPLG PDF.
Dynamics 365 Business Central Premium	4 GB / user	4 GB / user	Per the April 2026 D365 Licensing Guide.
Dynamics 365 Team Members	250 MB / user	2 GB / user	Per the April 2026 D365 Licensing Guide.

Sources: Power Apps pricing; Power Automate pricing; Power Platform Licensing Guide April 2026 (PDF); Dynamics 365 Licensing Deck March 2026 (PDF).

Pricing-page vs Licensing Guide disagreement. At the time of writing, the public Power Apps pricing page reports 250 MB DB + 2 GB File per Premium user, while the April 2026 Power Platform Licensing Guide PDF reports higher per-user accruals. Sizing should be based on the figures the customer is contractually entitled to under the licensing-guide PDF in force at the time of purchase — confirm with your Microsoft account team or CSP partner before signing.

3.3 Capacity add-ons

Add-on	List price (USD)
Dataverse Database Capacity	$40 / GB / month
Dataverse File Capacity	$2 / GB / month
Dataverse Log Capacity	$10 / GB / month

Capacity is purchased per tenant and allocated across environments by an admin in the Power Platform admin center.

3.4 Dataverse for Teams vs full Dataverse

Dataverse for Teams is a constrained Dataverse instance bundled with any Microsoft 365 plan that includes Teams (Business Basic and above, E1+, F3, A1+, G1+). It exists to make canvas Power Apps inside Teams feasible without buying Premium (about Teams environment).

Limits:

2 GB capacity per Teams environment (auto-provisioned per Team that adds a Power App).
Maximum 5 GB per environment after upgrade.
No Premium connectors, no custom connectors, no external API integrations outside Teams. No advanced security roles. No model-driven apps.

An admin can upgrade a Dataverse-for-Teams environment to a full Dataverse production environment, at which point Premium licensing rules apply and the per-user accrued capacity is added to the tenant pool. This is a one-way upgrade.

3.5 Real-world example — Dataverse capacity math

A 200-user Dynamics 365 Customer Service Enterprise tenant in 2026, using the licensing-guide-PDF per-user figures (30 GB DB / 30 GB File per Enterprise CRM user):

Default + accrued DB = 10 GB (tenant default) + 200 × 30 GB (accrued) = 6,010 GB Database
File = 20 GB + 200 × 30 GB = 6,020 GB File

At the older 10 GB per-user accrual, the same tenant would have entitled 10 + 200 × 10 = 2,010 GB DB — meaningfully less, and historically the line item that drove Dataverse capacity overage billing for mid-market CRM customers.

Confidence note for §3.5. The 30 GB/user figure is reported in the April 2026 Dynamics 365 Licensing Guide PDF but is not displayed on the public Dynamics 365 Customer Service pricing page. Treat the “6,010 GB DB” headline as MODERATE confidence and re-verify against the current PDF before using it for budget planning. Customers below the headline number can still hit overage if the file or Log capacity is consumed disproportionately (audit-heavy compliance scenarios, high-attachment-volume case management).

4. Copilot Studio with Dynamics 365 Contact Center

In 2024, Microsoft repositioned the omnichannel pieces of Customer Service as a CRM-agnostic Contact Center as a Service offering. The strategic intent: sell a “Copilot-first” CCaaS to organizations whose system of record is Salesforce, ServiceNow, Zendesk, or anything else — not just Dynamics 365.

4.1 Dynamics 365 Contact Center SKUs

SKU	List price (USD)	Entitlement
Dynamics 365 Contact Center (full)	$110 / user / month	Digital + voice channels, unified routing, Copilot in service representative desktop, integrations with Salesforce / Dynamics 365 / ServiceNow / Zendesk. AI agents (Customer Intent, Customer Knowledge, Quality Evaluation) require Copilot Credits sold separately.
Dynamics 365 Contact Center Digital	$95 / user / month	Digital messaging and chat channels only; no voice.
Dynamics 365 Contact Center Voice	$95 / user / month	Native voice channel only; no digital messaging.
Promotional discount	40% off, Oct 1, 2025 → Jun 30, 2026	EA / CSP only; not stackable.

Source: Contact Center pricing.

Capacity entitlements per Contact Center user (per the Dynamics 365 Licensing Guide April 2026): 50 record routes / user, 1,000 messaging conversations / user / month, 3,000 IVR voice-bot minutes / tenant / month with the Voice add-in. Overage is billed via Copilot Credits or Azure Communication Services (ACS) pass-through.

4.2 Voice channel — Azure Communication Services pass-through

Voice is built on Azure Communication Services. Phone-number rental and per-minute usage charges are NOT included in the Contact Center subscription — they are billed separately through an Azure subscription.

Voice meter	Rate (USD)
PSTN inbound (US toll-free)	$0.022 / min
PSTN outbound (US)	$0.013 / min
VOIP inbound	$0.004 / min
SBC → ACS direct routing	$0.004 / min
Single-channel mixed-audio recording	$0.004 / min

Phone-number leases run roughly $1 / month (US local DID) to $2 / month (US toll-free). SMS and WhatsApp messaging are metered per message under ACS pass-through. International outbound PSTN rates vary widely by destination — pull the current ACS price list per country before scoping any non-US deployment. Source: voice channel pricing scenarios.

Confidence note for §4.2. ACS per-minute rates and DID lease costs change periodically and vary by region. The figures above are widely quoted US commercial rates at the time of writing (MODERATE confidence); always pull the live ACS pricing per country / channel before contracting.

4.3 Where Copilot Studio meets Contact Center

When a customer interacts with an AI agent inside Contact Center — for example, a Customer Intent Agent that captures reason-for-contact before routing, or a Customer Knowledge Agent that drafts answers from the knowledge base — each turn consumes Copilot Credits at the rates in §2.2. The organization must hold either a Copilot Studio Pre-Purchase Plan or PAYG capacity. AI agents are NOT included in the base $110 Contact Center subscription — the official pricing page explicitly labels them “Requires Copilot Credits (sold separately).”

This is the single most-misunderstood line in the entire Dynamics 365 portfolio. Buying Contact Center alone gives you the orchestration runtime — channel ingress, routing, the agent desktop, and reporting. It does NOT give you the AI agents the marketing material is built around. Those run on Copilot Studio credits.

4.4 Unified routing

Unified routing — skill-based, attribute-based, and longest-idle distribution across voice, chat, email, and social channels — is included with Contact Center, Contact Center Digital, Contact Center Voice, Customer Service Enterprise, and Customer Service Premium. It is NOT included with Customer Service Professional, which is the largest hidden functional gap between Professional and Enterprise.

4.5 Real-world example — Contact Center + ACS

A 60-seat outbound sales team uses Contact Center Voice ($95 × 60 = $5,700 / month, or $3,420 / month after the 40% promo) and makes 25 outbound calls per agent per day, average 4 minutes:

Monthly outbound minutes: 60 × 25 × 4 × 21 = 126,000 min
ACS PSTN outbound charge: 126,000 × $0.013 = $1,638
60 toll-free DIDs at $2/each = $120
All-in: $3,420 + $1,638 + $120 = $5,178 / month

Add a Customer Intent AI agent that captures reason-for-contact on every call (2 credits per turn, average 3 turns per call): 60 × 25 × 21 × 3 × 2 = 189,000 credits / month ≈ $1,512 / month at Pre-Purchase rates. The AI agent line item is real money — budget for it separately.

5. Dynamics 365 Customer Service

5.1 Base SKUs

SKU	List price (USD)	Entitlement
Customer Service Professional	$50 / user / month	Case management, knowledge management, customer service hub UI, mobile app, M365 integration. Limited customization: 15 custom tables, 5 BPFs, 5 dashboards, 2 forms/views per table, 15 queues. No unified routing, no multisession workspace, no embedded intelligence.
Customer Service Enterprise	$105 / user / month	Everything in Professional + unified routing, multisession workspace, embedded intelligence, Copilot in service representative desktop (case summary, email draft, conversation summary, Q&A over knowledge), full Power Apps customization (write access to all standard/custom tables, unlimited BPFs, dashboards, forms).
Customer Service Premium	$195 / user / month	Customer Service Enterprise + Dynamics 365 Contact Center bundled. Saves $20 / user / month vs buying them separately ($105 + $110 = $215).
Premium step-up (introduced March 2026)	Step-up SKU	Customers on Enterprise can step up to Premium without re-signing the agreement.

Source: Customer Service pricing.

Recent pricing changes. Customer Service Enterprise moved from $95 to $105 / user / month in mid-2025; partner blogs dated 2024 still cite $95. The 40% promotional discount running October 1, 2025 → June 30, 2026 applies to Customer Service Premium, Dynamics 365 Contact Center, Contact Center Digital, and Contact Center Voice SKUs only — Customer Service Enterprise is NOT included in the promotion, per the eligibility footnote on the Contact Center pricing page. The promotion is EA / CSP only and is not stackable with other discounts.

5.2 Capacity entitlements per Customer Service license

Dataverse: the April 2026 Dynamics 365 Licensing Guide reports up to 30 GB DB / 30 GB File / 2 GB Log per Customer Service Enterprise user (MODERATE confidence; verify against current PDF).
Unified routing (Enterprise+): 50 record routes / user, 1,000 messaging conversations / user / month.
API requests: 40,000 / user / 24 h.
Copilot for Customer Service: Included in Enterprise and Premium since 2024 — case summary, email draft, conversation summary, real-time agent assist, Q&A over linked knowledge sources.

5.3 Add-ins available to Customer Service Enterprise

These add-ins enable omnichannel capabilities for Customer Service Enterprise customers who do not want the full Contact Center bundle. They cannot be purchased on top of Customer Service Professional.

Add-in	List price (USD, est.)	Entitlement
Digital Messaging Add-in	$75 / user / month	Live and persistent chat, SMS, WhatsApp, Facebook Messenger, Apple Messages for Business, LINE, WeChat, custom messaging channels.
Voice Channel Add-in	$75 / user / month	Native ACS-powered voice on Customer Service — inbound/outbound PSTN, IVR (3,000 voice-bot minutes / tenant included), call recording, transcription, sentiment analysis. ACS per-minute pass-through still applies.
Digital Messaging + Voice Add-in	$90 / user / month	Bundle of both — saves $60 / user / month vs separate.
Chat Add-in	$60 / user / month	Live chat only (subset of Digital Messaging).

Sources: Microsoft Dynamics community thread, MS employee response (June 2024), TrustRadius Customer Service pricing 2026, voice channel pricing scenarios.

Confidence note. Add-in USD list prices are confirmed via the Microsoft Dynamics community (employee response) and TrustRadius pricing aggregation, but at the time of writing they are not directly published on the public microsoft.com Customer Service pricing page, which links only to the three base plans. Treat as MODERATE-confidence list prices; final quotes should come from the Microsoft account team or a CSP partner.

5.4 Customer Service Enterprise vs Contact Center vs Premium — the decision matrix

Need	Recommended SKU	Monthly cost (200 seats, list, before promo)
Case + knowledge management only	Customer Service Professional	$10,000
Case + omnichannel digital messaging	CS Enterprise + Digital Messaging Add-in	(105+75) × 200 = $36,000
Case + voice	CS Enterprise + Voice Channel Add-in	(105+75) × 200 = $36,000
Case + digital + voice (full omnichannel)	Customer Service Premium	195 × 200 = $39,000
CRM-agnostic CCaaS (no D365 CRM in scope)	Dynamics 365 Contact Center	110 × 200 = $22,000
Existing non-MS CRM + native voice + AI agents	Contact Center + Copilot Studio Pre-Purchase	110 × 200 + credit pack = ~$22,000 + credits

5.5 Real-world example — when Premium beats Enterprise + add-ins

A 500-seat global support center needs digital messaging on day one and plans to add voice within 12 months. List-price comparison:

Enterprise + Digital Messaging immediately: ($105 + $75) × 500 = $90,000 / month (Enterprise is NOT eligible for the 40% promo)
Adding voice 12 months later (Digital Messaging + Voice combined add-in): ($105 + $90) × 500 = $97,500 / month
Customer Service Premium from day one: $195 × 500 = $97,500 / month

Premium at list price matches Enterprise + combined add-in. The decisive factor is the promotional window. Under the 40% promo (Oct 1, 2025 → Jun 30, 2026):

Customer Service Premium with promo: $195 × 0.60 × 500 = $58,500 / month for 500 seats
Enterprise + Digital Messaging (no promo eligibility on either component): $90,000 / month

Premium under the promo is roughly $30,000 / user / month cheaper than the Enterprise + add-in path while bundling the full Contact Center feature set (AI agents framework, ACS integration, unified routing with 1,000 messaging conversations / user / month, advanced reporting). The Premium step-up SKU reported in March 2026 (MODERATE confidence; verify with your account team) further reduces re-papering friction for Enterprise customers moving up. The recommendation: if voice is on the roadmap inside 18 months, start on Premium — especially if the contract can be signed inside the promo window.

6. Cross-cutting Guidance — How to Decide What to License

6.1 Decision principles

Start with the data. If the workload needs full Dataverse and Premium connectors, you are in Premium territory. If everything lives in SharePoint, Excel, and Teams, M365-seeded rights may be sufficient.
Count the apps per user. Power Apps Premium wins when most users run most apps; per-App wins when usage is role-segmented and you can count app users by the hundred, not the thousand.
Separate the AI line item from the seat line item. Copilot Studio credits are a separate budget. Contact Center seats do not include AI agent consumption. Customer Service Enterprise seats do not include the omnichannel add-ins.
Use the promotional window — but check eligibility carefully. The 40% discount applies to Customer Service Premium, Dynamics 365 Contact Center, Contact Center Digital, and Contact Center Voice through June 30, 2026. Customer Service Enterprise is NOT eligible. If a sizing exercise is sitting on Enterprise + add-ins, model the Premium-with-promo alternative explicitly before deciding.
Re-verify the moving parts before signing. Copilot Credit billing rates, Customer Service add-in list prices, and Dataverse per-user accruals have all moved within the last 12 months. The next revision of this article will track those in a dedicated changelog section.

6.2 Cloud variants and regulated tenants

Government clouds (GCC, GCC High, DoD). Power Platform and Dynamics 365 SKUs in US government clouds have a separate price list, separate feature-parity timeline (Copilot Studio voice and some AI agents have historically reached GCC clouds later than commercial), and constraints on which ACS regions and Azure OpenAI endpoints are available. Public-sector and defense readers should treat this article’s pricing as commercial-cloud-only and verify GCC/GCC High availability with their account team before sizing.
EU Data Boundary. Microsoft completed full inclusion of Copilot and AI services in the EU Data Boundary in early 2025; processing for tenants in scope remains in EU/EFTA data centers. Multi-geo Dataverse is available as a separate capability with its own capacity implications.
Sovereign and regulated EU clouds. Specific sovereign offerings (such as the Microsoft Cloud for Sovereignty, and locally-operated partner offerings where applicable) have distinct SKU availability and price lists. Confirm specifics with your account team.

6.3 Education and Nonprofit

Education (A-SKUs). A1, A3, and A5 plans grant seeded Power Platform rights similar in shape to E-series equivalents but with reduced commercial use scope. Dynamics 365 has dedicated Education SKUs.
Nonprofit. Eligible nonprofits qualify for steep discounts on Power Apps Premium and Dynamics 365 base SKUs via the Microsoft Tech for Social Impact program. Pricing varies by entity and country — engage Microsoft Philanthropies for current quotes.

6.4 Common mistakes to avoid

Buying Contact Center without Copilot Credits. The AI agents in marketing material are not included in the seat price — see §4.3.
Assuming Managed Environments is free. It has no SKU price, but it gates per-user license type — see §1.5.
Treating “Premium” as a single product. Power Apps Premium ≠ Customer Service Premium ≠ Contact Center Premium (does not exist; Contact Center has three flavors instead). Always specify.
Mixing M365-seeded users into a Power Apps Premium app silently. As soon as one Premium or custom connector is added to the app, every user needs a paid license — there is no occasional-use carve-out.
Forgetting that F-series ≠ E-series for Power Platform rights — see §1.1 caveat.
Assuming the 40% promo applies to Customer Service Enterprise. It does not — see §5.1 and §6.1 step 4.

6.5 Negotiation levers — EA vs CSP vs MCA-E

Enterprise Agreement (EA). Best for very large tenants with predictable three-year demand; gates access to certain volume discounts and the 40% Contact Center promotion. Price-protected through the EA term.
Cloud Solution Provider (CSP). Most flexible for mid-market — monthly cadence, partner-managed billing, easier mid-term seat changes. Promotion eligibility usually mirrors EA but ask the CSP partner to confirm.
Microsoft Customer Agreement for Enterprise (MCA-E). Microsoft’s direct-purchase model, replacing some EA scenarios. Modern, online-managed, but coverage varies by region and SKU. Confirm what is available in your geography.

7. Conclusion

Microsoft’s business-application licensing in 2026 reflects a maturing, three-pillar commercial design: per-user subscriptions for the seat-based products, capacity-based consumption metering for Dataverse and Copilot Studio Copilot Credits, and MAU-based capacity packs for citizen-facing Power Pages portals.

The structurally interesting shift of the last twelve months is the consolidation of Power Platform AI consumption under a single Copilot Credit meter (with AI Builder credits scheduled to be retired in November 2026) — a strategic move toward a unified Azure-billed currency for all AI workloads. Future licensing decisions will increasingly be about how much AI you can commit to up front (Pre-Purchase Plan) versus flexibility to spike (PAYG), rather than which SKU contains which feature. In parallel, the April 2026 licensing guides report higher per-user Dataverse accruals for Power Apps Premium and several Dynamics 365 SKUs than the live pricing pages currently display — a discrepancy that materially affects sizing for tenants with 100+ seats and that should be re-verified against the licensing guide PDF in force at contract signing.

For the practitioner, three defaults: Power Apps Premium for new build-outs unless app usage is clearly segmented by role; Customer Service Premium over Enterprise + add-ins for any deployment that includes both voice and digital messaging (especially under the 40% promo window, which Enterprise is not eligible for); Copilot Studio Pre-Purchase Plan above ~25,000 credits / month. Confidence in these recommendations is HIGH for prices on Microsoft’s own pricing pages and MODERATE for add-in list prices, Copilot Credit billing rates, and Licensing Guide PDF Dataverse accrual figures — all should be re-verified before any commercial commitment.

This article will be revised. The next revision will append a Changelog section recording every license-relevant change Microsoft publishes — price adjustments, SKU additions or retirements, capacity changes, billing rate revisions — with effective date, source URL, and a one-line impact note.

Glossary

Term	Expansion
ACS	Azure Communication Services — Azure platform service that provides PSTN voice, SMS, chat, and email under per-meter billing. Underpins the Contact Center and Customer Service voice channels.
BPF	Business Process Flow — a guided multi-stage workflow in Dynamics 365 / Dataverse model-driven apps.
B2C	Business to Consumer — public-facing scenarios (e.g., anonymous web chat, citizen portals).
B2E	Business to Employee — internal scenarios where the user is a licensed employee of the tenant.
CCaaS	Contact Center as a Service — cloud-delivered contact center, often CRM-agnostic.
CoE Starter Kit	Center of Excellence Starter Kit — Microsoft’s free governance accelerator for Power Platform tenants.
CSP	Cloud Solution Provider — Microsoft’s indirect partner channel for purchasing cloud services.
Dataverse	Microsoft’s relational data platform behind model-driven Power Apps and Dynamics 365.
DID	Direct Inward Dialing — a directly-dialable telephone number, usually a local geographic number.
DLP	Data Loss Prevention — Power Platform policy controls that restrict which connectors can share data.
EA	Enterprise Agreement — Microsoft’s traditional 3-year volume licensing agreement.
EU Data Boundary	Microsoft commitment to process EU/EFTA customer data within EU/EFTA data centers.
FIFO	First In, First Out — credit-consumption order across a pooled allocation.
GCC / GCC High / DoD	US government cloud variants — GCC (Moderate), GCC High (IL4), DoD (IL5/IL6).
IVR	Interactive Voice Response — automated voice menu / bot at the start of a call.
MAU	Monthly Active User — a unique identity counted once per calendar month, regardless of session count.
MCA-E	Microsoft Customer Agreement for Enterprise — Microsoft’s modern direct-purchase contract model.
PAYG	Pay-As-You-Go — Azure-billed consumption with no upfront commitment.
PPLG	Power Platform Licensing Guide — Microsoft’s authoritative entitlement reference PDF, updated regularly.
PSTN	Public Switched Telephone Network — traditional dialed phone network.
RAG	Retrieval-Augmented Generation — pattern where an LLM is grounded on retrieved documents.
RPA	Robotic Process Automation — UI-automation of desktop and web applications (Power Automate desktop flows).
SBC	Session Border Controller — a network device that bridges enterprise voice (SIP) to a carrier.
VOIP	Voice over IP — voice traffic over the public internet rather than PSTN.

Sources (primary)

Power Platform Governance: A Practitioner's Reference (Part 2)

Sat, 23 May 2026 00:00:00 +0000

Summary lede. Part 2 of this two-article reference picks up where last week’s foundations ended. With the platform perimeter in place — environments, Managed Environments, environment groups, DLP, tenant isolation, identity, and monitoring — this article works through the resources that live inside that perimeter and the processes that move them through it: Copilot Studio agents, agent authentication and connector governance, Application Lifecycle Management and pipelines, solution checker and quality gates, licensing and capacity governance, and change management and release rings. A closing recap then ties both articles together into a single posture.

Last verified: May 2026. Feature availability and documentation links were checked against Microsoft Learn as of this date. Power Platform evolves rapidly; confirm preview/GA status before acting on release-sensitive claims.

Who this is for. Same audience as part 1 — Power Platform administrators, security and compliance officers, Center of Excellence leads, architects, and makers. Part 2 assumes you have read Part 1 or have an equivalent grasp of environment design, Managed Environments, environment groups, and DLP. Where part 1 answered “what is the perimeter and how do we hold it?”, part 2 answers “what gets built inside it, and how does that work move from a maker’s hands into production safely?” The format is unchanged: each control begins with the reason it exists, moves to the how, and points you to the authoritative Microsoft Learn page.

A note on the kits (continues from part 1).
Two pieces of widely-deployed community tooling have changed status: the CoE Starter Kit is no longer actively maintained — its core capabilities are now part of the Power Platform admin center (Inventory, Usage, Monitor, Actions) — and the ALM Accelerator for Power Platform is formally deprecated, with Power Platform Pipelines as the named replacement. Sections 9.14 (agent inventory) and 11 (ALM and pipelines) reflect that. The detailed write-up of the CoE Starter Kit transition lives in part 1, section 8.6; the ALM Accelerator transition is summarised in section 11.6 of this part.

Recap: where part 1 left off

As we saw last week, platform-level governance is the foundation on which everything else rests. Part 1 walked through eight sections of foundations:

Environment strategy. Environments are the unit of governance because DLP, security roles, capacity, and compliance boundaries all follow environment lines. A topology that mirrors your delivery lifecycle (default for personal productivity; dev/test/prod for solutions; dedicated CoE and training environments) gives every later control a place to attach to.
The default environment. It cannot be deleted, every licensed user is a maker in it, and Dataverse cannot be removed once added. Renaming it, attaching a restrictive DLP policy, enabling default environment routing, and converting it to a Managed Environment turn it into a known, bounded surface.
Managed Environments. A premium governance layer that adds sharing limits, the weekly digest, solution checker enforcement, maker welcome content, pipelines hosting, IP firewall, extended backup, and DLP for desktop flows. Most of part 2’s controls depend on Managed Environments being on.
Environment groups and rules. Groups apply policy in bulk to Managed Environments. When a rule is published at the group level, the corresponding setting becomes read-only in each member environment, which makes the policy enforceable rather than advisory.
Data Loss Prevention. Connectors are sorted into Business, Non-business, and Blocked. Data cannot flow between Business and Non-business in the same resource. Endpoint filtering and connector action control let you keep useful connectors while blocking their dangerous edges.
Tenant isolation and cross-tenant controls. Restricts which external Entra ID tenants can be the identity source for connections. Tenant isolation is off by default; enable it explicitly and configure inbound and outbound rules for each trusted tenant.
Security roles and identity. Layered authorization: Entra ID at the tenant, Dataverse roles inside each environment, service principals for non-interactive work, Conditional Access and MFA on the Power Platform API.
Monitoring, analytics, and tenant inventory. Built-in admin center analytics (the Inventory, Usage, Monitor, and Actions experiences), the weekly digest, Microsoft Purview audit log, Application Insights export, and Microsoft Sentinel for SOC integration. The CoE Starter Kit is no longer actively maintained; its inventory and attestation scenarios are now Microsoft’s responsibility in the admin center, accessible via the Power Platform inventory API and the Power Platform for Admins V2 connector for custom automation.

The minimum viable foundation from part 1 was: restrict default environment creation, attach a tenant-wide baseline DLP policy, enable default environment routing with a Managed Environments group, turn on tenant-level analytics, lean on the Power Platform admin center’s Inventory, Usage, Monitor, and Actions experiences (the CoE Starter Kit is no longer actively maintained), and verify your tenant isolation defaults. Everything in part 2 assumes that the foundation is in place. The section numbering continues from part 1, starting at section 9.

9. Governing Microsoft Copilot Studio

Copilot Studio agents are Power Platform resources. They are stored in environments, secured with Dataverse, shared through the same sharing model as apps and flows, and subject to DLP policies. A Copilot Studio agent is not a separate governance domain; it is a new resource type inside the platform perimeter. The controls below are specific to agents and combine with the platform-wide ones covered in part 1.

9.1 Decide agent posture in tenant settings

Why. The most basic question — “should agents exist in this tenant at all, and where?” — is answered at the tenant level. Skipping this step makes every later control fight a current.

How. In Power Platform admin center > Settings > Tenant settings, control whether Copilot Studio is enabled, who can create agents, whether agents can be created in the default environment, and which AI features (generative answers, autonomous triggers, external models) are available.

Learn more. Tenant settings reference.

9.2 Use the Copilot Studio admin center for agent-specific controls

Why. Some agent controls live outside the Power Platform admin center because they are specific to Copilot Studio’s data model.

How. Visit admin.copilotstudio.microsoft.com to control sharing org-wide, tenant-wide data access settings for agents, and transcript retention.

Learn more. Copilot Studio admin center.

Why. “Share with my entire organization” is a one-click action that bypasses normal sharing limits. Without restriction, any maker can publish a tenant-wide agent.

How. Org-wide sharing is controlled through a combination of tenant settings and Managed Environment sharing rules. In the Power Platform admin center, restrict who can share agents broadly; in Managed Environments, use sharing limits to cap the number of viewers and disable sharing via security groups. Restrict org-wide sharing to a CoE or approvals group for production-grade use.

Learn more. Control how agents are shared.

Why. Even with tenant-wide sharing locked down, intra-tenant oversharing is still possible. Sharing limits cap blast radius per agent.

How. In a Managed Environment, apply Limit sharing to cap viewers per agent and disable sharing via security groups. Mechanics are in part 1, section 3.

Learn more. Limit sharing.

Why. Sharing limits per environment are tedious to manage at scale. Group rules let you apply the same sharing posture across many environments at once.

How. Use the Sharing agents with Editor permissions and Sharing agents with Viewer permissions environment group rules.

Learn more. Rules for environment groups.

9.6 Set maker welcome content for Copilot Studio

Why. Most makers entering Copilot Studio will not have read your governance documentation. The welcome banner is the cheapest place to put guardrails in front of them.

How. Configure maker welcome content in Managed Environments to surface agent guidelines as makers enter Copilot Studio.

Learn more. Copilot Studio security and governance.

9.7 Run solution checker on agent solutions

Why. Static analysis catches structural problems in agents the same way it does in apps and flows — missing fallbacks, knowledge sources without authentication, references to blocked connectors.

How. Solution checker runs at solution import in Managed Environments. Mechanics are covered in section 12.

Learn more. Solution checker enforcement.

9.8 Govern AI features per environment group

Why. Generative and external AI features carry different risk profiles in different environments. Production with regulated data needs a stricter stance than a pilot environment.

How. Use the AI-powered Copilot features, Generative AI settings, External models, AI prompts, and Preview and experimental AI models rules to turn capabilities off where they should not be available.

Learn more. Rules for environment groups.

9.9 Control transcript access

Why. Conversation transcripts can contain sensitive prompts and customer data. Default-on transcript retention is a poor fit for regulated environments.

How. The Accessing transcripts from conversations in Copilot Studio agents rule turns transcript retention off for environments in regulated groups.

Learn more. Rules for environment groups.

9.10 Block high-risk agent connectors in DLP

Why. DLP on agent connectors is the only way to stop entire classes of bad behavior at design time — public agents, ad-hoc HTTP, autonomous triggers — without playing whack-a-mole.

How. Common blocks for regulated tenants:

Chat without Microsoft Entra ID authentication in Copilot Studio — prevents publishing public, unauthenticated agents.
Direct Line channels in Copilot Studio — block if only Teams, SharePoint, and Microsoft 365 Copilot channels are approved.
Skills — prevents invocation of arbitrary Bot Framework skills.
HTTP requests — prevents ad-hoc outbound calls from agents.
Event triggers — disables autonomous agents until they are approved.

Enforcement is real time; makers see validation errors while authoring.

Learn more. Configure data policies for agents.

9.11 Constrain knowledge sources

Why. Knowledge sources are how agents reach data. A loose knowledge configuration is a loose data perimeter.

How. Apply scope-aware controls to each source type:

A broad SharePoint URL can expose a large portion of the site’s content to the agent, limited by supported file types, page types, and the user’s permissions at runtime. Grant scope at the document library or folder level where possible to minimize exposure.
Public website knowledge is fetched at runtime; treat it as untrusted input for prompt-injection exposure.
Files uploaded as knowledge are stored in the agent’s Dataverse tables and inherit environment backup and data residency.

Use sensitivity labels and Microsoft Purview to label and classify content before it is indexed.

Learn more. Copilot Studio security and governance.

9.12 Pick an authentication mode per agent

Why. Authentication mode determines whether sharing limits apply at all. Sharing limits apply only to agents that require authentication; public agents bypass the sharing model entirely.

How. Three modes exist:

Authenticate with Microsoft (Entra ID, default) — recommended for regulated environments.
Authenticate manually — generic OAuth.
No authentication — public; not recommended for tenants with sensitive data.

Require Entra ID authentication in regulated environments by blocking the no-authentication connector in DLP. Blocking no-authentication is the prerequisite for sharing limits to be meaningful at all.

Learn more. Configure user authentication.

9.13 Approve a deployment channel matrix

Why. Each channel has its own risk profile and operational model. Without an approved matrix, channel selection becomes a maker-by-maker decision.

How. Enforce an approved channel matrix through tenant settings and DLP:

Channel	Control
Microsoft Teams	Admin-approved app catalog; manifests are solution-aware
Microsoft 365 Copilot	Tenant Copilot extension governance
SharePoint	Site permissions; viewer licensing applies at runtime
Custom website	Block for regulated environments; pair with IP allow-list
Direct Line	Block by default

Learn more. Copilot Studio security and governance.

9.14 Monitor agents with the right surface for the question

Why. Different questions have different right surfaces. Behavior questions, audit questions, and inventory questions each have a primary tool.

How. Match the surface to the question:

Agent analytics in Copilot Studio for sessions, resolution rate, and escalations.
Copilot Studio audit logs in Microsoft Purview for create, publish, share, knowledge change, and tool add events.
Application Insights export (Managed Environments) for detailed traces.
Power Platform admin center Inventory (and the Power Platform inventory API / Power Platform for Admins V2 connector) for owner, environment, authentication mode, and last publish across all agents in the tenant. This is the replacement surface for the CoE Starter Kit’s Power Platform agents inventory table, which is no longer actively maintained.

Learn more. Copilot Studio audit logs in Purview, Power Platform inventory API.

9.15 Treat autonomous agents as a higher-risk class

Why. Autonomous (event-triggered) agents run without interactive sessions, which expands the attack surface and removes the human-in-the-loop signal that interactive agents give you.

How. Keep autonomous agents in a dedicated environment, require code review on triggers, and disable them with the Event triggers DLP connector in environments that are not ready.

Learn more. Configure data policies for agents.

9.16 Govern MCP servers through advanced connector policies

Why. Model Context Protocol (MCP) servers extend agents with external tools. From a governance standpoint, each MCP server is an integration path that must be governed; treating it informally creates an unaudited surface.

How. MCP connectors are a distinct connector class in Power Platform — they are not custom connectors and are not governed through custom connector DLP. Instead, use advanced connector policies (ACP) to control MCP server registration and usage. Review the server code or vendor, restrict outbound network paths, and block ad-hoc registration by makers through ACP rules.

Learn more. Agents and MCP, Data policies.

10. Agent Authentication and Connector Governance

Agents built in Copilot Studio interact with data and services through connectors, knowledge sources, and tools. Connector governance for agents uses the same Power Platform DLP engine applied to Power Apps and Power Automate, but a few controls are agent-specific.

10.1 Choose an authentication mode

Why. Authentication mode determines who can use the agent and whether platform sharing controls apply at all.

How. Pick one of three modes:

Authenticate with Microsoft (default) — uses Microsoft Entra ID. The agent requires sign-in; sharing limits apply.
Authenticate manually — generic OAuth 2.0 (Okta, Auth0, custom IdP). Agent requires sign-in but identity lives outside Entra ID.
No authentication — public link or embedded web chat. Sharing limits are bypassed.

Block the connector Chat without Microsoft Entra ID authentication in Copilot Studio in the tenant baseline DLP to remove the No authentication option entirely.

Learn more. Configure user authentication.

10.2 Use Entra Agent ID for outbound calls (preview)

Why. Older agent integrations relied on stored client secrets, which are awkward to rotate and easy to leak. Entra Agent ID replaces that pattern with a managed identity model that the platform owns.

How. Entra Agent ID (currently in preview) provisions each Copilot Studio agent with its own Microsoft Entra service principal of subtype Agent. Once enabled per environment, the agent presents this identity on outbound calls. The Agent ID is managed by the platform and visible in the Entra ID portal under enterprise applications. Administrators opt in at the environment level; the feature is not automatic by default. Where legacy connectors still rely on stored secrets, rotate them through Azure Key Vault.

Learn more. Entra agent identities (preview).

10.3 Block high-risk connectors

Why. A handful of connectors account for most of the risk in agent tooling. Blocking them by default forces every exception to be justified.

How. Common blocks for regulated tenants:

HTTP, HTTP with Microsoft Entra ID (or endpoint-filter them to an allow-list).
Chat without Microsoft Entra ID authentication in Copilot Studio.
Skills (Bot Framework skills as tools).
Event triggers (autonomous agents).
Custom connectors unless catalog-approved.

Learn more. Configure data policies for agents.

10.4 Use action control for partial approval

Why. Some connectors are too useful to block entirely but too dangerous to allow in full. Action control gives you a middle ground.

How. Allow read actions and block write actions on high-risk connectors — for example, allow Get rows on SQL Server but block Execute a SQL query.

Learn more. Connector action control.

10.5 A scripted policy baseline

Why. A baseline that lives only in the UI is not portable across tenants and not testable in code review. PowerShell-defined baselines fix both problems.

How. A starter snippet using the Power Apps Administration PowerShell module:

# Create a new DLP policy
$policy = New-AdminDlpPolicy -DisplayName "Agent baseline"

# Move SharePoint Online to the Business data group
Set-AdminDlpPolicy -PolicyName $policy.PolicyName `
  -MoveTo "BusinessDataOnly" `
  -ConnectorName "shared_sharepointonline"

# Move HTTP to the Blocked group
Set-AdminDlpPolicy -PolicyName $policy.PolicyName `
  -MoveTo "Blocked" `
  -ConnectorName "shared_logicflows_http"

# Set the default group for new connectors to Blocked
Set-AdminDlpPolicy -PolicyName $policy.PolicyName `
  -SetNonBusinessDataGroupState "Block"

Learn more. DLP PowerShell cmdlets.

10.6 Govern tools, prompts, and MCP

Why. Agents do more than call connectors. Prompt content and external tools are governance surfaces in their own right; ignoring them leaves a hole the connector model alone cannot close.

How. Govern each surface:

Generative orchestration with built-in prompts — control via the AI prompts and Generative AI settings rules.
Custom prompts (prompt columns, AI Builder prompts) — audit through Dataverse.
MCP servers as external tools — govern through advanced connector policies (ACP) and inventory via the Copilot Studio admin center.

Learn more. Agents and MCP, Data policies.

10.7 Constrain knowledge sources upstream

Why. Knowledge sources are the easiest way for an agent to reach data the maker should not be able to reach. Upstream labels and authentication requirements close that gap.

How. Apply layered controls:

Require authenticated SharePoint sources; block public websites in regulated environments.
Apply Microsoft Purview sensitivity labels upstream; agents honor label-based access for SharePoint and OneDrive content.
Use the Accessing transcripts from conversations in Copilot Studio agents rule to block transcript retention where conversations could contain sensitive prompts.

Learn more. Purview sensitivity labels for Copilot, Endpoint filtering.

11. Application Lifecycle Management and Pipelines

Application Lifecycle Management (ALM) for Power Platform is built on solutions. A solution is a versioned container for apps, flows, agents, tables, roles, and environment variables. Movement between environments always goes through solution export and import — manually, via Power Platform Pipelines, or via Azure DevOps or GitHub.

11.1 Treat solutions as the unit of deployment

Why. Solutions give you a versioned, traceable artifact. The Default Solution does not; deploying out of it is how teams lose change history.

How. Use one solution per deployable unit and avoid the Default Solution.

Learn more. ALM basics.

11.2 Make flows solution-aware

Why. Non-solution-aware flows do not move cleanly between environments. Teams that skip this setting end up rebuilding flows in production by hand.

How. Turn on Default to creating new cloud flows as solution-aware so every new flow lands in a solution by default.

Learn more. ALM basics.

11.3 Use environment variables and connection references

Why. Hard-coded connection strings and configuration values break promotion. Variables and references decouple configuration from solution content.

How. Use environment variables for configuration and connection references for flows and agents so connections can be rebound per environment without editing solution content.

Learn more. ALM basics.

11.4 Version solutions semantically

Why. Semantic versioning makes it possible to reason about what changed between releases. Without it, “version 7” tells you nothing.

How. Use semantic versioning (1.4.2) and tag the source control commit that produced each version.

Learn more. ALM basics.

11.5 Adopt Power Platform Pipelines for native deployment

Why. Pipelines provide a deployment surface that runs inside the Power Platform itself — no external CI/CD required. For most low-code teams, they are the right starting point, and as of 2024 Microsoft has positioned them as the strategic replacement for the now-deprecated ALM Accelerator for Power Platform (covered in 11.6).

How. Pipelines require a host environment where the pipeline configuration is stored. Target environments must be Managed Environments (the host itself does not need to be). Source and target environments are registered in the host. A deployment imports a solution, rebinds connection references, and runs solution checker. Approvals can be attached to deployment stages.

Learn more. Power Platform Pipelines.

11.6 Set up the pipelines host (and migrate off the ALM Accelerator)

Why. Two pieces of status to keep straight when standing up native ALM:

The ALM Accelerator for Power Platform is deprecated (Microsoft Learn page last updated 2024-04-09). Microsoft’s overview page is now titled “ALM Accelerator for Power Platform (Deprecated)” and carries this notice: “The ALM Accelerator is deprecated and will be removed in a future release. Use Pipelines in Power Platform to bring ALM automation capabilities to Power Platform and Dynamics 365 services. Pipelines can be used with source code integration or extended to integrate with other providers.” The accelerator was a canvas-app-plus-Azure-Pipelines reference implementation; the strategic replacement is the native Power Platform Pipelines experience described in 11.5. The accelerator continues to function for now, but no new investment is going into it and it is on track to be removed.
The pipelines host solution is not the CoE Starter Kit. They are different solutions with different purposes; conflating them leads to stalled rollouts. (The CoE Starter Kit itself is also no longer actively maintained — see part 1, section 8.6 — but that is a separate transition from the ALM Accelerator one.)

How. Install the Power Platform Pipelines managed solution in the host environment (sometimes referenced as the Deployment Pipeline Configuration app). Register environments in the Deployment Environments table. If your tenant currently runs on the ALM Accelerator canvas app and Azure DevOps templates, treat this as the trigger to plan a migration to Pipelines — start by mapping each accelerator pipeline to a Pipelines stage, then route new solutions through Pipelines and freeze the accelerator pipelines for net-new work. Source-control integration is on the Pipelines roadmap; if you need it today, fall back to Build Tools or GitHub Actions (11.10) rather than to the accelerator.

Learn more. Set up Pipelines, ALM Accelerator for Power Platform (Deprecated).

11.7 Run pipelines as service principals

Why. Pipelines should not depend on a human account that might leave the company. Service principals carry their own lifecycle and credentials.

How. Assign a service principal with System Administrator in source and target environments. Use a delegated service account or managed identity where supported to avoid storing client secrets.

Learn more. Application users.

11.8 Promote solutions with the PAC CLI

Why. Manual export and import via the UI is fine for one-off moves but not for repeatable deployments. The CLI is what survives review, automation, and offboarding.

How. A typical export/import:

pac auth create --url https://dev.crm.dynamics.com
pac solution export --name HRSolution --path ./HRSolution.zip --managed
pac auth create --url https://test.crm.dynamics.com
pac solution import --path ./HRSolution.zip --force-overwrite

Learn more. pac pipeline reference.

11.9 Trigger a pipeline deployment from the CLI

Why. Pipeline runs should be drivable from automation. The CLI provides exactly the surface needed.

How. Authenticate against the source environment first, then run:

pac pipeline deploy --solutionName HRSolution `
                    --currentVersion 1.4.1 `
                    --newVersion 1.4.2 `
                    --stageId <stageId>

The active pac auth profile selects the pipeline; deployment notes are not a CLI argument and are added through the admin UI when needed.

Learn more. pac pipeline reference.

11.10 Use Azure DevOps or GitHub when policy requires it

Why. Native pipelines are the right tool for most low-code teams, but they do not cover every release scenario — external approvals, multi-stack coordination, artifact signing.

How. Power Platform Build Tools (Azure DevOps) and Power Platform Actions (GitHub) expose the same CLI commands as pipeline tasks. Use them when the release policy requires capabilities the native pipelines do not have.

Learn more. Power Platform Build Tools, GitHub Actions for Power Platform.

11.11 Deploy managed, not unmanaged, to higher environments

Why. Unmanaged solutions in production allow layered customization that erodes traceability. Managed solutions force changes back through ALM.

How. Deploy managed solutions to test and production. Enable the Block unmanaged customizations setting per environment (under Settings > Features) for production environments to prevent unmanaged changes from being imported.

Learn more. ALM basics, Block unmanaged customizations.

12. Solution Checker and Quality Gates

Solution checker is a static-analysis engine that inspects solution contents against a Microsoft-maintained rule set. It runs on canvas apps, model-driven apps, Power Fx, Dataverse customizations, plug-ins, web resources, cloud flows, and Copilot Studio agents.

12.1 Run on demand for fast feedback

Why. Makers and reviewers want feedback before they commit, not after the fact. On-demand runs close that gap.

How. Run from the Power Platform admin center, from make.powerapps.com, or with pac solution check.

Learn more. Solution checker.

12.2 Integrate with pipelines

Why. Manual runs depend on discipline. Pipeline-integrated runs depend on configuration, which is more reliable.

How. Solution checker runs automatically before deployment in Power Platform Pipelines. No additional setup is needed beyond registering the pipeline.

Learn more. Power Platform Pipelines.

12.3 Enforce at solution import

Why. A warning that does not block is a warning that gets ignored. Enforcement turns solution checker into an actual gate.

How. In Managed Environments, set Solution checker enforcement to Warn or Block for solution import. At Block, an import containing a rule violation at or above the threshold fails with the list of offending components.

Learn more. Solution checker enforcement.

12.4 Understand the rule categories

Why. Knowing what solution checker looks for helps you read the output and prioritize fixes.

How. The rule categories include:

Security — use of Execute Fetch with user-supplied input, open redirects in web resources, plug-in secrets in traces.
Performance — non-delegable queries in canvas apps, missing indexes in Dataverse, synchronous plug-ins on create/update of high-volume tables.
Design — missing connection references, hard-coded GUIDs, deprecated API calls.
Reliability — missing error handling in flows, unbounded loops, overlapping workflow triggers.
Compatibility — usage of deprecated or removed platform features.

Learn more. Rule reference.

12.5 Run from the CLI and consume SARIF

Why. Output that can be parsed by the rest of your toolchain is output that gets used. SARIF is the lingua franca of code scanners.

How. Run with the CLI and consume the SARIF output:

pac solution check --path ./HRSolution.zip `
                   --geo Europe `
                   --ruleSet "Solution Checker"

The CLI returns a SARIF file that can be uploaded to GitHub code scanning or parsed in Azure DevOps. Severity is one of High, Medium, Low, Informational.

Learn more. pac solution check.

12.6 Configure enforcement thresholds explicitly

Why. Default thresholds may not match your risk tolerance. Configuration makes the threshold explicit instead of implicit.

How. In the admin center, Edit Managed Environments > Solution checker:

Enforcement: Block
Severity threshold: High
Exclusion rules: (solution-specific overrides)

Learn more. Solution checker enforcement.

12.7 Validate agents through complementary checks

Why. Agents have failure modes apps and flows do not — missing fallbacks, public knowledge, blocked-channel publish. No single tool covers all of them.

How. Solution checker validates the solution container that holds a Copilot Studio agent (flows, plug-ins, web resources inside the solution), and DLP enforcement validates connector usage at design time. For agent-specific quality — topic coverage, fallback behavior, knowledge source configuration — use agent evaluations (section 12.8) and manual review as part of the deployment approval. DLP policy violations (references to blocked connectors, no-authentication publish) surface as real-time authoring errors, not as solution checker findings.

Learn more. Solution checker, Configure data policies for agents.

12.8 Add agent evaluations for behavioral quality

Why. Solution checker validates structure, not behavior. Behavioral quality — does the agent give the right answer to the right prompt — needs a separate gate.

How. Copilot Studio includes agent evaluations: define test sets of prompts and expected behaviors, then run them before publish. Evaluations are complementary to solution checker, not a replacement.

Learn more. Agent evaluations.

13. Licensing and Capacity Governance

Licensing is a governance concern because runtime usage of Power Platform and Copilot Studio is gated by assigned licenses and consumed capacity. Capacity misconfiguration is a leading cause of outages.

13.1 Pick the right Power Apps license model

Why. Per-app and per-user pricing have different break-even points. Choosing the wrong one for your usage pattern overpays for licenses or under-provisions makers.

How. Power Apps ships per user or per app. Per-app covers one app (or one portal) per license per user; per-user covers unlimited apps. Pick based on the number of apps the average user consumes.

Learn more. Power Platform licensing overview.

13.2 Match Power Automate plans to flow type

Why. Per-user, per-flow, and process plans suit different scenarios. Buying the wrong plan creates a cliff: either you over-license low-volume flows or run out of capacity on high-volume ones.

How. Power Automate ships per user (user plan) or per flow (Process license). The Hosted Process license is a superset that adds hosted machine capacity for unattended RPA workloads. Pick per-user for broad automation adoption; use Process or Hosted Process licenses for high-volume or RPA-specific flows.

Learn more. Power Platform licensing overview.

13.3 Allocate Dataverse capacity per environment

Why. Without explicit allocation, environments draw from the tenant pool until exhausted. When the pool is gone, every over-pool environment goes read-only at once.

How. Dataverse capacity (database, file, log) accrues per tenant and is allocated per environment. Assign capacity explicitly under Resources > Capacity > Environments.

Learn more. Capacity in admin center.

13.4 Plan Copilot Studio consumption

Why. Copilot Studio consumption is metered in credits, and there is no hard tenant-wide cap. Budget alerts, not blocks, are the primary guard against runaway spend.

How. Copilot Studio consumes Copilot Credits based on feature type (generative answers, actions, autonomous events), sold as prepaid capacity or pay-as-you-go (PAYG). Microsoft 365 Copilot user licenses include a separate allowance. Credit consumption varies by the capabilities an agent invokes, not by a flat per-message rate. Constraints to plan for:

PAYG requires a billing policy linked to an Azure subscription, configured at the environment level; without it, PAYG is inactive.
Configurable consumption caps are being introduced (2026 release wave 1); until fully rolled out, budget alerts remain the primary guard against runaway spend.
Consumption reporting is in Resources > Capacity > Copilot Studio.

Monitor trends weekly and set Azure budget alerts on the PAYG meter subscription.

Learn more. Copilot Studio licensing, Pay-as-you-go setup.

13.5 License Power Pages by site capacity

Why. Power Pages licensing is per-site, not per-user, which is easy to miss when projecting cost.

How. Power Pages is licensed by authenticated or anonymous user capacity per site. Plan capacity per site, not per identity.

Learn more. Power Platform licensing overview.

13.6 Use group-based licensing and audit monthly

Why? Direct license assignment leaves orphaned licenses behind when users leave. Group-based licensing keeps assignment in sync with employment.

How. Use Microsoft Entra ID group-based licensing. Audit monthly with PowerShell:

Connect-MgGraph -Scopes "Directory.Read.All"
Get-MgUser -All -Property AssignedLicenses,UserPrincipalName |
  Where-Object { $_.AssignedLicenses.SkuId -contains "<Power Apps Per User SKU>" } |
  Select-Object UserPrincipalName

Learn more. Power Platform licensing overview.

13.7 Account for Developer Plan environments

Why. Developer environments are free per user but count against tenant environment quotas. Without a plan, they accumulate quietly.

How. Power Apps Developer Plan provides free developer environments (up to three per user) for learning and building. Developer environment capacity does not count against the tenant’s paid environment quota. Use default environment routing to manage developer environments centrally.

Learn more. Developer Plan.

14. Change Management and Release Rings

Power Platform receives continuous updates from Microsoft and from in-tenant makers. A change management practice that controls both streams keeps environments predictable.

14.1 Choose a release channel per environment group

Why. Microsoft pushes updates continuously. Channels let you control whether an environment gets updates as soon as they ship or after a slower validation period — a critical lever for production.

How. Power Platform environments support three channels:

Auto (default) — updates arrive as they are released to ring-by-ring deployment and are recommended for production environments where stability is achieved through Microsoft’s own gradual rollout.
Monthly — fixed monthly cadence; let’s pilot environments to preview the next set of updates before they reach Auto.
Semi-Annual — available for model-driven apps; updates arrive on a six-month cadence for organizations that need longer validation cycles.

Set the channel with the environment group rule Release channel. Production groups typically stay on Auto; pilot groups use Monthly for early validation. The Semi-Annual channel is primarily relevant for model-driven app scenarios that require extended validation.

Learn more. Release channels, Model-driven app release channels.

14.2 Track Microsoft release waves

Why. Release waves announce major capability changes twice a year. They are how you anticipate behavior changes that channels alone cannot smooth over.

How. Track release waves through the Microsoft Dynamics 365 release plans site and surface relevant items in your CoE communications.

Learn more. Release waves.

14.3 Gate previews and experimental features

Why. Preview features can disappear, change behavior, or carry undocumented limits. They do not belong in regulated environments.

How. Use the Generative AI settings and Preview and experimental AI models rules at the environment group level to gate preview capabilities. Keep previews off in regulated groups; enable in a pilot group with representative data.

Learn more. Rules for environment groups.

14.4 Define in-tenant change categories

Why? Treating every deployment the same way over-controls routine changes and under-controls risky ones. Categories let you match scrutiny to risk.

How. Apply the same change categories used in traditional IT:

Standard (pre-approved) — patch increments of an existing solution, deployed via pipelines.
Normal — new apps, flows, or agents; requires CoE or architecture review.
Emergency — hotfixes; post-implementation review required.

Each category maps to a pipeline approval configuration. Approvals are implemented as Dataverse records in the pipelines host with Azure AD group-based reviewer lists.

Learn more. Power Platform Pipelines.

14.5 Use administration mode during deployments

Why. Deploying while users are active risks corrupted state and poor user experience. Administration mode blocks user traffic while the change is being made.

How. Enable administration mode with the CLI:

pac admin set-runtime-state --runtime-state AdminMode

Revert with --runtime-state Enabled.

Learn more. Administration mode.

14.6 Take a manual backup before risky changes

Why. Automatic backups follow a schedule; risky changes do not. A manual restore point taken just before a deployment is the cheapest insurance available.

How. Run pac admin backup to create a manual restore point. Set the Backup retention rule to at least 28 days for production groups.

Learn more. Manual backups.

14.7 Communicate changes through known channels

Why. Surprises drive support volume. The cheapest way to reduce surprise is to communicate changes through channels the audience already reads.

How. Layer three channels:

The Message Center in the Microsoft 365 admin center surfaces Power Platform MC alerts. Subscribe Power Platform admins and CoE members.
Use the Maker welcome content rule to publish in-product notices for upcoming behavior changes.
Maintain a tenant changelog in the CoE environment, linking MC IDs, affected environments, and owners.

Learn more. Message Center.

14.8 Plan for rollback

Why. Rollback in Power Platform is limited and asymmetric. Pretending it is straightforward leads to ugly outages when something does need to be reversed.

How. Rollback is constrained to Dataverse restore points and solution re-import of a prior version. Canvas apps retain version history; model-driven apps roll back via solution version. For Copilot Studio, earlier agent versions can be restored from the agent version list.

Learn more. Manual backups, Copilot Studio agent versions.

Conclusion: bringing both parts together

Power Platform governance is not a single product, a single policy, or a single role. Across the two articles in this reference, the cumulative result is shown to be the result of many small, well-placed controls working together. Part 1 covered the platform on which everything stands: an environment topology that matches how the organization actually builds, a default environment treated as a perimeter rather than a playground, Managed Environments and environment groups that make policy enforceable at scale, DLP and tenant isolation that bound where data can move, identity and Conditional Access that decide who is allowed to touch the platform at all, and monitoring that turns activity into evidence. Part 2 covered everything that runs on that platform: Copilot Studio controls that extend the same model to AI agents, agent authentication and connector governance that shape what agents are allowed to do, ALM and pipelines that move solutions through environments traceably, solution checker and agent evaluations that gate quality at import and publish, licensing and capacity governance that prevent runtime surprises, and change management practices that absorb both Microsoft’s rollouts and your own without disrupting users.

The two halves only work together. Part 1’s controls are not useful without something to govern; part 2’s controls do not stick without the foundations underneath them. Sharing limits matter only because Managed Environments make them enforceable. Solution checker enforcement matters only because environmental groups can apply it consistently. Entra Agent ID matters only because Conditional Access gates the identities of those agents present. The two articles are designed to be read as a single document, split for readability, not as independent pieces.

The controls described across both parts already exist in the platform today. Nearly all are generally available; Entra Agent ID (section 10.2) is still in preview. None of them requires custom engineering or third-party tooling to be useful. What they require is decision-making: which environments belong in which group, which connectors are business versus non-business, which agents must authenticate with Microsoft Entra ID, which release channel each group follows, who approves a production deployment, and where the lines are drawn between regulated and general-purpose work. Those decisions are governance.

Start small and iterate. A minimum viable posture across both articles is: restrict default environment creation, attach a tenant-wide baseline DLP policy, enable default environment routing with a Managed Environments group, turn on tenant-level analytics, lean on the Power Platform admin center’s Inventory, Usage, Monitor, and Actions experiences (the CoE Starter Kit is no longer actively maintained), verify your tenant isolation defaults, require authenticated agents, run solution checker at import, deploy through Power Platform Pipelines as a service principal (the strategic replacement for the now-deprecated ALM Accelerator), and set Auto channel for production with Monthly for a pilot ring. Everything else in these two articles is a refinement on that foundation. Governance that grows with the platform is governance that lasts; governance that is bolted on after an incident rarely recovers the ground it lost.

Read this reference end to end once to map the territory, then return to it section by section as decisions come up. Both articles are designed to be skimmed for vocabulary and read closely when a specific control is at issue.

Power Platform Governance: A Practitioner's Reference (Part 1)

Sat, 16 May 2026 00:00:00 +0000

Summary lede. Power Platform and Copilot Studio now let every licensed Microsoft 365 user build apps, automations, and AI agents that touch enterprise data. This first part of a two-article reference walks through the platform-level foundations that everything else rests on — environment strategy, default-environment hardening, Managed Environments, environment groups and rules, DLP, tenant isolation, identity, and monitoring — and shows how they combine into a coherent, enforceable posture. Part 2 next week will cover Copilot Studio governance, agent authentication, ALM and pipelines, solution checker, licensing, and change management.

Who this is for. Power Platform administrators, security or compliance officers responsible for a Microsoft 365 tenant, Center of Excellence leads, architects, designing a low-code or AI-agent platform, and makers who want to understand the guardrails around the tools they build with. The document replaces fragmented documentation with an ordered walkthrough of what actually exists today: CLI snippets, PowerShell examples, and direct links to authoritative Microsoft Learn pages. Nothing here is speculative, so the patterns can be applied to a tenant without waiting for a future release. If you need to defend an environment posture to auditors, onboard a new admin, set priorities for a governance rollout, or decide what “good” looks like for your tenant, this gives you the vocabulary, the examples, and the reasoning in one place.

Why governance matters

Power Platform and Copilot Studio have turned a large part of every Microsoft 365 tenant into a build surface. Employees who never wrote code are now authoring apps, flows, and AI agents that read from SharePoint, write to Dataverse, send email on behalf of users, and call external APIs. That shift changes the risk profile of the tenant in ways that are visible to three constituencies, each with a different stake.

For the business, governance is what keeps low-code and AI investments returning value instead of accumulating liability. Ungoverned environments grow a long tail of half-finished apps, orphaned flows, and agents with unknown owners — each one a support ticket, compliance finding, or incident waiting to happen. Regulators increasingly ask who authored a control, what data it touched, and how changes were approved. A documented governance posture answers those questions without forensic archaeology and lets the business say yes to new use cases because the controls are already in place.

For IT, governance is the mechanism that preserves tenant integrity while the perimeter expands. Data Loss Prevention, tenant isolation, identity controls, and pipelines are not optional add-ons; they are how IT shifts from gatekeeper to platform operator. Without them, the only available stance is blanket denial — which does not reduce risk, because work simply moves to spreadsheets, personal accounts, and shadow SaaS where IT has no visibility at all. With them, IT can set guardrails at the platform level, delegate day-to-day authoring to business units, and focus engineering time on integrations, security, and automation.

For makers, governance is the difference between building with confidence and building in the dark. Clear environment boundaries, known DLP rules, a predictable ALM path, and a Center of Excellence to turn to all reduce the cognitive load of citizen development. Makers who know what is allowed spend their time on business logic, not on working around unclear policy. Maker welcome content, solution checker, and sharing limits exist to shorten the feedback loop so that problems are caught while they are still cheap to fix.

This first article works through the platform-level foundations: environment design, the default environment, Managed Environments, environment groups, DLP, tenant isolation, identity, and monitoring. Each control begins with the reason it exists, moves to the how, and points you to the authoritative Microsoft Learn page. Part 2 will build on this base by covering the resources that live inside those environments — Copilot Studio agents, ALM, licensing, and change management.

A note on the kits.
If you are coming to this article expecting the CoE Starter Kit or the ALM Accelerator to do the governance heavy lifting: that picture has changed. Microsoft has confirmed that the CoE Starter Kit is no longer actively maintained — its core capabilities are now part of the Power Platform admin center — and the ALM Accelerator for Power Platform is formally deprecated, with Power Platform Pipelines as the named replacement. Section 8.6 covers the CoE Starter Kit transition to the admin center; section 3.5 covers the ALM Accelerator → Pipelines transition; the rest of the article reflects that shift.

1. Environment Strategy

An environment in Power Platform is a container for apps, flows, agents, connections, and Dataverse data. Environment design is the foundation of governance because DLP scope, security roles, capacity, and compliance boundaries all follow environment lines. Get the topology right and every later control has somewhere clean to attach. Get it wrong and you spend the rest of the rollout retrofitting policy onto a sprawl.

1.1 Know the environment types

Why. Each type carries different defaults for licensing, data residency, and lifecycle. Choosing the wrong type at provisioning time creates rework that is rarely cheap to undo.

How. Five types are in active use today:

Default — one per tenant, created automatically, open to every licensed user.
Production — business-critical workloads, backed by Dataverse.
Sandbox — non-production, resettable, suitable for UAT and load tests.
Developer — single-maker environments, created manually or via routing.
Trial and Teams — time-limited or chat-scoped; not recommended for production assets.

Learn more. Environments overview.

1.2 Adopt a topology that mirrors your delivery lifecycle

Why. A topology aligned with how your organization actually builds shortens the path from idea to production and gives every governance rule (DLP, sharing limits, release channel) a natural place to land.

How. A typical enterprise pattern separates by lifecycle and purpose:

Default  -> personal productivity only (restricted)
DEV-*    -> per-maker or per-team developer environments
TEST-*   -> solution UAT with production-like data volume
PROD-*   -> published solutions, scoped by region or business unit

Add a dedicated CoE environment for governance tooling (pipelines host and any remaining CoE Starter Kit components — see section 8.6 for the kit’s status) and a training environment for enablement.

Learn more. Establishing an environment strategy.

1.3 Restrict who can create environments

Why. Self-service environment creation is the fastest way to lose tenant-wide visibility. Most makers do not need to create environments; the few who do should be deliberately empowered.

How. In tenant settings, configure Who can create production and sandbox environments and Who can create trial environments to limit creation to admins or a named CoE group. For repeatable provisioning, drive creation through the CLI:

pac admin create --name "DEV-Finance-EU" --type Sandbox --region europe

Learn more. Control who can create environments, pac admin reference.

1.4 Pick a region before you provision

Why. Environments are region-locked. Region determines data residency, latency, and which regional services (Application Insights endpoints, Dataverse data centers) integrate cleanly. Moving an environment between regions is not a supported operation.

How. Choose the region from the regional catalog at provisioning time. For regulated workloads, pick the region that satisfies the controlling jurisdiction even if it is not where most of your users sit.

Learn more. Environment regions.

1.5 Plan capacity before you turn on Dataverse

Why. Dataverse-enabled environments draw from a tenant-wide capacity pool. Capacity surprises are a leading cause of unplanned read-only mode in production.

How. Any Dataverse-enabled environment — production or sandbox — requires the tenant-level minimum of 1 GB of database capacity. Capacity is a tenant pool, not a per-environment allocation, so plan total tenant capacity against the number of Dataverse-enabled environments you intend to run.

Learn more. About Dataverse storage capacity.

1.6 Isolate regulated workloads

Why. DLP, security roles, and Dataverse auditing settings are scoped per environment. Mixing regulated and non-regulated workloads in the same environment forces every control to be the strictest common denominator and complicates compliance reporting.

How. Provision separate environments for HR, Finance, and other regulated workloads. Each one becomes a clean target for environment-specific DLP, role assignments, and backup retention.

Learn more. Establishing an environment strategy.

2. Governing the Default Environment

The default environment is the only environment created automatically in every Power Platform tenant. Every licensed user is a member and holds the Environment Maker role, which lets them create apps, flows, connections, and Copilot Studio agents. It is always present, always writable, and cannot be deleted or renamed — which makes it the single most common source of shadow IT on the platform. It needs explicit governance, not benign neglect.

2.1 Understand what makes the default environment different

Why. Treating the default environment like any other production environment leads to surprises. Several behaviors are unique to it and cannot be disabled.

How. Plan around four facts:

It cannot be deleted. It can be renamed and reassigned to a non-default type for display purposes, but Microsoft treats it as the fallback environment for personal productivity.
Every new tenant user inherits Environment Maker. There is no tenant setting that removes this role on the default environment.
Dataverse is optional by default, but once added it cannot be removed.
Connectors default to the same tenant-wide DLP policy as any other non-scoped environment.

Learn more. Default environment overview.

2.2 Rename and tag for clarity

Why. Makers cannot make good decisions about where to build if the default environment looks like any other production candidate. The name is the first signal.

How. Rename the default environment to something like Personal Productivity (Default) so its purpose is unambiguous. Apply a consistent solution-naming convention for any assets that genuinely belong there (such as personal flows).

Learn more. Default environment overview.

2.3 Attach a restrictive DLP policy

Why. The default environment is where ungoverned makers land first. A restrictive DLP policy turns the blast radius from “every connector Microsoft ships” into a known, defensible set.

How. Move risky connectors (HTTP, custom connectors, social media, unauthenticated agent chat) to Blocked. Keep only Microsoft 365, Dataverse, and a short approved list in Business.

Learn more. Data policies overview.

2.4 Keep Dataverse out (or contained) by default

Why. Once Dataverse is added to the default environment, it cannot be removed. Production data living next to ungoverned personal flows is a compliance problem that is hard to walk back.

How. If the default environment still lacks Dataverse, leave it off. Production data belongs in dedicated environments where capacity and backup are managed deliberately.

Learn more. Default environment overview.

Why. Without sharing limits, a maker can publish an app or agent to the entire tenant with one click. The default environment is the most common origin for that mistake.

How. Convert the default environment to a Managed Environment and apply Limit sharing rules: cap the number of users an asset can be shared with and disable sharing through security groups. Mechanics are covered in section 3.

Learn more. Limit sharing in Managed Environments.

2.6 Enable default environment routing

Why. The cleanest way to keep the default environment empty is to redirect new makers somewhere else automatically. Routing replaces “the default environment is where people end up” with “the default environment is where nobody builds.”

How. Turn on default environment routing under Settings > Default environment routing in the Power Platform admin center. Each routed maker receives a personal developer environment; group those environments with Environment groups and apply policies in bulk (sharing limits, maker welcome content, solution checker).

Learn more. Default environment routing, Environment groups.

2.7 Lock down agents and Copilot in the default environment

Why. Copilot Studio agents created in the default environment are immediately discoverable by all licensed users. Without explicit controls, makers can publish unauthenticated agents, call any non-blocked connector, and add knowledge sources the creator already has access to.

How. Apply layered controls: convert the default environment to a Managed Environment, block the Chat without Microsoft Entra ID authentication in Copilot Studio connector in DLP, block the HTTP and HTTP with Microsoft Entra ID connectors, and enable tenant-level Copilot Studio restrictions on who can publish.

Learn more. Data policies for Copilot Studio, Tenant settings reference.

2.8 Turn on monitoring before you need it

Why. Telemetry collected after an incident is worth less than telemetry collected before one. Get visibility on the default environment first, because that is where ungoverned activity tends to land.

How. Enable tenant-level analytics in the Power Platform admin center to capture telemetry. Use the admin center Inventory, Usage, Monitor, and Actions experiences to list apps, flows, and agents by owner — these have replaced the CoE Starter Kit inventory flows (see section 8.6). Review the Managed Environments weekly digest for inactive and top-used assets.

Learn more. Tenant-level analytics.

2.9 A starting DLP stance

The example below is not a policy you should ship verbatim, but it is a defensible starting point for a default environment that has no other governance in place:

Business group:    Microsoft 365 connectors (Outlook, SharePoint, Teams, OneDrive), Dataverse, Approvals
Non-business:      (empty)
Blocked:           HTTP, HTTP with Microsoft Entra ID, custom connectors,
                   Chat without Microsoft Entra ID authentication in Copilot Studio,
                   SMTP, FTP, social media connectors

Learn more. Create a data policy, Control environment creation.

3. Managed Environments

Managed Environments is a premium governance layer that augments a standard environment with administrative controls. Enabling it does not change the environment’s region, type, or Dataverse schema; it activates a set of tenant-visible features that admins can enforce. Most of the controls that follow in this document depend on Managed Environments being on.

Why. Uncontrolled sharing is one of the highest-impact governance gaps. A single misconfigured share can expose an app or agent to the entire tenant.

How. Cap the number of users an app or agent can be shared with, block sharing through security groups, and block editor sharing. Configure under Edit Managed Environments > Limit sharing. Rules apply on the next share action; existing assignments remain.

Learn more. Limit sharing.

3.2 Receive a weekly digest

Why. Admins do not have time to log into the admin center every day. A scheduled summary keeps inactive and top-used assets in front of them without manual polling.

How. Power Platform and Dynamics 365 admins automatically receive an email summary covering active users, top apps, and inactive apps and flows. Add additional recipients via PowerShell:

$t = Get-TenantSettings
$t.powerPlatform.governance |
  Add-Member -NotePropertyName additionalAdminDigestEmailRecipients `
             -NotePropertyValue 'coe@contoso.com;ops@contoso.com'
Set-TenantSettings -RequestBody $t

Learn more. Usage insights (weekly digest).

3.3 Enforce solution checker

Why. Static analysis catches problems while they are cheap to fix. Without enforcement, solution checker becomes optional and stops being run.

How. Run static analysis on solution import; warn or block. Configure under Edit Managed Environments > Solution checker (mechanics in part 2, section 12).

Learn more. Solution checker enforcement.

3.4 Show maker welcome content

Why. Makers who never see your governance guidance cannot follow it. The first experience inside the maker portals is the cheapest channel for organizational rules.

How. Configure a banner that appears for new makers in make.powerapps.com and copilotstudio.microsoft.com. Use it to point makers at internal documentation, the right environments, and approval processes.

Learn more. Managed Environments overview.

3.5 Host Power Platform Pipelines

Why. Power Platform Pipelines are the native, low-code path for promotion across environments. They require Managed Environments to run, and as of 2024 Microsoft has positioned them as the strategic replacement for the ALM Accelerator for Power Platform, which is formally deprecated and slated for removal in a future release. New ALM rollouts should start here rather than on the accelerator.

How. Designate a Managed Environment as the pipelines host (covered in part 2, section 11). Source and target environments are registered in the host. If your tenant currently runs on the ALM Accelerator canvas app + Azure DevOps templates, treat this as the trigger to plan a migration to Pipelines — the accelerator continues to function for now, but no new investment is going into it.

Learn more. Power Platform Pipelines, ALM Accelerator for Power Platform (Deprecated).

3.6 Restrict Dataverse access by IP

Why. Network-level controls reduce the attack surface even when identity controls are intact. They also satisfy auditors who expect defense in depth.

How. IP firewall restricts Dataverse access to declared IP ranges. IP cookie binding adds session-level enforcement so that a stolen token cannot be replayed from a different network.

Learn more. IP firewall.

3.7 Customer Lockbox and Customer-Managed Key

Why. Regulated tenants often need explicit approval before Microsoft engineers can access tenant data, and they need encryption keys under their own control.

How. Customer Lockbox requires customer approval for Microsoft support access to environment data. Customer-Managed Key brings tenant-controlled keys into Dataverse encryption. Both require premium tenant licensing.

Learn more. Managed Environments overview.

3.8 Extend backup retention

Why. The seven-day default backup window is short for production workloads. An incident discovered on day eight has no restore point.

How. Managed Environments support extended retention windows beyond the seven-day default. Configure retention per environment or, for groups, via the Back-up retention rule.

Learn more. Manual backups.

3.9 DLP for desktop flows

Why. Desktop (RPA) flows can interact with anything on the host machine, which makes connector-level DLP particularly important for them. The control is gated behind Managed Environments.

How. Apply DLP policies to desktop flows the same way you apply them to cloud flows; enforcement happens at design and run time.

Learn more. Data policies overview.

3.10 Use the Catalog for internal distribution

Why. Without a catalog, reusable components are shared informally — by email, by chat, by file share — and traceability collapses. A catalog gives makers an approved internal store.

How. Publish components (templates, connectors, plug-ins) to the Catalog so makers can install them with provenance and version metadata.

Learn more. Managed Environments overview.

3.11 Plan for the licensing implications

Why. Managed Environments changes how runtime licensing works for users, and that change is the most common surprise during rollout.

How. Every user who activates an app, flow, or agent in a Managed Environment must hold a premium Power Platform license (Power Apps per user/per app, Power Automate Premium, or Dynamics 365). Confirm license posture before flipping the switch.

Learn more. Power Platform licensing overview.

3.12 Enabling

Why. The toggle is per environment, so enablement is a deliberate act, not a tenant flag.

How. In the Power Platform admin center, choose the environment, then Edit Managed Environments. From the CLI:

pac admin set-governance-config --environment-id <GUID> --protection-level Standard

Learn more. Enable Managed Environments.

3.13 When to enable

Why. Managed Environments costs licensing and increases admin overhead. Enabling it everywhere is wasteful; enabling it nowhere defeats the purpose.

How. Use Managed Environments for any environment with production workloads, external sharing, or sensitive data. Apply it to personal developer environments created by default environment routing so sharing limits and solution checker apply uniformly.

Learn more. Managed Environments overview.

4. Environment Groups and Rules

Environment groups organize Managed Environments into collections so admins can apply policies in bulk. Each environment belongs to at most one group; groups cannot be nested or overlap; non-managed environments cannot be added.

4.1 Group environments by policy intent

Why. Without grouping, every environment is a one-off configuration. As the platform scales, that becomes unmaintainable. Groups let policy intent travel with environments instead of with people.

How. Build groups around policy needs rather than reporting structure: a regulated production group, a pilot group for previews, a routed personal-productivity group, an admin/CoE group. A typical layout:

Personal Productivity        -> routed per-maker developer envs; sharing disabled
Pilot                        -> experimental AI features on; release channel = Monthly
Production EU                -> AI off for regulated data; release channel = Auto
Production US                -> same policies as EU, separate region
CoE / Admin                  -> governance tooling; locked down

Learn more. Environment groups.

4.2 Apply rules at the group level

Why. When a rule is published at the group level, the corresponding setting becomes read-only inside each member environment. This makes policy enforceable rather than advisory; per-environment overrides are not supported.

How. Use the admin center to publish any of the rules currently available (generally available unless noted):

Sharing agents with Editor permissions
Sharing agents with Viewer permissions
Sharing controls for canvas apps
Sharing controls for solution-aware cloud flows
AI-powered Copilot features
Generative AI settings
External models
AI prompts
Accessing transcripts from conversations in Copilot Studio agents
Sharing data between Copilot Studio and Viva Insights
Maker welcome content
Release channel
Back-up retention
Solution checker enforcement
Unmanaged customizations
Usage insights
Power Apps component framework for canvas apps
Content security policy
Power Apps code apps
Preview and experimental AI models
Default deployment pipeline (preview)
Advanced connector policy (preview)
AI-generated descriptions (preview)

Learn more. Rules for environment groups.

4.3 Manage group membership from the CLI

Why. Group membership changes are routine — onboarding new environments, retiring old ones — and should be scriptable. Rule definitions still live in the admin center; the CLI handles membership.

How. Use the pac admin group commands:

pac admin list-groups
pac admin add-group --environment <env-id> --environment-group <group-id>

Learn more. pac admin reference.

4.4 Plan for group removal

Why. Removing an environment from a group is a half-revert: rule values stay where they were, but the environment becomes editable again locally. Without a manual reconciliation step, the environment can drift in ways that are hard to detect.

How. When you remove an environment from a group, treat the action as the start of a configuration review. Reconcile every formerly group-managed setting against your current standard before declaring the migration done.

Learn more. Environment groups.

4.5 Pair groups with default environment routing

Why. Routed personal developer environments multiply quickly. Without grouping, you end up with hundreds of environments each configured independently.

How. Auto-route new makers into personal environments, then assign those environments to a Personal Productivity group with sharing disabled and solution checker enforced. Policies follow membership automatically.

Learn more. Default environment routing.

5. Data Loss Prevention Policies

Data Loss Prevention (DLP) policies in Power Platform control which connectors can be combined inside apps, flows, and agents. Policies apply to Power Apps, Power Automate cloud flows, desktop flows (in Managed Environments), and Copilot Studio agents.

5.1 Sort connectors into three groups

Why. Data leaks happen when organizational data moves alongside non-organizational connectors in the same resource. The three-group model is how Power Platform prevents that combination at design time.

How. Place each connector into one of three groups:

Business — connectors that can exchange organizational data with each other.
Non-business — connectors that can exchange non-organizational data with each other.
Blocked — connectors that cannot be used at all.

Data cannot flow between Business and Non-business within the same resource.

Learn more. Data policies overview.

5.2 Set the default group for new connectors

Why. Microsoft adds connectors continuously. If new connectors land in a permissive group by default, your DLP posture decays without anyone editing policy.

How. Set the Default group to Blocked. New connectors stay blocked until an admin explicitly classifies them.

Learn more. Create a data policy.

5.3 Choose the right policy scope

Why. A tenant-wide policy is the right baseline for high-risk connectors, but environment-specific policies let you allow connectors where they are needed without opening them everywhere.

How. Target a policy at all environments (with optional exclusions), at specific environments, or only at the default environment. Policies aggregate: a connector blocked by any applicable policy is blocked for that environment.

Learn more. Create a data policy.

5.4 Filter by endpoint

Why. A blanket block on HTTP is often too restrictive. Endpoint filtering keeps the connector available for the URLs you actually need while denying everything else.

How. Allow or block specific URLs on HTTP-capable connectors, SQL Server, Azure Blob, and others. This is a premium-tier capability.

Learn more. Endpoint filtering.

5.5 Restrict individual connector actions

Why. Many connectors expose both safe (read) and dangerous (arbitrary execute) actions. Action control lets you keep the safe ones while blocking the dangerous ones.

How. Allow or block individual actions on a connector — for example, block Execute a SQL query on SQL Server while allowing table reads. Premium tier.

Learn more. Connector action control.

5.6 Allow-list custom connector patterns

Why. Custom connectors are an open door if left ungoverned. Pattern-based allow-listing lets you approve a class of internal endpoints without approving every custom connector individually.

How. Allow-list custom connectors by URL pattern. Pair with a tenant-wide block on unmatched custom connectors.

Learn more. Connector endpoint filtering.

5.7 A high-risk tenant baseline

The example below is a defensible starting point for a tenant where regulated data lives next to general productivity:

Business:      Microsoft 365 connectors (Outlook, Teams, SharePoint, OneDrive),
               Dataverse, Approvals, Planner
Non-business:  Bing Search, Translator, MSN Weather
Blocked:       HTTP, HTTP with Microsoft Entra ID (unless endpoint-filtered),
               custom connectors in default env, Twitter/X, Facebook, SMTP, FTP,
               Chat without Microsoft Entra ID authentication in Copilot Studio
Default group: Blocked

Learn more. Create a data policy.

5.8 Manage DLP from PowerShell

Why. UI configuration does not survive disaster recovery, audit reproduction, or environment cloning. Scripted policy management does.

How. Use the DLP cmdlets to retrieve, create, and modify policies:

Get-DlpPolicy
New-DlpPolicy -DisplayName "Tenant baseline"
# manage connector groups via Set-DlpPolicyDefaultConnectorGroup, Add-ConnectorToBusinessDataGroup, etc.

Learn more. DLP PowerShell cmdlets.

5.9 Understand enforcement timing

Why. Knowing when a policy takes effect is critical during incident response — and during planned changes that you do not want to break in production at noon.

How. Policy changes take effect within minutes for new resources and on the next save or publish for existing ones. Copilot Studio enforces DLP in real time; makers see a validation error immediately when a blocked connector is referenced.

Learn more. Data policies overview.

6. Tenant Isolation and Cross-Tenant Controls

Tenant isolation restricts which external Microsoft Entra ID tenants can be used as the identity source for connections inside your Power Platform tenant. It is a separate control from DLP and from Microsoft Entra B2B. DLP governs which connectors can be used; tenant isolation governs which tenants users can authenticate to when creating a connection.

6.1 Distinguish inbound from outbound

Why. Tenant isolation is directional. Mixing the two leads to either over-blocking (legitimate B2B work breaks) or under-blocking (data exfiltration paths remain).

How. Configure each direction explicitly:

Inbound — another tenant’s users creating a connection that points into your tenant.
Outbound — your tenant’s users creating a connection that points into another tenant.

Learn more. Tenant isolation.

6.2 Verify your default — it depends on tenant age

Why. The default behavior changed in 2026, and assumptions from older guidance no longer apply universally.

How. Tenants created before 30 March 2026 have both directions allowed by default; tenant isolation must be enabled explicitly. Tenants created on or after 30 March 2026 ship with tenant isolation enabled and both directions defaulting to deny — only allow-listed tenant IDs can be used. Verify the current state in your tenant rather than assuming a default.

Learn more. Restrict cross-tenant inbound/outbound.

6.3 Configure tenant isolation deliberately

Why. The control is tenant-wide; there is no per-environment override. A misconfiguration affects the entire tenant.

How. In the Power Platform admin center, under Security > Tenant isolation, set:

Tenant isolation: On
Default:          Block
Exceptions:       contoso-partner.onmicrosoft.com  (Inbound, Outbound)
                  fabrikam.onmicrosoft.com          (Outbound only)

Learn more. Tenant isolation.

6.4 Know what tenant isolation does not cover

Why. Tenant isolation is sometimes mistaken for a complete cross-tenant boundary. It is not. Pairing it with the right Entra controls is the only way to close the gap.

How. Tenant isolation applies to connectors that authenticate with Microsoft Entra ID (SharePoint, OneDrive, Dataverse, Outlook, Microsoft 365, Azure, etc.). It does not apply to:

Connectors that use API keys or generic OAuth.
Service principal and managed identity authentication, which follow Microsoft Entra cross-tenant access policies.

Pair tenant isolation with Microsoft Entra cross-tenant access settings for a complete boundary.

Learn more. Tenant isolation.

6.5 Layer Conditional Access

Why. Tenant isolation controls where identities can come from; Conditional Access controls under what conditions identity is accepted. Both layers are needed.

How. Apply Conditional Access policies to the Power Platform API application to restrict sign-in by user, device, location, and risk.

Learn more. Conditional Access for Power Platform.

6.6 Layer the IP firewall

Why. Network-level controls reduce the attack surface even when identity controls are intact. They also satisfy auditors who expect defense in depth.

How. The IP firewall (Managed Environments) restricts Dataverse access to declared IP ranges. Configure per environment.

Learn more. IP firewall.

6.7 Enable continuous access evaluation

Why. Static sign-in evaluation cannot react to changes in identity posture mid-session. CAE narrows the window between an account becoming risky and that account losing access.

How. Continuous access evaluation (CAE) on Dataverse revokes sessions when identity posture changes — for example, when a user is disabled or moves outside an allowed network.

Learn more. Conditional Access for Power Platform.

6.8 Monitor configuration changes and runtime denials

Why. Tenant isolation is most useful when its events are visible. Two surfaces matter: configuration changes (someone modifying the policy) and runtime denials (someone hitting the policy).

How. Tenant isolation events flow to the Power Platform audit log and the Microsoft Purview unified audit log. Configuration changes appear under the TenantIsolationPolicyUpdate activity; runtime denials surface as connection-creation failures rather than under a single unified filter — review both when investigating.

Learn more. Audit logs.

7. Security Roles and Identity

Power Platform authorization is layered. Microsoft Entra ID provides tenant-level identity and global roles; Dataverse provides row- and column-level security inside each environment; connectors use per-user or service-principal credentials.

7.1 Use the right tenant role

Why. Tenant-scoped governance work does not need Global Administrator. Over-privileged accounts increase blast radius without buying capability.

How. Pick from the Microsoft Entra ID roles that govern Power Platform:

Power Platform Administrator — full control of environments, DLP, tenant settings, licenses (within Power Platform scope). Sufficient for almost all governance work.
Dynamics 365 Administrator — equivalent scope for Dynamics 365 and Dataverse-backed environments.
Global Administrator — superset; not recommended for day-to-day platform work.
Fabric Administrator — required for Power BI workspace and capacity governance that overlaps Power Platform.

Assign least-privileged roles.

Learn more. Microsoft Entra roles for Power Platform.

7.2 Map environment roles to job function

Why. Environment roles control everything inside an environment, including who can hand out further roles. A misassignment here is hard to roll back without auditing.

How. Inside each environment, the standard roles are:

System Administrator — root of the environment; can assign any role.
System Customizer — schema and solution changes without user management.
Environment Maker — create apps, flows, agents, and custom connectors.
Basic User — runtime access to assigned records.
Delegated Admin — scoped admin, granted via Microsoft Entra ID groups.

Learn more. Dataverse security roles.

7.3 Build custom roles from a known baseline

Why. Privileges in Dataverse are granular; granting * privileges in a custom role is the fastest way to recreate the problems custom roles were supposed to solve.

How. Always start from a copy of an out-of-box role and remove or add the privileges you need at table, action, and column level. Avoid wildcard privileges.

Learn more. Dataverse security roles.

Why. Individual record sharing is auditable in theory and unmaintainable in practice. Teams turn membership into access.

How. Use Owner teams or Access teams for direct ownership and sharing. For large memberships, use Microsoft Entra group teams so group membership drives row access automatically.

Learn more. Microsoft Entra group teams.

7.5 Use service principals for non-interactive work

Why. Pipelines, integrations, and admin automation should not depend on human accounts. Service principals carry their own lifecycle and credentials, which is what audit and compliance expect.

How. Register the app in Microsoft Entra ID, then assign an application user:

pac admin create-service-principal `
  --environment <env-id> `
  --name "Pipelines SPN" `
  --role "System Administrator"

Rotate secrets and prefer federated credentials or managed identities where supported.

Learn more. Application users.

7.6 Apply Conditional Access and MFA

Why. Identity is the perimeter. Conditional Access and MFA are how that perimeter actually behaves under load — risky logins, anomalous locations, compromised credentials.

How. Apply Conditional Access to the Power Platform API app and to Microsoft Dataverse. Enforce MFA for administrators and for makers who connect to sensitive data sources.

Learn more. Conditional Access.

8. Monitoring, Analytics, and Tenant Inventory

Governance without telemetry degrades quickly. Power Platform exposes several monitoring surfaces; the Inventory, Usage, Monitor, and Actions experiences in the Power Platform admin center wrap them into a tenant-wide inventory and alerting layer that Microsoft maintains as a first-party feature. The community CoE Starter Kit filled this role for years but is no longer actively maintained — section 8.6 covers what that transition means in practice.

8.1 Use admin center analytics for per-environment visibility

Why. Most operational questions (“is anyone using this app?”, “are flow runs failing?”) have answers in the admin center. Reaching for the CoE Starter Kit before checking the built-in analytics wastes time.

How. Per-environment charts cover Power Apps usage, Power Automate runs, Dataverse API calls, and Copilot Studio sessions. Tenant-level analytics must be enabled in tenant settings before charts populate.

Learn more. Tenant-level analytics.

8.2 Push the weekly digest to a wider audience

Why. The digest is a high-signal, low-noise summary. Only Power Platform and Dynamics 365 admins receive it by default, which is usually too narrow.

How. Add CoE leads, security reviewers, and operations partners using additionalAdminDigestEmailRecipients (mechanics in section 3.2).

Learn more. Usage insights (weekly digest).

8.3 Stream audit events to Microsoft Purview

Why. Platform-level actions — DLP changes, environment creations, sharing events — must be reviewable months after they happen. Purview is the long-term store.

How. Power Platform activities flow natively into the Microsoft Purview unified audit log. Search them in the Purview portal, with the Search-UnifiedAuditLog Exchange Online PowerShell cmdlet, or via the Microsoft 365 Audit API.

Learn more. Audit logs and Purview, Search the audit log.

8.4 Turn on Dataverse auditing per table

Why. Per-table read and change auditing is the only way to answer record-level forensic questions (“who saw this row?”, “what changed and when?”). Without it, the trail stops at the API layer.

How. Enable auditing on tables that hold sensitive data. Retention follows the environment’s audit retention setting; review it before assuming you have history.

Learn more. Audit logs and Purview.

8.5 Export to Application Insights

Why. Built-in analytics is summary-level. Application Insights gives you raw traces for performance and error analysis — the same signal an Azure team would expect.

How. In an environment’s settings under Product > Application Insights (preview), add the connection string:

InstrumentationKey=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx;
IngestionEndpoint=https://westeurope-1.in.applicationinsights.azure.com/

Power Apps emit pageView, traceEvent, and error events; model-driven apps add form performance metrics.

Learn more. Application Insights for Power Platform.

8.6 The CoE Starter Kit and ALM Accelerator — what changed

Why. Until recently, the CoE Starter Kit and the ALM Accelerator for Power Platform were the two community-driven kits most enterprise governance setups leaned on — one for inventory and oversight, the other for solution promotion and source control. Native, in-product experiences now supersede both, and following the old guidance without qualification leads new tenants into a maintenance dead end.

How. Two formal status updates to be aware of:

CoE Starter Kit — no longer actively maintained (Microsoft, May 2026). The Microsoft Learn page now opens with a clear notice: “The Power Platform CoE Starter Kit is no longer actively maintained. Its core capabilities are part of the Power Platform admin center. Issues are no longer reviewed or addressed.” The kit remains available for existing and new deployments, but it will not receive new features, and GitHub issues are not triaged. Microsoft directs admins to the native admin center experiences instead:
- Inventory — view and govern all apps, flows, and agents across the tenant.
- Usage — track adoption and identify top resources and their owners.
- Monitor — operational health of heavily used resources.
- Actions — surface risks, enforce best practices, and act on governance insights.
Beyond the UI, the same data is reachable through the Power Platform CLI, the Power Platform API, the Power Platform inventory API, and the Power Platform for Admins V2 connector — which is what to build automation against going forward.
ALM Accelerator for Power Platform — formally deprecated (Microsoft Learn page last updated 2024-04-24). Microsoft’s overview page is now titled “ALM Accelerator for Power Platform (Deprecated)” and carries this notice: “The ALM Accelerator is deprecated and will be removed in a future release. Use Pipelines in Power Platform to bring ALM automation capabilities to Power Platform and Dynamics 365 services. Pipelines can be used with source code integration or extended to integrate with other providers.” The accelerator was a canvas-app-plus-Azure-Pipelines reference implementation; the strategic replacement is the in-product Power Platform Pipelines experience (introduced in section 3.5 and detailed in part 2). The accelerator continues to function for now, but no new investment is being made in it, and it is on track to be removed.

Practical recommendation. If you already run either kit, keep operating it — neither is being switched off tomorrow — but stop building new dependencies on top of it. For inventory, attestation, and orphaned-asset detection, build against the admin center experiences and the inventory API. For ALM, route new solutions through Power Platform Pipelines and plan a migration off the ALM Accelerator to avoid being caught out when a removal date is announced. Tenants starting from scratch in 2026 should skip both kits and build directly on the in-product surfaces.

Learn more. CoE Starter Kit transition to Power Platform admin center, ALM Accelerator for Power Platform (Deprecated), Power Platform Pipelines, Power Platform inventory API.

8.7 Forward to Microsoft Sentinel

Why? SOCs want one queue. Forwarding Power Platform signals to Sentinel places platform incidents alongside other security telemetry, rather than in a separate, unmonitored location.

How. Forward the Power Platform activity log and Purview audit events to Sentinel via the Microsoft Power Platform administrative logs data connector. Pre-built analytic rules cover suspicious DLP changes, mass app sharing, and unauthenticated agent publishing.

Learn more. Sentinel connector.

Outlook: what part 2 covers

Part 1 has established the platform-level perimeter — the environments themselves, the policies that bind them, the identities that reach them, and the telemetry that watches them. None of those controls answers the question of what gets built inside that perimeter, or how that work moves from a maker’s hands into production. That is the territory of part 2.

Next week’s article picks up where this one ends and walks through six topics in the same Why → How → Learn more pattern:

Governing Microsoft Copilot Studio. Tenant- and environment-level controls for AI agents, including who can publish, what AI features are allowed where, how knowledge sources are scoped, and how transcripts are retained.
Agent authentication and connector governance. The three authentication modes, the Entra Agent ID model that replaces stored client secrets, the connectors that should be blocked in regulated tenants, and the action-level controls that turn dangerous connectors into safe-but-useful ones.
Application Lifecycle Management and pipelines. Solutions as the unit of deployment, environment variables and connection references, Power Platform Pipelines as the native promotion path (and the strategic replacement for the now-deprecated ALM Accelerator for Power Platform), and when to fall back to Azure DevOps or GitHub.
Solution checker and quality gates. Static analysis for apps, flows, and agents; how to enforce it at solution import; how to read SARIF output; and how agent evaluations complement structural checks with behavioral ones.
Licensing and capacity governance. Power Apps and Power Automate license models, Dataverse capacity allocation, the Copilot Credits consumption model and its gotchas, and how to keep license assignment in sync with employment.
Change management and release rings. The two release channels that actually exist for Power Platform (Auto and Monthly — there is no Semi-Annual), how to gate previews per environment group, in-tenant change categories, administration mode, manual backups, and rollback realities.

If you treat part 1 as the platform on which everything stands, part 2 is everything that runs on that platform. The two are designed to be read together: the controls in part 1 matter only because they shape the work covered in part 2, and the controls in part 2 stick only because the foundations in part 1 hold them up.

Conclusion (Part 1)

Platform-level governance is the foundation of everything else. It is the cumulative result of many small, well-placed controls working together: an environment topology that matches how the organization actually builds, a default environment treated as a perimeter rather than a playground, Managed Environments and environment groups that make policy enforceable at scale, DLP and tenant isolation that bound where data can move, identity and Conditional Access that decide who is allowed to touch the platform at all, and monitoring that turns activity into evidence.

The controls described in this article already exist on the platform. None of them requires custom engineering, third-party tooling, or preview access to be useful. What they require is decision-making: which environments belong in which group, which connectors are business versus non-business, which tenants are trusted for cross-tenant connections, and who has the right to administer what. Those decisions are the platform half of governance.

Start small and iterate. A minimum viable foundation is: restrict default environment creation, attach a tenant-wide baseline DLP policy, enable default environment routing with a Managed Environments group, turn on tenant-level analytics, lean on the Power Platform admin center’s Inventory, Usage, Monitor, and Actions experiences (the CoE Starter Kit is no longer actively maintained — see section 8.6), and verify your tenant isolation defaults. Everything in part 1 is a refinement on that minimum viable foundation; everything in part 2 will be a refinement on top of part 1.

Read on next week for the second half — agents, ALM, licensing, and change management — and a closing recap that ties both articles together.

Microsoft Agent 365: The Control Plane for AI Agents Is Now Generally Available

Sat, 09 May 2026 00:00:00 +0000

Summary Lede
On 1 May 2026, Microsoft moved Agent 365 from preview into general availability, positioning it as the control plane that organizations need in order to observe, govern, and secure the rapidly growing population of AI agents working across their tenants. The service is licensed at fifteen US dollars per user per month as a standalone add-on, or as a component of the new Microsoft 365 E7 suite, and it integrates directly with the security and compliance products that most enterprises already operate, including Microsoft Entra, Microsoft Purview, and Microsoft Defender. Rather than introducing yet another place to build agents, Agent 365 sits above existing platforms and consolidates operational disciplines that have, until now, been distributed across many disconnected tools and dashboards.

Why read this: If your organization has begun deploying AI agents — whether built in Copilot Studio, embedded in third-party SaaS, developed in Microsoft Foundry, or installed by users on their own devices — you are facing a governance question that did not exist eighteen months ago. This article explains what Agent 365 actually is, what it changes in the operating model of an organization that has already invested in Microsoft 365 Copilot, and how to take the first practical steps after acquiring a license. It is intended to bring the moving parts into a single, coherent narrative you can use when you brief stakeholders, plan a pilot, or write your internal adoption proposal.

Introduction: Why a Control Plane for Agents Is Now a Necessity

AI agents are no longer a category of pilot project owned by a single innovation team. They are appearing inside Word, Excel, PowerPoint, Outlook, Teams, partner SaaS portals, custom-built applications, and, increasingly, on the local workstations of individual employees who have installed AI assistants on their own initiative. According to figures Microsoft cites from IDC, the worldwide population of AI agents is expected to reach approximately 1.3 billion by 2028.

Even at a small fraction of that figure, the implications for an enterprise tenant are significant. The questions IT leaders are being asked have outpaced the tools available to answer them: Which agents are running in our tenant today? Who owns each one? What data does each one touch, and on whose authority? Is it behaving as expected? If it has been compromised, when, by whom, and how would we know?

Microsoft now refers to this phenomenon openly as agent sprawl, and a newer category — the so-called shadow agent, meaning a local AI assistant installed on an endpoint without IT approval — has begun to appear on enterprise risk registers because it represents an identity-less, policy-less, telemetry-less actor with access to the same documents and chats as its human user. A control plane is the established architectural answer to this class of problem, and Agent 365 is, very deliberately, that control plane.

What Microsoft Agent 365 Actually Is

Agent 365 is a tenant-level service that gives administrators a single, authoritative view of every AI agent operating in the organization, together with the policy, identity, and security mechanisms required to manage them at scale. Microsoft summarizes its purpose using three verbs that recur throughout the official documentation: observe, govern, and secure.

To observe means that administrators have real-time visibility into the agents in their environment, what those agents are doing, and how they are performing.
To govern means that the lifecycle of each agent — from registration, through approval and assignment, to retirement — is controlled through consistent policies rather than ad-hoc decisions.
To secure means that the same enterprise-grade identity, data protection, and threat detection that already apply to users are extended, faithfully, to agents.

The service is built around five capabilities that Microsoft consistently identifies as the pillars of the offering:

Pillar	Role in the control plane
Registry	A unified inventory of every agent in the organization — including those issued an Entra Agent ID, those published in the Microsoft Teams or Agent Store, and shadow agents discovered on endpoints
Access Control	Unique Entra Agent ID for every agent, with policy templates and adaptive, risk-based access decisions enforced by Microsoft Entra
Visualization	Telemetry, dashboards, role-based reports for IT, security, and business audiences, plus an Agent Map of relationships between agents, users, and resources
Interoperability	Governs agents built with Microsoft tools, with open-source frameworks, and with ecosystem partner platforms; agents can use the same Microsoft 365 context that users do
Security	Integration with Microsoft Defender, Microsoft Entra, and Microsoft Purview for threat detection, identity protection, data loss prevention, and compliance

It is also worth being precise about what Agent 365 is not. It is not a new platform for building agents. Copilot Studio, Microsoft Foundry, and external frameworks remain the places where agents are designed, configured, and developed. Agent 365 is the layer above those platforms — the layer that ensures whatever you build, or whatever a partner ships into your tenant, becomes a managed, identified, observed, and governable entity within your organization.

The Five Pillars in Greater Detail

Registry

The Registry is, in many respects, the foundational capability, because every other discipline depends on having an authoritative inventory. Through the Registry, administrators see a unified list of agents that includes those issued an Entra Agent ID, those published in the Microsoft Teams Store or the Agent Store, and — as discovery functionality continues to roll out — shadow agents detected on managed Windows endpoints by Microsoft Defender and Microsoft Intune. From the Registry, administrators can install agents for selected audiences, block or unblock them across the organization, assign or reassign owners, publish requested agents to the store, reject submissions, or delete agents and their associated files.

Access Control through Entra Agent ID

Each agent is given a unique identity, the Entra Agent ID, which enables agents to be governed in the same identity-centric manner as human users. Administrators can apply policy templates that encode standard guardrails on day one, and Microsoft Entra enforces adaptive, risk-based access decisions that respond to real-time context, blocking agents that show signs of compromise from reaching organizational resources. The principle of least privilege, long established for human accounts and service principals, is now available in operation for agents.

Visualization

The visualization layer goes beyond conventional dashboards. In addition to Telemetry, alerts, and role-based reports tailored separately to IT, security, and business audiences, Agent 365 provides an Agent Map that displays the relationships between agents, the users on whose behalf they act, and the resources they connect to. This is particularly valuable for spotting unintended data flows or excessive privilege. Microsoft also references built-in performance measurement to help decision-makers assess return on investment. However, the granularity of those metrics will, in practice, depend on the specific agents and host applications involved.

Interoperability

The interoperability story is significant because it acknowledges that agents in a real enterprise are not all built on the same platform. Agent 365 governs agents created with Microsoft tools, with open-source frameworks, and with ecosystem partner platforms, with pre-integrated partner agents available to deploy directly from the Microsoft 365 admin center at general availability. Agents can access the same Microsoft 365 context that users do — Teams, calendars, mailboxes, SharePoint — and Microsoft has highlighted unified SDKs and consistent Model Context Protocol (MCP) interfaces for developers building agentic tools across Outlook, Teams, and SharePoint.

Security

The security pillar is delivered through tight integration with the existing Microsoft security stack rather than through a parallel set of agent-specific tools.

Microsoft Purview brings information protection, data loss prevention, sensitivity labels, eDiscovery, Insider Risk Management, and the data security posture management capability for AI (often referred to as DSPM for AI) into scope for agents.
Microsoft Defender XDR contributes agent inventory, real-time runtime protection, threat hunting, and security posture management.
Microsoft Entra contributes adaptive access enforcement and, as announced at RSAC 2026, network-level prompt-injection protection and explicit shadow-AI detection.

The cumulative effect is that agents become first-class citizens of your existing security operations rather than exceptions that need to be handled separately.

What Changes Operationally with Agent 365

For organizations that have been running Microsoft 365 Copilot for some time, the introduction of Agent 365 changes several aspects of day-to-day operations in concrete ways:

Area	Before Agent 365	With Agent 365
Identity	Agents represented by shared service accounts or app registrations	Every agent receives a unique Entra Agent ID and is governed individually
Inventory	Scattered across Teams Store, Copilot Studio, partner portals	Single Agent Registry view in the Microsoft 365 admin center
Access control	Per-agent manual permission grants	Policy-template-driven, adaptive, risk-based enforcement through Microsoft Entra
Observability	Vendor-specific dashboards	Unified telemetry, role-based reports, and an Agent Map of relationships
Security and compliance	Reaching into agent behaviour required significant effort	Native coverage through the same Defender, Entra, and Purview controls used today

The new shadow-AI dimension is also worth highlighting. Until now, an unsanctioned local AI assistant on an employee’s laptop has been more or less invisible to IT. With Agent 365, Defender, and Intune, surface those agents in the Registry so administrators can quarantine them, block them from accessing organizational resources, or, where appropriate, formally onboard them under policy. This is one of the more visibly novel capabilities of the GA release.

Licensing and Availability

Microsoft Agent 365 is licensed on a per-user basis:

Standalone price: fifteen US dollars per user per month.
Bundled option: included in the new Microsoft 365 E7 suite, which combines Microsoft 365 E5, Microsoft 365 Copilot, the Microsoft Entra Suite, and Agent 365 into a single offering aimed at enterprises that want to standardize on a fully integrated identity, productivity, and agent-governance platform.
Availability segment: Commercial cloud at general availability. Microsoft’s documentation also notes that Microsoft 365 for Government Community Cloud High and Government Community Cloud Moderate environments support agent publishing scenarios.

There are no strict product prerequisites to enable Agent 365. Still, Microsoft recommends that customers hold Microsoft Entra P1, Entra P2, or the Entra Suite, alongside Microsoft Purview Data Loss Prevention, to make full use of the governance and security benefits. A Microsoft 365 Copilot license remains necessary to use Copilot-based agents. Pricing details should always be validated with your account team, since regional adjustments, channel offers, and bundle economics can materially change the total cost of ownership.

Taking Your First Steps After Acquiring a License

One of the most pragmatic aspects of Agent 365 is that there is no infrastructure to deploy. The service is activated via licensing and configured in the Microsoft 365 admin center, so the initial steps are administrative rather than technical. The following sequence reflects the recommended path from the Microsoft Learn documentation, organized as most teams will execute it in practice.

1. Confirm Roles and Licenses

Begin by ensuring that the right people hold the right roles. Please assign the Global Administrator role and any other agent-administration roles required for your organization, in line with your least-privilege practices. At the same time, confirm that the audiences for which you intend to enable agents have appropriate licenses in place — Microsoft 365 Copilot in particular, but also any Entra and Purview SKUs that you plan to rely on for governance and protection.

2. Open the Agents Area in the Microsoft 365 Admin Center

Sign in to the Microsoft 365 admin center, expand … Show all in the left navigation, select Agents, and open All agents. This view, with Registry selected, is the canonical inventory of every agent known in your tenant. It is worth spending time here before making any operational decisions; many organizations are surprised by what already exists in their environment once it is presented in a single list.

3. Establish a Baseline Policy

Before approving anything broadly, define and apply an Agent Policy Template that captures your organization’s standards. The template determines, among other things, which connectors and data sources agents may use, what sensitivity-label boundaries apply, and which Conditional Access conditions Entra should enforce. Treat this template as a living governance artifact, deliberately version it, and review it with your security and data-protection stakeholders before it becomes the default for new approvals.

4. Activate or Install Your First Agent

To install an agent for users:

Select the agent from the Registry list.
Choose Install in the agent details pane.
Decide whether the deployment scope should be the entire organization or specific users and groups, and select Next.
Review the requested permissions, and select Grant admin consent.
Accept the requested permissions, and select Next.
Select Finish deployment.

The agent will subsequently appear in the relevant host product — Copilot, Teams, Outlook, or another Microsoft 365 surface — for the chosen audience.

5. Process Activation and Approval Requests

End users can request agents from the Microsoft Teams Store or the Agent Store, and those requests surface to administrators for review. Each request can be approved and activated, or rejected with a rationale. From a governance perspective, formally approving or rejecting requests is at least as important as installing approved agents, because it creates the decision trail that auditors and risk reviewers will look for in 12 months.

6. Turn On Observability and Security

The full value of Agent 365 only emerges when its companion services are correctly configured:

In Microsoft Purview, enable the data security posture management capability for AI, configure DLP policies that include agent identities, and bring agent interactions into your retention and eDiscovery scope.
In Microsoft Defender XDR, review the agent inventory, switch on real-time runtime protection for agents, and integrate agent telemetry into your existing threat-hunting workflows.
In Microsoft Entra, define the adaptive access policies that should apply to agent identities, and decide explicitly whether and how external parties may interact with your agents — by default, agents behave as internal identities and external access is constrained by administrative policy.

7. Use the Agent Map to Validate Reality Against Intent

Once a small number of agents are running under the new policies, open the Agent Map to inspect the relationships between agents, users, and data sources. This is the single most effective way to detect unintended privilege, unexpected agent-to-agent connections, or data flows that violate your sensitivity-label model. The Map is intended to make excessive privilege visually obvious, and it should become a regular part of your operational review cadence.

8. Maintain Lifecycle Hygiene

Agent 365 supports a comprehensive set of lifecycle actions through the Microsoft 365 admin center, including install, uninstall, block, unblock, assign a new owner, publish to the store, reject a submission, and delete. Schedule a recurring review — quarterly is a reasonable starting point — to identify orphaned, unused, or stale agents and retire them deliberately.

Practical Guidance for a Successful Rollout

A few principles consistently distinguish successful rollouts from those that struggle:

1. Begin with discovery rather than deployment. The first weeks should be spent observing what already exists in your tenant before approving anything new, because the inventory you uncover will materially shape your governance design.

2. Please assign an Agent Owner to each agent. Agents without accountable human owners tend, over time, to drift outside policy. Make ownership explicit at registration and revisit it quarterly.

3. Treat the initial Agent 365 program as a security and compliance project at least as much as a productivity project. The most defensible early wins are reducing shadow-AI exposure and producing a credible audit trail. Productivity outcomes follow naturally once stakeholders trust the guardrails.

4. Be honest about the operational overhead. A control plane only delivers value if someone is operating it. Plan for a small but explicit team responsible for policy templates, request triage, agent reviews, and lifecycle hygiene, and make sure that the team has the authority to say no when an agent does not meet your standards.

5. Evaluate the Microsoft 365 E7 bundle carefully if you are already an E5 customer. The bundle economics can become attractive once Microsoft 365 Copilot, the Entra Suite, and Agent 365 are all in scope. Still, the decision should be evaluated through a deliberate commercial analysis rather than a reflex.

Caveats and What to Watch

Several aspects of the service deserve a measured note:

Shadow-agent detection is described in Microsoft’s announcement materials as a capability that will continue to expand over time, which suggests that initial coverage will improve as the service matures.
Performance and ROI metrics are real. Still, their granularity in any given environment will depend on the specific agents and host applications you operate, so it is wise to validate them against your own reporting needs early.
End-to-end value depends on companion services. Because Agent 365 spans several Microsoft products, the value you obtain will depend on how thoroughly Entra, Purview, and Defender are configured in your tenant — partial deployments will yield partial value.

Conclusion: A Single, Coherent Place to Govern Agents

The general availability of Microsoft Agent 365 is a significant milestone, less because it introduces dramatic new capabilities than because it consolidates a set of operational disciplines that enterprises have urgently needed. Organizations have been building, buying, and deploying AI agents for some time. The absence of a unified control plane has become increasingly difficult to defend against in front of security committees, auditors, and regulators. Agent 365 closes that gap by extending the same identity, governance, and security model that already underpins your users to the agents that increasingly act alongside them.

For most Microsoft 365 customers, the practical implication is straightforward. The infrastructure question is settled, the licensing path is clear, the integration with the existing Entra, Purview, and Defender stack is real, and the first steps are administrative rather than technical. What remains is the work that always determines the success of a governance program: defining sensible policy, assigning accountable owners, observing what is happening in your tenant, and acting on what you learn. Agent 365 will not do that work for you, but it now provides — for the first time — a single, coherent place in which to do it.

If you are considering when to begin, the answer is almost certainly now. The agents are already there. The control plane is finally here.

Official Sources

Microsoft Learn — Microsoft Agent 365 overview (https://learn.microsoft.com/en-us/microsoft-agent-365/overview)
Microsoft Learn — Get started with Microsoft Agent 365 (https://learn.microsoft.com/en-us/microsoft-agent-365/get-started)
Microsoft Learn — Governance and Lifecycle actions for agents available in Microsoft 365 admin center (https://learn.microsoft.com/en-us/microsoft-365/admin/manage/agent-actions)
Microsoft 365 Blog — Microsoft Agent 365: The control plane for AI agents (Charles Lamanna, Executive Vice President, Business Applications & Agents, November 2025) (https://www.microsoft.com/en-us/microsoft-365/blog/2025/11/18/microsoft-agent-365-the-control-plane-for-ai-agents/)
Microsoft — Microsoft Agent 365: The Control Plane for Agents (product page, https://www.microsoft.com/en-us/microsoft-agent-365)
Microsoft Copilot Acceleration Team — Microsoft Agent 365 Resources (https://microsoft.github.io/agent-resources/agent365/)

What Is Next: E7, Agent 365, and the Researcher

Sat, 02 May 2026 00:00:00 +0000

What Is Next: E7, Agent 365, and the Researcher

Post 14 of 14 — Series Close

Introduction

Cowork is one feature inside a larger shift. Microsoft 365 E7 — the new Frontier Suite tier — bundles Cowork-class capabilities with an enterprise control plane for AI agents. This post sketches the immediate horizon, sticking to what is publicly documented today.

The Near-Term Horizon

Microsoft 365 E7 — the Frontier Suite. Generally available 1 May 2026 at $99 per user per month. E7 brings together:

Microsoft 365 E5 — productivity, security, identity, and compliance foundation.
Microsoft Entra Suite — adaptive identity and network access controls.
Microsoft 365 Copilot — including Cowork as a Frontier preview.
Agent 365 — the control plane for AI agents.

E7 is positioned as a unified enterprise AI platform rather than a collection of separate products. Pricing represents a 65% increase over E5 — the value case rests on Cowork-class capabilities and Agent 365 governance, not on individual app features.

Agent 365. Agent 365 extends Microsoft’s existing user-management infrastructure to AI agents — central management, identity, security, and compliance for agents at scale. It generally available 1 May 2026 alongside E7. For organizations planning to use multiple agents (built in Copilot Studio, custom agents, third-party agents, and Cowork itself), Agent 365 is the management layer that keeps governance consistent.

Researcher with Critique. The Researcher agent’s Critique capability — one model draft and a second model from a different provider’s review — produces measurable quality improvements. Microsoft reports a DRACO benchmark score of 57.4 for Researcher with Critique, a 13.8% improvement over single-model approaches. The Model Council feature exposes some of this multi-model orchestration to administrators and advanced users.

Multi-model orchestration as a pattern. Cowork’s combination of Anthropic Claude and OpenAI models, with routing managed by Microsoft, is the prototype for how Microsoft expects agent platforms to evolve: the best model per task, governed within the tenant, invisible to most users by default.

What to plan for in the next phases:

General availability of Cowork — no firm public date yet. Treat preview content as pilot input, not production scope.
Agent 365 adoption — model your agent inventory now, even if you have only Cowork plus a few Copilot Studio agents.
Custom skill libraries — start a SKILL.md library for your team in OneDrive (post 5). When organizational skill sharing arrives, you will have curated content ready.
Workforce model — train people on prompt design, approvals, and oversight. These are the durable agentic-AI skills.

The honest framing. Cowork is not finished. The skill set will grow, the regional availability will expand, Agent 365 will mature, and audit-log coverage will deepen. Teams that win are running structured pilots now, not waiting for GA.

Series Recap

Across 14 posts: enabled Cowork, navigated Anthropic governance, toured 13 built-in skills, built custom skills with SKILL.md, worked through every skill family, set up approvals and the Tasks view, framed three-zone governance, and faced the limits honestly. That is the working set for a credible Cowork rollout today.

Takeaway

Start small. Build one custom skill. Run one scheduled briefing for two weeks. Pilot one document workflow with one team. Compound from there. The Frontier preview rewards organizations that show up with real use cases, not slide decks.

Sources

Cowork common questions (Frontier)
Introducing Microsoft 365 E7: The Frontier Suite
Cowork deep-dive (attached source)

Copilot Studio Billing – A Short Answer to a Frequent Question

Sat, 02 May 2026 00:00:00 +0000

Summary Lede
Organizations implementing Microsoft Copilot Studio often ask about the machine structure and how to monitor and analyze resource use across their deployed agents. This article addresses these common questions by examining the foundational principles of Copilot Studio’s billing methodology. Specifically, the platform employs a usage-based billing model that operates through Copilot Credits, a standardized measurement unit that quantifies billable computational resources. Microsoft Copilot Studio gives you comprehensive visibility into consumption and costs through integrated Analytics. You get real-time visibility into billing metrics, consumption attribution, and capacity planning, without needing external tools or manual reconciliation.

Usage-based billing with Copilot Credits

Microsoft Copilot Studio employs a consumption-based billing model centered on Copilot Credits, a standardized unit of measurement that quantifies the billable computational resources your agent uses. We add up each agent’s operational costs by summing all Copilot Credits used across your organizational tenant, providing a transparent, predictable billing framework. The volume of Copilot Credits your agent consumes is determined by multiple contributing factors, including the frequency and intensity of user interactions, the specific AI capabilities invoked during those interactions (such as natural language responses, backend action execution, or business process flows), and the overall complexity of the scenarios the agent must handle. This approach lets your costs scale with your actual usage and feature use across your organization.

Where to see billing and consumption

Copilot Studio provides a dedicated Analytics page at the agent level that shows billing‑relevant data for a selected time period. This includes:

Total billed Copilot Credits for the agent

The Analytics dashboard provides comprehensive visibility into your agent’s billing metrics through several key components:

Billing trend visualization: A temporal representation of Copilot Credit consumption plotted over your selected time period, enabling stakeholders to identify consumption patterns, peak usage intervals, and seasonal fluctuations in agent utilization.
Activity-based consumption breakdown: A detailed attribution analysis that segments credit consumption by interaction type and feature category. This granular view helps identify which capabilities—such as natural language processing, action executions, or business process integrations—are the primary drivers of your organization’s computational costs.
Credit allocation and remaining capacity: A dashboard element that displays your monthly credit allocation alongside actual consumption to date, providing clear visibility into remaining available credits within the current billing cycle and helping prevent unexpected cost overruns.

This analytical approach helps makers and administrators go beyond simple cost visibility to understand the factors and user behaviors that drive consumption patterns in their agents.

Near‑real‑time visibility

Please note that consumption data in the Analytics experience isn’t reflected immediately. Because data collection and aggregation are distributed across Microsoft’s infrastructure, there is a deliberate processing interval between when an interaction occurs in your agent and when the corresponding credit consumption metrics appear in the Analytics dashboard. Specifically, recent user activity and associated Copilot Credit charges typically require several hours to propagate through the telemetry pipeline and surface in the analytics interface. This temporal lag between actual consumption and reported metrics is a critical consideration when conducting performance monitoring, particularly in scenarios involving new agent deployments, recent architectural modifications, or optimization initiatives. Organizations implementing consumption tracking during these periods should account for this delay when interpreting analytics data and making operational decisions based on observed billing trends.

Why this matters

The relationship between billing metrics and agent design decisions is a core principle in building and running Microsoft Copilot Studio deployments. Organizations that recognize and leverage this connection are better positioned to make informed architectural decisions that balance functional requirements with cost efficiency. The Analytics experience provided within Copilot Studio serves a dual purpose that extends well beyond simple billing transparency. As a primary governance tool, it enables organizations to establish consumption baselines, define and enforce cost budgets, and implement optimization strategies at both the agent and organizational levels. This comprehensive analytical framework becomes increasingly critical as agents transition from the experimentation and proof-of-concept phases to production environments, where operational costs accumulate rapidly, and optimization opportunities become more constrained. By establishing clear visibility into consumption patterns during early development stages, teams can identify inefficient architectural patterns, optimize interaction flows, and refine AI capabilities—all before deploying agents at scale. Furthermore, the transparency provided by the Analytics dashboard facilitates organizational governance by empowering stakeholders to establish accountability for resource utilization, track consumption trends against budgetary targets, and make data-driven decisions regarding agent expansion, feature prioritization, and technology investments.

Links and resources

billing rates

Conclusion

Microsoft Copilot Studio’s billing model, centered on usage-based Copilot Credits, provides a transparent and scalable framework for managing the costs associated with AI agent deployment. By leveraging the built-in Analytics experience, organizations can gain comprehensive insights into their agents’ consumption patterns, enabling informed decision-making around agent design, optimization, and cost management. As organizations continue to adopt and scale their use of AI agents, understanding the nuances of billing and consumption visibility will be essential for maximizing the value of their investments in Microsoft Copilot Studio while maintaining control over operational costs.