The agentic platform market has split into planes

Gartner's first Hype Cycle for Agentic AI quotes three numbers: 17% of organisations already have agents deployed. More than 60% expect to deploy within two years. And more than 40% of agentic projects, Gartner predicts, will be cancelled by the end of 2027.

The third number matters most because of the reason Gartner gives: the projects will fail on integration and governance, not on model capability.

Gartner was not alone in that diagnosis. In its 2025 report "The GenAI Divide", MIT's NANDA initiative found that roughly 95% of GenAI pilots showed no measurable P&L impact. It drew on interviews, leader surveys and a review of more than 300 public AI initiatives. Its method has been challenged, and it looked at GenAI pilots rather than agents, but the diagnosis has held up: the pilots failed on integration, enterprise readiness and fragmented data governance, not on the models. Gartner makes a related point about the vendors: of the thousands now selling "agentic AI", it estimates only around 130 offer the real thing.

MITRE got there from the security side. Its first ATLAS update of 2026 moved the threat framework from how agents reason to how they act: runtime access, tool invocation and delegated authority. That is where incidents now happen. A value study, a market taxonomy and a threat model are very different tools, and all three say the same thing: the models are ready, but the way companies run and govern them is not.

That matches what I see in European enterprises, and it explains why the question buyers have asked for two years no longer makes sense.

It is also where the EggAI meta-framework whitepaper we published last year left off. That paper told engineering teams how to build enterprise-grade multi-agent systems: which components to use, how they connect and how to keep them at production quality. It did not cover a question the market had not yet raised: once agents run on several platforms at once, who governs them, and who can be trusted to say what they did? This series is about that question.

The question that no longer fits

Through 2024 and 2025 the buying question was: which agent platform should we standardise on? It was a sensible question at the time. It assumed that agents, like ERP or CRM before them, would live in one place.

They do not. Look inside any real enterprise estate in late 2026 and you find agents on several runtimes at once: some on a hyperscaler agent service, some built on an open-source framework running on Kubernetes, some shipped inside an application vendor's suite, and a growing number built on low-code tools by people who would not call themselves developers. Nobody was being careless. Each agent had a sound business case and went onto whichever runtime was closest to hand.

These estates have plenty of places to build agents. What none of their runtimes offers is one place to know what agents exist, what they are allowed to do and what they did.

The analysts now have a name for it. Forrester defined it in December 2025 as the agent control plane, a third functional plane sitting outside both the build and the orchestration layers. Gartner separates agent management platforms and agentic AI governance from agent development platforms. Both definitions cover the same ground: inventory and identity, policies and guardrails, monitoring and insight, control and coordination, and risk, compliance and audit.

In other words, the agentic platform market has split into three planes: a build plane where agents are created, an orchestration plane where they run and coordinate, and a control plane that is supposed to govern both. Once you see the market this way, the vendor announcements of 2026 are easy to sort.

This split will look familiar to readers of the concept stack we published a few weeks ago. The EggAI Agentic Architecture Doctrine sets out nine principles an enterprise agent estate must meet. The Reference Frame is the versioned architecture that meets them, built around an agent control plane, evidence classes and seam mechanics. The Bindings map that architecture onto specific jurisdictions and vendor stacks. It describes where the control boundaries should sit. Its registry, policy, enforcement and evidence components still have to be built and verified in each deployment. The analysts and the Doctrine reach the same conclusion from opposite directions. Most of the Doctrine's principles are enforced in what Forrester and Gartner now call the control plane. The Frame puts that plane outside build and run, because a principle cannot be enforced from inside the environment it constrains. Build, orchestration and control are a way to read the market. The Reference Frame goes further and splits the control function into management, hot-path control and forwarding. This series makes the argument at the market level, and the concept stack makes it at the architecture level.

The hyperscalers: complete planes, tightly coupled

Microsoft, Google and AWS each now ship all three planes. Microsoft has the Foundry Control Plane for the build estate, Agent 365 for the enterprise estate, and Entra Agent ID for agent identity. Google's Gemini Enterprise Agent Platform offers cryptographic agent identity, an agent gateway and registry, a semantic governance policy engine, regional residency controls and ISO/IEC 42001 certification. Since September 1st, it meters agents themselves, per session and per memory. AWS Bedrock AgentCore's runtime has been generally available in Frankfurt and Ireland since August, and comes with Identity, Policy (written in Cedar), Gateway, Observability and Evaluations.

These are capable control planes, so their limits are worth looking at closely. All three are tied to the vendor's own identity system, tenancy and runtime. Your agent inventory lives in the vendor's tenant, under the vendor's policy model, and the party vouching for it is the same one running the workloads. The pricing differs in detail. Google meters agents per session and per memory, and AWS meters the runtime. Microsoft prices Agent 365 per user with capacity tiers and no consumption charges yet, while the rest of its stack is metered in Copilot Studio credits. The effect is the same in each case: the vendor's price list sets what your agent estate costs, and the vendor can change it. So picking one of these control planes is not only a governance decision. It also hands cost forecasting and cost control to the vendor. Their sovereignty options (EU regions, data boundaries, sovereign-cloud offerings) meet the formal regulatory minimum, but they are still subject to the US CLOUD Act. You get the control plane that comes with the cloud, and you can only leave it by leaving the cloud.

The application platforms: registries inside the vendor

SAP introduced the AI Agent Hub in May 2026, building on LeanIX. It discovers AI assets across Microsoft, Google, AWS, ServiceNow and SAP AI Core, and applies a verification badge that controls which agents are approved in connected runtimes. ServiceNow's AI Control Tower governs agents that touch ServiceNow and lets external agents call governed actions through Action Fabric. Salesforce, Databricks and Snowflake follow the same pattern.

If SAP or ServiceNow runs most of your estate, these registries work well. But the record lives inside the vendor, under the vendor's policy model, and governance stops at the vendor's perimeter. Governing your agents from inside SAP adds one more system you would have to migrate off, and the agents that matter most rarely stay inside one suite.

The independents: closest to the idea, each shaped by its origin

A third group entered in 2026. Thoughtworks Agent/works offers a control plane and governed runtime across any cloud, checks compliance before execution, and grants permissions that are capability-based, scope-bound and time-limited. Boomi's Agent Control Plane connects agents to enterprise systems, governs actions and access, controls token spend, inspects live traffic and holds high-risk transactions for human review. Datadog is approaching the control plane from observability, and Drata from compliance automation.

Where a vendor started shapes what its control plane covers and what it leaves out. A vendor that came from connectors governs connections well. One that came from observability sees a lot, so ask how much it can block. One that came from consultancy delivers projects well and turns them into products late.

Even in this group, independence has limits. Thoughtworks bundles its own runtime with the control plane, so the same vendor governs the agents and runs them. As far as I know, none of the platforms reviewed here ships supply-chain governance (SBOMs, advisory matching, signed releases) across the whole agent estate. And none is run as a managed service by a company under EU jurisdiction. An EU-hosted region run by a US company is still within reach of the US CLOUD Act, and that matters as soon as the records it holds become evidence a European regulator asks for.

The planes that are not competitors

Two more groups complete the picture, though neither is a competitor here. The EU build platforms and frameworks (Mistral AI Studio, the Cohere/Aleph Alpha PhariaAI platform, deepset Haystack, LangChain and LangGraph with LangSmith) and agent runtimes such as McKinsey's ARK or Veryfront are places where agents are built and run. They are part of the estate that needs governing. The sovereign cloud providers and integrators (STACKIT, OVHcloud, IONOS, T-Systems, Sopra Steria, Atos/Eviden) supply infrastructure, capacity and delivery work. None of them is a control plane.

For both groups, the question that matters is which control plane can see them.

The question to ask instead

So when the next "agentic platform" lands on your desk, ask a different question: which plane is this, and who owns each plane in our estate today? Who holds the inventory of agents across all our runtimes? Whose policy model applies to an agent that touches SAP, runs on AWS and was built in LangGraph? And now that Google and AWS meter agents directly and Microsoft prices them per user, whose pricing model does each plane run on?

When you map your own estate against the three planes, you will usually find the build and orchestration planes crowded. The control plane, which the analysts say must sit outside the other two, is either missing or owned by a vendor who also owns one of the planes it is supposed to govern.

For a European reader, "evidence a regulator will ask for" is meant literally. The EU AI Act's record-keeping and logging duties (Article 12) and its transparency obligations (Article 50) are enforceable now, and DORA is in active supervision. Both laws assume you can produce a trustworthy account of what your systems did. Whichever plane holds that account must be able to pass an audit of its own independence.

One disclosure before the closing question. EggAI builds an independent control plane, so an analysis that ends at the control plane is convenient for me. The analyst definitions are public, so you can check my sorting against them. Several vendors reviewed here now market control-plane capabilities, and each of them attests its own output. Whether that can work is the subject of the next post. The Doctrine's first principle, independent attestation, exists to answer that question: who attests the attester?