The agent internet is not one protocol: a four-plane architecture for enterprise autonomy

The enterprise conversation about agent interoperability has been compressed into two acronyms: MCP for tools and A2A for agents. That shorthand is useful, but architecturally incomplete.

An autonomous agent crossing an organizational boundary needs more than a message format. It must discover a counterparty, establish identity, prove delegated authority, negotiate a protocol, invoke tools, isolate execution, preserve state, meter cost, produce evidence, and remain revocable after work has started.

No single protocol should own all of that.

The more durable architecture is beginning to look like the Internet itself: a set of narrow, composable contracts arranged into four planes—interaction, trust, control, and execution. MCP and A2A occupy important parts of the interaction plane. They do not replace the other three.

Executive summary

MCP’s 2026 stateless redesign is the inflection point. Agent tools can now run behind ordinary load balancers, gateways, WAFs, caches, and policy engines instead of transport-bound sessions.
A2A makes delegation a service boundary. Its Agent Cards, tasks, artifacts, streaming, polling, and webhooks provide a contract for opaque agents to collaborate across platforms.
Authentication is not delegation. Enterprises need verifiable evidence of who authorized an agent, for what action, resource, time, value, and re-delegation limit.
Open components are becoming a stack. The Agentic AI Foundation now spans skills, model interfaces, tool and agent protocols, routers, gateways, training environments, runtimes, and sandboxes.
The enterprise differentiator moves upward. As protocol plumbing standardizes, advantage shifts to policy, domain context, evaluation, workflow design, and operational evidence.

What changed in 2026

Four developments turned agent architecture from a framework question into an infrastructure question.

1. MCP became stateless web infrastructure

The MCP 2026-07-28 specification removed the protocol handshake and session identifier. Each request carries its protocol version, client identity, and capabilities. A request can land on any server instance behind a round-robin load balancer without shared transport state.

The same release added:

Mcp-Method and Mcp-Name HTTP headers for routing, metering, and authorization;
cache hints and deterministic ordering for tool, prompt, and resource lists;
Multi Round-Trip Requests for elicitation and sampling without a permanently open bidirectional stream;
an extension framework, with long-running Tasks moved outside the core;
authorization hardening and a move from Dynamic Client Registration toward Client ID Metadata Documents.

This does not make agent workflows stateless. It makes workflow state explicit. A tool can issue a handle; the model or orchestrator carries that handle into the next request. State leaves the transport and enters the application contract, where it can be persisted, audited, migrated, and recovered.

2. A2A stabilized agent-to-agent task contracts

A2A v1.0 introduced a stable cross-agent contract with multiple protocol bindings, version negotiation, multi-tenancy, and signed Agent Cards. Consumers can receive task progress through polling, streaming, or webhooks.

The important architectural move is not “agents can chat.” It is that an agent can expose an opaque asynchronous service boundary:

the Agent Card advertises identity, capabilities, endpoints, and protocol support;
a task represents delegated work rather than a synchronous function call;
artifacts carry outputs independently of the model’s internal reasoning;
lifecycle events make long-running work observable.

A2A is therefore closer to a contract for autonomous services than a conversation protocol.

3. Delegated intent became a security primitive

The FIDO Alliance’s agentic work separates human authentication from authorization of future agent actions. Its announced direction covers verifiable user instructions, agent authentication, and bounded delegation for commerce, drawing on AP2 and Verifiable Intent.

That distinction is fundamental. A valid access token may prove who obtained it; it does not necessarily prove:

what the user intended;
whether the agent may act while the user is absent;
the maximum value or risk permitted;
which resource and counterparty are in scope;
whether authority may be delegated again;
whether the instruction has been revoked.

The security boundary is moving from the prompt to the delegation artifact.

4. The open agent stack became visible

The Agentic AI Foundation announced Agent Skills, Open Responses, OpenEnv, and OpenSandbox alongside MCP, A2A, Agent Router, agentgateway, AGENTS.md, and goose. Together, these projects expose distinct layers: portable capabilities, provider-neutral model interfaces, agent communication, routing and governance, training and evaluation environments, runtime behavior, and secure execution.

Shared governance does not guarantee interoperability. It does, however, make one point clear: the strategic unit is no longer a monolithic “agent framework.” It is a supply chain of replaceable contracts.

The four-plane reference architecture

1. Interaction plane — how participants communicate

The interaction plane carries calls, tasks, artifacts, events, and protocol metadata.

MCP fits primarily between an agent and tools, resources, or contextual services. A2A fits between autonomous agents or agent-backed services. Open Responses targets a portable model interaction schema. Standard HTTP, JSON-RPC, gRPC, streaming, webhooks, and polling remain the transport foundations.

This plane should answer:

What operation or capability is being requested?
Which protocol version and binding are supported?
Is the work synchronous, interactive, or long-running?
How are partial results, artifacts, errors, and cancellation represented?
Which identifiers correlate the work across hops?

It should not decide whether the request is allowed. That belongs to the trust and control planes.

2. Trust plane — who is acting, for whom, and within what limits

The trust plane binds workload identity to delegated authority.

A useful authorization object needs more than a bearer credential. It should be able to express:

principal: the human or organization accountable for the action;
agent identity: the workload or agent instance presenting the request;
audience: the intended service or counterparty;
scope: permitted operations and resources;
constraints: time, geography, value, data classification, and risk;
re-delegation: whether and how authority may be passed onward;
evidence: signed intent, policy decision, and execution receipt;
revocation: a way to stop authority before its natural expiry.

Signed Agent Cards can establish integrity of advertised agent metadata. They do not, by themselves, prove that a specific business action was authorized. Authentication proves identity; delegation proves bounded intent; policy determines whether that intent may be exercised here and now.

3. Control plane — what is admitted, routed, budgeted, and observed

The control plane turns protocols into an operable enterprise service.

It includes:

capability and endpoint discovery;
gateway routing and protocol mediation;
policy-as-code evaluation;
credential brokering and secret isolation;
budgets, quotas, and rate limits;
data-loss prevention and payload inspection;
model, tool, and agent allowlists;
risk-tiered approval and step-up authorization;
telemetry, lineage, cost attribution, and incident controls;
kill switches, revocation, and emergency suspension.

MCP’s header-visible method and tool names matter here. A gateway can authorize and meter tools/call for a named capability without parsing an opaque body. Stateless requests also remove session affinity from the gateway, making horizontal scale and regional failover conventional infrastructure problems.

The control plane should remain protocol-aware but framework-neutral. Otherwise, every new agent runtime creates another policy island.

4. Execution plane — where untrusted effects happen

The execution plane performs model calls, code execution, browser automation, file mutation, API calls, and transactions.

Its core abstractions are:

disposable sandboxes or microVMs;
scoped filesystem and network access;
egress proxies and destination policy;
short-lived credentials issued at execution time;
tool adapters and MCP servers;
durable task and artifact stores;
explicit state handles;
model runtimes and agent harnesses;
evaluation environments and replay fixtures.

A sandbox is not the policy system. It is the containment boundary that limits damage when policy, prompting, or model behavior fails.

One transaction across the four planes

Verifiable delegation chain from human authentication to durable evidence

The trust plane must preserve authorization beyond the lifetime of any one agent process: authenticate the principal, sign bounded intent, evaluate policy, contain execution, verify the counterparty, and retain evidence.

Consider a procurement agent asked to renew a software subscription.

Intent is captured. The user authenticates and authorizes renewal up to a defined amount, for a named supplier, before a deadline, with no re-delegation outside the procurement domain.
The control plane resolves capability. It discovers an approved supplier agent, validates its signed metadata, selects A2A v1.0, and applies organizational policy.
An A2A task is created. The procurement agent delegates quote retrieval and renewal preparation without exposing its internal reasoning.
The supplier agent invokes tools through MCP. Stateless calls reach horizontally scaled catalog, contract, and payment services.
Execution is contained. Document parsing and browser work occur in disposable sandboxes; secrets are brokered only for the permitted destination.
A high-risk step requires evidence. Before payment, the counterparty verifies the signed mandate, amount, audience, and expiry.
Artifacts and receipts return. The task produces the renewed contract, payment receipt, policy decision, and provenance record.
Authority is closed. The mandate is consumed or revoked; residual credentials and sandboxes are destroyed.

Each plane has one job. The task can survive process restarts because durable state is not hidden inside a connection. The transaction can be audited because authorization and execution evidence are explicit.

Why “MCP versus A2A” is the wrong decision

The protocols solve different boundaries:

Question	MCP	A2A
Primary relationship	Agent to tool/context service	Agent to autonomous agent/service
Core unit	Tool/resource/prompt call	Task, message, artifact, lifecycle
Internal reasoning exposed?	Not required	No; agent remains opaque
Long-running work	Tasks extension / explicit state	Native task lifecycle patterns
Discovery	Server capabilities and catalogs	Agent Card and capabilities
Enterprise role	Tool integration substrate	Delegated service contract

Most serious platforms will use both. The real decisions are:

where policy is enforced;
how identity and delegation flow across both protocols;
which state is durable;
how tools and agents are discovered and trusted;
how effects are contained;
how evidence remains queryable after completion.

Stateless transport does not mean stateless agents

Stateless protocol cores improve scale, but hidden state can simply reappear elsewhere.

Enterprises should classify state explicitly:

State type	Correct home	Failure strategy
Transport state	Avoid where possible	Retry on another instance
Workflow/task state	Durable task store or event log	Resume from checkpoint
Tool-specific state	Explicit opaque handle	Validate ownership and expiry
Conversation context	Governed memory service	Version and redact
Authorization state	Policy and delegation store	Re-evaluate and revoke
Execution scratch state	Disposable sandbox	Destroy on completion/failure
Business artifacts	System of record	Idempotent write and receipt

The design test is simple: can a request land on another instance, can a task resume after failure, and can an auditor reconstruct authority and effects without recovering process memory?

The missing enterprise contracts

Open protocols reduce integration cost, but production interoperability still needs profiles that standards do not fully provide.

Identity profile

Define accepted issuers, workload identity format, agent identity binding, key rotation, signed metadata validation, tenant isolation, and cross-domain trust anchors.

Delegation profile

Define mandate structure, audience and resource semantics, risk/value constraints, re-delegation rules, proof-of-possession, revocation, and receipt format.

Capability profile

Define stable capability names, versioning, input/output schemas, side-effect classification, idempotency, data sensitivity, and required approval level.

Telemetry profile

Carry trace, task, principal, agent, policy-decision, tool, model, cost, and artifact identifiers across protocol boundaries without leaking prompts or personal data into metric labels.

Failure profile

Distinguish protocol failure, policy denial, authorization expiry, business rejection, tool failure, partial completion, cancellation, and unknown outcome. “Agent failed” is not an operable error model.

Security: contain capabilities, not personalities

Prompt-based restrictions are useful guidance, not a security boundary. A model that “knows” it must not access production still requires a credential or network path before it can do so.

Use capability containment:

issue short-lived credentials after policy evaluation;
bind credentials to audience, operation, and execution environment;
isolate high-risk tools into separate sandboxes and network zones;
default-deny egress and broker exceptions;
require idempotency keys for mutating operations;
insert human approval at irreversible or high-value transitions;
separate planning identity from execution identity;
revoke active mandates and tasks, not only future logins;
preserve tamper-evident receipts for consequential actions.

The model may propose. The trust and control planes authorize. The execution plane constrains.

Architecture choices enterprises should make now

Adopt protocols at boundaries, not everywhere

Use MCP where portable tool/context integration creates value. Use A2A where teams or organizations need opaque autonomous services. Do not wrap every internal function in a protocol merely to claim interoperability.

Build an agent gateway, not another agent framework

The durable enterprise investment is the control layer that understands identities, delegation, protocols, policies, budgets, evidence, and revocation across multiple runtimes.

Treat skills as governed software supply chain artifacts

Portable skills contain instructions, scripts, and resources that affect agent behavior. Version, sign, review, scan, test, and promote them like code. Loading a skill is a capability change and should be visible to policy and telemetry.

Make sandbox portability a first-class requirement

If execution contracts are portable, the organization can place work according to sensitivity, cost, residency, and accelerator needs without coupling the agent to one runtime.

Keep business state outside the agent process

The agent process should be replaceable. Put task state, authorization, artifacts, and receipts in durable systems with explicit schemas and ownership.

A practical adoption roadmap

Map current boundaries. Inventory agents, tools, model APIs, identities, secrets, sandboxes, task stores, and systems of record.
Classify effects. Label capabilities as read-only, reversible, mutating, financial, privileged, or safety-critical.
Standardize correlation. Carry trace, task, principal, delegation, and policy-decision identifiers end to end.
Make MCP services stateless. Remove transport-bound session assumptions and externalize required state through explicit handles.
Introduce a protocol-aware gateway. Route and authorize on protocol metadata; centralize quotas, egress, credentials, and evidence.
Use A2A at organizational seams. Start where independent ownership and asynchronous tasks already exist.
Create a delegation profile. Bind authenticated users to bounded agent mandates with expiry, value, audience, and revocation.
Standardize execution contracts. Make sandbox lifecycle, network policy, artifacts, and cleanup portable.
Exercise failure and revocation. Kill processes, rotate issuers, expire mandates, interrupt streams, retry tasks, and prove that unknown outcomes are reconciled.
Measure portability. Replace one model, one agent runtime, one MCP server, and one sandbox implementation without changing business policy.

Architecture review checklist

Can every action be tied to an accountable principal and agent identity?
Is delegated authority narrower than the user’s full authority?
Can authority be revoked while a long-running task is active?
Are protocol, policy, business, and execution failures distinguishable?
Can MCP requests land on any healthy instance without hidden session state?
Are A2A Agent Cards verified against trusted issuers and current policy?
Are skill packages versioned, reviewed, and promoted like software?
Are mutating tool calls idempotent or explicitly reconciled?
Are credentials issued just in time and bound to their audience?
Is execution isolated from the agent planner and from unrelated tenants?
Can state survive process, node, region, and runtime replacement?
Are evidence and artifacts durable after sandboxes are destroyed?
Can one layer be replaced without reimplementing policy in every other layer?

The strategic conclusion

The emerging agent internet is not a new network and should not become one universal protocol. It is a coordinated stack built on ordinary web infrastructure, with new contracts where autonomy creates genuinely new semantics.

MCP makes tools routable. A2A makes agents contractable. Delegation makes authority verifiable. Gateways make policy operable. Sandboxes make effects containable. Skills and model interfaces make capabilities portable.

The enterprise architecture task is to keep those concerns separate while preserving one trace of identity, intent, policy, execution, and evidence across them all.

Sources

CTA

If your agent platform has accumulated overlapping protocols, identity flows, gateways, sandboxes, and task stores, KMS ITC can turn them into a governed four-plane target architecture and migration roadmap.