AI Architecture

Enterprise Agent Interoperability: A2A + MCP Operating Model

Published
Updated

Material update: 2 September 2026

MCP and A2A solve different integration problems. Model Context Protocol describes how an AI application uses tools, resources and reusable prompts. Agent2Agent Protocol supports collaboration between independent agents: discovering capabilities, handing off work, tracking task state and receiving artefacts. Replacing one with the other either reduces a capable agent to a brittle function call or introduces an orchestration layer where a straightforward tool contract would have been safer.

The timeline also needs to be explicit. Google announced A2A on 9 April 2025, the project moved to the Linux Foundation in June, and A2A v1.0 became the first stable release on 12 March 2026. The relevant MCP baseline is the 25 November 2025 protocol revision. These standards make message-level interoperability possible; they do not decide which party should be trusted, who owns the outcome or whether an action is acceptable to the business.

Draw the agent-to-tool boundary first

Start with an architecture map that labels each participant as an agent or a tool. A tool usually has a narrow contract, predictable inputs and outputs, and no independent multi-step conversation. An agent may plan, use several tools, retain task context, request more information and return work asynchronously.

The official A2A and MCP comparison expresses the distinction plainly: MCP connects agents to tools and resources, while A2A lets independent, often opaque agents collaborate as peers. A common design uses A2A between domain agents and MCP inside each domain for database, document and API access.

Do not turn every model-backed service into an A2A agent. If an operation should remain atomic, stateless and easy to repeat, an MCP tool is simpler to authorise and test. A2A becomes useful when the remote party retains execution autonomy, needs a task lifecycle or cannot expose its internal tools.

Operate a catalogue of versioned contracts

Every enterprise agent needs an owner, trust domain and catalogue entry. Record its Agent Card location, A2A versions and bindings, declared skills, data classifications, authentication schemes, operational limits and escalation route. An equivalent MCP entry should capture server version, tools, resources and prompts, schema ownership and deprecation policy.

An Agent Card is a capability claim, not permission to use the capability. Clients should retrieve cards from approved locations, verify a signature when one is present and apply local admission policy. A public card must not contain credentials or unnecessary internal details that expand the attack surface.

Schema changes can break a workflow even when the transport remains healthy. Contract tests should cover both syntax and behaviour, and consumers need a defined migration interval. Version the semantics of a skill or tool rather than relying solely on the SDK package number.

Specify the complete task lifecycle

A2A defines concepts including Message, Task, Artifact and task-status events. The operating model must add retry, cancellation, deduplication and retention rules. A client needs to distinguish a request that never started from work that is still running or work that finished but whose response was lost.

Every state-changing action needs an idempotency key or another reliable duplicate-control mechanism. Retrying a read differs materially from retrying a payment, publication or account update. A completed state should mean that a defined business contract has been fulfilled, not merely that the remote agent has stopped processing.

Treat an artefact as data from another system. Attach a content type, schema version, provenance, classification, validity rules and, where relevant, an integrity check. A natural-language answer must not become an authorised executable instruction simply because it arrived over a valid A2A session.

Separate identity, delegation and consent

A2A declares authentication requirements in the Agent Card, but credentials are obtained outside task semantics. The server must authenticate every request and make its own authorisation decision for the requested skill, action and data. A known agent is not automatically entitled to exercise every capability it advertises.

For MCP over HTTP, the current authorisation specification requires protected-resource discovery and Resource Indicators so that a token is intended for a specific MCP server. It also prohibits passing the inbound token unchanged to an upstream API. An MCP server calling another service should obtain separate credentials for that relationship.

User delegation must preserve both who initiated the process and which workload performed the action. High-risk operations need narrow scope, short-lived authority and consent tied to a concrete effect—for example, submitting a particular order—rather than broad permission for an agent to “act on the user’s behalf”.

Treat tool and agent output as untrusted input

Instructions can arrive through a document, web page, issue, API response or another agent. The protocol structures the exchange but cannot establish whether the content is truthful or safe. Every MCP and A2A boundary is therefore a validation point for schema, size, media type, data classification, references and execution policy.

Separate read-only tools from state-changing tools. Validate consequential parameters in deterministic code outside the model. Irreversible actions should use a prepare-and-approve pattern: the agent constructs a proposed action and explains the expected effect, while a policy component or authorised person grants execution authority.

Design a safe degraded mode as part of the contract. When a partner agent, model or MCP server is unavailable, the workflow should stop, enter a manual queue or offer reduced functionality according to a prior decision. Silently switching to another agent or model can alter both behaviour and the trust boundary.

Test failures, not just protocol demos

A successful happy-path exchange provides little operational assurance. A conformance suite should exercise an unsupported version, unknown skill, denied authorisation, expired token, duplicate request, mid-task cancellation, interrupted stream, delayed webhook, malformed artefact and unavailable downstream tool. Each result should show whether the workflow left a partial business effect, not only the protocol error code.

Useful measures include completion by terminal state, handoff latency, retry volume, policy-denial rate, duplicate effects, tasks requiring human intervention and actions for which full provenance could not be reconstructed. An audit trail should connect the initiator, workload identity, Agent Card revision, task, tool version and final effect.

Interoperability becomes an operating capability when a new agent can join through a governed contract and when its failure can be contained and explained. Connecting two demonstrations is a useful engineering checkpoint, but it is not evidence of that capability.

Assign ownership at each boundary

The domain team owns skill semantics and business outcomes. The identity team owns credential issuance and trust-domain federation. The platform team owns discovery, gateways, observability and common SDK controls. Security defines admission and action policy, while product owners decide where human approval is required.

No central team should become the manual broker for every agent connection. It should provide the catalogue, policy engine, reference contracts, compatibility tests and incident mechanism. Domain owners then remain accountable for what their agents promise and do. This division keeps standards from becoming an excuse for anonymous responsibility.

Sources

01

AI Architecture

RAG in Production: Quality and Governance Framework

RAG is not a feature that automatically grounds a model. It is a system with two dependent stages: retrieval must locate the right evidence, and generation...