DEV Community: Holger Imbery

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

Holger Imbery — 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

Holger Imbery — Sat, 11 Jul 2026 00:00:00 +0000

Four end-to-end scenarios on different orchestration patterns, a starter MCP server inventory, and the ten anti-patterns that recur in production Copilot Studio deployments.

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

Holger Imbery — 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

Holger Imbery — Sat, 27 Jun 2026 05:58:35 +0000

How Teams Phone Agent's out-of-the-box voice experience and custom Copilot Studio voice agents bring conversational AI to Microsoft Teams Phone — capabilities, call-flow design, setup, gating, and consumption billing in the Frontier preview.

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.

2.1 Real-world example — replacing a keypad menu

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)

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

Holger Imbery — 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.

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 that everything else rests on. 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.
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 from a shadow-IT magnet 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 inside each member environment, which is what makes 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. Defaults differ by tenant age — tenants created on or after 30 March 2026 ship with isolation enabled and both directions defaulting to deny.
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, reachable through the Power Platform inventory API and the Power Platform for Admins V2 connector for any 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 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.

9.3 Restrict who can share agents tenant-wide

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. The recent tenant setting “Choose who has permission to share agents with your entire organization” allows three modes: all users, no users, or specific groups. Restrict to a CoE or approvals group for production-grade sharing.

Learn more. Control how agents are shared.

9.4 Cap agent sharing per environment

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.

9.5 Apply group rules for agent 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 grants the agent the site’s entire content tree — to makers who already have access. Grant scope at the document library or folder level where possible.
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 as connectors

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

How. Treat each MCP server as a custom connector for governance: review the server code or vendor, restrict outbound network paths, and block ad-hoc registration by makers.

Learn more. Agents and MCP.

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

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. Each Copilot Studio agent is automatically provisioned with its own Entra Agent ID — a Microsoft Entra service principal of subtype Agent — when the agent is created. The agent presents this identity on outbound calls. Administrators do not configure trusted app registrations for “agent federation”; the Agent ID is managed by the platform and visible in the Entra ID portal under enterprise applications. Where legacy connectors still rely on stored secrets, rotate them through Azure Key Vault.

Learn more. Entra Agent ID for Copilot Studio agents.

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:

$policy = New-DlpPolicy -DisplayName "Agent baseline"
Add-ConnectorToBusinessDataGroup -PolicyName $policy.Name -ConnectorName shared_sharepointonline
Add-ConnectorToBlockedGroup -PolicyName $policy.Name -ConnectorName shared_logicflows_http
Set-DlpPolicyDefaultConnectorGroup -PolicyName $policy.Name -DefaultGroup Blocked

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 — treat each server as a connector and inventory via the Copilot Studio admin center.

Learn more. Agents and MCP.

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 that is a Managed Environment. 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 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 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. Use the environment group rule Unmanaged customizations to block unmanaged changes in production groups.

Learn more. ALM basics.

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 are:

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.
Maintainability — missing connection references, hard-coded GUIDs, deprecated API calls.
Reliability — missing error handling in flows, unbounded loops, overlapping workflow triggers.

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 `
                   --ruleSetName "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 Use agent-specific checks

Why. Agents have failure modes apps and flows do not — missing fallbacks, public knowledge, blocked-channel publish. Solution checker covers them.

How. Solution checker validates Copilot Studio agents for unused topics, missing fallback, knowledge sources without authentication, publish to blocked channels, and references to DLP-blocked connectors.

Learn more. Solution checker.

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 or two apps 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 (hosted plan). Process plans allocate capacity to a single flow, typically for RPA workloads.

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 per message, sold as prepaid capacity or pay-as-you-go (PAYG). Microsoft 365 Copilot user licenses include a separate allowance. Each agent message consumes credits based on type (generative answers, actions, autonomous events). Constraints to plan for:

PAYG requires the Dataverse Azure subscription meter configured at the environment level; without it, PAYG is inactive.
No hard tenant-wide consumption cap exists today.
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 a free, single-user environment for learning. 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 two channels:

Auto (default) — updates arrive as they are released to ring-by-ring deployment. 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.

Set the channel with the environment group rule Release channel. Production groups typically stay on Auto; pilot groups use Monthly for early validation. (There is no “Semi-Annual” channel for Power Platform — that term applies to Microsoft 365 Apps update channels, not Power Platform environments.)

Learn more. 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. 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 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)

Holger Imbery — Sat, 16 May 2026 07:15:44 +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.

2.5 Constrain sharing through Managed Environments

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.

3.1 Limit sharing

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.

7.4 Prefer teams over individual sharing

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

Holger Imbery — 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/)

Copilot Studio Billing – A Short Answer to a Frequent Question

Holger Imbery — Sat, 02 May 2026 08:04:40 +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.

Microsoft IQ: The New Intelligence Layer for Enterprise AI Agents

Holger Imbery — Sat, 25 Apr 2026 08:42:12 +0000

Summary Lede

Microsoft's new IQ layers - Work IQ, Fabric IQ, and Foundry IQ - are unified intelligence systems that give enterprise AI agents deep organizational context. Rather than relying solely on general knowledge, these layers ground agents in your company's real data, workflows, and knowledge domains, enabling them to make decisions with the credibility and awareness of experienced employees.

Why read this: If you're building or deploying AI agents in enterprise environments, understanding these three intelligence layers is essential. Learn what each layer does, the business value they unlock, practical developer integration steps with Copilot Studio, and real limitations to watch for - whether you're looking to protect your competitive edge or avoid common deployment pitfalls.

Introduction: Why Enterprise Context Is the New AI Differentiator

AI agents - autonomous systems that plan, reason, and act on behalf of users - are moving from experimentation to production at enterprise scale. A July 2024 Capgemini survey of 1,100 companies with over \$1 billion in annual revenue found that 82% plan to integrate AI agents within the next one to three years, with only 7% reporting no plans at all Of those surveyed, 71% expect AI agents to drive automation, and 64% expect them to free human workers from repetitive tasks so they can focus on higher-value functions. Separately, KPMG's Q2 2025 AI Quarterly Pulse Survey of 130 U.S.-based C-suite leaders (from organizations with \$1 billion or more in revenue) reports that 33% of organizations have now deployed at least some agents - a three-fold increase after two consecutive quarters at 11%. The same survey found that 82% of leaders agree their industry's competitive landscape will look fundamentally different within 24 months due to AI.

Yet deploying powerful language models alone does not guarantee business impact. Large language models ship with broad general knowledge but lack awareness of an organization's current data, internal processes, contractual obligations, and human workflow patterns. The real differentiator is no longer how smart the model is, but how well it understands your organization. At Microsoft Ignite 2025, Microsoft addressed this gap by introducing a "Unified Context Layer" comprising three tightly connected intelligence systems: Work IQ, Fabric IQ, and Foundry IQ. Together, they form "Microsoft IQ" - a unified intelligence layer spanning productivity, data, and knowledge - designed to ground AI agents with deep enterprise context so they can make reliable decisions and continuously optimize operations.

Each IQ layer addresses a distinct dimension of organizational context:

IQ Layer	Context Domain	Platform	Primary Function
Work IQ	User & work context	Microsoft 365	Captures collaboration signals - emails, meetings, chats, documents, relationships - and builds persistent memory of how people and teams work
Fabric IQ	Business & data context	Microsoft Fabric	Unifies analytical, operational, and real-time data into a governed semantic model with ontologies, graphs, and business rules
Foundry IQ	Knowledge & reasoning context	Microsoft Foundry (Azure AI Foundry)	Creates multi-source, permission-aware knowledge bases with agentic retrieval for grounded, citation-backed answers

Each workload is standalone, but they can be used together to provide a comprehensive organizational context for agents. For business decision-makers, these layers translate into faster time-to-insight, more trustworthy AI outputs, and the ability to deploy agents that act with the contextual awareness of experienced employees rather than generic assistants. For developers building with Microsoft Copilot Studio (low-code) or the Microsoft Agent Framework / Agent 365 (pro-code), the IQ layers provide ready-made intelligence services that eliminate the need to hand-build retrieval pipelines, semantic models, or user-context systems from scratch.

Work IQ - Personalizing AI with User & Collaboration Context

What It Is

Work IQ is the intelligence layer in Microsoft 365 that gives AI agents a real-time, permission-aware understanding of how people actually work. It is built on three tightly integrated layers - Data, Memory, and Inference - that work together to provide Microsoft 365 Copilot and custom agents with continuous contextual understanding of work:

Data unifies signals from files, emails, meetings, chats, and business systems across Microsoft 365 to capture how work happens across the organization.
Memory builds a persistent understanding of how people and teams work, enabling agents to stay aligned to priorities and remain consistent across tasks, apps, and sessions.
Inference brings together models, skills, and tools so agents can reason and take action while the Agent 365 control plane ensures those actions remain observable, governed, and compliant.

Work IQ connects to organizational and personal data - SharePoint files, Outlook emails, Teams meetings - and builds personalized memory based on user preferences, habits, and workflows. Conversational memory in Microsoft 365 Copilot, powered by Work IQ, enables it to retain context and important details across sessions by drawing on a user's work profile, instructions, preferences, and insights from past chats. Users stay in control and can review or delete these memories at any time.

Importantly, Work IQ does not merely retrieve information - it interprets context. This is why a Work IQ-enabled agent can answer questions like "What did we decide last week about the field project budget?" or "Summarise the latest customer escalations and draft a report". It reasons over signals, patterns, and workflows rather than searching a document library.

Strategic Value for Business

For decision-makers, Work IQ delivers personalization at scale without sacrificing security. It enables AI agents to recognize who a user works with, what they focus on, and how they typically accomplish tasks. Microsoft is now exposing the power of Work IQ through APIs, allowing developers to build AI agents targeting specific enterprise scenarios beyond what the built-in Copilot offers.

Work IQ also surfaces workflow intelligence - for example, identifying that operations teams are overloaded handling exceptions manually, observing long email chains, or spotting recurring "delay review" meetings that consume capacity. This kind of insight goes beyond analytics into organizational awareness, helping leaders understand where human effort is being consumed and where agents can provide the most value.

Tradeoff consideration: Work IQ can only be as effective as the signals it can access. It is accessed primarily through Copilot and works best when collaboration data is well-structured and consistently captured in Microsoft 365 tools. Organizations with fragmented communication (e.g., heavy use of external email, shadow IT chat tools, or poorly organized SharePoint) will see diminished returns until information management improves.

Developer Integration - Copilot Studio

Work IQ is surfaced to developers as Model Context Protocol (MCP) tools that can be attached to agents in Copilot Studio. The following step-by-step process adds the Work IQ Mail server to an agent:

Sign in to Copilot Studio and select or create your agent.
Select the Tools tab and then Add Tool.
On the Add tool page, select Model Context Protocol to see Work IQ MCP servers and other MCP servers.
Type "mail" in the search box.
Select Work IQ Mail and expand the connection dropdown to select Create New Connection.
Select Create, provide credentials, and complete the sign-in process.
Select Add and Configure to complete the process.
Test the agent - for example, prompt: "Send an email to [name] and ask how the hands-on lab is going."
When asked to allow the Work IQ tool to connect and use services, select Allow.

After configuration, the agent can read email content, understand the context, and respond accordingly. Repeat these steps for Work IQ Calendar or Work IQ Teams to extend the agent's capabilities with meeting insights, chats, and more>.

Prerequisite: A Microsoft 365 Copilot license is required to use Work IQ MCP servers.

Developer Integration - Microsoft Agent Framework (Agent 365)

For pro-code developers, the Work IQ tooling infrastructure is built into the Microsoft Agent 365 SDK and CLI, Microsoft Foundry, and Copilot Studio. Agent 365 provides a secure, centralized gateway for extending agents with enterprise-ready tools through Work IQ for Microsoft 365 services and custom tooling servers for specialized workflows. This means developers building agents programmatically - using the Agent 365 SDK in Python, C#, or other supported languages - can invoke Work IQ's capabilities (querying recent communications, documents, or calendar entries) as part of an agent's reasoning loop without manually calling Microsoft Graph APIs and interpreting raw data.

Governance and Security

IT administrators retain full control over Work IQ MCP tools through the Microsoft 365 admin center under the Agents and Tools section, where they can:

View all activated Work IQ MCP servers (Work IQ Mail, Work IQ Calendar, Work IQ Teams, and any custom servers).
Allow or block specific servers based on organizational policies.
Apply scoped permissions so agents only access what they need.

If an admin blocks a Work IQ MCP tool or MCP server, it blocks access for every user and every agent. Permissions always take precedence over configuration.

Observability is built in via Microsoft Defender. Admins can run queries in Advanced Hunting to inspect trace logs of tool calls made by agents, monitor execution details (which tools were invoked, parameters passed, and outcomes), and detect anomalies or unauthorized usage patterns.

All Work IQ MCP servers also undergo continuous evaluationto measure accuracy, latency, and reliability, ensuring production-grade robustness.

Fabric IQ - Turning Enterprise Data into Business-Meaningful Intelligence

What It Is

Fabric IQ (preview) is a workload in Microsoft Fabric that unifies data across OneLake and organizes it in the language of your business. The unified data is then exposed to analytics, AI agents, and applications with consistent semantic meaning and context. While Work IQ understands work, Fabric IQ understands data - and specifically what data means in business terms.

Fabric IQ models business data through ontologies, semantic models, and graphs so agents can reason over analytics in OneLake and Power BI. It combines the following items into one semantic intelligence workload

Fabric IQ Item	Description
Ontology (preview)	Enterprise vocabulary and semantic layer that defines entity types, relationships, properties, and condition-action rules (through Fabric Activator). Binds definitions to real data so downstream tools share the same language
Plan (preview)	Unified no-code platform for collaborative planning, reporting, analytics, data integration, and management on a single platform
Graph (preview)	Native graph storage and compute for nodes, edges, and traversals over connected data - suited to path finding, dependency analysis, and graph algorithms. Integrated with the ontology item
Data Agent (preview)	Conversational Q&A systems using generative AI that connect to the ontology to understand business concepts when answering questions
Operations Agent (preview)	AI agent to monitor real-time data and recommend business actions, aware of business terminology from the ontology
Power BI Semantic Models	Curated analytics models optimized for reporting and interactive analysis with measures, hierarchies, and relationships. Ontologies can be generated directly from them

Several of these items are shared with other Fabric workloads (e.g., Graph and Operations Agent are also part of Real-Time Intelligence; Data Agent is shared with Data Science).

Strategic Value for Business

Fabric IQ delivers six key benefits identified by Microsoft:

Unification of data - Combines data from various OneLake sources (lakehouses, eventhouses, Power BI semantic models) into a single consistent model. Can also unify external operational data using OneLake shortcuts without copying data or building ETL pipelines.
Consistent language across tools - A single definition of a concept (like Customer, Material, or Asset) drives how Power BI, notebooks, and agents interpret data.
Faster onboarding - Business concepts only need to be declared once, then new dashboards and AI experiences inherit that meaning automatically.
Governance and trust - Reduces duplication and inconsistent definitions across teams by enforcing clear semantics, while constraints improve data quality.
Cross-domain reasoning - Represents relationships between concepts with graph links, enabling traversals like Order → Shipment → Temperature Sensor → Cold Chain Breach to explain outcomes.
AI readiness and decision-ready actions - Provides structured grounding for copilots and agents so answers reflect enterprise language. Rules defined in the ontology (via Fabric Activator) enable governed, real-time actions (e.g., alerts and notifications) when conditions are met.

For finance teams, this means an AI agent can answer questions like "Why did request volume spike in the North region last month?" or "Show anomalies in field service cycle time" - grounded in what the data means, not just where it lives. The semantic model ensures that metrics such as "net profit" and "customer churn" are calculated exactly as defined by the business, so CFOs can trust the AI's output.

For operations teams, Fabric IQ's ontology can model supply chain entities, inventory levels, delivery metrics, and their relationships. When an on-time delivery percentage dips below historical norms, a Fabric IQ-informed agent can detect the anomaly, correlate it with upstream bottlenecks, and surface the issue before it escalates.

Tradeoff consideration: Fabric IQ requires upfront investment in semantic modeling. Organizations must define ontologies and business rules, which demands collaboration between data engineers and domain experts. Once agents depend on business meaning, that meaning becomes production infrastructure - semantic models must be versioned, governed, deployed, and monitored with the same rigor applied to code. For organizations already using Power BI, existing data models provide a head start: they instantly serve as a catalyst, giving agents rich, business-specific context.

Developer Integration

Developers interact with Fabric IQ primarily through the Microsoft Fabric portal, where they can create ontologies, bind them to data sources, and build Data Agents or Operations Agents that reason over the unified data model. The recommended approach for choosing the right Fabric IQ item depends on the scenario:

Item	When to Use
Ontology (preview)	Cross-domain consistency, governance, and AI/agent grounding; reasoning across processes
Graph (preview)	Relationship-heavy questions (impact chains, communities, shortest paths) dominate; GQL-style pattern matching needed
Power BI Semantic Model	Business users need trusted KPIs and fast visuals with dimensional modeling and governed datasets

Several key item relationships support combined use:

Ontology + Semantic Model: Generate or align Power BI semantic models so terminology and KPIs stay consistent across reports.
Ontology + Graph: Ontology declares which things connect and why; Graph stores and computes traversals.
Ontology + Data/Operations Agents: Ontology grounds agents in shared business semantics and rules, enabling them to retrieve context, reason across domains, and trigger governed actions.
Plan + Semantic Model: Plan connects to existing semantic models, allowing dimensions and measures to be used in planning sheets for seamless plan-versus-actuals analytics.

Foundry IQ - Unified Knowledge Retrieval and Reasoning for AI Agents

What It Is

Foundry IQ (preview) is a managed knowledge layer in Microsoft Foundry that enables the creation of configurable, multi-source knowledge bases providing agents with permission-aware, citation-backed responses based on organizational data. It tackles what many architects consider the hardest challenge in agent design: knowledge retrieval and grounding.

A Foundry IQ knowledge base consists of knowledge sources (connections to internal and external data stores) and parameters that control retrieval behavior. Multiple agents can share the same knowledge base. When an agent queries the knowledge base, Foundry IQ uses agentic retrieval - a multi-query pipeline - to process the query, retrieve relevant information, enforce user permissions, and return grounded answers with citations.

Core Capabilities

Foundry IQ offers the following capabilities:

Multi-source knowledge bases: Connect one knowledge base to multiple agents. Supported knowledge sources include Azure Blob Storage, SharePoint, OneLake, and public web data.
Automated document processing: Automate document chunking, vector embedding generation, and metadata extraction for indexed knowledge sources. Schedule recurring indexer runs for incremental data refresh.
Flexible query modes: Issue keyword, vector, or hybrid queries across indexed and remote knowledge sources.
Agentic retrieval engine: Uses a large language model to plan queries, select sources, run parallel searches, and aggregate results. The retrieval reasoning effort can be configured at three levels: minimal, low, or medium for LLM processing.
Extractive data with citations: Returns answers with source references so agents can reason over raw content and trace answers back to source documents.
Permission-aware: Synchronizes access control lists (ACLs) for supported sources and honors Microsoft Purview sensitivity labels. Enforces permissions at query time so agents return only authorized content.
Identity-based queries: Runs queries under the caller's Microsoft Entra identity for end-to-end permission enforcement.

The underlying indexing and retrieval infrastructure is powered by Azure AI Search.

Components

Component	Description
Knowledge base	Top-level resource that orchestrates agentic retrieval. Defines which knowledge sources to query and parameters that control retrieval behavior, including retrieval reasoning effort (minimal, low, or medium)
Knowledge sources	Connections to indexed or remote content. A knowledge base references one or more knowledge sources
Agentic retrieval	Multi-query pipeline that decomposes complex questions into subqueries, executes them in parallel, semantically reranks results, and returns unified responses. Uses an optional LLM from Azure OpenAI in Foundry Models for query planning

Foundry IQ knowledge bases can be used in Foundry Agent Service, Microsoft Agent Framework, or any custom application by calling the knowledge base APIs from Azure AI Search.

Strategic Value for Business

Foundry IQ is the layer that makes AI enterprise-grade for knowledge work. It enables agents to understand contracts, policies, procedures, SLAs, regulatory constraints, and unstructured documents - and to reason across them safely. The combination of permission enforcement and source citations directly addresses the two most common executive concerns about enterprise AI: data leakage and hallucination. Every assertion the agent makes can be traced to a vetted document, supporting trust and auditability.

Foundry IQ serves as a single endpoint for high-quality organizational data to maximize context for AI applications. Its knowledge retrieval engine runs over multiple data sources including Work IQ, Fabric IQ, Azure data services, custom web applications, and the web.

Tradeoff consideration: Because Foundry IQ indexes and retrieves content automatically, the quality of the knowledge base depends heavily on the quality and curation of source content. Outdated, duplicated, or poorly written documents will produce lower-quality retrieval results. Organizations should invest in content hygiene (removing obsolete documents, standardizing formatting, clarifying ownership) before connecting sources to Foundry IQ. Additionally, Foundry IQ is currently in public preview without a production service-level agreement, which means production-critical workloads should be tested thoroughly and planned around the preview constraints.

Developer Integration - Setting Up via the Microsoft Foundry Portal

The typical portal-based workflow for Foundry IQ:

Sign in to Microsoft Foundry at https://ai.azure.com. Ensure the "New Foundry" toggle is on.
Create a project or select an existing project.
From the top menu, select Build.
On the Knowledge tab:
- Create or connect to an existing search service that supports agentic retrieval.
- Create a knowledge base by adding one knowledge source at a time.
- Configure knowledge base properties for retrieval behavior.
On the Agents tab:
- Create or select an existing agent.
- Connect to your knowledge base.
- Use the playground to send messages and refine your agent.

For proof-of-concept testing, you can use the free tier for Azure AI Search and a free allocation of tokens for agentic retrieval.

Developer Integration - Connecting Foundry IQ to Agents Programmatically

For pro-code developers, the connection from an agent to a Foundry IQ knowledge base uses the Model Context Protocol (MCP) to facilitate tool calls. When invoked by the agent, the knowledge base orchestrates:

Plans and decomposes the user query into subqueries.
Processes the subqueries simultaneously using keyword, vector, or hybrid techniques.
Applies semantic reranking to identify the most relevant results.
Synthesizes the results into a unified response with source references.

SDK and API support (as of the documentation)>:

Platform	Python SDK	C# SDK	JavaScript SDK	Java SDK	REST API
Microsoft Foundry	✔️	-	-	-	✔️

Prerequisites for programmatic setup:

An Azure AI Search service with a knowledge base containing one or more knowledge sources.
A Microsoft Foundry project with an LLM deployment (such as gpt-4.1-mini).
Authentication and permissions configured on the search service and project.
Python SDK version 2.0.0 or later or the 2025-11-01-preview REST API version:

For role-based access control (RBAC):

Azure AI User role on the parent resource to access model deployments and create agents.
Azure AI Project Manager role on the parent resource to create a project connection for MCP authentication.
A system-assigned managed identity on the project for interactions with Azure AI Search.

Microsoft provides an end-to-end Python sample on GitHub - the agentic-retrieval-pipeline-example - for integrating Azure AI Search and Foundry Agent Service for knowledge retrieval.

How the Three IQ Layers Work Together - A Practical Scenario

Understanding each IQ layer individually is important; understanding how they combine is what unlocks transformative use cases. As one analysis frames it: think of a three-layer stack - Fabric IQ at the foundation (structured data intelligence), Foundry IQ in the middle (reasoning and knowledge grounding), and Work IQ on top (human workflow intelligence).

Scenario: Supply Chain Delay Management (Operations)

Consider a company building an AI agent to help manage supply chain delays:

Fabric IQ detects anomalies in delivery metrics. It sees that certain suppliers are trending late beyond historical norms, notices that on-time delivery percentages are dipping in specific regions, and correlates delays with upstream bottlenecks. This is data-driven awareness.
Foundry IQ grounds the agent in supplier contracts, SLAs, penalty clauses, and internal policies. It understands what the agreement actually says about late deliveries, interprets escalation thresholds, and knows which suppliers have stricter terms. This is contextual reasoning.
Work IQ observes that operations teams are overloaded handling these exceptions manually. It sees long email chains, recurring "delay review" meetings, and individuals spending hours every week tracking updates from vendors. It identifies patterns of reactive work consuming capacity. This is workflow intelligence.
The agent combines all three streams: it recommends which delays need escalation based on contractual impact, drafts communications to suppliers referencing the correct SLA language, suggests internal reprioritization, and surfaces issues before they become crises.

Scenario: Customer Service Knowledge Agent

A customer service team deploys an agent using:

Foundry IQ as the primary knowledge source, indexing product manuals, troubleshooting guides, FAQs, and past support ticket resolutions. When a customer asks about error code E305, the agent retrieves the relevant manual section with a citation to the source document.
Work IQ to access recent internal communications - for example, identifying that an engineering team discussed this exact error in a Teams conversation last week and already developed a workaround. The agent can surface this workaround alongside the official documentation.
Fabric IQ to check whether the error is correlated with a particular product batch or region by querying the semantic model of manufacturing and logistics data, enabling the support agent to proactively notify affected customers.

Scenario: Financial Reporting and Analysis (Finance)

A finance team connects Fabric IQ to its consolidated financial data in OneLake and Power BI:

The Ontology defines entities like Account, Transaction, Cost Center, and Region with standardized definitions for metrics like Operating Margin and Revenue Growth.
A Data Agent in Fabric IQ allows analysts to ask natural-language questions such as "What are the top five cost centers by budget variance this quarter?" - grounded in the official semantic model, ensuring the answer uses Finance's own calculation methodology.
Foundry IQ supplements this with knowledge from internal accounting policies, audit findings, and regulatory guidance documents, so the agent can explain why a variance occurred and whether it triggers any policy-based escalation.
Work IQ can surface the context of recent discussions among the finance team (e.g., "The CFO discussed this variance in Monday's meeting and requested a root-cause analysis by Friday"), ensuring the AI's recommendations are aligned with current priorities.

Practical Guidance for Copilot Studio and Agent Framework Developers

Choosing the Right Development Platform

Microsoft offers two primary paths for agent development, and both can leverage the IQ layers. The choice depends on the developer persona and scenario complexity:

Criteria	Copilot Studio	Microsoft Agent Framework (Agent 365 SDK)
Target audience	Business users, makers, power users, fusion teams	Professional developers, IT teams
Approach	Low-code / no-code with visual design canvas	Pro-code (Python, C# SDKs) with full programmatic control
IQ integration	Work IQ via MCP tools (Add Tool > Model Context Protocol); Foundry IQ via MCP connection; Fabric IQ via Fabric Data Agent	Work IQ via Agent 365 SDK; Foundry IQ via knowledge base APIs and Python SDK; Fabric IQ via APIs
Governance	Built-in through Agent 365 control plane + M365 admin center	Same Agent 365 governance + Azure RBAC
Best for	FAQ bots, task-specific assistants, business-process agents with moderate complexity	Multi-agent orchestration, complex retrieval pipelines, custom reasoning logic, enterprise-grade production agents

Copilot Studio is aimed at low-code builders while Azure AI Foundry serves pro-code developers; Agent 365 delivers a consistent, developer-friendly experience backed by rigorous evaluation for accuracy, latency, and reliability across both paths.

These platforms are not mutually exclusive. A common pattern is to use Foundry to build and fine-tune the agent's reasoning backend (including Foundry IQ knowledge bases) and Copilot Studio for the conversational front-end and deployment to Microsoft 365 channels. Microsoft also supports connecting a Foundry agent directly into Copilot Studio for organizations that want pro-code control over the backend with low-code deployment】.

Additional Developer Resources

Microsoft provides a hands-on learning experience called the IQ Series - an official GitHub repository (microsoft/iq-series) that includes video episodes, Jupyter notebooks, and Azure deployment templates spanning Foundry IQ, Work IQ, and Fabric IQ. This is a valuable starting point for developers exploring integration patterns.

For Copilot Studio, the Copilot-Studio-and-Azure GitHub repository includes a lab on Microsoft Foundry agentic retrieval (labs/2.4-microsoft-foundry-agentic-retrieval) with a notebook (foundry-IQ-agents.ipynb) that demonstrates how to connect Copilot Studio agents to Foundry IQ.

Key Best Practices

1. Curate your knowledge sources deliberately. For Foundry IQ, prioritize high-quality, authoritative content - official policy libraries, product documentation, and knowledge articles that customer service reps already use. Remove outdated or duplicated material before indexing. Please use scheduled indexing for incremental data refresh so agents always use the current information.

2. Invest in semantic modeling. For Fabric IQ, collaborate with business domain experts to design ontologies that capture actual business rules, relationships, and terminology. Start from existing Power BI semantic models when possible - they can be used as a bootstrap for ontologies, keeping language consistent across Fabric experiences.

3. Clean up collaboration data. For Work IQ, ensure that the organization's SharePoint structures are tidy, file ownership is clear, and key processes are documented. Reduce duplication and align Dataverse models with real business logic. As noted in an analysis by VisualLabs, "Copilot cannot infer intent from SharePoint chaos" - AI amplifies what already exists.

4. Combine IQ layers for maximum impact. **Foundry IQ can incorporate Work IQ and Fabric IQ as data sources, enabling custom agents to unify all three context dimensions through a single retrieval interface.

5. Govern and monitor rigorously. Use the M365 admin center for Work IQ tool governance and Azure RBAC for Foundry IQ permissions. Use Microsoft Defender's Advanced Hunting to audit all tool calls your agents make in production. For Foundry IQ, enforce permissions at query time by passing user tokens to filter results based on identity.

6. Use the "Bring Your Own Model" capability strategically. Copilot Studio supports connecting models from Microsoft Foundry's model catalog (including GPT 4.5, Llama, DeepSeek, and 11,000+ more models) to specific prompt actions within an agent. This allows you to pick the best-performing model for each task - not just use a single model globally. Governance for these model connections is managed through Power Platform admin center policies under the "Microsoft Foundry" connector.

Use Case Summary

The following table consolidates practical use cases across three domains, illustrating which IQ layers contribute and how:

Domain	Use Case	Work IQ Contribution	Fabric IQ Contribution	Foundry IQ Contribution
Customer Service	Intelligent support agent that resolves complex tickets	Surfaces recent internal discussions about the issue (Teams chats, email threads)	Correlates the issue with product batch data, defect rates, or regional patterns	Retrieves official troubleshooting guides, product manuals, and policy documents with citations
Finance	Automated financial analysis and variance reporting	Identifies which finance team members have been discussing a variance and surfaces meeting action items	Provides a governed semantic model of financial KPIs, ensuring consistent definitions (e.g., how "operating margin" is calculated)	Grounds the agent in accounting policies, audit findings, and regulatory guidance documents
Operations	Supply chain delay advisor	Detects that ops teams are overloaded with manual exception handling (long email chains, recurring meetings)	Identifies anomalies in delivery metrics, correlates delays with upstream bottlenecks, and detects regional performance dips	Retrieves supplier contracts, SLAs, and penalty clauses to determine contractual obligations and escalation thresholds
HR / Onboarding	New employee onboarding assistant	Understands who the new hire's team members are and what projects are active	N/A	Retrieves onboarding guides, IT setup instructions, benefits documentation
Compliance	Regulatory compliance advisor	Tracks which compliance officers have been communicating about a specific regulatory change	Monitors regulatory metrics and flags anomalies against defined thresholds	Retrieves the latest regulatory texts, internal policies, and past audit reports with citations

Addressing the Runtime and Governance Layer: Agent 365

No discussion of enterprise agent deployment is complete without addressing who monitors these agents and who is accountable for them. Microsoft's answer is Agent 365 - the runtime and governance layer that sits over all IQ workloads and agent interactions.

Agent 365 monitors agent decisions, tracks accuracy over time, enforces compliance boundaries, and provides deep observability into how agents behave in the real world. It gives visibility into what the agent is doing, why it is doing it, and whether it is staying within defined guardrails. This is not just logging - it is operational control: knowing when performance drifts, when policies change, and when human override is required. Without this layer, as one analysis notes, "you have experiments - clever, promising, but fragile. With it, you have enterprise-grade systems that can scale responsibly.".

For organizations evaluating AI agent initiatives, the presence of Agent 365 as a centralized governance layer is a critical factor in the build-versus-buy decision. It combines extensibility, security, and compliance to help organizations confidently scale AI agents across productivity and business systems.

Conclusion: Turning Enterprise Context into Competitive Advantage

Work IQ, Fabric IQ, and Foundry IQ represent a structural shift in how enterprises build AI agents. Rather than bolting generic AI onto existing workflows, these intelligence layers embed organizational understanding directly into the agent's reasoning process - from user collaboration patterns (Work IQ) to governed business semantics (Fabric IQ) to secure, multi-source knowledge retrieval (Foundry IQ).

For business decision-makers evaluating AI investments, the implication is clear: the value of enterprise AI is proportional to the quality and depth of context it can access. Organizations that invest in structuring their work data (M365), defining business semantics (Fabric), and curating knowledge bases (Foundry) will extract far more value from AI agents than those relying on generic models. KPMG's survey found that among organizations scaling AI, the top ROI metrics are productivity (cited by 98% of leaders), profitability (97%), and improved performance and work quality (94%) - all outcomes that depend on context-rich, trustworthy AI rather than raw model capability.

For developers, the three IQ layers provide a clear architecture and integration path - whether through Copilot Studio's visual MCP tool integration or through the Agent 365 SDK's programmatic APIs. The key is to start with well-defined data foundations (clean SharePoint, governed Fabric models, curated knowledge sources) and progressively layer in IQ capabilities as agent scenarios mature.

The organizations that will lead in the agentic era are those that recognize deployment is only the beginning - and that contextual intelligence, not model size, is the true differentiator.

Connecting Azure Application Insights to Microsoft Copilot Studio: Unlocking Deep Analytics for Agentic Systems

Holger Imbery — Sat, 18 Apr 2026 07:08:42 +0000

Summary Lede

Agentic systems demand visibility. By connecting Azure Application Insights to your Copilot Studio agents, you gain enterprise-grade monitoring that goes far beyond built-in analytics—enabling real-time diagnostics, performance optimization, and strategic business insights in a single integrated platform.

Why read this: You'll discover how to unlock faster issue detection and resolution, measure and improve user experience, demonstrate ROI to stakeholders, and establish the telemetry foundation that separates high-performing teams from those operating blindly. This guide walks through prerequisites, configuration steps, and best practices to help you implement a mature observability strategy immediately.

As agentic systems grow in complexity and autonomy, visibility becomes critical. Analytics illuminate how agents interpret user intent, make decisions, and interact with external systems—transforming a "black box" into an understandable, debuggable, and continuously improving system. In production environments, telemetry reveals performance bottlenecks, catches errors before users notice them, and provides the evidence base for optimizing agent behavior and dialog flows. Without analytics, teams operate blindly; with it, they make data-driven decisions and build trust through transparency.

Benefits of Connecting Azure Application Insights to Copilot Studio

Connecting Azure Application Insights to Microsoft Copilot Studio agents significantly extends your monitoring, diagnostics, and analytics capabilities far beyond the native tooling provided by Copilot Studio alone. Application Insights, a powerful component of the broader Azure Monitor platform, is a fully extensible Application Performance Management (APM) service designed to meet enterprise-scale requirements. This service captures granular message-level telemetry, topic trigger events, interaction latency measurements, custom domain-specific events, and comprehensive error details in near real-time, enabling immediate visibility into agent behavior. By establishing this integration, organizations gain access to both fine-grained technical observability, which empowers engineering teams to debug and optimize agent performance, and strategic usage intelligence, which informs business stakeholders about adoption patterns, user satisfaction trends, and operational efficiency metrics.

Key Benefits Overview

Benefit Area	Technical Capabilities	Business / Strategic Value
Real-Time Monitoring	Live telemetry stream of conversations; configurable Azure Monitor alerts for anomalies or thresholds	Proactive issue detection minimizes downtime; enables swift scaling responses during usage spikes
Performance Optimization	Latency and performance data per interaction; Smart Detection flags unusual performance drops automatically	Faster, more reliable agent increases user satisfaction; reduces abandonment from slow responses
Diagnostics & Error Logging	Automatic capture of exceptions with full context (stack traces, conversation state, topic/step); custom telemetry events for domain-specific tracking	Faster troubleshooting lowers support costs; higher reliability builds user trust
User Interaction Analytics	Conversation counts, active users, channels, topics triggered, session durations — queryable via KQL	Data-driven improvements to dialog design; evidence base for prioritizing development effort
Dashboards & Reporting	Pre-built Copilot Studio Dashboard (Azure Workbook) with total conversations, latency, exceptions, tool usage, and topic analytics — editable and shareable	Cross-functional visibility for technical and business stakeholders; supports ROI reporting
Ecosystem Integration	Connects to Power BI, Azure Data Lake, Azure Monitor alerts, and other Azure services	Enterprise-grade reporting pipelines; cross-system correlation between bot telemetry and business outcomes
Custom Events & Extensibility	"Log a custom telemetry event" action in Copilot Studio for domain-specific tracking; KQL for arbitrary analysis	Tailored KPI tracking (resolution rates, conversion events); structured A/B testing of agent configurations

How Telemetry Is Collected

Setting up Application Insights for your Copilot Studio agents involves configuring where and how telemetry data flows. The process is straightforward but requires understanding key configuration options and prerequisites. Here's what you need to know to get started:

Per-agent configuration: There is no tenant-wide switch. Each agent must be connected to Application Insights individually.
Setup: Add the Application Insights connection string in Settings → Advanced → Application Insights within Copilot Studio.
Azure Subscription: Required to use Application Insights.
Logging Options:
- Log activities: Logs all incoming/outgoing messages and events.
- Log sensitive Activity properties: Includes userid, name, text, and speak. Off by default due to privacy implications.

What Metrics and Data Are Available

Custom Dimensions

Telemetry records include rich metadata in the customDimensions field:

Field	Description	Sample Values
`type`	Type of activity	`message`, `conversationUpdate`, `event`, `invoke`
`channelId`	Channel identifier	`emulator`, `directline`, `msteams`, `webchat`
`fromId`	Sender identifier	`<id>`
`fromName`	Username from client	`John Bonham`, `Keith Moon`
`locale`	Client origin locale	`en-us`, `zh-cn`, `de-de`
`recipientId`	Recipient identifier	`<id>`
`recipientName`	Recipient name	`John Bonham`, `Keith Moon`
`text`	Text in message	`find a coffee shop`
`designMode`	Whether conversation occurred in the test canvas	`True` / `False`

{: .important }
Note: Data quality varies by channel. For example, unique user counts are only reliable when users are authenticated.

Built-In Copilot Studio Dashboard

Copilot Studio provides a pre-built Azure Workbook dashboard that offers immediate visibility into your agent's performance and usage patterns. This dashboard aggregates key metrics without requiring custom configuration:

Location: Application Insights → Monitoring → Workbooks → Copilot Studio Dashboard
Metrics Included: Total conversations, latency, exceptions, tool usage, topic analytics
Customizable: Add tiles using KQL, save and share dashboards with team members (requires Reader role)

KQL Querying

Use Kusto Query Language (KQL) to analyze telemetry data:

let queryStartDate = ago(14d);
let queryEndDate = now();
let groupByInterval = 1d;
customEvents
| where timestamp > queryStartDate
| where timestamp < queryEndDate
| summarize uc=dcount(user_Id) by bin(timestamp, groupByInterval)
| render timechart

To exclude test conversations:

customEvents
| extend isDesignMode = customDimensions['designMode']
| where isDesignMode == "False"

Built-In Analytics vs. Application Insights

Use Case	Built-In Analytics	Azure Application Insights
Track topic usage and completion	yes	yes (with custom events)
Understand user satisfaction	yes	yes (if instrumented)
Debug dialog transitions	no	yes
Monitor API latency or errors	no	yes
Visualize trends over time	yes (limited)	yes (custom dashboards)
Correlate with external systems	no	yes
Alerting and anomaly detection	no	yes

{: .important }
Application Insights complements — not replaces — built-in analytics.

Technical Benefits

Application Insights delivers powerful technical capabilities that transform agent monitoring and diagnostics:

Live Metrics: Real-time monitoring of bot activity.
Smart Detection: Automatic anomaly and performance issue detection.
Custom Telemetry: Log domain-specific events from within Copilot Studio.
Centralized Monitoring: Consolidate logs, metrics, and traces across agents.
Scalability: Monitor bots across multiple environments and regions.
Extensibility: Integrate with Power BI, Azure Data Lake, and more.

Business Value and Strategic Advantages

Application Insights transforms agent monitoring from a purely technical exercise into a strategic business tool. By connecting telemetry data to measurable outcomes, organizations can demonstrate ROI, accelerate innovation cycles, and build confidence in agentic systems. The following sections explore the key business advantages:

Data-Driven Decision-Making

Telemetry provides the foundation for evidence-based improvements across your agent ecosystem.

Use telemetry to understand user behavior, optimize dialog flows, and prioritize development.
Dashboards and reports provide evidence for product decisions and stakeholder communication.

Operational Efficiency

Application Insights dramatically reduces the time and effort required to maintain reliable agents in production. By automating detection and providing detailed diagnostics, teams can respond faster to issues and prevent recurring problems from consuming resources.

Reduce mean time to detect and resolve issues.
Identify systemic issues and eliminate recurring failures.

Customer Satisfaction

Application Insights enables you to measure and enhance user experience by providing visibility into agent responsiveness and identifying friction points in conversations. By understanding where users encounter delays or confusion, teams can make targeted improvements that directly impact satisfaction and retention.

Improve response times and reduce errors.
Analyze drop-offs and confusion points to refine UX.

Compliance and Auditing

In regulated industries and enterprises subject to data governance requirements, comprehensive audit trails and compliance documentation are non-negotiable. Application Insights provides the forensic capabilities needed to demonstrate regulatory compliance, investigate incidents, and maintain defensible records of agent behavior and data handling.

Maintain detailed logs for audit trails.
Support regulatory requirements with timestamped, queryable data.

Best Practices

Implementing a robust telemetry strategy requires discipline and intentionality. The following best practices will help you maximize the value of Application Insights while minimizing operational overhead and ensuring data quality:

Log Meaningful Events: When instrumenting your Copilot Studio agents, focus exclusively on capturing events that provide actionable intelligence. This includes clear indicators of user intent (such as topic invocations or explicit requests), documented dialog outcomes (successful resolutions, escalations, or abandonment), and comprehensive error context. By avoiding noise and focusing on the signal, you reduce data volume while improving analysis quality and reducing query latency.
Use Correlation IDs: Implement correlation identifiers to link related activities across multiple services, dialogs, and organizational boundaries. This practice is essential in distributed systems where a user's interaction may involve multiple agents, backend APIs, and cloud services. Correlation IDs enable end-to-end tracing of requests, making it significantly easier to diagnose complex failures and understand latency across the entire interaction pipeline.
Set Up Alerts: Configure Azure Monitor alerts on critical performance thresholds and anomalies. Rather than waiting to discover problems through manual dashboard review, proactive alerting ensures that your team is immediately notified of concerning patterns—such as sudden spikes in error rates, performance degradation, or unexpected traffic patterns. This enables rapid response before issues escalate into user-facing problems.
Review Dashboards Regularly: Establish a cadence for reviewing Application Insights dashboards with relevant stakeholders—both technical teams who investigate issues and business stakeholders who track adoption metrics. Regular review sessions transform telemetry from a passive record into an active feedback loop that informs prioritization, guides feature development, and validates hypotheses about agent behavior and user satisfaction.

Connect your Copilot Studio agent to Application Insights

Establishing a connection between your Copilot Studio agent and Azure Application Insights requires careful configuration to ensure telemetry data flows correctly to your monitoring environment. This section provides comprehensive guidance on the setup process, prerequisites, and optional configuration settings that affect which data is captured and transmitted.

Prerequisites and Initial Setup

Before you can establish a successful connection between your Copilot Studio agent and Application Insights, ensure that you have an active Azure subscription and an existing Application Insights resource. The connection process relies on authentication credentials stored in your agent's configuration so that you will need administrative access to both your Copilot Studio environment and your Azure resources.

To initiate the connection process, navigate to the Settings page for your agent within Copilot Studio. From the Settings page, locate and select the Advanced tab. This tab contains configuration options not exposed in the standard settings interface and typically reserved for operational and monitoring settings.

Configuring the Application Insights Connection String

Within the Advanced settings tab, you will find a dedicated Application Insights section. In this section, locate the Connection string field and populate it with the connection string obtained from your Azure Application Insights resource.

The connection string serves as the authentication and routing credential that enables your agent to transmit telemetry data to your specific Application Insights instance securely. Refer to the Azure Monitor documentation for comprehensive instructions on locating and retrieving your connection string from your Application Insights resource in the Azure portal.

Optional Logging Configuration

In addition to basic connectivity, Application Insights offers two optional configuration flags that let you control the scope and sensitivity of captured telemetry data. These settings provide flexibility to balance comprehensive monitoring with privacy and compliance considerations.

Log Activities: When this setting is enabled, Application Insights captures comprehensive details of all incoming and outgoing messages exchanged between users and your agent, as well as all event notifications triggered during agent operation. This option provides maximum visibility into agent behavior and user interactions, enabling detailed diagnostics and comprehensive audit trails. However, enabling this option increases telemetry volume and may have cost implications for higher-traffic agents.

Log Sensitive Activity Properties: This setting governs whether certain data fields that may contain personally identifiable information (PII) or other sensitive information are included in logged telemetry. When enabled, the following properties are captured in logs: userid, name, text, and speak (note that the text and speak properties apply exclusively to message-type activities and are not captured for other event types).

By default, this setting is disabled due to data privacy and compliance considerations. Organizations operating under strict data governance frameworks, healthcare regulations (HIPAA), financial regulations (PCI-DSS), or general privacy standards (GDPR) should exercise caution when enabling this option. If enabled, ensure that appropriate data retention policies, encryption measures, and access controls are in place to protect sensitive information logged to Application Insights.

Conclusion

Connecting your Copilot Studio agents to Azure Application Insights represents a fundamental shift in how you approach agent observability and operational excellence. By moving beyond built-in analytics, you gain enterprise-grade monitoring capabilities that illuminate every aspect of agent behavior—from granular message-level telemetry to high-level strategic insights about adoption and ROI.

The integration delivers immediate practical benefits: faster issue detection and resolution, performance optimization grounded in real data, and comprehensive audit trails that satisfy regulatory requirements. It also turns your organization's relationship with agentic systems from speculative to evidence-driven, so you can scale confidently and keep improving.

Whether your priority is reducing support costs, accelerating time-to-resolution, or demonstrating measurable business value to stakeholders, Application Insights provides the visibility and analytical power to achieve those goals. Start with the fundamentals—configure the connection string, enable appropriate logging, and establish a dashboard review cadence. As your telemetry practice matures, layer in custom events, automated alerts, and deeper correlation across your broader system ecosystem.

Telemetry infrastructure pays off right away and grows over time as your teams build data-driven habits, and your agents become more reliable, responsive, and aligned with business goals.

Building On‑Prem AI Agents with Azure Local, Foundry Local, and Microsoft Agent Framework

Holger Imbery — Sat, 11 Apr 2026 07:26:18 +0000

Summary Lede

Cloud-native architecture belongs on-premises too

On-premises and cloud-native are not contradictions — they are complementary. While enterprises have spent years building cloud-native practices in the cloud, those same principles—containerization, orchestration, API-driven integration, and infrastructure-as-code - deliver even greater value when deployed on-premises. This guide shows you how to build production AI agents that (must) run locally and using cloud native deployment schemas with Azure Local, Foundry Local, and Microsoft Agent Framework - this is proving that cloud-native excellence is not constrained by your network boundary.

If you operate in regulated industries, manage constrained connectivity, or face data residency requirements, this architecture gives you the operational consistency of the cloud without leaving your premises.

This article is the second in a series on Azure Local:

Azure Local, Foundry Local, and Microsoft 365 Local: A Comprehensive Guide for IT Architects and Decision-Makers.

Enterprise teams are moving beyond “chatbots” toward agents that can retrieve internal knowledge, call tools, orchestrate workflows, and produce outcomes aligned to real business processes. The challenge is that many agent reference designs assume always‑on cloud connectivity and cloud-hosted inference. That assumption does not hold everywhere.

In regulated industries, in plants and branches with constrained connectivity, or in environments where latency and data locality are non‑negotiable, the architecture has to follow the use case. This post describes a pragmatic design you can implement today by combining:

Azure Local as the on‑prem infrastructure substrate, managed through Azure Arc.
AKS on Azure Local as the standardized Kubernetes runtime for agent services and supporting components.
Foundry Local (preview) as the local inference runtime exposing an OpenAI‑compatible REST interface for model calls.
Microsoft Agent Framework (MAF) as the agent and workflow layer, including tool integration, session/state management, middleware, and telemetry patterns.

A critical insight: cloud-native architecture and practices are not limited to cloud deployments. The principles—containerization, orchestration, infrastructure-as-code, API-driven integration, observability, and declarative state management—are equally valuable on‑premises. In fact, they become more essential when your infrastructure cannot scale elastically or rely on the implicit redundancy of cloud regions. By applying cloud-native architecture to on‑prem agent deployments, you gain consistent operational models across locations, faster iteration, clear boundaries between layers, and the ability to treat infrastructure changes as routine rather than exceptional.

One design choice drives everything that follows: separate the agent runtime from the model runtime. You want the agent layer (routing, tools, workflows, state, observability) to evolve independently from inference, especially when local inference is in preview and can change.

The architecture in one picture (logical view)

A practical baseline pattern is “local inference, centralized orchestration.”

This separation keeps your application surface stable by establishing a clear boundary between stateless agent logic and stateful model inference. Because the agent layer and model runtime are decoupled, you can update agent code, refine routing logic, add new tools, or adjust middleware without touching the inference layer. Tools can be added safely behind constrained proxies or API gateways, allowing you to apply fine-grained network controls and audit trails at the integration boundary. Governance policies, observability hooks, and logging patterns remain consistent across agent operations regardless of where inference is placed. Simultaneously, inference becomes a managed dependency that can scale, relocate, or upgrade independently of application code. This architectural separation is particularly valuable in regulated environments where model serving and application logic often require separate operational controls, hardware isolation, or audit commitments. By decoupling these layers, you achieve the flexibility to place inference close to hardware accelerators (GPUs, NPUs) and data sources without forcing agent code to depend on infrastructure choices that are still evolving, especially when the inference runtime is in preview status and subject to API changes or performance tuning.

Where this approach fits (and where it does not)

This is a good fit when

This pattern becomes the right choice when one or more of the following constraints are fundamental to your deployment environment:

Data residency and regulatory compliance are hard boundaries. When regulations, industry standards, or organizational policy require that prompts, retrieved context, and inference results remain physically within an on‑premises boundary—whether for financial data, healthcare records, or proprietary intelligence—local inference becomes non‑negotiable. Cloud-based APIs, even with encryption and data-deletion assertions, may not satisfy audit requirements or legal obligations in certain jurisdictions. In these cases, the agent architecture must be designed to keep the full inference pipeline local while still benefiting from cloud-based observability and control planes, where appropriate, via segregated connections.

Latency is a direct measure of operational usability. In manufacturing plants, field service operations, retail branches, or other environments where agents serve human users on the shop floor or remote locations, response time is not a performance metric—it is a functional requirement that affects whether the agent is used at all. When users are waiting for a troubleshooting recommendation or a work instruction, a response that takes tens of seconds to traverse cloud networks is often abandoned. Local inference, combined with local agent orchestration, ensures that the slowest part of the response pipeline is your own internal network and compute capacity, not external connectivity.

Connectivity cannot be assumed to be always available and high-bandwidth. Many operational environments have constrained connectivity: scheduled outbound traffic windows, rate-limited connections, air-gapped subnets, or intentional network fragmentation for security isolation. The agent needs to function usefully within these constraints rather than degrade into a pass-through to cloud APIs. Azure Local supports this by enabling local execution and local state, while Arc provides a control-plane integration path when connectivity is available, rather than requiring continuous connectivity.

You want cloud-native operational practices applied on‑premises. This includes containerized deployments, Kubernetes orchestration for workload management, infrastructure-as-code for reproducibility, GitOps-driven delivery pipelines, policy enforcement at the runtime boundary, and standardized telemetry and logging. These practices are not exclusive to cloud deployments; they provide the same benefits on‑premises—clear separation of concerns, predictable deployments, and auditability—but require an infrastructure platform like Azure Local to realize them consistently.

When this pattern becomes problematic

Reconsidering a local-first architecture is warranted in several practical scenarios. If your inference workload demands elastic horizontal scaling and you cannot predict peak capacity without overprovisioning on-premises infrastructure, then chasing elastic scale with local hardware becomes economically and operationally inefficient. Building auto-scaling logic that manages standby capacity across stateful models would contradict the efficiency argument for locality. Similarly, if your operational environment requires production-grade stability guarantees from the inference API layer with minimal risk of breaking changes between deployments, the current maturity of local inference runtimes (such as Foundry Local, which remains in preview) presents a material risk. Preview components introduce uncertainty regarding backward compatibility, performance-tuning recommendations, and troubleshooting depth, which may not align with production SLAs. Finally, if the problem you are solving is fundamentally deterministic—where steps follow a fixed sequence, validation rules are static, and branching logic is known in advance—a structured workflow orchestration tool or a conventional microservice often provides clearer observability, simpler debugging, and lower operational overhead than an agent. Not every problem with tools and state management requires agentic behavior; sometimes explicit choreography is both simpler and more reliable.

These are the constraints that inform the "whether" decision. The next section moves to the "why Azure Local" specifically, grounded in use-case context rather than abstract on-premises philosophy.

Why Azure Local makes sense here (the use case drives locality)

Azure Local is not the point of the architecture. It is the platform choice that becomes rational when the agent pattern has to follow the environment: where data and tools live, what network rules allow, what latency targets are required, and what failure modes are acceptable.

1) The agent needs to live where the tools and data already are

High‑value agents are typically tool-heavy, and the distribution of that tooling directly affects where the agent runtime should run. The model call itself—the inference step that generates a response — is only one part of the agent interaction. The larger portion of the interaction involves retrieving documents from internal repositories, querying operational databases, validating business rules and constraints, and writing outcomes back to systems of record. Each of these operations carries a latency cost, integration overhead, and often data governance implications.

When the authoritative data sources and the systems that perform work live on‑premises—whether that is an ERP system, a manufacturing execution system, a document repository, or a service dispatch platform—moving the agent runtime closer to those systems becomes pragmatically necessary rather than architecturally optional. A remote agent calling back into on‑premises tools over the network incurs not only the latency of each call but also the operational complexity of maintaining secure, reliable network pathways between cloud and on‑premises infrastructure, managing retry logic for transient failures across that boundary, and reasoning about whether a failure in the agent's response came from the model inference or from a tool integration issue.

Placing the agent runtime on‑premises reduces integration complexity by collapsing tool interactions into local function calls with minimal network hops. It also materially shrinks the trust boundary. Data that would otherwise traverse a cloud service boundary—even with encryption in transit and assertions of deletion—can remain inside the perimeter where it originated. Azure Local provides a consistent, repeatable substrate on which to host the runtime within the organizational boundary while still enabling cloud-native operational practices such as containerization, orchestration, and declarative configuration management that teams have come to expect.

2) Latency is a functional requirement, not a nice-to-have

In operational scenarios, predictable response time is not an optimization target—it is a functional requirement embedded in the task itself. When a field technician, floor supervisor, or support worker invokes an agent for a troubleshooting recommendation or work instruction, they are typically performing a task that cannot proceed until they receive guidance. A response that arrives within seconds fits naturally into human workflow and decision-making; the user can act on it immediately and move forward. A response that takes tens of seconds—or worse, becomes non-deterministic depending on cloud API load—exceeds the mental context window of the task. Users abandon the agent, fall back to phone calls or manual lookups, or proceed without the agent's input entirely, making the agent operationally irrelevant regardless of its intelligence.

The latency problem compounds when the agent's response is not a single inference call. A typical operational agent orchestrates multiple steps: retrieving context from a document repository, querying a database to validate prerequisites, calling an external service to fetch the current state, and then synthesizing a response. Each of these operations incurs round-trip time. When those dependencies live on-premises, and the agent runtime lives in a cloud region thousands of kilometers away, the baseline latency floor is determined by geography and internet backbone capacity, not by the execution speed of any individual component. You cannot optimize away the speed of light or your ISP's rate limiting. Placing the agent runtime and its tooling in the same local environment—where internal networks typically offer latency in the single-digit millisecond range—ensures that the slowest element becomes your own infrastructure capacity, which you can measure, predict, and scale. This transforms latency from an externality you absorb to a variable you control.

Azure Local supports this placement strategy by providing AKS-hosted agent services and local model-serving infrastructure in a shared operational footprint. The inference engine, the agent orchestration layer, and the tool integrations all run in the same data center or facility where the authoritative systems live. This collapse of distance translates directly into a collapse of latency, which translates into usability in environments where response time affects task completion.

3) Connectivity constraints are a design input

Many environments are not "cloud-connected" as cloud reference architectures assume. The assumption embedded in most cloud-native architecture guidance is that outbound connectivity is available, reliable, and incurs acceptable latency and throughput. In practice, many operational environments operate under very different constraints. Outbound traffic to public cloud endpoints may be restricted by security policy or rate-limited by egress gateways. Connectivity may be scheduled—available only during specific windows or subject to maintenance blackouts. In other cases, network segments may be deliberately disconnected by design: operations technology networks in manufacturing facilities, isolated domains in financial institutions, or intentionally air-gapped environments in highly regulated sectors all follow this pattern. Even when connectivity exists, it may be mediated by proxies, firewalls, or VPNs, adding latency and complexity to troubleshooting when the agent's inference or tool calls fail.

Azure Local enables local execution of the agent runtime and inference engine regardless of whether upstream cloud connectivity is available. Simultaneously, it aligns with Azure's control-plane concepts and governance models via Azure Arc when connectivity is available. This dual capability means you can design and operate an agent system that functions reliably in disconnected or intermittently-connected scenarios without abandoning cloud-native operational practices. When connectivity is available, Arc can be used for centralized observability, policy enforcement, and update orchestration. When connectivity is unavailable, the local agent continues to function using local tools and data. This gives you an operational path that respects the actual constraints of your environment rather than forcing an architecture that assumes away those constraints or requires workarounds to compensate for them.

4) You can keep cloud-native operations without reinventing on‑prem deployment

Teams generally want repeatable delivery, policy enforcement, and consistent observability. The conventional tension between on-premises deployments and cloud-native operations has historically forced a false choice: either accept the operational discipline and automation of cloud platforms at the cost of moving workloads outside your perimeter, or keep infrastructure on-premises and revert to manual configuration management, bespoke deployment scripts, and fragmented observability tooling.

Azure Local plus AKS on Azure Local severs that coupling. Containerized deployments, GitOps-driven configuration management, Kubernetes namespaces, and declarative rollout strategies work identically whether your agent runtime is in a public cloud region or in your own data center. The infrastructure boundary becomes transparent to operational practices. Teams can maintain the same deployment pipelines, policy engines, and observability systems they have built for cloud workloads and apply them without modification to on-premises clusters. This continuity of tooling and process significantly reduces the operational friction that typically accompanies on-premises agent deployments. The "local" decision becomes a deployment location decision—a choice about where to run proven, familiar infrastructure patterns—rather than a return to bespoke server management, manual patching, and isolated monitoring infrastructure that would otherwise characterize traditional on-premises deployments.

5) Local inference forces you to manage capacity and hardware intentionally

If inference is local, capacity planning and acceleration hardware become first-class concerns that demand explicit decision-making rather than outsourced abstraction. When inference runs in a public cloud service, capacity is nominally infinite—or at least, the perception of infinity is maintained through multi-tenancy and auto-scaling tiers that obscure the underlying hardware realities. Costs accumulate by token count and API call frequency, but the physical infrastructure remains opaque. The tradeoff is acceptable if your workload is occasional or bursty; the cost volatility is a known variable you can budget for.

When inference runs locally, however, the hardware economics become tangible. A single GPU accelerator costs tens of thousands of dollars upfront, requires power and cooling infrastructure, and has a finite lifespan. Acquiring that hardware is no longer a usage-based charge smoothed into monthly billing; it is a capital expenditure that sits in your facility and has opportunity cost. This visibility forces intentional capacity planning: you must understand your typical inference load, peak throughput requirements, model sizes, and acceptable latency percentiles, and then purchase hardware that meets those requirements with some headroom for growth. You cannot simply add capacity by changing a tier or waiting for auto-scaling to provision more instances; you provision intentionally.

Azure Local provides a platform to run and govern those resources, allowing you to isolate inference nodes, stage updates, and enforce change control without coupling the inference lifecycle to the agent code lifecycle. You can reserve specific nodes for specific models, apply resource quotas to prevent one workload from starving another, and manage hardware refreshes independently from application deployments. This separation of concerns means you can upgrade your inference engine or swap model versions without draining the entire cluster, and you can plan hardware replacement without triggering emergency application refactorings. The operational rigor this imposes is not a burden—it is an alignment of technical decision-making with the actual cost structure of your infrastructure.

6) The architecture stays incremental and reversible

By separating agent runtime from model runtime, you establish a deployment boundary that allows you to make infrastructure decisions independently from application logic. This separation is critical in practice because it decouples two sources of change that typically move at different velocities: the agent orchestration layer (tools, workflows, routing, state management) tends to evolve rapidly as teams refine business logic and respond to operational feedback, while the inference runtime makes infrequent but high-impact decisions around model selection, hardware acceleration strategy, and inference node topology that are capital-intensive and difficult to reverse.

Starting small means you can pilot with a single inference node running a small quantized model, then grow to multiple specialized nodes—some optimized for latency-sensitive operations, others for throughput—without requiring changes to the agent code itself. The agent layer continues to interact with inference through the same OpenAI-compatible API boundary, indifferent to whether a single GPU or a distributed cluster backs that endpoint. You can keep your agent API stable while swapping models; if a new quantization or a different model family becomes available, you can stage it on a secondary node and route traffic to validate behavior before completing the migration. You can change inference node placement by adjusting scheduling constraints or moving nodes between racks without triggering a redeploy of agent services. This mobility is not possible when agent code and inference are tightly coupled—for example, when inference decisions are embedded in application code or when the agent layer depends on model-specific features or tokenization strategies.

Azure Local supports this incremental expansion by providing a consistent Kubernetes control plane and standard scheduling mechanisms that treat compute resources as fungible. Your initial pilot might span a single machine running AKS on Azure Local in a branch or regional office; as you validate the model and prove business value, you can expand to a small cluster in your primary data center. Each step remains operationally routine because you are not changing how workloads are deployed or managed—you are only changing the scale and distribution of resources. A pilot deployment and a production cluster follow the same GitOps patterns, use the same artifact promotion pipelines, and respond to the same observability signals, allowing you to graduate from proof-of-concept to production without a redesign of your delivery model or a learning curve on unfamiliar operational practices.

Practical decision test: Azure Local tends to be the right call when most of these are true: the authoritative tools/data are on‑prem, prompts and retrieved context must remain local, latency is a requirement, connectivity is constrained, and you want cloud-native operations in the same footprint.

With that context, we can move from "why" to "how".

Step‑by‑step implementation runbook

Phase 0 — Define boundaries: agent vs workflow, and what "done" means

Write the outcome in business terms.

Define success in measurable outcomes, not in model features. Examples include reduced downtime, faster triage, fewer escalations, shorter handling time, or improved compliance auditability.
Classify steps as agent or workflow.
- Use an agent for open-ended interpretation, conversational assistance, flexible tool use, and summarization.
- Use a workflow for deterministic steps, routing, approvals, checkpoints, and auditable state transitions.
Produce a tool inventory and trust boundary map.

For each tool, define authentication, authorization, validation, allowed destinations, and audit requirements.

Operational gotcha: Teams often prototype by giving agents broad access "to move fast." That security debt becomes expensive later. Start with constrained proxies and allow-lists from day one.

Phase 1 — Platform baseline: Azure Local + Arc + AKS on Azure Local

1.1 Establish baseline assumptions

Decide upfront:

Topology: pilot node, datacenter cluster, or distributed sites.
OS mix: Linux nodes, Windows nodes, or mixed.
Acceleration: CPU only vs GPU/NPU inference nodes.
Connectivity mode: connected, constrained, or partially disconnected.

Operational gotcha: Constrained connectivity changes everything about artifact flow. Treat "how will nodes pull images and models?" as a first-class requirement (private registry, artifact promotion, caching).

1.2 Build a minimal AKS baseline (repeatable)

Include:

Namespaces for separation (platform, agents, tools, observability).
Ingress and certificate strategy.
Secrets management strategy.
Logging/metrics pipeline.
Network policies and egress controls.

Example namespace baseline:

apiVersion: v1
kind: Namespace
metadata:
  name: agents
  labels:
    pod-security.kubernetes.io/enforce: "restricted"
---
apiVersion: v1
kind: Namespace
metadata:
  name: tools
  labels:
    pod-security.kubernetes.io/enforce: "restricted"

Operational gotcha: Without early namespace boundaries and baseline policies, your cluster becomes a collection of special cases that are hard to govern and hard to migrate.

Phase 2 — GitOps delivery (recommended even for pilots)

2.1 Repository layout pattern

A structure that scales:

clusters/<cluster-name>/ for cluster-specific overlays
platform/ for shared add-ons (ingress, monitoring, policy)
workloads/agents/ for agent services
workloads/tools/ for tool proxies and connectors

2.2 Kustomization pattern (example)

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: agents
  namespace: flux-system
spec:
  interval: 5m
  path: ./workloads/agents/overlays/prod
  prune: true
  sourceRef:
    kind: GitRepository
    name: platform-repo
  timeout: 5m

Operational gotcha: GitOps only reduces drift if "kubectl apply in production" is the exception with a documented break-glass process.

Phase 3 — Foundational services: state, memory, and observability

Make state explicit and intentional:

Conversation state (threads, session context) belongs in agent stores designed for that purpose.
Business state (work items, approvals, tickets) belongs in systems of record.

Common supporting components on AKS:

Redis for caching and rate limiting
PostgreSQL (or equivalent) for durable state
A vector store if you implement local RAG
OpenTelemetry collector for traces/metrics/logs

Operational gotcha: Agent telemetry can explode. Define retention, sampling, and content redaction policies early. In regulated environments, you often cannot log raw prompts or retrieved text.

Phase 4 — Install Foundry Local (preview) on inference nodes

Treat Foundry Local as a managed runtime dependency.

4.1 Placement and isolation

Prefer dedicated inference nodes where possible.
Place them where the acceleration hardware lives.
Segment networking so AKS can reach them reliably while keeping exposure minimal.

4.2 Endpoint discovery (avoid hard-coded ports)

Prefer one of these:

Discovery service pattern: publish the current base URL into a config store that your agent services read.
Gateway pattern: place a stable internal proxy in front of Foundry Local to normalize routing and policies.

Operational gotcha: Hard-coded ports work in a lab and fail after reboots, upgrades, or runtime changes. Build discovery or stable routing into the design.

Phase 5 — Network, TLS, and identity between AKS and Foundry Local

5.1 Connectivity options

Common choices:

Direct HTTPS from agent pods to Foundry node IP/DNS
Internal L4/L7 proxy for stable routing and policy
Service mesh for mTLS and telemetry (only if you already operate one)

5.2 TLS strategy

Use your standard PKI approach, if possible, and ensure that clients validate certificates by default.

Operational gotcha: "Works with curl -k" is a warning sign, not a milestone. Fix trust chains early so insecure shortcuts do not become permanent.

Phase 6 — Implement the inference adapter in your MAF service

Design goal: agent code calls a model client abstraction, not a concrete endpoint.

6.1 Configuration pattern (ConfigMap + Secret)

apiVersion: v1
kind: ConfigMap
metadata:
  name: agent-config
  namespace: agents
data:
  FOUNDRY_BASE_URL: "https://foundry-local.internal.example"
  FOUNDRY_MODEL: "local-chat-model"
  INFERENCE_TIMEOUT_SECONDS: "30"
  INFERENCE_MAX_RETRIES: "2"
---
apiVersion: v1
kind: Secret
metadata:
  name: agent-secrets
  namespace: agents
type: Opaque
stringData:
  FOUNDRY_API_KEY: "placeholder-if-required-by-client"

Deployment consuming it:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: maf-agent-api
  namespace: agents
spec:
  replicas: 2
  selector:
    matchLabels:
      app: maf-agent-api
  template:
    metadata:
      labels:
        app: maf-agent-api
    spec:
      containers:
      - name: api
        image: registry.local/agents/maf-agent-api:1.0.0
        envFrom:
        - configMapRef:
            name: agent-config
        - secretRef:
            name: agent-secrets
        resources:
          requests:
            cpu: "250m"
            memory: "512Mi"
          limits:
            cpu: "2"
            memory: "2Gi"
        readinessProbe:
          httpGet:
            path: /health/ready
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 10

6.2 Client policy (timeouts, retries, circuit breakers)

Start with conservative defaults:

Timeout: 20–60s depending on model/prompt size
Retries: 1–2 for transient failures only
Circuit breaker: open after repeated failures to prevent cascading latency
Concurrency limits: protect inference nodes from overload

Operational gotcha: Without explicit backpressure, a single busy agent route can saturate inference and degrade every workload that shares the runtime.

Phase 7 — Tool integration with constrained proxies

Do not give agents direct access to sensitive systems.

Recommended approach:

Deploy tool proxy services in a dedicated namespace.
Restrict outbound connectivity to approved destinations only.
Enforce authorization, validation, and allow-lists in the proxy.
Log every invocation with correlation IDs.

A default-deny egress policy concept:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: tools-default-deny-egress
  namespace: tools
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress: []

Operational gotcha: If you skip network controls early, you will discover "mystery dependencies" later when tools call endpoints that were never approved.

Phase 8 — Observability: correlate agent → tools → inference

Minimum requirements:

Correlation ID propagated across inbound request, tool calls, inference calls, and response
Latency breakdown (tool time vs inference time vs orchestration time)
Error classification by category (tool failure, inference failure, policy block, timeout)
Token/prompt size metadata if available

Operational gotcha: Decide what is safe to log. For many environments, metadata and hashes are acceptable, but raw prompts and retrieved snippets are not.

Phase 9 — Hardening: safety, governance, regression testing

Hardening checklist:

Prompt and tool regression tests for critical flows
Golden conversations for validation after runtime updates
Tool schemas and allow-lists are enforced centrally
Timeouts on every external call
Rate limits per user and per route
Graceful degradation when inference is unavailable (fallback to workflow/human)

Operational gotcha: Preview inference runtimes can introduce behavior changes that are not "errors" but still break user expectations. Without regression tests, you will find out in production.

Phase 10 — Operations: versioning, rollouts, and capacity planning

10.1 Independent update cadencess

Operate on separate cadences:

Agent services: frequent updates via CI/CD
Inference runtime: cautious updates via staged rollout
Cluster/platform: regular maintenance windows

10.2 Rollout strategy

Canary agent changes with a small traffic slice and compares latency/error rates
Pin inference runtime versions and validate with representative load before expanding rollout

10.3 Capacity planning

Define explicit SLOs:

p95 latency target for a representative prompt
maximum concurrent sessions per inference node
acceptable queueing delay under peak load

Operational gotcha: Size for peaks and recovery scenarios. A thundering herd is common when shifts start, sites reconnect, or batch processes trigger.

A practical “day‑1 to day‑30” plan

Day 1–3: Foundation

Define business outcomes and agent/workflow boundaries
Stand up AKS baseline namespaces, ingress, and GitOps scaffolding
Deploy telemetry pipeline and basic dashboards

Day 4–10: Inference integration

Install Foundry Local on inference nodes
Implement endpoint discovery and TLS trust
Add inference adapter in the MAF service with externalized configuration

Day 11–20: Tools and data

Build constrained tool proxies with allow-lists and audit logs
Implement retrieval paths that keep data inside the boundary
Add correlation IDs end-to-end

Day 21–30: Hardening and operations

Add regression tests and golden conversations
Implement rollouts, version pinning, and canary strategy
Load test and finalize a capacity plan and operational runbooks

Conclusion

This stack is not about "on‑prem versus cloud." It is about aligning the agent pattern with the constraints imposed by the use case: data locality, tool proximity, latency targets, and network realities. Azure Local provides a consistent on‑prem platform for that pattern; AKS keeps operations cloud-native; Foundry Local enables local inference; and Agent Framework provides the application layer to build agents and workflows that map to real business outcomes. By following this architecture and implementation runbook, you can deliver production‑grade AI agents that run locally, proving that cloud-native excellence is not constrained by your network boundary.

Testing Copilot Agents: When to Use Agent Evaluation vs. the Copilot Studio Kit

Holger Imbery — Sun, 05 Apr 2026 07:29:14 +0000

Microsoft's Agent Evaluation GA announcement on March 31, 2026, update to Testing Copilot Studio Agents: Copilot Studio Kit vs. Agent Evaluation (Preview)

Summary Lede
Agent Evaluation and the Copilot Studio Kit are not competing tools—they represent a layered quality-assurance strategy. Agent Evaluation provides fast, AI-assisted behavioral validation embedded directly in Copilot Studio, ideal for iteration and rapid feedback. The Copilot Studio Kit delivers deterministic, enterprise-grade verification for production gates, compliance, and governance. This article breaks down what each tool does, when to use them, and how to adopt both as your agent quality matures.

Why read this
If you're building or scaling Copilot agents in your organization, you need clarity on testing strategy. This article cuts through the positioning and provides a practical decision framework for when to reach for Agent Evaluation versus the Copilot Studio Kit, with real-world scenarios showing how mature teams layer both tools across their development lifecycle.

What Microsoft shipped with Agent Evaluation (GA)

On March 31, 2026, Microsoft announced the general availability of Agent Evaluation, marking a significant milestone in Copilot Studio's testing and validation capabilities. Agent Evaluation is now generally available and built directly into Copilot Studio. Its goal is to make agent quality visible, repeatable, and scalable without requiring external tools or setup. This GA release represents the culmination of Microsoft's efforts to democratize agent quality assurance, bringing evaluation capabilities previously limited to advanced setups directly into the hands of everyday agent makers in the Copilot Studio authoring environment.

Core characteristics (as of 31. March 2026)

Integrated directly into the Copilot Studio authoring experience
Agent Evaluation is not a separate tool or external service. It lives within the Copilot Studio interface, where agents are built, allowing makers to validate their agents without context-switching or complex integrations. This tight integration reduces friction and encourages frequent validation during development cycles.

Designed to answer the production question:
"Can we trust this agent to behave correctly, consistently, and safely?"
This core question drives the entire design philosophy. Agent Evaluation focuses on behavioral confidence—whether the agent produces appropriate, consistent, and safe responses across diverse scenarios and user inputs.

Replaces unscalable manual testing and spot‑checking
Before Agent Evaluation, agent validation relied heavily on manual testing: individually testing scenarios, reviewing responses, and hoping coverage was adequate. This approach doesn't scale with agent complexity or usage volume. Agent Evaluation automates and scales this process through AI-assisted evaluation and reusable test sets.

Intended to be used before launch and continuously after changes
Agent Evaluation is not a one-time gate. It's designed for continuous validation: before initial launch, before deploying updates, and continuously as conversations flow through production. This shift from ceremonial testing to continuous validation aligns with modern DevOps practices.

Evaluation capabilities

Agent Evaluation allows makers to:

Create evaluation sets from:
- Manually added questions
- Imported test sets
- AI‑generated queries derived from agent metadata and knowledge sources
Choose flexible evaluation methods, including:
- Exact/partial match
- Semantic similarity
- Intent recognition
- Relevance and completeness scoring
Mix AI‑generated and human‑defined scenarios to balance breadth and depth
Reuse evaluations over time and run them via APIs for lifecycle testing

Key framing:
Agent Evaluation is positioned as a lightweight, AI‑assisted validation layer that fits naturally into everyday agent authoring and iteration. Unlike heavy external testing frameworks that require context switching and specialized infrastructure, Agent Evaluation operates within Copilot Studio itself, where agents are built. This embedded approach acknowledges that agent makers are iterating rapidly, testing comprehensively at each step, and need validation feedback within their authoring flow rather than as a post-production bottleneck. The AI-assisted scoring means makers don't need to hand-write every test case or define complex rubrics upfront; they can generate relevant test scenarios from their agent's own knowledge sources and metadata, then refine them. This makes evaluation accessible to makers of all skill levels and scales with agent complexity.

What the Copilot Studio Kit provides for testing

The Copilot Studio Kit (Power CAT) is a separate, solution‑based toolkit that augments Copilot Studio with enterprise‑grade testing, governance, and analytics. Developed by the Microsoft Power CAT (Patterns and Practices) team, the Kit represents a mature, production-ready framework built for organizations requiring rigorous quality assurance, regulatory compliance, and scalable CI/CD integration. While Agent Evaluation addresses everyday iteration and behavioral confidence within the authoring canvas, the Copilot Studio Kit provides the structural backbone for organizations that need deterministic verification, audit trails, multi-layer testing orchestration, and governance enforcement across large deployments.

Explicit testing capabilities

The Kit supports structured, deterministic, and multi‑layer testing, including:

Response Match (exact or conditional text comparison)
Attachment Match (Adaptive Cards/files)
Topic Match (requires Dataverse enrichment)
Generative Answer evaluation using AI Builder and rubrics
Multi‑turn tests running in a shared conversation context
Plan Validation for generative orchestration (verifying which tools/actions are invoked, not just what the agent says)

Execution and automation

Tests are executed via Copilot Studio APIs (Direct Line)
Bulk creation and maintenance via Excel import/export
Detailed run‑level telemetry:
- Pass/fail
- Latency
- Observed responses
- Aggregated metrics
Results can be enriched with:
- Azure Application Insights
- Dataverse conversation transcripts

Enterprise extensions beyond testing

The Kit also includes:

Conversation KPIs for Power BI
Prompt Advisor
Agent Inventory
Agent Review Tool
Compliance Hub with policy enforcement and SLA‑driven reviews

Key framing:
The Copilot Studio Kit is built for verification, regression testing, production gates, and governance at scale. Unlike Agent Evaluation's lightweight, AI-assisted approach that lives within the authoring canvas, the Kit functions as an enterprise testing backbone designed for organizations that require deterministic verification, full audit trails, and regulatory compliance enforcement. It bridges the gap between development-time validation and production-readiness, enabling structured quality gates that align with enterprise DevOps pipelines. The Kit's emphasis on exact response matching, topic validation, and orchestration plan verification makes it essential for mission-critical deployments where agent behavior must be predictable, traceable, and compliant.

Direct comparison

Dimension	Agent Evaluation (GA)	Copilot Studio Kit
Where it lives	Built into Copilot Studio UI	Separate Power CAT solution
Primary purpose	Behavioral validation	Functional verification
Setup effort	Minimal	Higher (Dataverse, AI Builder, App Insights optional)
Test creation	Manual, import, AI‑generated	Manual + Excel bulk
AI‑assisted scoring	Yes (core feature)	Yes (Generative Answers via AI Builder)
Deterministic checks	Limited	Strong (exact match, topic, attachments)
Multi‑turn scenarios	Not explicitly documented	Explicitly supported
Orchestration plan validation	Not documented	Explicitly supported
CI/CD & quality gates	Implicit / API‑based	Explicit pipeline integration
Governance & compliance	Not in scope	First‑class feature

How they relate (this is the key insight)

Microsoft is not replacing the Copilot Studio Kit with Agent Evaluation.
Instead, the sources show a clear layering strategy:

Agent Evaluation
→ Fast, AI‑assisted, in‑product validation
→ Ideal for early feedback, iteration, and continuous confidence
Copilot Studio Kit
→ Deep, deterministic, automatable verification
→ Ideal for release gates, regression testing, orchestration correctness, and governance

This positioning is also explicitly reflected in community and Microsoft guidance that frames Agent Evaluation as filling the gap that manual testing cannot scale, while the Kit remains the system‑level quality backbone.

Practical takeaway for enterprise teams

Based on what is explicitly documented:

When to use each tool

Agent Evaluation is best suited for:

Rapid iteration cycles during agent development
Early-stage quality validation before formal review
Continuous behavioral checks without infrastructure complexity
Scenarios where AI-assisted, semantic evaluation is sufficient
Teams prioritizing speed of feedback over deterministic guarantees
Questions like: "Is this agent generally behaving well after my last change?" → Use Agent Evaluation.

Copilot Studio Kit is best suited for:

Production release gates and formal deployment approval
Regression testing before pushing updates to production
Regulatory and compliance-driven scenarios requiring audit trails
Mission-critical agents where deterministic verification is mandatory
Complex orchestration scenarios requiring plan and tool invocation validation
Multi-turn conversations that need end-to-end correctness
Questions like: "Did we break anything? Are the topics correct? Are the tools invoked? Can this ship?" → Use the Copilot Studio Kit.

How they complement each other

In mature setups, the tools are complementary, not competitive:

Development phase: Agent Evaluation provides fast feedback loops for iteration
Pre-production phase: Copilot Studio Kit enforces deterministic verification gates
Production phase: Both tools support continuous monitoring—Agent Evaluation for behavioral trends, the Kit for functional regression detection
Governance phase: The Kit's compliance and KPI tracking provide the enterprise audit trail and policy enforcement layer

Organizations scaling from single-agent projects to enterprise deployments should expect to adopt both tools at different maturity stages, using them in sequence rather than as either/or choices.

Conclusion

Agent Evaluation and the Copilot Studio Kit represent Microsoft's thoughtful answer to the agent testing maturity curve. As organizations build, iterate, and scale agents from proof-of-concept to mission-critical systems, both tools play essential roles at different stages of the lifecycle.

Agent Evaluation brings quality validation into the authoring experience, reducing friction in everyday iteration and making behavioral confidence accessible to all agent makers. Its AI-assisted approach acknowledges the reality of rapid development cycles and the need for fast feedback loops.

The Copilot Studio Kit, by contrast, provides the deterministic backbone that enterprises require—exact verification, governance enforcement, regulatory compliance, and the audit trails necessary for mission-critical deployments.

The key insight is that these tools are not competitors but complementary. Teams should adopt them in sequence, starting with Agent Evaluation during development for rapid iteration, then layering in the Copilot Studio Kit as the agent approaches production. Organizations serious about agent quality at scale will ultimately adopt both, using them to build confidence at every stage from ideation to production and beyond.