MCP + A2A Production Architecture

Use MCP where software capabilities cross a boundary and A2A where responsibility crosses to a remote agent.

MCP and A2A solve different interoperability problems. The Model Context Protocol lets an AI application access tools, resources, and prompts exposed by servers. The Agent2Agent Protocol lets a client collaborate with a remote agent through messages, tasks, status, and artifacts.

A production system may need both. A coordinator agent might use MCP to read customer records and search internal knowledge, then use A2A to delegate contract analysis to a specialist maintained by another team. That specialist may use its own MCP servers internally.

The protocols complement each other, but they do not provide orchestration, product policy, or business authorization on their own.

The responsibility map

Assign each concern deliberately.

MCP handles capability integration:

• discover tools, resources, and prompts;
• invoke an operation or retrieve context;
• exchange structured capability metadata and results;
• support local or remote server boundaries.

A2A handles remote-agent collaboration:

• discover an agent through an Agent Card;
• send messages and initiate task-oriented work;
• observe task status;
• receive messages and artifacts;
• support compatible interaction bindings.

The orchestrator handles workflow:

• decompose the goal;
• choose local execution or remote delegation;
• manage dependencies and timeouts;
• combine results;
• decide when to ask a human;
• recover or compensate after failure.

The application handles product policy:

• authenticate the user;
• decide which systems and agents are permitted;
• display approval and progress;
• enforce data and retention rules;
• define the final user experience.

If these boundaries are blurred, teams expect the protocol to make decisions it was not designed to make.

Reference scenario

Consider an account-renewal assistant. A user asks:

Prepare a renewal brief for Northstar Ltd, identify support risks, review the proposed contract, and draft next steps.

The coordinator needs:

• CRM account details;
• support-ticket summaries;
• internal pricing policy;
• a specialist legal review;
• a final, cited renewal brief.

The CRM, support, and policy systems are capabilities. They fit MCP servers. Legal review is a goal-directed service with its own workflow, status, and artifact. It fits a remote A2A agent.

End-to-end task flow

One execution can proceed as follows:

1. The application authenticates the user and creates a task ID.
2. The coordinator interprets the renewal goal and checks policy.
3. The host exposes a bounded set of approved MCP capabilities.
4. The coordinator reads account data and support summaries through dedicated MCP clients.
5. It discovers the approved contract-review agent from its A2A Agent Card.
6. The application confirms that the contract may be sent to that agent.
7. The coordinator sends an A2A message or task with the contract, playbook version, constraints, and expected artifact.
8. The specialist performs its workflow, perhaps calling document and policy tools through its own MCP host.
9. The specialist returns status and a cited risk artifact through A2A.
10. The coordinator verifies the artifact, combines it with local evidence, and drafts the renewal brief.
11. The application records the outcome and presents it for human review.

The task ID should correlate the application run, local MCP operations, A2A task, specialist trace, and final outcome without forcing all systems into one trace backend.

Why not expose the specialist as one MCP tool?

You could wrap legal review as a tool named review_contract. That may be enough when the operation is short, synchronous, and has a stable request-result shape.

A2A becomes more useful when the remote service:

• owns a multi-step workflow;
• may take a long time;
• communicates progress;
• asks for clarification;
• produces multiple artifacts;
• is operated as an independent agent service;
• needs its own task lifecycle.

The distinction is responsibility, not intelligence. An MCP tool can call a sophisticated system. An A2A agent can run a deterministic workflow. Choose the boundary from the interaction contract.

Why not expose every tool through A2A?

Turning a database query or file read into a remote-agent task adds lifecycle and ambiguity without adding value. MCP provides a narrower contract for capabilities and context.

Use a direct MCP capability when the host knows the operation it needs and wants a bounded result. Use A2A when the host delegates a goal and the remote party owns how to accomplish it.

Identity across boundaries

There may be several identities:

• the human user;
• the application or tenant;
• the coordinator service;
• the MCP client and server principals;
• the A2A client and remote-agent principals;
• backend service accounts.

Do not collapse them into one bearer token. Each credential should be valid for its intended audience. The coordinator may act on behalf of a user, but the receiving server must validate that delegation and enforce its own scope.

For sensitive operations, propagate verified claims such as tenant, user, purpose, and correlation ID through supported mechanisms. Never trust identity fields simply because the model included them in a message.

The specialist should receive only the data required for its delegated task. It does not need broad access to the coordinator’s CRM merely because both participate in one workflow.

Permission and approval design

Create a policy matrix by action:

• read account summary: user role plus account scope;
• read support tickets: support-data permission;
• send contract to external specialist: destination and data-class policy;
• specialist tool use: specialist-side authorization;
• send customer communication: explicit human approval.

Approval occurs at the meaningful side effect. Asking the user to approve “A2A” or “MCP” is too abstract. Show the destination agent, document, intended analysis, retention or sharing implications, and action to be performed.

Both sides enforce policy. The coordinator decides whether it may delegate. The specialist decides whether it may accept the task and use its own capabilities.

State ownership

Distributed agent systems become fragile when every component treats its state as authoritative.

Assign ownership:

• the application owns the user-visible workflow and final status;
• the coordinator owns the decomposition and aggregation state;
• each MCP server owns its backend operation state;
• the A2A server owns its remote task state and artifacts;
• systems of record own business data.

Store references and version identifiers instead of copying full mutable state everywhere. If the contract changes while the specialist is reviewing it, the coordinator must know which document version the artifact covers.

Use explicit state transitions. “Running,” “waiting for input,” “completed,” “failed,” and “canceled” should map to application behavior. Do not infer task completion from a polished natural-language message.

Timeouts, retries, and uncertain outcomes

MCP reads can often be retried safely. Side-effecting tools require idempotency keys or a status check. An A2A task may continue after the coordinator times out, so a network timeout does not prove the work stopped.

Define:

• client and server timeouts;
• maximum task duration;
• retryable error categories;
• idempotency or deduplication keys;
• task-status reconciliation;
• cancellation behavior;
• compensation for partial side effects.

If the legal specialist times out, the coordinator can query task status before starting a duplicate. If an invoice-send tool times out, it should check the operation ID before trying again.

Retries need a budget. Cascading retries across coordinator, A2A server, MCP server, and backend can multiply load and cost.

Failure boundaries

Classify failures by owner:

Local capability failure: the coordinator cannot read a required source. It may use a permitted fallback or stop with missing evidence.

Discovery failure: no compatible, approved agent is available. The application can route to a human or postpone.

Remote task failure: the specialist rejects, fails, or returns an invalid artifact. The coordinator should not present it as success.

Policy failure: the user or tenant cannot share the required data. Do not retry as a technical error.

Aggregation failure: components succeeded, but evidence conflicts or the final output lacks required citations. This is a coordinator-quality failure.

Preserve partial results with provenance, but do not silently downgrade success criteria.

Observability across MCP and A2A

Create one top-level execution context with child operations for:

• model decisions;
• MCP discovery and calls;
• approval events;
• A2A discovery and task operations;
• specialist status changes;
• artifact validation;
• final aggregation.

Record IDs, timing, status, error category, dependency, and result metadata. Avoid copying private prompts, full contracts, or credentials into every trace span.

Distributed trace headers may not flow through every protocol or organization. When they cannot, exchange a safe correlation identifier and link traces rather than pretending there is one continuous trust domain.

Metrics should include task success, tool success, specialist acceptance, end-to-end latency, approval wait time, retries, cancellations, cost, and failure category. Protocol uptime alone does not measure the workflow.

Data contracts and artifacts

Natural language is useful, but important handoffs need explicit structures.

The contract-review request might include:

• document identifier and version;
• analysis scope;
• approved playbook version;
• prohibited actions;
• deadline;
• required output schema;
• citation requirement.

The returned artifact might contain risk level, clause reference, issue, rationale, recommended action, and confidence. The coordinator validates this structure before aggregation.

MCP tool results and A2A artifacts should preserve source identity and version. That makes later evaluation and audit possible.

When using both is over-engineering

Do not add two protocols merely to appear “agentic.”

One protocol—or no protocol—may be better when:

• one application and one backend share a codebase;
• the workflow is a short synchronous function call;
• no independent remote agent owns a task;
• a stable internal API already solves the boundary;
• the operational cost exceeds interoperability benefits.

Protocols become valuable when independently owned systems need a durable contract.

Production review checklist

• Is each boundary clearly a capability or a remote-agent responsibility?
• Does the orchestrator—not the protocol—own workflow decisions?
• Are current server and Agent Card versions validated?
• Are identities audience-bound and permissions resource-scoped?
• Is sensitive cross-agent data explicitly approved?
• Does every important artifact have source and version?
• Are timeouts, retries, cancellation, and idempotency defined?
• Can failures be attributed to the correct boundary?
• Are traces correlated without leaking payloads?
• Is there a simpler architecture that meets the same need?

My Take

The cleanest MCP-plus-A2A architecture is asymmetric. The coordinator uses MCP for concrete local capabilities and A2A for a remote responsibility it cannot or should not implement itself. The specialist is free to use MCP internally without exposing that implementation to the coordinator.

That separation preserves autonomy without surrendering governance. Each side owns its tools, permissions, and execution. The application owns the user promise. The protocols make the boundaries understandable; production engineering makes the whole path reliable.

Sources

• MCP Specification, revision 2026-07-28
• MCP Architecture
• A2A Protocol Specification v1.0.0
• [MCP vs A2A](/mcp-vs-a2a/)