A2A Protocol in Practice: Cross-Organization Agent Collaboration

APIs are rigid and deterministic. Agents are fluid and autonomous—and when you build a multi-agent system entirely in one framework, on one team’s infrastructure, you’ve built a silo. The whole point of agents is that they can work with other agents, built by other teams, on other frameworks, running on other servers.

That’s the problem the Agent2Agent (A2A) protocol solves. A2A is the open standard for agent-to-agent communication. It lets independent agents—built with ADK, LangGraph, CrewAI, or your own custom stack—discover each other, delegate tasks, and coordinate without sharing internal state, memory, or tools.

In this tutorial, you will learn how A2A works under the hood, how to expose an agent as an A2A service, and how to build a cross-organization workflow with discovery and secure delegation.

Prerequisites

• An agent built with any framework (this tutorial uses Google ADK)
• The A2A SDK for your language (Python and Go are 1.0 GA)
• Two agents on different frameworks for the cross-org demo

MCP and A2A: Complementary, Not Competing

Before writing code, get the mental model right. The A2A ecosystem splits cleanly in two:

• MCP (Model Context Protocol) is for agent-to-tool communication. It standardizes how an agent connects to its tools, APIs, and resources.
• A2A is for agent-to-agent communication. It lets agents discover each other, delegate tasks, and share results across framework and organizational boundaries.

If it’s a quick deterministic resource or action, it’s a tool (MCP). If you might end up with a conversation, it’s an agent (A2A). In practice, most systems use both: MCP inside agents, A2A between agents.

How A2A Works

A2A is JSON-RPC 2.0 over HTTP(S), designed with the architecture of the web in mind:

• Discovery via Agent Cards published at a well-known URL (/.well-known/agent-card.json).
• Synchronous request/response, streaming (SSE), and asynchronous push notifications for long-running tasks.
• Rich data exchange: text, files, and structured JSON.
• Opaque collaboration: agents coordinate without exposing their internal state, memory, or tools.

A2A v1.0 (stable, released March 2026 under the Linux Foundation) adds multi-protocol bindings, version negotiation, multi-tenancy, and Signed Agent Cards for cryptographic identity verification.

Expose an Agent as an A2A Service

Turning an ADK agent into an A2A service is nearly one line:

from google.adk.a2a.utils.agent_to_a2a import to_a2a

app = to_a2a(pricing_agent, port=8001)
# Serves the Agent Card at /.well-known/agent-card.json
# and the A2A JSON-RPC endpoints

Now any A2A-compliant client—in any framework, in any organization—can discover the pricing agent’s capabilities and delegate tasks to it.

Discovering Agents with Agent Cards

Agent Cards are the discovery mechanism. Each card describes a remote agent’s name, capabilities, connection info, and authorization scheme at a well-known URL:

{
  "name": "Pricing Agent",
  "description": "Quotes prices for supplier orders",
  "url": "https://pricing.internal.example.com",
  "capabilities": {
    "skills": [
      { "id": "quote", "description": "Get a price quote for an order" }
    ]
  }
}

Your agent fetches these cards to learn what each remote agent does, then routes queries to the right one at runtime. Adding a new remote agent is as simple as adding a new URL—no manual code changes or redeploys.

Client-side discovery and invocation with the a2a Python SDK:

import a2a.client

client = await a2a.client.create_client(agent_card_url="https://pricing.internal.example.com")
task = await client.send_task(
    message="Quote 500 units of SKU-1242 for delivery in 30 days"
)
result = await task.wait_until_complete()
print(result.artifact_list)

The Enterprise Wins

A2A isn’t just plumbing—it changes the architecture of multi-agent systems:

• The secure boundary. Specialized internal agents maintain their own secure environment. The requesting agent gets the high-value output while proprietary data and “how-to” logic stay encapsulated. A “black box” handoff that protects your secret sauce.
• Zero context pollution. Finite context windows fill up when one agent juggles every dependency. With A2A, specialized peers handle their own massive dependencies and internal state without cluttering the primary agent’s memory.
• Dynamic autonomy. When an agent calls an A2A peer, it initiates a collaboration—the receiving agent can understand intent, refine the plan, push back on incomplete requests, and ask clarifying questions.
• Workload distribution. Different parts of a solution can be built and managed by different teams or vendors who are domain experts, continuously improving their components.

Cross-Organization Delegation in Practice

Here’s the pattern that changes enterprise architecture: a primary agent delegates a long-running, specialized task to a remote A2A peer.

Imagine a research pipeline. Your primary agent manages the overall research. It needs protein structure modeling—work that lives in a specialized remote agent (like Google’s Foldrun). Instead of writing custom glue code:

from google.adk import RemoteA2aAgent, Agent

foldrun_agent = RemoteA2aAgent(agent_card_url="https://foldrun.example.com/agent-card.json")

research_agent = Agent(
    name="research_agent",
    instructions="Delegate protein modeling to the foldrun agent, then continue the pipeline.",
    tools=[foldrun_agent.as_tool()],
)

The primary agent stays free to manage the rest of the research pipeline while the remote specialist handles the heavy lifting—and the results come back over the standard protocol.

For flows that span multiple remote agents at once (checking price, quality, and delivery together), use the a2a-sdk directly to fan out across peers.

Security with Signed Agent Cards

Cross-organization collaboration is only trustworthy with identity. A2A v1.0’s Signed Agent Cards provide cryptographic verification of agent identity and metadata, establishing trust before interaction across organizational boundaries.

Combined with multi-tenancy (a single endpoint securely hosting many agents) and web-aligned security patterns, A2A gives enterprises the same load-balancing, gateway, security, and observability tooling they already use for web systems—applied to agents.

The A2Family

A2A isn’t alone. The open-source “A2Family” extends the same model:

• AP2 — Agent Payment Protocol for secure, interoperable agent commerce.
• A2UI — what to render when an agent interacts with a user.
• AG-UI — how to stream agent output to frontends with low latency.
• UCP — Universal Commerce Protocol connecting commerce systems.

Protocols solve one problem each. Adopt them as your requirements grow rather than building all of them on day one.

Putting It All Together

For the full A2A spec, SDKs, and multi-framework examples (ADK, LangGraph, AG2, CrewAI collaborating), see:

• https://a2a-protocol.org/latest/
• https://github.com/a2aproject/A2A

Conclusion & Next Steps

You now know how A2A enables cross-organization agent collaboration: expose agents via Agent Cards, discover peers over the standard, delegate long-running tasks, and secure it all with signed identity.

Next steps:

• Expose one of your existing agents as an A2A service and connect a client from another framework.
• Set up the MCP-inside / A2A-between architecture for a real system.
• Evaluate the AP2 and A2UI protocols for commerce or rich-UI use cases.

Agents become truly useful when they can collaborate across the boundaries that used to silo software. A2A is the common language that makes that possible.

References

• A2A Protocol spec and v1.0 announcement
• A2A on GitHub
• How A2A is building a world of collaborative agents
• Developer’s guide to AI agent protocols