Three AI Agents. Three Frameworks. Zero Shared Code. One Protocol.
How A2A — the open standard already backed by AWS, Microsoft, Salesforce, and 150 more organizations — lets AI agents from any company, any framework, discover and work together over plain HTTP.
The Problem
You can build a great AI agent today. So can someone else. So can the team at a different company using a different framework.
Now try to make your agent work with theirs.
Without a shared standard, each connection between agents is custom work. You figure out their API, they figure out yours, and the integration breaks every time either side changes something. Scale this to hundreds of agents across dozens of companies and the whole thing becomes unworkable.
That is the problem the A2A protocol solves.
What A2A Is
A2A stands for Agent-to-Agent. It is an open protocol that defines a standard way for AI agents to discover each other, send each other work, and receive results back.
Google announced it on April 9, 2025. Two months later, Google donated it to the Linux Foundation so no single company would control it. Today more than 150 organizations support it, including AWS, Microsoft, Salesforce, SAP, and IBM.
Think of A2A like HTTP for agents. HTTP did not invent the idea of computers sending data to each other. It created a common language so any computer could talk to any other computer without custom wiring. A2A does the same thing for agents.
It runs over HTTP, uses JSON-RPC 2.0 for request formatting, and supports Server-Sent Events for live streaming — three standard web protocols that any server can implement.
The Agent Card
Every A2A-compliant agent publishes one document called the agent card.
The agent card is a JSON file that lives at a fixed address on every agent's server: /.well-known/agent.json. That address follows RFC 8615, an internet standard for well-known URIs. You have encountered this standard before. When iOS verifies that an app can open a link, it fetches /.well-known/apple-app-site-association from your website. Same standard, same idea.
The agent card contains four things:
- The agent's name and what it does
- The URL where it accepts work
- The authentication it requires
- The skills it offers
Any other agent in the world can fetch /.well-known/agent.json and immediately know how to work with that agent. No documentation, no SDK, no prior arrangement.
How Tasks Are Sent
Once an agent has read another agent's card, sending it work is a single HTTP POST request.
The request body follows JSON-RPC 2.0. It contains the task: a description, any input data, and a task ID so both sides can track it. The receiving agent does its work and returns a result as JSON.
For longer tasks, the receiving agent can stream progress back using Server-Sent Events. This is how real-time updates work in a browser: the server keeps the connection open and pushes messages as they arrive. The sending agent sees each update immediately rather than waiting for the full result.
How It All Fits Together
When Agent A needs Agent B to do something, the full exchange unfolds in four steps.
Agent A starts by fetching Agent B's agent card from /.well-known/agent.json. The card tells it the endpoint URL, what authentication Agent B requires, and what skills it offers. Agent A then constructs a task — a description, input data, and a task ID — and sends a single HTTP POST to Agent B's /a2a endpoint. Agent B processes the task and responds: either a complete JSON object when the work is done, or a live stream of Server-Sent Events for longer tasks so Agent A can see progress in real time. No setup, no SDK, no shared code between the two agents at any point.
A Real Example
I built a project called Codebase Explainer that uses A2A to connect three agents built on three different frameworks: Google ADK, LangGraph, and CrewAI.
Agent 1 runs on ADK and acts as the orchestrator. When it needs to analyze source code files, it fetches Agent 2's card at /.well-known/agent.json, reads where to send work, and POSTs the repository map to Agent 2's /a2a endpoint. Agent 2 runs a LangGraph loop, reading files and following imports. When it finishes, it returns the analysis as JSON.
Agent 1 then sends that analysis to Agent 3, a CrewAI crew that writes the developer onboarding kit. Three agents, three frameworks, zero shared code. A2A is the only connection between them.
Because every agent follows the same protocol, any one of them could be swapped out for a completely different service from a completely different company. The other two would not need to change a single line.
You can find the full project and source code on GitHub here, and the detailed write-up on the project page here.
Why This Matters
Right now, most AI systems are silos. One company's agent cannot talk to another company's agent without custom integration work on both sides.
A2A changes the model. An agent that follows the protocol can be discovered, called, and composed by any other A2A-compliant agent anywhere. The value of every individual agent goes up because it can be connected to everything else.
This is what happened to the web when HTTP became the standard. Suddenly every server could talk to every client. The ecosystem that built up on top of that single shared protocol changed everything.
A2A is early. But with 150 or more organizations already committed, it is moving toward that same kind of ubiquity for agents.
What Comes Next
The web became powerful when open standards meant any browser could load any website, regardless of who built either side. A2A is attempting the same shift for agents: any A2A-compliant agent discoverable by, and callable from, any other.
With the spec now under the Linux Foundation and 150-plus organizations already committed, that infrastructure is being built in the open. The most exciting part is what this unlocks: specialized agents from different teams and companies composing into systems far more capable than any one of them could produce alone. Every new A2A-compliant agent makes the whole network more powerful.