At least five products in a typical enterprise IT stack now claim to be the control plane for AI agents.
- Productivity suite: Microsoft Copilot Studio is “the control plane for AI agents.”
- Workflow: ServiceNow is “the AI control tower for the enterprise.”
- Data: Databricks and Snowflake are each a “control plane for enterprise AI.”
- Cloud runtime: AWS Bedrock AgentCore runs “any framework, any model.”
Meanwhile, your developers are already running Claude Code, Cursor and GitHub Copilot every day, and nobody filed a request for a control plane before they started.
The leadership team is not asking which vendor is right. It is asking harder questions. Which needs do we meet centrally, through the functions, or by letting employees build? What do we standardize and what do we leave flexible? How are creation, access, sharing, execution and ownership governed over time? And what roles do the platforms we already own play, and when is yet another orchestration layer warranted?
This post lays out the framework we use with CIOs to answer those questions. Choose the workflows first, then work through four steps that all key off one classification. Everything else, including which vendor’s “control plane” you anchor on, follows from that.
Agentic orchestration is three things, and vendors sell only one of them
The term is doing too much work. At least five meanings circulate in analyst and vendor material: runtime coordination between agents, an enterprise management layer, workflow automation relabeled (what Gartner calls “agent washing”), an architectural paradigm (McKinsey’s “agentic AI mesh”), and humans managing fleets of agents. Gartner’s 2026 governance Hype Cycle files “agent orchestration” under governance at under 1% penetration. Almost nobody has it, whatever it is.
Our working definition: agentic orchestration is the enterprise capability that makes many agents, built by many people on many platforms, behave as one governed system in service of the workflows the business has chosen. It has three layers, and it helps to keep them apart.
Runtime coordination is how an agent calls tools and other agents to finish a task: supervisor agents, chains, agent-as-tool. It is mostly a per-platform engineering choice. It is also where most documented failures originate. UC Berkeley’s MAST study traces roughly 78% of multi-agent failures to specification and inter-agent coordination, not to model capability.
Enterprise control is inventory, identity, policy, monitoring and audit across every agent, wherever it runs. Forrester describes it as a control plane that “inventories, governs, orchestrates and assures” heterogeneous agents, and notes that governance “must sit outside” the build and orchestration planes. This is the layer the vendors above are competing to own.
The operating model is who may build, configure, use and own agents, under what conditions: decision rights, risk tiers, intake, ownership transfer, decommissioning. Only 21% of organizations report a mature model for governing autonomous agents, in a Deloitte survey of 3,235 respondents. No product supplies this layer. It has to be designed by your leadership team, and the rest of this post is a framework for doing that.
Workflows first, then four steps off one classification
The sequence matters more than any single step. Governance protects the downside. Workflow redesign and business ownership are where the value is, and a governance framework adopted without the workflow step behind it is Gartner’s forecast in waiting: projects cancelled for “unclear business value.”
So the first step is choosing which workflows to redesign and who owns each outcome. The next four are classification (tier every agent by data sensitivity, autonomy and reach), delivery model (let the tier cap how the agent is built and who owns it), standards (fix the interfaces between agents and the enterprise, leave implementations flexible), and control (assign each control function to the platform with leverage, and add a layer only against a named gap).
Step 1: Choose the workflows and name the owners
The evidence on this point is unusually consistent. In McKinsey’s 2026 State of AI survey, high performers are nearly three times likelier to have fundamentally redesigned workflows (74% versus 25%), the strongest correlate of value in the study. Gartner finds that organizations whose IT, business and leadership agree on what AI should solve are three times likelier to report significant value, and only 14% strongly agree that they do. And the counter-evidence is just as clear: 37% of organizations attribute any EBIT impact to AI, flat year on year, while 40% of large organizations are now scaling agents somewhere. Scaling without redesign is not producing returns.
Fewer than 10% of deployed use cases pass pilot under the center-of-excellence model. McKinsey’s practitioners, after more than fifty builds, put their first lesson simply: “it’s not about the agent, it’s about the workflow.”
What the leadership team settles here is modest in scope and large in impact. Agree with the business what to solve: a short list of workflows ranked on impact, effort and risk, not a list of agents. Redesign rather than automate in place; rework the handoffs, approvals and data flows so an agent has a place to stand, because automating a broken workflow scales the breakage. Name a business owner accountable for the outcome and the run cost, with the central team accountable for operating shared services. Agree outcome metrics before the build, and make token and gateway spend visible; only 26% of organizations have real-time AI cost visibility, per KPMG. And check the registry before any build. The best use case is the reuse case.
Step 2: Tier every agent by what it can touch, not by who built it
The incidents on record (EchoLeak, the Copilot Studio and ServiceNow agent-discovery cases, Agentforce, the GitHub MCP exposure, Replit) share one pattern: default configurations and over-broad permissions, not model failure. The ServiceNow and GitHub MCP incidents in particular were agents whose effective risk tier rose through configuration with no reclassification. Classification is the control that would have caught them.
We use four tiers, set by data sensitivity, autonomy and reach. Gartner’s agent risk profiles use data sensitivity and autonomy; the CISA/NSA guidance of May 2026 and AWS’s Agentic AI Lens tier oversight by reversibility. The tiers below combine those dimensions.
| Tier | Profile | Typical examples | Oversight |
|---|---|---|---|
| Tier 1 Personal productivity |
Read-only or draft-only; inherits the user’s existing permissions; no new connectors; individual or small-team audience | Q&A over a team site; copy drafter over approved brand assets; a data question answered in a data agent or CoWork | Owner self-review; platform-level policies only |
| Tier 2 Team workflow |
Team-scoped; approved connectors; reversible actions with human approval; limited customer data | Draft a quote from CRM for rep approval; triage tickets and propose assignments; route an invoice exception | Named owner; functional lead approval; managed environment |
| Tier 3 Governed enterprise workflow |
Cross-system; customer or partner data; writes to systems of record; acts on exception approval | Quote-to-cash agent posting orders; recommendation agent over customer data; incident agent executing runbooks | Central or joint delivery; architecture, security and privacy review; evaluation gate; audit trail |
| Tier 4 Restricted |
External-facing; autonomous or irreversible actions; regulated data or compliance exposure | Customer-facing ordering or claims agent; pricing or payment changes; regulatory output | Executive sponsor; governance review before pilot; kill switch; continuous monitoring |
Three rules make the tiers work in practice. Assign the tier at intake, with a common set of questions asked wherever the agent is built. Re-tier whenever connectors, actions or audience change, because that is exactly how the incidents above happened. And tier by the agent’s profile, never by the builder or the platform. A marketer’s agent and an engineer’s agent that both write to a system of record are both Tier 3.
Step 3: Let the tier cap the delivery mode
There are three pure delivery models, and the evidence is against each of them on its own.
All central delivery, where IT builds and runs everything, gives the highest control and the clearest ownership. But fewer than 10% of use cases pass pilot under the CoE model, 59% of organizations already have unsanctioned use, and the central team becomes the bottleneck that shadow agents route around. McKinsey’s verdict: the CoE “reaches its limits in the agentic era.”
All self-service, where employees build what they need, is the fastest to adopt and closest to the work. The sprawl numbers follow directly from it: agents up fifteen-fold in a year in M365, a Gartner forecast of 150,000 agents at an average Fortune 500 enterprise by 2028, 60% of vibe-coded apps retired by 2028, and the RPA record of weekly bot breakage at firms unable to size their own estate.
All federated to functions, where each function owns its agents, is closest to the workflow, and workflow redesign is the strongest value correlate. But functions duplicate (Walmart collapsed “dozens” of agents into four), apply inconsistent controls, and lack the engineering to evaluate or operate Tier 3. Gartner expects 70% to abandon vendor-built agentic systems they cannot evolve.
The resolution is not to pick one. Set the mix per tier, with the tier capping the maximum delivery mode and carrying the ownership obligations that come with it.
| Tier | Maximum delivery mode | Ownership and lifecycle |
|---|---|---|
| Tier 1 | Create: employee self-service on the suite’s maker tools (Copilot Agent Builder, Gemini, CoWork skills, data-platform self-service agents) | Creator is owner; inventoried automatically; auto-expiry on inactivity; sharing beyond the team steps it up to Tier 2 |
| Tier 2 | Configure: function-owned on an approved platform’s sanctioned tier (Copilot Studio managed environment, a governed data agent, a ServiceNow or Agentforce agent) | Named business owner accountable for outcome and run cost; its own agent identity; approved connector set; owner transfer on departure; annual re-certification |
| Tier 3 | Configure jointly with central engineering, or Use | Business owner accountable for outcome and run cost, central team for operation; evaluation gate before production; traces logged |
| Tier 4 | Use: centrally delivered | Executive sponsor; governance board review; kill switch tested; incident response defined |
What moves the line in a given enterprise: regulatory exposure, whether the platform’s governance controls are actually licensed and turned on, the maturity of the data foundation (self-service data agents only work over a governed semantic layer), engineering capacity in the functions, and existing shadow use, which argues for sanctioning Tier 1 quickly rather than pretending it is not happening.
Above Tier 1, three rules apply everywhere. Every agent has a named human owner, enforced by the directory. Reuse comes before build. And decommissioning is a first-class lifecycle state. The central team’s job changes accordingly: shared services, workflow selection and measurement, not building.
Step 4: Standardize the interfaces, leave the implementations alone
Forrester: “your AI platform strategy will be a portfolio, not a monolith.” Gartner: it is “too early to rely on a single vendor for an AI agent strategy.” McKinsey’s mesh principles say the same in architecture terms: layered decoupling and vendor neutrality. Already 37% of CIOs run five or more models. That is not a problem to be fixed. It is the shape of the estate.
What you standardize is the set of interfaces between any agent and the enterprise. Agent identity: one directory of record with human sponsors and least-privilege scopes, federated by OAuth on-behalf-of into the data and cloud platforms. The tool and connector catalog: approved MCP servers published once and consumed everywhere, with unapproved ones hidden from builders. MCP is the only bridge every platform supports, which is why governing the MCP door matters as much as it does. Data semantics: one canonical definition per metric and entity, so every self-service data agent answers from the same place. Traces and evaluation gates: a common trace store and a minimum evaluation standard before anything at Tier 3 reaches production. Intake and registry metadata: the same intake form and risk questions wherever the agent is built. Model access and budgets: sanctioned models through gateways with spend caps.
What you leave flexible is everything inside a platform: the model, within the sanctioned set; the framework and harness (AgentCore, Foundry, Vertex AI and Agent Bricks all accept the major ones); which platform a function builds on, settled by a published decision tree given tier and workflow; the surface, whether Copilot, Teams, Slack, CoWork, Genie One or a ServiceNow portal; prompts and instructions, owned by the business owner; and the runtime pattern, supervisor, chain or single agent with tools, chosen per workflow.
Step 5: Enforce where you already have leverage, and add a layer only against a named gap
Each control function is enforceable where a platform has leverage, and each platform covers only part of the map. The table below maps the five platform categories most enterprises already own against the five control functions, using the leading vendors in each category as the reference point.
| Control function | Productivity suite Microsoft 365 Copilot, Google Workspace |
Workflow and business apps ServiceNow, Salesforce Agentforce |
Data platforms Databricks, Snowflake, Microsoft Fabric |
Cloud runtimes AWS Bedrock AgentCore, Azure AI Foundry, Google Vertex AI |
Network security Palo Alto, Zscaler |
|---|---|---|---|---|---|
| Inventory and identity | Agent registry in the admin center; agent IDs in the directory (Entra Agent ID); cross-cloud registry sync mostly in preview | ServiceNow discovers agents across AWS, Azure, Vertex, Salesforce, Databricks and Snowflake and publishes into the suite’s registry; Agentforce inventories its own agents in Command Center | Catalog registers agents, tools and MCP services with cryptographic agent identity (Unity Catalog, Horizon); Fabric data agents run under the requesting user’s identity | Agent registries with approval workflow (AgentCore Registry, Foundry control plane, Vertex Cloud API Registry for tools); identity federated to Entra or Okta, or native Entra Agent ID | Discovery of shadow AI and SaaS-platform agents (AI asset management, AI-SPM); not a lifecycle registry |
| Policy and guardrails | DLP and managed environments; connector governance covers MCP; sensitivity labels | Steward approval gates for MCP servers and model providers, enforced in tooling (ServiceNow); MCP access governed by existing security and API policies (Agentforce, MuleSoft) | Gateway service policies, tool filtering, budgets with hard caps; Purview DLP on Fabric sources | Policy services and guardrails on inputs, tool calls and outputs; gateway rate limits; admin-curated tool registries | Gateway policy on LLM, MCP and A2A traffic; runtime tool blocking; allow, block, warn or isolate by role and app risk |
| Monitoring | Agent traces; endpoint agent detection (preview) | Agentic threat monitoring (detections, not blocks); OpenTelemetry signals to Datadog or Splunk | Payload logs to tables; SIEM-ready traces; built-in diagnostics on source selection | OpenTelemetry traces from inference through tool calls; evaluations before production and continuously on live traffic | Runtime security; per-request cost and token telemetry |
| Coordination | Connected agents; A2A GA; no tenant-level admin control over A2A documented | Native orchestrators; A2A in and out, but ServiceNow’s AI gateway does not govern A2A; Agentforce A2A via MuleSoft | Supervisor agent over data agents and MCP tools; data agents exposed to external orchestrators; no native A2A | MCP and A2A supported; agent-as-tool the recommended cross-platform pattern | None; traffic layer only |
| Audit and compliance | Audit and eDiscovery of agent activity | Compliance packs (EU AI Act, state acts); session-tracing data model in Data Cloud | Lineage and access logs; Purview audit on Fabric (preview) | CloudTrail, Azure Monitor and Purview, Cloud Audit Logs | Gateway logs |
Illustrative mapping of documented capabilities as of September 2026, drawn from the leading vendors in each category. Specifics vary by vendor, and several cross-platform integrations are preview; verify before relying on any one of them.
Read across the rows and the pattern is clear. Every category has a registry, and none is complete. Every platform enforces policy on what it builds, and the seams between them are where coverage drops. The coordination row is the most telling: the productivity suite ships agent-to-agent with no documented tenant-level admin control, the workflow platform’s AI gateway does not govern A2A at all, and the security gateway sees traffic but coordinates nothing.
Given that map, there are four ways to assemble enterprise control.
Platform-native only. Each platform governs what it builds; IT aggregates the reports. Fits when one or two platforms dominate and agents answer rather than act. The risk: nobody sees a Tier 3 chain that crosses platforms.
Anchor on one incumbent. One platform is the registry of record for inventory, owner and tier; the others enforce natively. This is the realistic 2026 design for a mid-size enterprise; match the anchor to the estate’s center of gravity. The risks: preview debt, layered licensing, and the registry becoming the vendor’s lock-in point.
Add a neutral control plane. A vendor-neutral registry and gateway. Forrester tracks 33 vendors in the category and reports 40% of enterprises with active RFPs. Fits when a specific cross-platform enforcement gap cannot be closed natively. The risk: a fourth registry to reconcile and another set of previews. Not a first move.
Build the mesh. Your own composable layer with registry, gateway and observability. Fits a large platform-engineering team with a strategic reason to own the layer. For most, the expensive version of the previous option.
Our recommendation: name a registry of record now, usually an incumbent; enforce natively where each platform has leverage; and agree in advance the triggers that would justify a neutral layer. Those triggers are concrete: the first Tier 3 workflow that spans two platforms, the first production agent-to-agent call across vendors, coding agents in production outside the productivity suite, a regulator or auditor asking for agent-level evidence, or agent and platform counts outrunning the native inventories.
Three runtime rules follow from the failure evidence. Keep chains inside one platform per workflow. Cross platforms by agent-as-tool over MCP. Limit chain depth and give one agent the final say.
One agent, three governance paths
The framework is easiest to see on a single agent as it grows. A marketer builds a copy drafter in Agent Builder over approved brand assets in SharePoint. It drafts only. That is Tier 1: employee-created, inheriting the maker’s permissions, no review beyond platform defaults, inventoried automatically and expired if unused.
Marketing then wants it to pull segments from the CDP for personalization. Customer data and a new connector step it up a tier. It moves to Copilot Studio in a managed environment, gets a named owner, an approved connector and its own agent identity. Tier 2, edging toward Tier 3 depending on how much customer data it reads.
Then someone asks why it cannot just post the finished copy to the CMS autonomously. A write action to a system of record is Tier 3: joint delivery with central engineering, an evaluation gate, traces logged, run cost budgeted, rollback defined.
Same agent, three governance paths, determined by impact and never by the fact that a marketer built it. Two more cases take the same shape. The customer question (“who bought product Y last season and has not reordered?”) is answered by a data agent over the semantic layer and exposed as an MCP tool into the productivity suite, so the rep asks in Teams. The data platform owns the answer, the productivity platform owns the surface, and nobody builds a second data agent in Copilot Studio. And coding agents are agents with write access to source and sometimes to infrastructure. They get their own policy (sandboxing, egress controls, no production credentials, a registry entry) rather than being waved through as “developer tools.”
Ninety days: policy before tooling, one workflow before generalizing
The sequencing we recommend fits in a quarter, and it deliberately sets policy before it touches tooling.
Days 0 to 15, decide. Choose the workflows with the business and name an owner for each. Adopt the tiering and the tier-to-mode rule as leadership policy. Publish the intake questions and who assigns a tier. Name the registry of record.
Days 15 to 45, switch on. Turn on what is already licensed: managed environments, agent identities, DLP for connectors, model gateways with budgets. Inventory sanctioned and unsanctioned agents, name owners, retire orphans. Publish the approved connector and MCP catalog and the platform decision tree.
Days 30 to 75, prove. Redesign and ship one Tier 3 workflow that crosses platforms. Test the seams: identity federation, MCP exposure, trace collection. Measure the outcome and the run cost.
Day 75 onward, operate. Open Tier 1 self-service broadly, with auto-inventory and expiry. Agree the triggers for a neutral control layer. Run a quarterly review of outcome and run cost per workflow, agents by tier, owners named, incidents, and reuse rate.
What the evidence actually says
A note on the numbers, because the agentic market is awash in weak ones. We have not used the widely quoted “95% of AI pilots fail” figure from MIT NANDA, which rests on 52 interviews and 153 conference surveys with an undisclosed instrument. The figures we rely on come with sample sizes attached: McKinsey (n=1,719), Gartner (n=360), Deloitte (n=3,235), Menlo Ventures (n=495), and Berkeley’s MAST analysis across seven agent frameworks. Gartner’s 150,000-agent figure is cited as a forecast, method undisclosed. Two more are worth a line each. Menlo Ventures finds that only 16% of enterprise “agent” deployments actually plan, act, observe and adapt. And in NIST’s CAISI red-teaming competition, all thirteen frontier models tested were hijacked at least once, across 400-plus participants and more than 250,000 attempts.
Put together, the evidence says three things. Scaling is a minority practice. Sprawl is the trajectory. And the failures on record are design failures, in specification, coordination, configuration and permissions, not model failures. That is the case for treating agentic orchestration as an operating model you design rather than a product you buy. The agents are already in the building. The question is whether the operating model around them has been built.
Sources
- McKinsey, The State of AI 2026 (n=1,719, mid-2026); McKinsey practitioner findings from 50+ agent builds
- Gartner, AI value alignment survey (n=360, 2025); Gartner agent forecast, April 2026; Gartner 2026 Hype Cycle for AI governance; Gartner agent risk profiles
- Deloitte, autonomous agent governance survey (n=3,235)
- Forrester, enterprise AI control plane and AI platform portfolio research
- UC Berkeley, MAST: Why Do Multi-Agent LLM Systems Fail? (NeurIPS 2025)
- NIST CAISI, agent red-teaming competition results, March 2026
- KPMG, AI cost visibility findings
- Menlo Ventures, enterprise agent deployment survey (n=495)
- a16z, CIO survey on model usage
- CISA/NSA, guidance on AI agent oversight, May 2026; AWS Well-Architected Agentic AI Lens
