What is A2A, the Agent2Agent protocol?

1. 1Discover. The calling agent reads the other agent’s Agent Card, a JSON document usually published at /.well-known/agent-card.json.
2. 2Send a message. It sends a message made of parts, such as text, a file or structured data, to the address on the card.
3. 3Work on a task. The receiving agent turns the request into a task with a state: submitted, working, input required, completed, failed, cancelled or rejected.
4. 4Get the result. The caller waits for the answer, asks for the task’s state later, or follows its progress as a stream of server-sent events. Some agents can also call back a webhook when the task changes.

The protocol runs over HTTPS. Its main binding is JSON-RPC 2.0; gRPC and a plain HTTP and JSON binding exist too.

An Agent Card is an agent’s public description. It gives the agent’s name, a description, its skills, the address to call, the protocol versions it speaks, and how callers must sign in. A calling agent, or a person setting one up, reads the card to decide whether the agent can help and how to reach it.

Because the card is text that shapes what the caller does, a card that changes without warning deserves the same suspicion as a changed tool description. Good platforms notice when a card changes.

They solve different problems and work well together. MCP connects an agent to tools; A2A connects an agent to another agent.

• Connects

  MCP

  An agent to tools and data

  A2A

  An agent to another agent

• The other side

  MCP

  A tool that does one thing and returns

  A2A

  An agent that reasons, may take many steps and may ask questions

• Description

  MCP

  A list of tools with input schemas

  A2A

  An Agent Card with skills

• One request is

  MCP

  A tool call

  A2A

  A task with states, which can take time

• Typical use

  MCP

  Read a CRM record, post a message

  A2A

  Ask a partner’s agent to plan a delivery

MyDeepAgents speaks A2A in both directions, in versions 1.0 and 0.3 over the JSON-RPC binding. It answers each caller in the version the request names.

Outside agents are agents at other companies that your agents can call:

• You add one by its card’s address or its base address; the platform tries /.well-known/agent-card.json, then the older /.well-known/agent.json.
• Sign-in is none, a bearer token or custom headers, and it is tested before the agent is saved.
• The card you accept is pinned by a SHA-256 hash. If the other side changes its card, calls stop until a person accepts the new one.
• Your agent sees the outside agent as one tool that sends a message and waits for the task to finish. A message is never sent twice by a retry.
• Calls follow the same approval settings, policy and outbound network checks as other tools. The call log keeps the outcome and timing for 30 days, never the message or the answer.

Shared agents are your own agents, offered to others:

• You share an agent at its live or staging version, and it gets its own address and Agent Card.
• Callers sign in with keys you issue, shown once and stored only as a hash, or you leave the agent open.
• Callers can send a message, stream the answer, check, list and cancel tasks, and subscribe to a task’s updates.
• Each shared agent has a limit on requests per minute and a daily spend cap. Each task is an ordinary run of your agent, so its own tools, approvals and limits apply.

The Agent network map in the console shows which of your agents work with which, inside and outside the company.

• Make callers sign in, and give each caller its own key so you can revoke one without the others.
• Treat messages from other agents as untrusted input, like an email from a stranger.
• Give a shared agent only the tools its callers should reach, and put approvals on writes.
• Cap what a shared agent may spend, and limit how often it can be called.
• Pin the cards of outside agents and review changes before trusting them again.