Executive briefOne protocol cannot preserve every enterprise relationship

An architecture can route tool calls, agent tasks and business events through one fashionable protocol and still fail at the first retry. The messages parse. The receiving system accepts them. Yet the bridge has replaced an end-user delegation with a service token, converted an event into an instruction, lost the business object version and interpreted HTTP success as completed work. Syntactic connection has amplified authority while making recovery less knowable.

MCP, A2A, typed service APIs and enterprise events begin from different relationships. A typed API exposes a known operation to a known client. MCP lets an AI host discover and invoke tools, resources and other interactive capabilities. A2A coordinates tasks, messages, status and artefacts across independently operated agent systems. CloudEvents and AsyncAPI describe asynchronous state-change messages and their channels. A human or deterministic workflow remains the correct boundary when meaning, consequence or responsibility is unresolved.

The Interoperability Envelope in this article places ten enterprise contracts around each exchange. It preserves principal, capability, semantics, state, delivery, transaction, policy, trust, evidence and lifecycle while allowing protocol-specific behaviour. Adapters translate at the edge. They cannot manufacture semantic equivalence, expand delegation or declare a business action complete because a transport layer responded.

The strongest rival: conventional APIs and events

OpenAPI, OAuth, queues, event schemas and workflow engines already integrate enterprises. Their operational practices are mature, and deterministic services do not need agent discovery or task delegation. Keep them as the default. Introduce MCP when an AI host genuinely benefits from governed dynamic access to tools or resources. Introduce A2A when a task crosses an independent agent ownership boundary and needs status, artefacts or multi-turn interaction.

Novel protocols are not architectural progress by themselves. They add version, capability-negotiation, security, tooling and skill requirements. A narrow MCP tool can still call a conventional service. An A2A task can produce enterprise events. The boundary map preserves each relationship instead of forcing old services into agent vocabulary or using an event bus to simulate task ownership.

Interoperability EnvelopeWrap ten contracts around every exchange

The envelope is an enterprise contract, not another universal payload. Each protocol maps its native identifiers, errors and states into the relevant fields without losing them. Some fields travel by token claim, header, message, task metadata, event context or protected evidence reference. The boundary receipt links them after execution.

Protocol Boundary MapMatch the relationship, not the fashion cycle

Typed synchronous OpenAPI service. Use when the client knows the operation and needs an immediate deterministic response. The service contract declares schemas, errors, preconditions and business receipt. Authentication and authorisation remain resource specific. An AI application can call the service without converting it into an MCP tool when dynamic discovery adds no value.

MCP host-to-capability boundary. The live `2026-07-28` specification defines a stateless core with self-contained requests and per-request capability negotiation, plus opt-in extensions. Use MCP where a host needs governed discovery and invocation of resources or tools. Pin the revision and supported extensions. Discovery results are untrusted descriptions until the host validates server, capability and policy.

A2A task boundary. The current 1.0 specification supports independent-agent discovery, messages, tasks, states, artefacts, streaming and several bindings. Use it when a sponsor delegates a task to another operated agent and needs status or artefact exchange. The accountable principal and purpose must survive; an agent card advertises capability but does not grant authorisation.

CloudEvents and AsyncAPI state change. CloudEvents stable v1.0.2 provides a portable event context, while AsyncAPI 3.1.0 describes channels, operations and messages. Use them when a producer announces a state-change fact without directing every consumer. Consumers make their own authorised decision. A fact that a customer status changed is not permission to close an account, issue funds or alter another system of record.

Human or deterministic workflow gate. Keep a named reviewer or workflow owner when the semantic contract is incomplete, the requested side effect is not recoverable, or principal and delegation cannot be proven. Delay is preferable to a bridge that silently invents authority. This is a designed route, not an integration failure.

These version statements were checked against the official specifications on 2 September 2026: MCP revision 2026-07-28, the A2A 1.0 specification line, CloudEvents stable v1.0.2 and AsyncAPI 3.1.0. A deployed boundary still pins its own supported version and extensions. “Latest” is unsuitable evidence because it can change without the application changing.

Authority pathDelegation must survive every bridge

Suppose a procurement assistant delegates supplier research to an independently operated research agent through A2A. That agent calls an MCP server to retrieve contract metadata, and the MCP tool calls a contract service. Four identities may be present: the sponsoring employee, the originating assistant, the delegated research agent and the service workload. None is a substitute for the others. The employee is accountable for the purpose; each workload proves which software is calling; delegation limits what an intermediate agent may do.

The bridge should carry an audience-bound authority record containing tenant, sponsor, purpose, authorised capability, resource, constraints and expiry. OAuth Rich Authorization Requests can express structured authorisation details, while Resource Indicators bind a token to the intended resource. SPIFFE-style workload identity can attest the calling service. Resource policy still evaluates the effective principal and entitlement. A broad bearer token copied from the A2A edge into the MCP service is not delegation; it is authority laundering.

At every hop, calculate effective authority as the intersection of sponsor permission, delegator grant, receiving capability and local policy. The result may narrow but never widen. If the research task allows reading supplier certifications, an MCP tool cannot add contract amendment merely because both operations share a server. If the next resource requires consent or a regional restriction that the original context lacks, stop and return an input-required state with the missing decision.

Identity context also has a lifetime and a tenant boundary. A long task must re-evaluate expiring permission before later side effects. Correlation identifiers should be scoped so observability does not join records across tenants. Logs can refer to protected evidence rather than copying sensitive claims. Zero-trust architecture supports this resource-centric decision pattern: identity is necessary, but every requested resource and action receives a current policy decision.

State and timeAn accepted task is not completed work

A transport response proves that a receiver understood enough to acknowledge a message. It does not prove that a calculation finished, an artefact passed validation or a downstream side effect committed. Long-running work therefore needs an application state machine. A useful minimum distinguishes submitted, accepted, working, input-required, completed, failed and cancelled. Each transition names its owner, timestamp, trigger and evidence.

A2A is suited to cross-owner tasks because the task itself can persist beyond one request and expose status and artefacts. The enterprise envelope adds business meaning. “Completed” must name the promised outcome, required validation and any committed side effects. An artefact can be delivered while the task remains input-required. An HTTP 200 can carry a failed business result. Conversely, a network timeout can hide a successful commit, so blind retry is dangerous.

Cancellation is a request to change state, not retroactive erasure. The receiver records when it observed cancellation, whether work stopped, which effects already occurred and which compensation remains. For a reversible research task, cancellation may simply halt execution. For a payment or booking, a separate compensating operation may be needed. When no safe compensation exists, the router requires confirmation or a human gate before initiation.

Time also has several meanings. Event time records when a domain fact occurred; recorded time says when a system observed it; effective time says when the change applies. Task update time says when status changed. Ordering should be declared per business entity or process rather than inferred from arrival. A later-arriving message may describe an earlier event, and a superseding version should be explicit.

Event boundaryA state-change fact is not an unrestricted command

An enterprise event says that a domain state changed. It carries an event identifier, type, source, subject and time alongside a versioned business payload. CloudEvents supplies portable context; AsyncAPI can describe the channel, operation and message contract. The producer should not need to know every consumer, and a consumer should decide its response under its own policy. This decoupling is the event model's strategic value.

Confusion begins when an event named CustomerStatusChanged is treated as an instruction to freeze funds, cancel orders or email a customer. Those effects require separate authority, preconditions and business rules. A maliciously crafted, stale or duplicated event must not acquire command semantics by arriving on a trusted broker. The consumer validates producer, schema, tenant, subject version and event chronology, then chooses an allowed action.

At-least-once delivery makes duplication ordinary. Deduplicate by a stable event identity within the correct producer and tenant scope, but also make the resulting business operation idempotent. A consumer may crash after committing an effect and before recording its offset. On replay, the event identifier and business key must recover the previous outcome instead of creating another transfer or case. An “effectively once” claim is therefore a system property backed by storage and receipts, not a broker slogan.

Commands travel differently. They address a named handler, state an intended operation, carry authority and expect an explicit outcome. If a workflow wants a consumer to act, model that request as a command or typed operation after policy, not as a suggestive event type. When a fact can trigger several governed responses, each consumer records its own decision and effect receipt. The source event remains immutable evidence; it does not become proof that every consequence succeeded.

Compensation follows business semantics. Reversing a notification may mean issuing a correction rather than deleting history. Reversing a reservation may require a cancellation service and could incur a fee. A generic protocol adapter cannot derive those rules. The envelope points to the domain recovery contract and next owner, allowing operations staff to distinguish retryable delivery, rejected policy, failed action and pending manual repair.

Boundary testsTen cases expose the differences that adapters hide

The negative controls matter as much as successful routes. They prevent an architecture review from becoming a procurement exercise in which every use case is forced through a selected standard. The router returns a protocol only when the relationship and non-compensable contracts are sufficiently clear. Otherwise, its fifth route makes the missing work visible.

Change controlPin versions, negotiate extensions and reject unsafe downgrades

Protocol standards evolve at different cadences. A deployment record should pin the core revision, binding, enabled extensions, schema versions and adapter build. Capability negotiation is evidence about what both endpoints support during that exchange. It does not prove that the selected combination satisfies policy or business invariants. Store the negotiated result in the boundary receipt so an incident can reconstruct actual behaviour.

Compatibility has at least four layers. Wire compatibility asks whether messages parse. Behavioural compatibility asks whether errors, streaming, cancellation and retries mean the same thing. Semantic compatibility asks whether entities, units and state transitions agree. Control compatibility asks whether identity, authorisation, evidence and retention remain enforceable. A successful conformance test at the first layer cannot waive failures in the other three.

An adapter belongs at a protocol edge. Its mapping is versioned, tested and observable. It preserves native identifiers and raw signed evidence where required, while adding its own transformation provenance. SLSA provenance can strengthen confidence in how adapter software was built, but software supply-chain evidence is not proof that a runtime mapping is semantically correct. Both are necessary controls with different claims.

Define an extension allow-list and a downgrade policy. Optional convenience may degrade safely when omitted. Required authorisation detail, tenant isolation, idempotency, cancellation or provenance cannot. When peers cannot negotiate a safe intersection, reject the exchange with the missing capability, supported alternatives and migration owner. Silent coercion into a weaker mode creates the appearance of availability by spending control integrity.

Retirement is part of interoperability. Inventory producers, consumers, agents, hosts, servers, adapters and evidence readers by pinned version. Publish overlap windows and test fixtures. Observe actual use before disabling an old revision, then keep the receipts needed for historical audit. An exit route should allow a service to return to a typed API or workflow boundary without rewriting its domain meaning.

Evidence contractIssue a boundary receipt for every consequential exchange

A boundary receipt is the durable answer to “what crossed, under whose authority, with which result?” It identifies the envelope and schema versions, principal and delegation chain, selected protocol and binding, request, task or event identifiers, policy decision, state transition, side effect, error, recovery status and next owner. It links evidence rather than copying sensitive material into every log.

The receipt separates observations that are often collapsed. Transport status records whether a request or message was accepted by infrastructure. Protocol status records the task, tool or event-processing state. Business status records whether the promised outcome and validation criteria were met. Transaction status records whether a side effect committed, was deduplicated, rolled back or awaits compensation. Evidence status records whether the relevant artefact, trace and policy decision can still be retrieved by an authorised reviewer.

Receipts need stable identities and explicit lineage. W3C PROV concepts help describe the entities, activities, agents, delegation and derivation involved. OpenTelemetry connects spans, metrics and logs across services, but trace context should be tenant-scoped and protected from injection. The receipt can point to a trace and signed artefact while retaining the domain identifiers that operations staff recognise.

Design the receipt before the adapter. This forces teams to confront mappings that would otherwise disappear: which A2A task caused which MCP call; which tool invocation reached which service transaction; which CloudEvent represented the committed change; and which agent or human now owns an exception. If a proposed bridge cannot produce that chain without reconstructing it from free text, the bridge is not ready.

Retention follows the underlying purpose, data classification and legal basis. Not every operator may see prompts, tool output or identity claims. Provide role-appropriate views and immutable integrity evidence. The EU AI Act may add documentation, logging, human oversight, monitoring and value-chain duties for in-scope systems. The receipt supports those activities but does not determine legal scope on its own.

A worked bridge receipt

For an A2A-to-MCP research flow, the receipt starts with the sponsoring user's tenant, approved purpose and delegation expiry. It records the remote task identifier, the negotiated A2A version, the receiving agent and its task transitions. For each tool use it adds the MCP server identity, capability version, invocation identifier, narrowed authorisation result and returned evidence digest. If the MCP tool calls a typed contract service, the service transaction and business receipt join the chain.

The final task may report completed only after required artefacts exist and validation passes. A missing citation can leave the task input-required even when every network call succeeded. A tool timeout may lead to a retry under the same idempotency key. A service commit observed after the timeout prevents a duplicate. If cancellation arrives, the receipt distinguishes stopped research from an already committed downstream change and identifies the compensation owner. This is how interoperability becomes operable rather than merely demonstrable.

Interactive instrumentEnterprise Interaction Protocol Router

Select a case or alter the contracts. The router returns one of exactly five boundary routes. It does not calculate an interoperability score because a high average could conceal a missing principal, invariant or recovery path. Identity, semantics, transaction, trust and evidence are non-compensable gates: uncertainty in one cannot be offset by strength in another.

Decision outputsFive routes, each with a different owner of state

The routes can compose without collapsing. An A2A agent can use an MCP tool, which calls a typed service that emits a CloudEvent after commit. Each boundary keeps its own identity, state and receipt, while shared envelope fields link the chain. Composition is safe only when authority narrows, semantic mappings are explicit and a failure can be assigned to the correct owner.

Governance and evidence boundaryInteroperability ends where claims exceed proof

The Interoperability Envelope, Protocol Boundary Map, boundary receipt and Router are this article's synthesis. They translate primary protocol, identity, provenance, operations and risk sources into an architecture decision method. They have not been validated as a universal standard, certification scheme or predictor of control effectiveness. Organisations should test the method against their own threat model, system of record, data obligations and operational failure history.

MCP is not a general event bus and does not prove that a discovered tool is safe. A2A is not a replacement for deterministic service APIs or enterprise process state. An agent card or tool catalogue describes a capability; it does not grant permission, validate accuracy or establish fitness for a business purpose. JSON-RPC or HTTP success establishes a protocol observation, not completed business work.

The architecture fails when bearer tokens replace delegation, discovery becomes automatic trust, schemas omit invariants, tool servers use broad service identities, agent tasks obscure the sponsor, events are replayed as commands, retries duplicate effects, cancellation leaves side effects unreported, adapters strip provenance or version negotiation silently weakens controls. It also fails when incident responders cannot tell transport failure from business failure or cannot identify the next owner.

NIST's AI Risk Management Framework and Generative AI Profile support lifecycle governance, measurement, third-party scrutiny and monitoring. OWASP's excessive-agency guidance reinforces narrow tools, permissions and autonomy with downstream authorisation. These sources justify caution around action boundaries but do not select a protocol. Protocol choice follows relationship; governance evidence establishes whether the deployed relationship remains controlled.

Review the boundary whenever ownership, protocol revision, adapter, schema, authorisation model, side effect or recovery path changes. Exercise expired delegation, duplicate delivery, timeout after commit, cancellation during work, poisoned resource content, cross-tenant correlation, version mismatch and evidence unavailability. Test that the safe failure route is reachable and that it names a human or deterministic workflow owner.

The closing rule is deliberately simple: use the narrowest protocol that matches the relationship, then make semantics, authority and recovery explicit outside the protocol. Interoperability is not one cable. It is the ability to cross a boundary without losing who asked, what was meant, what changed, what proved it and who acts next.

Evidence spineReferences

1. Model Context Protocol project. MCP Specification 2026-07-28.
2. A2A Project. Agent2Agent Protocol Specification.
3. Cloud Native Computing Foundation. CloudEvents Specification.
4. AsyncAPI Initiative. AsyncAPI Specification.
5. OpenAPI Initiative. OpenAPI Specification.
6. JSON-RPC Working Group. JSON-RPC 2.0 Specification.
7. IETF. OAuth 2.0 Rich Authorization Requests, RFC 9396.
8. IETF. OAuth 2.0 Resource Indicators, RFC 8707.
9. SPIFFE. SPIFFE Concepts.
10. NIST. Zero Trust Architecture, SP 800-207.
11. W3C. PROV-O: The PROV Ontology.
12. OpenTelemetry. Specification.
13. OpenSSF. SLSA Provenance.
14. NIST. AI Risk Management Framework 1.0.
15. NIST. Generative Artificial Intelligence Profile.
16. OWASP GenAI Security Project. LLM06: Excessive Agency.
17. European Union. Regulation (EU) 2024/1689.