Unified agent architectures: A2A and MCP in practice 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 establishment of the Agentic AI Foundation (AAIF) under the Linux Foundation brought industry consensus:

• IBM's ACP joined forces with Google's A2A, converging into the unified A2A protocol specification, now hosted under the neutral governance of the a2aproject/A2A repository.
• Anthropic's MCP became the foundation's standard for model-to-tool connectivity.

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: JSON-RPC schema describing parameters, arguments, and synchronous return values.

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.json), defining identity, capabilities, natural language skills, streaming interfaces, and mutual authentication.

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.

Under the AAIF standards, each framework retains its unique internal reasoning engine while sharing a universal external interface:

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.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: Details required authentication—such as OAuth2 client credentials or mutual TLS.

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

Production deployment blueprint

When building enterprise agents that adhere to the AAIF 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.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.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.

Perguntas frequentes

Why did IBM merge ACP into A2A under the Linux Foundation?

To eliminate industry fragmentation. With both Google's A2A and IBM's ACP aiming to solve agent-to-agent interoperability, uniting under the Linux Foundation's AAIF established a single open standard backed by the entire ecosystem.

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 a lightweight HTTP JSON-RPC server, registers its capabilities in an agent.json document at /.well-known/agent.json, and serves requests according to the A2A protocol.

How does security differ between MCP and A2A?

MCP assumes a pre-configured local or trusted session between the host and its tools. A2A traverses open network boundaries, requiring declarative security schemes (OAuth2, OIDC, API keys) and cryptographic JWS signatures in the Agent Card.

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.

Referências

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/