This post is a follow-up to my earlier announcement of our coverage of the agent control planes market. Research questionnaires for the Landscape report will formally go out in the second week of April 2026.

We are in the ‘dial-up Internet’ era of the agentic era. The architecture is emerging faster than the standards needed to make it work cleanly at enterprise scale.

In December 2025, I introduced Forrester’s view of the agent control plane as the third functional plane in an enterprise agentic architecture, alongside the build plane and the orchestration plane. The thesis is that, as enterprises deploy heterogeneous agents across vendors and domains, governance must sit outside both build and orchestration environments. Several vendors are building toward this framework. The architecture is sound, and vendor-agnostic control planes are inevitable. In late February I polled 47 tech vendors, and the results showed that:

  • 79% of participating vendors recognize agent control planes as a meaningful and distinct product category.
  • 92% have assigned a named product manager or team to agent governance or control plane functionality.
  • And 40% report active RFPs or customer buying motions that explicitly request a control plane or equivalent.

That said, enterprises today struggle to implement the control plane as a portable, vendor-agnostic governance layer, because the standards stack underneath it is incomplete.

Standards Lag Behind Architectural Best Practice

Forrester’s three-plane model decomposes the enterprise agentic ‘stack’ into three distinct planes: ‘build’, ‘orchestrate’, and ‘control’. The key hurdle to realizing a clean functional stack along this framework is that the connective tissue between planes, the standards and protocols that allow governance decisions in one plane to propagate reliably into another, remains underdeveloped. Three categories of standards gaps create three distinct barriers to making a consistent control plane operational at enterprise scale.

Barrier 1: Instrumentation Standards Are Incomplete

A control plane cannot govern what it cannot observe. The primary instrumentation standard for agentic AI telemetry is OpenTelemetry’s GenAI semantic conventions, which now cover model operations, agent creation and invocation, tool execution spans, evaluation events, and multimodal content. Recent releases added agent version attributes, retrieval span support, and cache token tracking. Datadog announced native support for GenAI Semantic Conventions at v1.37 and above in late 2025, allowing teams to instrument once with OpenTelemetry and export GenAI spans through existing collector pipelines. The momentum is building, but the conventions themselves remain experimental. The OpenTelemetry project has not yet published a stable version of the GenAI semantic conventions, which means every adopter builds on a moving target. More importantly, the current conventions address operational telemetry (spans, metrics, and traces for model calls and tool executions) but do not yet cover the full governance surface a control plane requires. Skill-level identity propagation, cost attribution traced to business value streams, and cross-orchestrator span correlation sit outside the current specification’s scope. Instrumentation standards can tell you what happened inside an agent’s execution but they cannot yet tell you who the agent was in governance terms, what business policy applied to it, or how interventions should propagate across platforms.

A parallel effort addresses the financial telemetry gap. The FinOps Foundation’s FOCUS specification (FinOps Open Cost and Usage Specification) normalizes billing data across cloud, SaaS, AI workloads, and data center spend. The State of FinOps 2026 report found that 98% of respondents now manage AI spend, up from 63% in 2025, and AI cost management ranks as the top forward-looking priority for FinOps teams globally. FOCUS addresses a different dimension of the control plane problem than OpenTelemetry does: financial telemetry rather than operational telemetry. Both must converge for a control plane to function as designed. And neither, on its own, solves the deeper problem: the agent’s governance identity does not yet travel with it.

Barrier 2: Agent Identity And Policy Propagation Lack Portable Standards

This is the most consequential gap on which the other two depend, and the one that connects all three barriers. When a developer wires an agent to a specific model, grants it access to a set of tools, and deploys it into a runtime environment, that agent carries a composite identity: model bindings, tool bindings, permission scopes, cost ceilings, and behavioral constraints. For the control plane to govern that agent at runtime, that identity must travel with the agent from build through deployment into production in a standardized format. No such standard exists at the level of maturity enterprises require. Without a portable agent identity descriptor that crosses all three planes, instrumentation (Barrier 1) cannot fully describe the agent, and integration schemas (Barrier 3) have no identity anchor to reference.

The protocol landscape reflects the problem. MCP (Model Context Protocol) handles agent-to-tool connectivity and has achieved extraordinary adoption, with several million monthly SDK downloads and governance under the Linux Foundation’s Agentic AI Foundation. MCP v2.1 introduced server identity and enhanced security features. Google’s A2A (Agent-to-Agent) protocol handles multi-agent coordination with Agent Cards that describe agent capabilities. IBM’s BeeAI Agent Communication Protocol uses Agent Manifests for a similar purpose. Microsoft’s Entra Agent Registry builds a production implementation of agent manifest-based discovery within a proprietary identity infrastructure. Each protocol addresses a real need, and the fragmentation reflects genuinely different design scopes rather than competing attempts at the same problem. But none solves the portable agent identity problem across all three planes, because none was designed to.

NIST recognized this gap directly. In February 2026, NIST’s Center for AI Standards and Innovation (CAISI) launched the AI Agent Standards Initiative, organized around three pillars: facilitating industry-led agent standards, fostering open-source protocol development, and advancing research in AI agent security and identity. The NCCoE released a concept paper titled “Accelerating the Adoption of Software and AI Agent Identity and Authorization,” exploring how existing identity and access management standards can apply to AI agents operating across enterprise infrastructure. Public comments close April 2, 2026. This initiative represents the first formal institutional effort to coordinate identity governance for autonomous AI systems at the federal level.

On the decentralized side, the Agent Network Protocol (ANP) uses W3C Decentralized Identifiers (DIDs) for cryptographic agent identity, and the W3C AI Agent Protocol Community Group targets official web standards for agent communication by 2026 to 2027. DIDs represent the closest thing to a portable identity primitive for agents, but adoption remains early-stage and concentrated in inter-organizational scenarios rather than intra-enterprise governance.

Every major vendor and standards body sees the same need. Every one builds a slightly different answer. Until a portable agent identity descriptor exists that can travel across build, orchestrate, and control planes, enterprises will hand-build the propagation logic for every integration. That limits the control plane to platform-specific implementations rather than the vendor-agnostic governance layer the architecture calls for. It also means that the third barrier, the absence of cross-plane integration schemas, has shaky foundations on which to build.

Barrier 3: Cross-Plane Governance Schemas Do Not Exist

Even if OpenTelemetry stabilizes its GenAI conventions and the industry converges on a portable agent identity standard, a third layer of standards remains absent: the schemas that define how the build, orchestrate, and control planes exchange governance-relevant information about agent state, policy, and lifecycle.

Consider what these schemas would need to express. When a control plane issues a policy change (revoke an agent’s access to a tool, lower its cost ceiling, require human approval for a class of actions), that change must propagate into the orchestration layer as an enforceable constraint on workflow execution and into the build layer as a configuration update or deployment gate. That requires a standardized policy propagation object: a machine-readable directive that any orchestration platform or CI/CD pipeline can consume without bespoke integration. When an orchestration platform detects that an agent’s behavior has drifted outside its expected performance envelope, it must emit a standardized lifecycle event (not just a telemetry span, but a governance-grade signal) that the control plane can act on: suspend, reroute, throttle, escalate. When a build tool publishes a new agent or updates an existing one, it must produce a capability manifest, a declared contract describing the agent’s model bindings, tool access, permission scope, and behavioral constraints, in a format the control plane can ingest and enforce at runtime.

What This Means For Enterprise Leaders

None of these gaps invalidate the case for an agent control plane. On the contrary, the gaps validate the architecture by identifying the boundaries where standards need to come into existence. Enterprises still need the conceptual separation between build, orchestrate, and control to make sound long-term platform decisions, even if the connective tissue between planes remains hand-built for now.

Each barrier carries a specific implication.

  • Against Barrier 1: instrument early. Adopt OpenTelemetry’s GenAI semantic conventions now, even in their experimental state, and align your FinOps practice with FOCUS. The cost of retrofitting instrumentation later far exceeds the cost of adopting evolving conventions today. Building the observability foundation now gives the control plane something to govern when it matures.
  • Against Barrier 2: track the identity standards landscape actively. NIST’s AI Agent Standards Initiative, the AAIF’s stewardship of MCP, and the W3C’s agent protocol community group represent the three most consequential efforts shaping how agent identity and authorization will work across enterprise boundaries. The decisions these bodies make over the next 12 to 18 months will determine which architectural bets pay off and which leave you locked into a single vendor’s identity model.
  • Against Barrier 3: design for plane separation now. Enterprises that conflate build-time governance, orchestration-time governance, and runtime governance into a single undifferentiated “agent management” function will face expensive architectural refactoring when cross-plane integration schemas emerge and the market consolidates around the three-plane model.

The individual standards are real and progressing. The integration between them is nobody’s job yet. That will change rapidly. Architect for this separation of planes today, so you are well positioned to adopt the connective tissue when it arrives.