How to Combine MCP and A2A in One Enterprise Agent Architecture

Define the decision rule before teams begin publishing endpoints. Otherwise, each product team will make a different interpretation and the architecture will drift.

Introduction

Best fit: Supply-chain coordination, managed services, partner workflows, and cross-company task delegation.

The well-known Agent Card endpoint is useful for protocol discovery, but enterprise callers should normally resolve agents through a trusted catalog or gateway. The catalog can validate signatures, apply allowlists, detect unauthorized card changes, and prevent direct trust in arbitrary endpoints.

Advantages: Consistent controls, easier support, shared tooling, simpler onboarding, and centralized evidence.

A2A and MCP produce different operational signals. The observability model must connect them without flattening them.

Multi-agent systems can easily copy the same prompt, conversation history, retrieved documents, and tool outputs across multiple services. That creates privacy, cost, retention, and prompt-injection risks.

Each business or technical domain operates its own agent runtime and MCP tool plane. A shared A2A catalog, identity federation, policy vocabulary, and telemetry standard connect the domains.

The Boundary That Keeps the Architecture Understandable

That creates two different interoperability problems.

A2A is also the correct place to preserve long-running task semantics. A downstream agent may return immediately, stream progress, expose a task for polling, or send asynchronous notifications. The caller should not have to pretend that every delegated outcome is a single synchronous function response.

The goal is not to connect everything to everything. The goal is to create controlled delegation between agents while keeping tool access narrow, explainable, and owned.

Shared does not mean one physical component. It means one control model, consistent policy vocabulary, common evidence, and clearly defined ownership.

This boundary is valuable for both security and organizational ownership. A finance agent can be operated by the finance platform team, a security agent by the security automation team, and an infrastructure agent by the platform engineering team. Each can maintain its own MCP servers, tool policies, evaluation suite, release cadence, and support model.

This distinction improves rollback, auditability, and change control. It also lets the operations agent replace one monitoring platform with another without changing the coordinator’s A2A contract.

The Enterprise Reference Architecture

Do not begin with unrestricted dynamic server discovery. Begin with an allowlisted registry and a small number of trusted agents.

Test denied paths as seriously as successful paths.

The Architecture Layers and Their Responsibilities

Experience and Entry Layer

The MCP plane provides structured tool and resource access inside an agent’s execution domain. MCP servers expose tools with names, descriptions, input schemas, and optional output schemas. Clients can list available tools and invoke the selected operation.

A gateway can deny a request early, but it should not be the only enforcement point. Otherwise, direct network paths, configuration errors, or gateway bypasses become authorization bypasses.

The mistake is building one generic gateway that treats A2A messages and MCP tool calls as interchangeable JSON traffic.

Coordinator Agent Layer

The A2A plane carries task-oriented communication between independent agents. It is where the coordinator discovers an agent’s declared skills, confirms supported interaction modes, sends a task, receives progress updates, handles multi-turn clarification, and retrieves final artifacts.

Introduce workload identities for every agent and server. Issue audience-bound tokens per resource. Preserve user context separately from workload identity. Add delegation-depth limits, tenant restrictions, data-classification rules, and approval evidence.

• decompose the request into tasks
• select approved agents from a trusted catalog
• attach the minimum context required for the delegated task
• define completion criteria and deadlines
• monitor task status
• handle clarification and authorization-required states
• combine returned artifacts
• present the final result or request human action

Some requests cannot be authorized entirely by static scopes. Production changes, financial commitments, data exports, account modifications, and destructive infrastructure operations may require a human decision.

A2A Collaboration Plane

Token passthrough collapses trust boundaries and makes audience, attribution, revocation, and least privilege harder to enforce. Each hop should obtain a token intended for the next resource.

A tool exposes a bounded capability. It normally has a defined input, a defined output, and a relatively narrow responsibility. A database query, ticket creation operation, document search, configuration check, or deployment action can be modeled as a tool even when the implementation behind it is complex.

The root trace should begin at the user or application request. A2A spans should represent agent selection, delegation, task state changes, streaming, retries, and artifact transfer. MCP spans should represent server discovery, tool listing when relevant, tool invocation, latency, error status, result size, and downstream dependency calls.

Agent Runtime Boundary

The MCP catalog should focus on executable capabilities:

A design that cannot answer these questions is not ready for broad dynamic discovery or autonomous execution.

Before approving a combined MCP and A2A design, confirm that the architecture can answer these questions:

MCP Tool Plane

Keep Authorization Decisions Local to the Resource

agent_policy: coordinator: operations-coordinator allowed_delegations: – target_agent: operations-domain-agent allowed_skills: – investigate-service-degradation – prepare-remediation-plan max_delegation_depth: 2 max_task_duration_minutes: 30 require_signed_agent_card: true

identity: preserve_user_context: true require_workload_identity: true token_strategy: audience_bound_per_hop prohibit_token_passthrough: true

mcp_policy: agent: operations-domain-agent allowed_servers: – observability-mcp – deployment-readonly-mcp – incident-management-mcp – remediation-mcp tools: remediation-mcp: execute_change: side_effect: destructive require_human_approval: true allowed_environments: – production max_invocations_per_task: 1

observability: propagate_trace_context: true capture_prompt_content: false capture_tool_arguments: redacted retain_policy_evidence_days: 90 retain_task_metadata_days: 30

Dynamic discovery is operationally useful, but discovery should never equal authorization. Finding an Agent Card does not grant permission to invoke the agent. Listing an MCP tool does not grant permission to call it.

A discovered Agent Card or MCP server description is a claim, not proof. Validate signatures where supported, resolve through trusted catalogs, enforce network policy, and require ownership and review metadata.

This reduces the blast radius of the coordinator. It also lets domain teams change internal tools without changing every upstream agent, provided the A2A skill contract remains stable.

• A2A message context: task goal, constraints, relevant business context, expected artifact, deadline, and correlation identifiers
• Agent-private state: planning notes, internal memory, model-specific state, intermediate reasoning, and private tool-selection logic
• MCP request context: exact tool name, validated arguments, purpose, authorization context, and trace identifiers
• Audit evidence: actor identities, policy decisions, tool and skill identifiers, timestamps, approvals, result classifications, and hashes or references to retained artifacts

The following YAML is not a protocol standard. It is an example of the policy metadata an enterprise control plane could use to govern an A2A-to-MCP workflow.

MCP standardizes the interaction, but the enterprise still owns the policy.

This layer should not be allowed to invent downstream permissions. It carries the user and workload context into the agent system, but the authorization service decides what that context permits.

The second is agent-to-agent collaboration. One agent needs to determine whether another agent can perform a task, delegate work, exchange context, monitor progress, handle clarification requests, and receive one or more artifacts. A2A fits this problem.

These identities are related, but they are not interchangeable.

An Illustrative Policy Configuration

The enterprise architecture should reflect that separation. A2A belongs between agents. MCP belongs between an agent and the tools inside its execution domain. Identity, discovery, gateways, policy, approvals, and observability must cross both layers without erasing their different semantics.

At minimum, capture:

Deployment Patterns for Different Enterprise Boundaries

Centralized Agent Platform

The coordinator should not receive broad credentials for every tool used by every downstream agent. That model turns orchestration into a privileged monolith.

In production, the MCP plane should be curated. An agent should not be allowed to connect to any server it can find. Approved MCP servers belong in a registry with ownership, trust level, allowed environments, data classification, required scopes, network policy, version, and review status.

The boundary is simple to state:

A2A discovery locates agents and their skills. MCP discovery locates servers, tools, prompts, and resources available to an agent. Combining these into one flat directory makes policy and ownership harder to understand.

Federated Domain Architecture

The tool catalog should be scoped to the receiving agent. A finance agent does not need to see every infrastructure remediation tool, and a customer service agent should not discover privileged security operations merely because they exist.

Agents that can freely delegate can create loops, excessive fan-out, cost spikes, and unclear accountability. Enforce maximum depth, maximum parallel tasks, time budgets, cost budgets, and approved target agents.

A2A supports task interruption and continuation patterns that fit this need. The domain agent can pause the task when authorization is required, return the reason and requested action, and resume only after the client supplies approved authorization. The underlying MCP tool call should not occur until the approval evidence is validated.

The agent catalog should store or index approved Agent Cards and enterprise metadata such as:

Partner and External Agent Boundary

The experience layer accepts requests from users, applications, event systems, or APIs. It authenticates the initiating principal, establishes the request context, applies intake controls, and selects the initial coordinator or domain agent.

Best fit: Organizations early in adoption that need strong standardization and a small number of platform-approved runtimes.

The first is agent-to-tool connectivity. An agent needs a consistent way to discover a capability, understand its input schema, call it, and validate the result. MCP fits this problem.

MCP and A2A both involve discovery, but they discover different things.

The practical starting point is not a large agent marketplace. It is one governed workflow with a clear coordinator, one domain agent, a small approved MCP tool plane, audience-bound identity at each hop, and a trace that proves what happened. Once that pattern is secure, observable, and operable, it can be repeated by domain.

Failure Modes That Look Convenient During a Pilot

Modeling Every Agent as an MCP Tool

The architecture below separates the user-facing orchestration layer, the A2A collaboration plane, the internal MCP tool plane, and the enterprise control services that govern both.

A coordinator with access to every tool becomes a high-value target and an operational bottleneck. Delegate to domain agents that hold narrowly scoped access to their own MCP plane.

Modeling Every Tool as an A2A Agent

Tradeoffs: Trust establishment, data minimization, residency, contract versioning, artifact validation, and external incident handling become critical.

An agent accepts a goal rather than only a function call. It may reason, plan, ask for clarification, select tools, maintain task state, produce multiple artifacts, or decide that it cannot safely complete the request. That autonomy and task lifecycle are what make A2A appropriate.

Passing the Original Token Through the Entire Chain

Advantages: Partner agents can collaborate without receiving direct access to internal tools or implementation details.

Trusting Discovery Metadata Automatically

Without shared correlation identifiers, operations teams see an A2A task in one system, several MCP calls in another, and downstream API events somewhere else. Preserve trace context and delegation identifiers across all hops.

Letting the Coordinator Accumulate Every Permission

The MCP gateway or broker can then apply controls such as:

Losing Trace Context at the Protocol Boundary

Central policy services are useful, but the resource still needs to enforce the result. The A2A server must authorize access to its skills and tasks. The MCP server must authorize tool discovery and invocation. The downstream API must authorize the action on the target resource.

Logging Everything for Debugging

Internal agents communicate with supplier, customer, or partner agents through an external A2A gateway. Internal tools remain hidden behind internal MCP boundaries.

Allowing Unbounded Delegation

Ownership should follow the trust boundary. The team that owns the domain agent should own its behavior and MCP tool set. The central platform should own interoperability and shared controls, not every domain decision.

A Phased Implementation Path

Establish the Protocol Boundary