Back to the journal
Protocol Deep DiveMarch 2026

A2A Protocol Explained. Why AI Agents Need Their Own Language.

MCP lets agents use tools. A2A lets agents talk to each other. That's a fundamentally different thing, and it's about to change how we build software.

MD

Marine Depoorter

Builder — 0toprod / A2ABay

Published

Mar 27, 2026

Reading time

8 min read

AGENT ACrewAI · PythonCompany XOPAQUE INTERNALSA2A PROTOCOLAgent CardsTask NegotiationStreaming / SSEPush NotificationsRich Data Exchangev0.3 · Linux FoundationAGENT BLangGraph · TypeScriptCompany YOPAQUE INTERNALS
A2A: agents talk as peers, not tools

The problem nobody talks about

You have a CrewAI agent that handles invoicing. Your colleague built a LangGraph agent that does customer support. Your ops team has a Google ADK agent for inventory tracking. Each one works fine on its own.

Now make them work together.

That is the problem. Today, every AI agent is a walled garden. Different frameworks, different languages, different companies. They cannot discover each other, negotiate, or collaborate without custom glue code that breaks as soon as one side changes.

MCP solved the agent-to-tool problem. An agent can now call Stripe, query a database, or read a file through a standard protocol. But MCP still treats everything as a tool: a function that takes input and returns output.

Agents are not tools. They have state, capabilities, and constraints. They can ask for clarification, stream progress, fail gracefully, or push back. They need to communicate as peers, not as master and servant.

That is what A2A does.

MCP gave agents hands. A2A gives them a voice.

MCP

Agent → Tool

Call this function with these parameters and give me back the result.

  • One-way communication
  • Stateless
  • Tools are transparent
  • Synchronous by default

A2A

Agent ↔ Agent

Here's what I need. Here's what I can do. Let's figure this out together.

  • Bidirectional conversation
  • Stateful task lifecycles
  • Agents stay opaque
  • Async, streaming, and push-based

How A2A actually works

A2A is surprisingly simple. There are three core concepts: Agent Cards for discovery, Tasks for work, and Artifacts for output.

The three pillars of A2A

Agent Cards, Tasks, and Artifacts

  • 01

    Agent Cards

    Every A2A agent exposes a JSON business card, typically at /.well-known/agent.json, describing skills, interaction modes, and auth requirements.

  • 02

    Tasks

    The unit of work. A client agent submits a task and the server agent processes it across a lifecycle, potentially over long-running async execution.

  • 03

    Artifacts

    The output layer. Tasks can return files, structured data, text, images, or multiple streamed results packaged as artifacts.

Why opacity matters

The protocol handles authentication, error handling, streaming, push notifications, and format negotiation, while keeping agents opaque.

Agent A does not need to know how Agent B works internally. It only needs the Agent Card to understand what B can do and the Artifacts to understand what B produced. That is what makes interoperability possible across different frameworks, languages, and companies.

150+

Partner organizations

v0.3

Current spec version

40+

SDKs available

Who's backing this

A2A was created by Google and donated to the Linux Foundation in February 2026. But it is not a Google-only project. Microsoft, Salesforce, SAP, IBM, Cisco, Adobe, PayPal, Atlassian, Deloitte, Accenture, and major cloud vendors are already involved.

Official SDKs exist for Python, Java, and .NET. Community SDKs cover TypeScript, Go, Rust, and more. Cisco has already built an open-source A2A security scanner, and the protocol is already the subject of dedicated courses.

The momentum looks a lot like MCP did in its early phase, except A2A has stronger institutional backing earlier in the curve.

What you can build with A2A today

The protocol is not theoretical. Real projects already use it for multi-agent commerce, coding workflows, marketplace coordination, and security analysis.

Multi-agent commerce

Official demos already show agents built in different frameworks coordinating purchasing flows through A2A.

Coding agent networks

Coding agents can now be orchestrated by QA, planning, or review agents rather than staying trapped in one closed workflow.

Agent task markets

Agents can register, negotiate work, and complete jobs for each other inside shared marketplaces and orchestration layers.

Security scanning

Security is already first-class. Open tooling exists to inspect A2A implementations and surface protocol-level risk.

Why this matters for builders

If you are building AI agents with CrewAI, LangGraph, AutoGen, Google ADK, or plain Python, A2A is the protocol that lets your agent participate in a broader ecosystem instead of staying an isolated island.

Make your agent A2A-compatible and it becomes discoverable, orchestratable, and hireable by other A2A agents. That is the difference between building a local app and building for a real network.

The ecosystem is still early. There are only a few dozen visible A2A-compatible agents, SDKs, and tools compared with the enormous MCP landscape. That is exactly why this moment matters.

If you have built something that speaks A2A or could benefit from it, there is already a marketplace where builders list, share, and sell their agents: A2ABay.

MCP plus A2A is the full stack. MCP for tools, A2A for agents. Use both.

Browse A2A agents, SDKs, and tools.

Curated by hand. Filterable by framework, language, and category. Sellers list for $6 and keep 93% of sales.

A2A Protocol Explained. Why AI Agents Need Their Own Language. | A2ABay