← Ayo Osunjuyigbe

· AI

A2A is for talking to other agents, not for calling Stripe

Monday, Agent2Agent moved under the Agentic AI Foundation. Same house as MCP, AGENTS.md, and goose. People will treat that as one stack and one problem. It is not.

I have an MCP server for Stripe. I do not have an A2A problem. I have a function call with a schema. The model in this process sees the tool description, the arguments, and the result. One prompt. One memory.

A2A is what you reach for when the other side is a different vendor’s agent, on a different box, and you have agreed not to share that prompt. Google said this on day one, 9 April 2025: complements MCP, does not replace it. The v1.0 blog said it again in March. Monday did not change the layer. It changed who stewards it.

What shipped

April was a draft and a hiring-manager demo. Capability discovery, a task object with a lifecycle, messages made of parts, an output called an artifact. Built on HTTP, JSON-RPC, SSE. Auth schemes with parity to OpenAPI. Long-running work that can take hours or days with a human in the loop. Not limited to text.

The key idea: agents collaborate in their natural modalities even when they do not share memory, tools and context. They were explicit that they did not want to limit the other agent to a tool.

June 2025 they donated the spec to the Linux Foundation. August, IBM folded BeeAI’s Agent Communication Protocol into it. One wire, not two camps.

12 March 2026, v1.0. Proto file is the normative data model. Three bindings — JSON-RPC, gRPC, HTTP/REST — supposed to mean the same Task. Version negotiation. Multi-tenancy on one endpoint. Agent Cards can be signed. The card itself stayed backward-compatible enough that a server can advertise 0.3 and 1.0 at once. The interaction protocol did not. If you are still speaking launch-draft JSON, you are not speaking 1.0.

Monday is just governance. Same layer. Their stack diagram is the sentence I needed: MCP is agent-to-tool, A2A is agent-to-agent.

The card is the handshake. The task is the contract.

Every A2A server publishes an Agent Card. In v1.0 that is /.well-known/agent-card.json, media type application/a2a+json. One GET. Name, description, skills, input and output types, whether it streams or pushes, which credentials it wants, which transports and protocol versions it speaks. The public card can be thin. If capabilities.extendedAgentCard is true, you authenticate with one of the schemes on the card and fetch a longer one.

That GET is not onboarding. It is also not a search engine. You already have a domain, or a registry handed you one. The card tells you whether to send work, and how.

Work is a Task with an ID the server owns. Eight states, not four, because delegated work can stop. Running: submitted, working. Paused: input-required, auth-required. Terminal: completed, failed, canceled, rejected. A paused task sits until you send another message with the same taskId — four seconds later or four days later. If the ask is small, the server can skip the task and reply with a Message.

You watch it three ways. Poll tasks/get — always there. Stream, if the card said it can. Push to a webhook, if it said that. After a push or a dropped stream, read the task again. The object on the server is the source of truth. The stream is a view.

A Message is a turn: role user or agent, one or more Parts (text, a file URL, structured data). An Artifact is the result you are supposed to keep. If the connection drops, you can lose a status line. You should not lose the artifact. The remote agent rebuilds context from the message, the task history it stored, and a server-issued contextId. It does not get your system prompt. It does not get your MCP tool list. Opaque execution is a spec principle, not a courtesy.

v1.0 signs the card — JWS over JSON Canonicalization Scheme (RFC 8785) — so you can tell who published those bytes and that nobody reordered them in transit. The spec does not pick your trust anchors. A valid signature on a card you should not have called is still a card you should not have called.

Wrapping the other agent as a tool is the bug

The temptation is obvious. MCP already has tools/call. Point it at ask the Workday agent. Return a string. Done.

That is the wrong object.

A Stripe charge returns. A SAP agent scheduling a background check returns input-required and waits for a human the other company employs. MCP’s happy path is milliseconds and a stack frame. A2A’s happy path is a task ID you can poll after your laptop closed. If you shove the second into the first, you either block the host until someone in another tenant clicks, or you lie and say the tool failed.

The other agent also cannot see your tools. That is the point. If you need it to just use my calendar MCP, you are not doing A2A. You are leaking a tool into a process you do not control. Give it a Part with the slots it is allowed to know. Keep the OAuth token.

Google’s own launch demo is the shape: a hiring agent talks to a sourcing agent, then a scheduling agent, then a background-check agent. None of those is create_charge. None of them share a context window. The artifact is a candidate list, an interview slot, a pass/fail. The task state is what you log.

An iframe in your thread is still your host. A remote A2A agent is their host. Different confirm. Different pin.

What I do now

I will put A2A on the agents I do not own. I will not put it on my own function calls.

Stripe, GitHub, the filesystem stay MCP. If I wrote the server and it lives in my allowlist, I want a schema and a confirm on the arguments. A2A is for when the other process is allowed to refuse (rejected), pause (input-required), or run until Wednesday.

Read the card before the first message. Hash it. If they sign, verify, then decide whether that key is one I installed. Pin supportedInterfaces, skills, and securitySchemes. A card that grew a skill overnight is a rug, same class as a poisoned tools/list. The description on the card will land in my model. Treat it as untrusted text that happens to look like a manual.

Send Parts, not a memory dump. No system prompt. No raw tool catalog. No customer blob the remote task will retain after completed. If the other agent needs a fact, it is in the message. If it needs a secret, the card’s auth scheme does that out of band, or the task goes to auth-required and I look at the domain before I continue.

The taskId is what I store. Poll if the stream dies. A push notification is a hint to call tasks/get, not a substitute for it. Do not send a follow-up onto a terminal task — the spec rejects that. New work, new task, or an explicit contextId the server already minted.

Do not wrap A2A as a synchronous MCP tool. If a host in my stack must expose talk to finance, the tool returns a task reference, not a fabricated completion. The human confirm is on the artifact and on any input-required that comes back, on a surface the remote agent did not draw.

I wanted one protocol for the model can use things. We have that. It is MCP. A2A is the other sentence: two agents, no shared prompt, a task ID, and a card I pinned. Monday put them in the same foundation. It did not make them the same call.

References