Your vendor emails to say their agent already speaks A2A and yours can plug in tomorrow. It sounds like plumbing, an afternoon of engineering. But the moment two agents from two different organizations negotiate a task — an order, an appointment, a complaint — the question that matters stops being how the messages travel. It becomes who answers when the message is right and the outcome is wrong.
The thesis in one line: the A2A protocol for agents between companies solves transport and leaves the real problem untouched, which is contractual. For almost every small and mid-size business, today, the decision isn't technical: it's what you sign with whoever runs the other agent, what permissions you give yours, and how you'll reconstruct a conversation neither side can see in full.
The A2A protocol and AI agents between companies: what it solves and what it leaves open
A2A (Agent2Agent) is an open protocol that lets one agent hand work to another without knowing how it's built inside. It started at Google, and on April 9, 2026 the Linux Foundation announced version 1.0, the first stable specification, with more than 150 supporting organizations according to the foundation itself. Mind the number: it comes from a press release by the people promoting the standard, and it measures backing, not production use.
It has two main pieces. The “agent card”, a document that says who the agent is, what it can do and how to authenticate, and which in 1.0 can be signed. And a task lifecycle with standard states: working, completed, failed, rejected, waiting for input, waiting for authorization.
What it doesn't do weighs as much as what it does. According to its specification, each agent collaborates without access to the other's internal state, memory or tools. That's a technical virtue — each side protects its implementation — and it's also the governance problem: your vendor's agent is a black box to you by design, and yours is one to them.
| Question | What A2A gives you | What's left for your contract |
|---|---|---|
| Who is the other agent? | Agent card, which can be signed | Who issues it and who answers for its being truthful |
| How is work requested and delivered? | Standard messages and task states | What counts as “delivered” and how long you have to dispute it |
| Who can ask for what? | Authentication and authorization schemes common on the web | What scope is granted, to whom, and how it's revoked |
| What if it gets it wrong? | “Failed” or “rejected” states | Who absorbs the error when the task shows as “completed” and is wrong |
| How is it audited? | Nothing specific | What each party records and for how long |
That last column isn't just our opinion. The specification sticks to the protocol and leaves trust, accountability and audit between organizations to whoever deploys it, and independent industry analysis agrees that security between organizations is the unresolved question.
How is A2A different from MCP?
Short answer: MCP connects your agent to your tools; A2A connects your agent to another organization's agent. With MCP you decide which tools exist, what they do and which credentials they use; we explain it in what MCP is and why it changes enterprise agents. With A2A, on the other side there's someone who decides on their own, with their own model, their own mistakes and their own change calendar. It's the difference between buying a tool and subcontracting a workshop.
A hypothetical example, no names
A customer's purchasing agent asks its distributor's sales agent to “restock this material at the best price”. The second replies with a price and a lead time, and the task is marked completed. Is that price binding? Is the lead time a commitment? Who checked that the distributor's agent used the right price list? None of that travels in the message. All of it is contract, and if it isn't written down, whoever complains loudest decides it.
Four contract questions before you connect your agent to a third party's
1. Who answers for the outcome?
When the task arrives as completed and the result is wrong — a mis-confirmed price, a double booking, an order for the wrong quantity — the protocol has no opinion. The contract must: what counts as delivery, who verifies it, and how long there is to contest it.
2. What happens if the other side's agent gets it wrong?
Your agent acts on what the other one tells it. If the other invents a delivery date and yours promises it to your customer, the mistake is already yours in the customer's eyes. Decide in advance what your agent may do alone with an external answer and what needs human confirmation: it's the logic of the levels of agent autonomy, applied to a source you don't control.
3. How do you audit a conversation between two black boxes?
Each party sees only its half. To reconstruct what happened you need to keep what your agent sent, what it received, under which identity and with what result, and agree that the other side keeps theirs for a set period. Without that, the first dispute gets settled with two incompatible stories. The foundation is traceability of AI decisions; for the retention period, how long to keep AI agent logs.
4. What can each side ask for, and how is it revoked?
An agent that talks to the outside opens a new surface. Give it its own identity, scope per task and a revocation you've tested, as the guide to AI agent permissions lays out, and demand the same from the other side. A signed agent card proves who the agent is; it doesn't prove it deserves the scope it asks for.
When you DON'T need A2A (yet)
Three situations where adopting it means getting ahead of a problem you don't have:
- The other side offers a normal API. If your customer or vendor exposes a service with defined inputs and outputs, a classic integration is cheaper, easier to audit and doesn't depend on two models understanding each other. A2A pays off when the work is open-ended and involves negotiation, not when it's a query with a closed answer.
- All your agents live inside your company. Internal coordination is solved with orchestration, not with a standard between organizations. Start with orchestrating several AI agents and by asking whether you need one agent or many.
- Nobody has asked your agent to talk to another. A protocol with plenty of supporter logos doesn't equal plenty of production use cases: industry analysis itself separates backing a standard from keeping it in production after the first real incident.
What to do this week
- Ask your key vendors whether their agent offers A2A and what it offers today through an API. If the answer is “we're evaluating it”, you know the timeline.
- For the first candidate case, write the four questions above with names attached: who verifies, who absorbs the error, what gets recorded and what scope is granted.
- Define which decisions of your agent need human confirmation when the data comes from outside, and test it with a deliberately wrong answer.
- Check that your log keeps what was sent and received, with the identity of the agent that acted. If it doesn't, fix that before opening any connection.