Skip to content

Portal Walkthrough: Control 2.17 — Multi-Agent Orchestration Limits

Last Updated: April 2026 Portals: Copilot Studio, Power Automate, Power Platform Admin Center (PPAC), Application Insights Estimated Time: 2–4 hours per orchestration pattern (initial); ~30 minutes per quarterly review Audience: AI Governance Lead, Power Platform Admin, Copilot Studio Agent Author

Design patterns, not platform-enforced controls

Copilot Studio does not natively enforce delegation depth limits, circuit breakers, financial stop-loss caps, or HITL checkpoints. The portal steps below configure the building blocks (topics, variables, Power Automate flows, telemetry); the limits themselves are enforced by the orchestration logic you author. Treat this playbook as a design and configuration aid — not as a one-click compliance switch.

Sovereign cloud (GCC / GCC High / DoD)

Replace https://copilotstudio.microsoft.com with your government cloud equivalent (e.g., copilotstudio.microsoft.us for GCC High). Confirm the current URL in the Microsoft 365 admin center before each session — sovereign-cloud URLs change less often than commercial but are not interchangeable.

Prerequisites

  • Roles:
    • Power Platform Admin (PPAC tenant settings, environment governance)
    • Environment Admin on each environment hosting orchestrating agents
    • Copilot Studio Agent Author on each agent in the delegation chain
    • AI Governance Lead sign-off on the proposed delegation graph and limits
  • Inventory artifacts:
    • Agent inventory (Control 2.1) listing every agent in the proposed orchestration
    • Zone classification per agent (Control 2.2)
    • Combined Model Risk Card if any agent in the chain is in Zone 3 (Control 2.6)
  • Approved limits documented in writing (delegation depth, circuit-breaker thresholds, financial stop-loss caps, HITL trigger conditions) — these are governance decisions, not defaults
  • Application Insights (or equivalent SIEM) workspace provisioned and connected to the environment for custom telemetry
  • Power Automate premium licensing for any flow that calls non-Microsoft endpoints (HTTP connector) or Dataverse-backed circuit-breaker state

Step 1: Document the Orchestration Graph (Before Any Configuration)

Configuration without a documented graph creates audit gaps. Produce a named delegation graph for each orchestration pattern:

  1. List every agent that may invoke another agent (parent → child).
  2. For each edge, record: invocation mechanism (A2A, MCP, Power Automate flow, direct tool call), expected payload class (PII / MNPI / public), and zone of each agent.

  3. Compute the maximum potential depth of the graph and confirm it does not exceed the per-zone limit recorded in the control:

    Zone Max delegation depth Notes
    Zone 1 (Personal) 0 Single-agent only; delegation is a design violation
    Zone 2 (Team) 2 Circuit breaker required; interactions logged
    Zone 3 (Enterprise) 3 Full telemetry, HITL on customer-impacting steps, financial stop-loss

  4. Store the graph as evidence (PNG / Mermaid / Visio) under your control evidence folder using the naming convention in Verification & Testing.

Use Microsoft Foundry agent diagrams

For agents authored in Microsoft Foundry, the Workflow designer surfaces a built-in graph view that exports to PNG. This is preferable to hand-drawn diagrams because it stays in sync with the deployed agent.

Step 2: Configure Per-Agent Tool and Connector Inventory

Each Copilot Studio agent supports up to 128 tools (connectors, plugins, MCP tools, child agents). Plan multi-agent architectures with this constraint in mind.

  1. Open Copilot Studio.
  2. Select the orchestrating agent → Tools (or Actions in older tenants).
  3. Record the current tool count and remaining headroom for each agent in the chain.
  4. Where tools are reused across multiple agents, package them into a Component Collection (GA) so updates propagate consistently and audit evidence references a single artifact.
  5. For child agents invoked via Agent-to-Agent (A2A) or Microsoft Foundry: list the child agent under the parent agent's tools and record the child's environment, zone, and owner.

Step 3: Implement Delegation Depth Tracking

Depth tracking is the foundation of every other control in this playbook. Without it, circuit breakers, stop-loss, and HITL cannot reliably scope to a single orchestration chain.

Pattern A — Conversation-scoped depth (single-environment chains):

  1. In the root agent, create a topic-level variable Topic.OrchestrationDepth (Number) initialized to 0.
  2. Before any delegation node (Tool call, child agent, A2A handoff), add a Set variable node: Topic.OrchestrationDepth = Topic.OrchestrationDepth + 1.
  3. Add a Condition node: if Topic.OrchestrationDepth > <max-for-zone>, route to a Send a message node returning a structured error and exit the topic. Log the violation (Step 6).
  4. Pass Topic.OrchestrationDepth as an input parameter on every child invocation so the child can continue tracking.

Pattern B — Correlation-ID-scoped depth (cross-environment chains):

  1. Generate a correlationId (GUID) at the root agent on first invocation.
  2. Persist {correlationId, currentDepth, startedUtc} in a Dataverse table (fsi_OrchestrationState) accessible to every environment in the chain.
  3. Each agent reads the row, increments depth, and writes back atomically (use a Power Automate flow with the Update a row action and the If-Match ETag header to detect concurrent updates).
  4. Add a row-level retention policy aligned to your audit-log retention (typically 6–7 years for FSI).

Cross-environment chains add operational risk

Pattern B introduces a Dataverse dependency on the critical orchestration path. Document the failure mode (Dataverse outage → orchestration blocks) in your incident-response playbook and validate the behavior in pre-production.

Step 4: Implement Circuit Breaker (Power Automate)

Copilot Studio has no native circuit breaker. Implement one as a Power Automate flow invoked before each delegation:

  1. Create a solution-aware flow fsi-CircuitBreaker-Check in the orchestration environment.
  2. Inputs: targetAgentId, correlationId.
  3. Steps:
    • Get rows from a fsi_CircuitBreakerState Dataverse table filtered by targetAgentId.
    • If state == 'Open' and (utcNow() - openedUtc) < resetTimeoutSeconds, return {allow: false, reason: 'circuit-open'}.
    • If state == 'Open' and timeout elapsed, set state = 'HalfOpen' and return {allow: true, mode: 'probe'}.
    • Else return {allow: true, mode: 'normal'}.
  4. Create a companion flow fsi-CircuitBreaker-Record invoked after every delegation:
    • Input: targetAgentId, success (bool).
    • On failure, increment consecutiveFailures. If it reaches the threshold (default 3), set state = 'Open' and openedUtc = utcNow().
    • On success in HalfOpen mode, reset state = 'Closed', consecutiveFailures = 0.
  5. In each orchestrating agent topic, call fsi-CircuitBreaker-Check immediately before delegation; gate the delegation on allow == true.

Recommended thresholds (organization may tune):

Setting Zone 2 Zone 3
Per-call timeout 30s 30s
Total chain timeout 120s 90s
Consecutive-failure threshold 5 3
Reset timeout 120s 60s
Half-open probe attempts 1 1

Step 5: Configure Human-in-the-Loop (HITL) Checkpoints

For Zone 3 chains and any chain that touches customer-impacting actions, regulated data, or material financial decisions:

  1. Identify the specific orchestration boundaries that require human approval (do not approve the whole chain — approve at the boundary closest to the action).
  2. In the agent topic, add an Adaptive Card (Teams or in-channel) with Approve / Reject actions. The card must include:
    • correlationId (so the approver can trace the full chain)
    • Summary of the action requiring approval (max 200 chars; do not embed customer PII in the card body)
    • Reviewer attestation field
  3. Use Power Automate's Wait for an approval action with a configured timeout (recommend 4 business hours for customer-impacting actions; 24 hours for non-urgent reviews).
  4. On timeout: route to escalation (secondary approver group) — never silently proceed.
  5. Persist the approval decision (approverUpn, decision, decisionUtc, correlationId) to the same Dataverse table used for orchestration state, retained per Control 1.7.

Microsoft Agent Framework HITL primitives

Microsoft Agent Framework (preview as of April 2026) documents RequestPort / request_info() / response-handler routing for HITL. If your orchestration is built on Agent Framework rather than Copilot Studio topics, prefer those primitives over hand-rolled adaptive cards — they integrate with checkpoint persistence and event streaming for chain-of-custody evidence.

Step 6: Configure Orchestration Telemetry

  1. In each orchestrating agent, enable Application Insights under Settings → Advanced → Analytics.

  2. Add custom event emission at four points using the Send a custom event action (or via Power Automate calling the Application Insights ingestion endpoint):

    Event name Emit when Required custom dimensions
    Orchestration.DelegationStart Before child invocation correlationId, parentAgentId, childAgentId, depth, zone
    Orchestration.DelegationEnd After child returns correlationId, childAgentId, success, durationMs
    Orchestration.CircuitBreakerOpen When state transitions to Open correlationId, targetAgentId, consecutiveFailures
    Orchestration.HitlDecision After HITL checkpoint resolves correlationId, approverUpn, decision, waitDurationMs
    Orchestration.MCP.ToolInvocation Each MCP tool call correlationId, mcpServer, toolName, dataClassification

  3. Configure Application Insights → Alerts for: depth-limit violations, circuit-breaker opens, HITL timeouts, and MCP invocations on unapproved servers (cross-reference your approved MCP registry — see Control 2.17 § MCP Server Governance).

  4. Forward Application Insights events to Microsoft Sentinel (or your SIEM) for correlation with Copilot audit log events from Control 1.7.

Step 7: Configure MCP Server Allow-list (If Applicable)

If your orchestration uses MCP servers (Microsoft-built or custom):

  1. Maintain an approved MCP server registry (recommended: SharePoint list with columns mcpServerId, vendor, dataClassification, approvedZones, approverUpn, approvedUtc, nextReviewUtc).
  2. In Copilot Studio → agent → Tools → Add tool → Model Context Protocol, register only servers from the approved list.
  3. Capture the server URL, authentication method (OAuth 2.0 minimum; OAuth 2.0 + certificate pinning for Zone 3), and tool surface (specific tools enabled vs. wildcard).
  4. Add a Power Platform DLP policy (Control 2.14) blocking the MCP HTTP connector from being combined with non-business connectors in Zone 2/3 environments.

Custom MCP servers — preview status

Microsoft documents custom MCP servers in the 2026 Wave 1 release plan with public preview in March 2026 and GA targeted for April 2026. Confirm current GA status on Microsoft Learn before promoting custom MCP servers to production. For Zone 3, do not use preview features in customer-impacting orchestrations.

Configuration by Governance Level

Setting Zone 1 (Baseline) Zone 2 (Recommended) Zone 3 (Regulated)
Max delegation depth 0 2 3
Depth tracking pattern N/A Pattern A Pattern A or B
Circuit breaker Not required Required Required
Per-call timeout N/A 30s 30s
Total chain timeout N/A 120s 90s
Failure threshold N/A 5 3
HITL checkpoints None Optional Required for customer-impacting / financial / regulated-data steps
Telemetry Basic Copilot audit log Custom events to App Insights App Insights → Sentinel with real-time alerts
Combined model risk card Not required Not required Required (Control 2.6)
MCP server registry N/A Required if MCP used Required + monthly review
Quarterly orchestration review Optional Required Required + approver attestation

Validation Checklist

After completing the steps above, confirm the following before declaring the control implemented:

  • Delegation graph documented and stored as evidence
  • Depth tracking variable / Dataverse row exists in every orchestrating agent
  • Circuit breaker flows deployed and invoked in topic flows
  • HITL checkpoints configured at the action boundary, not chain entry
  • All five custom events emit with required dimensions
  • Sentinel / SIEM alerts wired for depth violations, circuit opens, HITL timeouts, unapproved MCP invocations
  • MCP server registry exists and is referenced by the DLP policy
  • Combined Model Risk Card written for Zone 3 chains (Control 2.6)
  • Quarterly review scheduled in your governance cadence (Control 2.12)

Run the Verification & Testing playbook against this configuration before promoting to production.

Back to Control 2.17 | PowerShell Setup | Verification & Testing | Troubleshooting