A2A Protocol Integration With MCP in Enterprise Pipelines

Enterprises building multi-agent pipelines are not fighting one integration problem. They are fighting two that look similar and behave completely differently. One is about connecting agents to tools. The other is about connecting agents to each other. Conflating them is the fastest route to a pipeline that cannot be governed.

Why enterprises building multi-agent pipelines face two distinct integration problems, not one

The hard part of multi-agent systems is not the agent. It is interoperability. Every new connection between an agent and a tool, or between one agent and another, tends to require custom code. That glue multiplies with each addition. At fifty agents, the count becomes unmanageable.

The two problems have different shapes. Vertical fragmentation is an N×M connector problem. Every model that needs to reach a set of tools does so through its own method: a REST call wrap here, an SDK wrapper there, direct SQL elsewhere. Horizontal fragmentation is an N×N coordination problem. Agents built on LangChain, CrewAI, and AutoGen have no shared language for delegating work to each other, so every agent-to-agent path needs its own adapter. The integration surface grows combinatorially as the agent count rises.

This distinction matters because the remedies are structurally different. A universal tool interface solves vertical fragmentation. A shared agent-to-agent coordination protocol solves horizontal fragmentation. The result is not a platform. It is a pile of point-to-point integrations that nobody can audit end to end.

What MCP actually is and what problem it was built to solve

MCP, the Model Context Protocol, is the answer to vertical fragmentation. Anthropic released it as an open standard in November 2024. OpenAI, Google, and Microsoft adopted it, and AWS added support in November 2025. The protocol is now governed by the Agentic AI Foundation under the Linux Foundation, with membership spanning Anthropic, OpenAI, Google, Microsoft, AWS, Block, Cloudflare, and Bloomberg.

The architecture is a client-server model. The agent runtime operates as an MCP client. Each external capability is wrapped by an MCP server. The wire format is JSON-RPC 2.0, with stdio for local transport and HTTP for remote connections. This is deliberately simple. A single agent can reach a database, an API, a file system, and a code execution environment through the same interface, rather than learning four different access patterns.

The 2026-07-28 specification marks the most significant protocol change since launch. It removes transport-level session management entirely. The result is a stateless core that runs on ordinary HTTP load-balanced infrastructure. The GitHub MCP Server has already migrated, eliminating its Redis session storage. That change is what makes the protocol feasible if you run horizontally scaled gateway infrastructure.

The scope is precise. MCP covers structured, atomic interactions: agent-to-database queries, API calls, file system access, code execution. Inputs have explicit schemas, return values have fixed formats. An MCP server is a passive component. It responds to tool calls, has no independent agency, cannot initiate actions, and cannot further delegate work. These omissions are structural, not gaps to be fixed. They define the boundary of the protocol.

What A2A actually is and what MCP's scope limits required someone to build

A2A answers horizontal fragmentation. Google Cloud announced it at Google Cloud Next in April 2025 with more than 50 partner organizations, including Atlassian, Box, Cohere, Intuit, MongoDB, PayPal, Salesforce, and SAP. The protocol was donated to the Linux Foundation in June 2025. By April 2026, participating organizations numbered more than 150.

The protocol rests on four primitives. The Agent Card is a JSON document published at a well-known URI describing an agent's capabilities, input and output formats, authentication requirements, and service endpoint. It functions as the discovery mechanism, analogous to OpenAPI for REST. Terminal states are final, and subsequent work requires a new task within the same contextId. Streaming lets long-running tasks deliver partial results via Server-Sent Events, so you get intermediate progress before the full task completes.

The structural distinction matters for governance. An A2A endpoint is an active agent operating under its own identity and policy posture. It may have its own MCP-backed tool surface. The responding agent is a principal, not a passive responder. That maps to how enterprises actually want to compose agents across team and vendor boundaries.

How MCP and A2A compose into one stack rather than compete for the same role

The two protocols are not alternatives. They operate at different layers of the same stack. A production multi-agent system needs both. A2A handles agent coordination.

What has emerged by mid-2026 is a three-layer architecture. The first layer is tool integration, vertical, handled by MCP. It governs how a single agent connects to external capabilities. The second is agent coordination, horizontal, handled by A2A. It governs how agents discover each other, negotiate tasks, and exchange results, no matter the org or framework boundary. The third layer is cross-cutting: identity and trust, built on OAuth 2.1, Agent Cards, and W3C DIDs. This is how agents prove identity and verify counterparties on both lower layers.

In practice, each specialist agent operates as an MCP client internally, reaching its tools through MCP servers, and as an A2A peer externally, discoverable by and delegating to other agents through Agent Cards and Tasks. One agent, two roles, each on a different layer. The division holds.

An interoperability gap remains as of mid-2026. An MCP server cannot yet be directly consumed as an A2A skill, even though the concepts map closely. Teams maintain dual implementations: one MCP server for tool access, one A2A endpoint for agent-facing delegation, for each service. The joint MCP/A2A interoperability specification expected from the AAIF in Q3 2026 aims to close this. The gap is a known constraint to design around, not a reason to delay.

How do you enforce fine-grained permissions when agents delegate to other agents?

Both protocols define communication standards for a governed multi-agent system. Neither delivers end-to-end enterprise governance out of the box. You have to build audit trails, SSO integration, permission inheritance, and DLP enforcement on top. The 2026 MCP roadmap identifies four enterprise readiness gaps explicitly: structured audit trails and observability that plug into existing SIEM and APM infrastructure, enterprise-managed authentication with SSO-integrated flows, gateway and proxy patterns including authorization propagation and session affinity, and configuration portability across clients.

The current production baseline is sobering. Astrix Security found that the majority of MCP servers rely on static credentials rather than OAuth. At production scale it becomes a CISO-level problem. The data exposure risk is concrete. Every Slack channel and DM becomes an AI-readable surface. Tool calls carry PII, PHI, credentials, and intellectual property that traditional DLP was not built to inspect at the MCP layer.

The permission inheritance problem is the one that decides whether an orchestration platform can answer the buyer question at all. When a user triggers an agent that delegates to a second agent via A2A, and that second agent makes an MCP tool call, the question of whose permissions govern the final data access must be answered at design time. The protocols do not propagate user-level access controls through delegation chains on their own. A permission check at login is not the same as a permission check at the terminal data read. The governance layer that MCP and A2A leave to the implementer is delivered as infrastructure, not a bespoke build for each deployment.

How Pinterest's production MCP deployment shows what governed implementation actually requires

Pinterest's deployment is the most fully documented enterprise MCP implementation in production. What it shows is that the architectural decisions determining governance outcomes are not in the protocol spec. They are in how you structure the registry, the ownership model, and the access controls around it.

Pinterest built several domain-specific MCP servers, one for Presto, one for Spark, one for Airflow, and one for general institutional knowledge. Every client, human or agent, must pass through a central registry. No server reaches production without appearing in that registry under an owning team. A mandatory review gate requires Security, Legal/Privacy, and, where applicable, GenAI review tickets to be approved before any server goes to production. With JWT-based authorization and business-group access gating, not every employee or agent can call every server. Designated action categories carry human-in-the-loop safeguards.

The critical distinction is what Pinterest's registry answers. It answers: of the servers our own company runs against our own data, which are approved for production, who owns them, and what is any given employee or agent allowed to do through them. A public MCP registry answers none of those questions. Public registries solve discovery for open-source packages. They do not solve enterprise governance.

Department-specific patterns for composing MCP and A2A in production

The same two-layer stack produces different implementation patterns, and that depends on tool surface, data sensitivity, and coordination needs. Engineering teams work through the GitHub MCP Server, which gives read and write access to code review, issue triage, and repository queries in the same surface where engineers already work. By mid-2026, every major agent runtime, including Claude Code, Codex CLI, Cursor, Cline, Windsurf, and Gemini CLI, speaks MCP natively. A typical platform team pattern for a 50 to 500-engineer organization runs in a predictable sequence: broad Claude Code or Cursor rollout, then an MCP firewall once leadership raises concerns about secrets and deployments, then approval gates, then a model gateway once finance notices the bill. The A2A coordination need is a code-review agent delegating to a security-scan agent or dependency-audit agent without a human orchestrating the handoff.

RevOps and sales teams connect through Salesforce. The Salesforce Hosted MCP Server is the recommended path on Enterprise Edition or higher, with Developer Edition orgs receiving access at no cost. The same CRM data surface reaches every AI tool the sales team uses. The A2A coordination need is a pipeline-analysis agent delegating a contract-review subtask to a legal agent without either exposing its internal context to the other.

Support teams work through the Intercom MCP server, which exposes conversations, contacts, companies, and Help Center articles. Without a DLP layer operating at the MCP level, every support conversation containing PHI, PCI, or customer PII is reachable by any connected agent. The A2A coordination need is a triage agent delegating a complex ticket to a specialist engineering agent and receiving a structured response it can translate back into customer language.

Slack became a multi-surface deployment point when Slackbot's MCP client reached general availability in June 2026. It connects any MCP-compliant app to Slackbot, creating a single conversational interface across a unified tool surface. The governance model applies user-specific data boundaries in real time: if a user lacks credentials for a restricted source, Slackbot blocks the request automatically. IT administrators get a centralized surface to discover, install, manage, and audit access approvals. Atlassian's integration exceeded 15 million calls a day as of mid-2026, scoping access by toolset rather than broad product access, with read and write permissions managed separately. Team-scoped MCP provisioning sits naturally on top of these patterns. Each team gets its own scoped MCP surface that plugs into any agent or chat surface, with no UI to build or maintain.

The phased adoption path enterprises should follow and the architectural decisions that cannot be deferred

The lowest-risk enterprise path is to establish MCP-governed tool integration first, then introduce A2A coordination incrementally as agent count and coordination complexity justify it. Certain architectural choices made during MCP rollout will enable or constrain A2A adoption later. Phase 1 is the MCP foundation, and its decisions cannot be deferred. Stand up an internal MCP registry before servers proliferate. The registry must answer ownership, approval status, and per-role access, not just discovery. Adopt the 2026-07-28 stateless spec from the start. The session-affinity infrastructure required by earlier specs creates scaling debt that is expensive to unwind. Enforce OAuth rather than static credentials at the gateway level. Define team profiles in the gateway so permission scoping is a configuration decision, not a per-server engineering task. Engineering gets GitHub, Jira, and CI.

Phase 2 introduces A2A. Publish Agent Cards for each domain agent. The card declares capabilities and auth requirements without exposing internal tool surfaces or reasoning. This is the minimum A2A footprint. Start with synchronous delegation for well-defined subtasks before introducing asynchronous long-running patterns. Route A2A traffic through the same API gateway infrastructure you use for MCP. Until the joint MCP/A2A spec ships, plan for dual implementations per service and treat them as a temporary architectural cost, not a design flaw.

Three decisions determine long-term governance quality at both layers. First, audit trail routing: MCP tool calls and A2A task messages must be logged in formats that feed existing SIEM and APM infrastructure. Designing this in from the start is far cheaper than retrofitting it after a compliance inquiry. Second, permission propagation through delegation chains: when a user triggers an orchestrator that delegates via A2A to a specialist that makes MCP tool calls, the terminal call must reflect the originating user's permissions. Third, skill reuse versus skill sprawl: five teams rebuilding the same prompt or MCP server configuration compounds real cost. A shared skill registry with version control and access scoping converts that rebuild tax into reusable infrastructure.

The protocols handle communication. Governance is what you build on top. Enterprises that build it as infrastructure from the start are the ones that can scale agent coordination without fragmenting control.