Unified agent architectures: A2A and MCP under the AAIF

The Linux Foundation AAIF and protocol convergence

When multi-agent systems outgrow single-process scripts, they run directly into two distinct integration boundaries:

1. How does an LLM reliably reach tools and structured data sources?
2. How do autonomous agents built on disparate frameworks collaborate across organizational boundaries?

Early on, developers attempted to stretch single protocols to solve both problems. Teams tried adapting Model Context Protocol into a cross-network agent negotiation layer, or using custom HTTP APIs that created vendor lock-in.

The sequence of events brought industry consensus:

• June 2025: Google contributed A2A to the Linux Foundation, and its specification is developed in the open in the a2aproject/A2A repository.
• August 2025: IBM's ACP joined forces with A2A, converging into the unified A2A protocol specification.
• December 2025: the Linux Foundation launched the Agentic AI Foundation (AAIF), anchored by Anthropic's MCP as the standard for model-to-tool connectivity, together with Block's goose and OpenAI's AGENTS.md.
• August 2026: A2A was accepted into the AAIF as a Growth Stage project, putting both protocols under the same governance.

Rather than competing, the standards divide cleanly along orthogonal axes.

North-South MCP vs East-West A2A

The mental model for modern enterprise agent design maps directly to classic network topology:

North-South: The MCP Execution Layer

• Direction: Vertical (Agent ↔ Tool / Internal Data).
• Control Pattern: Strict deterministic invocation. The agent model is the master; the tool is a passive capability.
• Scope: Private infrastructure behind the firewall—relational databases, internal ERP systems, filesystem access, local CLI utilities.
• Contract: A JSON Schema per tool describing parameters and return values, exchanged over JSON-RPC.

East-West: The A2A Collaboration Layer

• Direction: Horizontal (Agent ↔ Peer Agent).
• Control Pattern: Asynchronous goal delegation. The caller states what needs to be accomplished; the recipient decides how to achieve it.
• Scope: Cross-team, cross-company, and cross-cloud collaboration.
• Contract: The Agent Card (agent-card.json), defining identity, capabilities, natural language skills, supported interfaces, and security requirements.

LangGraph, CrewAI, and Google ADK interoperating

Before protocol convergence, an enterprise agent written in LangGraph could not easily delegate a task to a CrewAI research team or a Google ADK workflow without bespoke API shims.

With A2A as the external interface, each framework retains its own internal reasoning engine while sharing a universal way to be called:

1. LangGraph (Coordinator): Serves as the primary customer-facing agent, managing complex graph state cycles.
2. CrewAI (Specialized Team): Operates a multi-role crew for market analysis, exposing an A2A interface at https://crew.example.com/a2a.
3. Google ADK (Worker): Handles document parsing and translation pipelines.

When the LangGraph coordinator determines that market research is required, it:

• Reads the CrewAI Agent Card from /.well-known/agent-card.json.
• Inspects the skills array to verify that the agent handles the market-analysis skill.
• Dispatches a task using JSON-RPC over HTTPS.
• Receives real-time status updates via server-sent events (SSE).

The role of Agent Card in multi-agent networks

In this architecture, the Agent Card is the linchpin. It transforms an isolated agent into a discoverable node on the global agentic web:

• Identity & Provider: Confirms who owns the agent and links to trust credentials.
• Skills Declaration: Communicates natural language competencies and input/output modalities (text, audio, JSON payloads).
• Supported Interfaces: Declares protocol bindings (JSONRPC, HTTP+JSON, or gRPC) and endpoints.
• Security Schemes and Requirements: Details required authentication—such as OAuth 2.0 client credentials or mutual TLS—and which schemes a caller must satisfy.

You can inspect every attribute of the canonical v1.0 standard in our Agent Card schema reference.

Production deployment blueprint

When building enterprise agents on the A2A and MCP standards, follow this sequence:

1. Internal Tools: Implement your data connections using standard MCP servers. Keep these endpoints private.
2. Draft Agent Card: Assemble your agent-card.json declaring the public skills your agent offers to other teams.
3. Validate Metadata: Run your card through the Agent Card validator to verify interface compliance and eliminate common syntax errors.
4. Deploy Well-Known Endpoint: Host the file at /.well-known/agent-card.json with HTTPS, valid CORS headers, and appropriate cache control.
5. Establish Peering: Provide your agent's domain to external teams, allowing automated capability discovery without bilateral custom engineering.

Frequently asked questions

Why did IBM merge ACP into A2A?

To avoid fragmentation. Google's A2A and IBM's ACP both aimed at agent-to-agent interoperability, so in August 2025 IBM Research and Google announced that ACP would join forces with A2A under the Linux Foundation. ACP's lead joined the A2A Technical Steering Committee and ACP's concepts were contributed to A2A. That happened a few months before the AAIF existed, and A2A itself joined the AAIF in August 2026.

Can an agent consume MCP tools while exposing an A2A Agent Card?

Yes, this is the standard production pattern. Internally, the agent connects to private databases and APIs via MCP; externally, it advertises its high-level capabilities and endpoints to other agents via an A2A Agent Card.

How do LangGraph or CrewAI agents expose an A2A interface?

An agent wraps its graph or crew invocation logic inside an A2A server, describes itself in an Agent Card served at /.well-known/agent-card.json, and handles requests over one of the protocol bindings (JSON-RPC, gRPC or HTTP+JSON). Several frameworks ship helpers that do the wrapping.

How does security differ between MCP and A2A?

With MCP, the host application configures each server connection ahead of time, so trust is established per connection (remote servers use OAuth-based authorization). A2A agents are discovered by strangers across organizations, so the Agent Card itself declares the accepted security schemes and requirements (OAuth 2.0, OpenID Connect, API keys, mutual TLS) and can carry JWS signatures for integrity.

What tools help build and test this dual-layer stack?

AgentCard.net provides the schema explorer, generator, and validator for the A2A discovery layer, which integrates seamlessly alongside your existing MCP servers.

References

1. A2A protocol specification (a2a-protocol.org)a2a-protocol.org
2. A2A protocol repository (a2aproject/A2A)github.com/a2aproject/A2A
3. Model Context Protocol specificationmodelcontextprotocol.io/