Agent to Agent Communication Protocol Explained

Your agents aren’t talking to each other. You are. Here is the protocol built to fix that, and why understanding it before you need it is the only move that makes sense.

Most ops leaders didn’t set out to become the connective tissue between their tools. They bought into AI to get time back, not to spend their afternoons copying outputs from one tab into another. Yet here we are: the agents are running, the tools are producing, and someone still has to carry the baton between them. The common assumption is that this is simply the current state of the art, that you build agents to do individual tasks and connect them manually or with a workflow builder, and that’s just how it works with AI right now. See our AI teammates for how this works in practice.

The Fragmented SaaS Stack: 291 Tools That Don’t Talk to Each Other According to Zylo’s SaaS Management Index, the average organization runs 291 SaaS applications. Each one solves a narrow problem. Each one stops at its own edge. What gets called a “multi-agent workflow” in most ops environments is really a collection of single-purpose tools that take turns, not a team that collaborates. The recruiting AI screens resumes. The scheduling tool books interviews. A human carries the shortlist between them, because nothing else will.

291 SaaS apps the average org runs

The failure point is always the same place: the gap between tools. One agent finishes its slice of work and produces an output.

The next agent starts fresh, with no knowledge that the first one ever ran. The nuance in the screening notes, the candidate ranking logic, the reason one applicant was flagged over another, none of it transfers. This isn’t a minor inconvenience. It means every handoff is a lossy compression of the actual decision.

The Missing Agent Handoff Layer - Why Humans Become the Integration A common assumption is that keeping a human in the loop between AI tools is a deliberate design choice, a quality-control measure. In practice, it’s almost never a choice. It’s what fills the absence of a shared agent handoff layer. When two tools share no common protocol for passing task state, the only entity that knows both results exist is the person running both tabs. They become the integration layer by default, not by design.

Key takeaways

• The human standing between two AI agents isn’t a workflow choice, it’s a protocol gap, and A2A is what closes it.
• Google’s Agent2Agent protocol replaces five manual handoff steps, finding, confirming, delegating, monitoring, and collecting, with a structured machine-to-machine sequence.
• A2A and MCP are not competing standards; they do different jobs. MCP connects agents to tools; A2A connects agents to each other. You need both or you’re still forwarding outputs by hand.
• Every agent handoff that skips identity verification is architecturally identical to routing sensitive task data to an unknown external party, a structural exposure, not a settings problem.
• A multi-agent hiring stack, sourcing, screening, scheduling, offer, only stops needing a human relay when each specialist agent can hand work to the next one directly. A2A is what makes that handoff automatic.
• The right buying question isn’t what each agent can do in isolation; it’s whether they can coordinate without you in the middle.
• SkyDive builds AI teammates that communicate across that entire handoff chain, reachable through Slack, email, iMessage, and web chat, so the bench of specialists actually functions as a team instead of a set of disconnected tools.

What Is the A2A Protocol and What Problem It Was Actually Built to Solve

That shared language is the Agent2Agent (A2A) protocol, and what it actually does is narrower and more precise than the term “protocol” tends to suggest to most technical teams evaluating AI infrastructure.

“Most developers building production agents haven’t hit a problem that actually requires agent-to-agent communication.”

Here is a thought experiment. Imagine you hired five specialists, put them in separate rooms, and then personally walked between every room to relay what each one said to the next. That is not a team. That is you doing the coordination work while the specialists wait. The “tools don’t talk to each other” problem most ops leaders hit is a protocol gap, and it compounds silently every time another agent gets added to the stack, staying invisible precisely because people normalize absorbing it.

That normalization has a scale problem. The average organization already juggles anywhere from 130 to 291 SaaS applications with no shared handoff layer, which means the human relay between systems is not an edge case: it is load-bearing infrastructure.

*Key takeaway: When A2A entered production at more than 150 organizations within its first year, the coordination layer it replaced was the manual, human relay between agents, closing handoff seams that had stayed invisible only because teams had learned to absorb them.*

150 orgs using A2A in its first year

Most developers building production agents today haven’t yet hit the wall that A2A was built for. The core problem, agents that need to discover each other, delegate work, and hand off state reliably, doesn’t announce itself until your stack gets complex enough that a single agent can no longer own an entire workflow end-to-end.

By the time teams feel it, the back-and-forth coordination overhead has already become a tax on every high-impact decision they should be making instead. That invisible tax is what a protocol-level solution addresses, and it is why understanding A2A precisely, as a defined interoperability contract, matters before you need it.

The One-Line Definition

Agent2Agent (A2A) is an open protocol that gives AI agents a shared language for discovering, trusting, and communicating with each other across different vendors and frameworks, so agents built by different teams on different platforms can exchange tasks and state without a human or a custom integration in the middle. That definition aligns with the protocol’s public specification and the Linux Foundation’s stewardship report, which confirmed A2A had reached enterprise production use at more than 150 organizations within its first year. Plain version: it is the handshake layer that lets one AI specialist pass real work to another without losing track of who owns what at each stage of a complex, multi-step workflow.

That ownership clarity matters in practice. When agents hand off work through an undefined channel, two failure modes compound each other: broken or unreliable behavior that is hard to reproduce, and no clear accountability for which agent in the chain dropped the context. A2A addresses both by making the handoff contract explicit. Discovery, trust, and state transfer are defined at the protocol level, not patched together per integration.

Why Agent-to-Agent Communication Needed Its Own Protocol

APIs move data. They do not coordinate agents. When one AI agent finishes a task and another needs to pick it up, the handoff requires more than a JSON payload. It requires three things:

• Discovery, does the receiving agent exist and can it do this?
• Trust, is this agent authorized to accept delegation?
• State transfer, what context does it need to act?

Standard REST APIs were never designed to carry all three simultaneously between autonomous systems. Without a dedicated protocol, every cross-agent handoff defaults to a bespoke connector, and every connector breaks the moment either agent updates, scales, or gets replaced. The maintenance burden is a recurring tax on every engineer who touches the system, compounded by the absence of robust testing and validation frameworks for cross-agent behavior, which means breakage often surfaces in production rather than in staging.

SkyDive is built multi-teammate by default, with per-teammate sandboxes, granular permissions, and memory and persistence baked in, so that the coordination layer A2A defines at the protocol level is matched by a platform layer that enforces ownership, context, and access boundaries across every agent in a workflow. Complex, multi-step workflows don’t require a human relay to stay on track: each teammate knows its scope, retains the state it needs, and hands off cleanly to the next.

Origin and Governance

Google announced A2A in April 2025, positioning it as an open interoperability standard backed by a broad coalition of technology partners at launch. The protocol was handed to the Linux Foundation for stewardship, the same neutral body that governs Kubernetes, Node.js, and dozens of other infrastructure standards enterprises depend on daily. According to the Linux Foundation’s report on A2A’s first year, the protocol surpassed that milestone in enterprise production use and landed in major cloud platforms, a trajectory that reflects the scale of the coordination problem it was designed to close.

How A2A Works - The Mechanical Steps Between One Agent Handing Off to Another

Five distinct human actions sit between one agent and another completing a piece of work: finding who can do it, confirming they’re ready, handing it off, watching it progress, and collecting the result. The A2A protocol replaces all five with a structured sequence. When Google announced A2A in April 2025, a broad coalition of enterprise partners, including major consultancies and cloud platforms, committed to building on it, which signals that this sequence is becoming the shared grammar of agent collaboration, not a niche experiment.

Agent Card Discovery

Before a single task moves, the calling agent needs to know whether the remote agent can handle it. According to the A2A Protocol Specification, each agent publishes a machine-readable Agent Card, a structured JSON document hosted at a well-known URL (/.well-known/agent.json), that declares the agent’s name, description, capabilities, skills, authentication requirements, and endpoint URL.

This matters because it removes hardcoded assumptions. A sourcing agent reading a job description can query an Agent Card directory, find a scheduling agent that declares it accepts interview-slot requests, and confirm that match before committing any work. Discovery is dynamic, not wired in advance.

Format and Transport Confirmation

Knowing a remote agent exists is not enough. The calling agent also reads the Agent Card to confirm that its own output format matches what the remote agent accepts, and that the transport layer is compatible. The A2A spec supports three transport options:

• Synchronous HTTP request/response
• Server-sent events for streaming
• Asynchronous push notifications via webhook

One data model, three transports.

This negotiation step is where a lot of custom-built agent orchestration breaks down in practice. Engineers who have rolled their own handoff logic report spending significant time debugging mismatched schemas and silent transport failures, precisely because there was no declared capability contract to check against before the task was sent.

A Structured Task Object Carries the Work Across Agent Boundaries

Once capability and format are confirmed, the calling agent sends a Task object to the remote agent’s endpoint via JSON-RPC 2.0 over HTTP. The remote agent acknowledges with a task ID. That ID is the thread that ties every subsequent update back to the original request, across systems, across time.

Real-Time Progress Streaming

Long-running tasks cannot wait for a single response. When a calling agent invokes tasks/sendSubscribe, the remote agent streams real-time TaskStatusUpdateEvent and TaskArtifactUpdateEvent messages back, as documented in the A2A Protocol Specification. No polling loop. No silent waiting. A research agent delegating a ten-source synthesis task receives paragraph-by-paragraph updates rather than a single payload at the end.

Artifact Return and Task Closure

Once work is complete, the remote agent returns a structured artifact, a document, a decision, a dataset, or a structured output, attached to the original task ID. The calling agent receives not just the result but the full provenance: which agent produced it, under what identity, and against which input. The task lifecycle is closed, traceable, and ready to become the input for the next agent in the sequence without any human interpretation in between.

A2A vs MCP - Two Protocols, Two Jobs: Why You Need Both

Wire every tool to an agent and you might still find yourself forwarding its output to the next one by hand. That gap is a protocol problem, and understanding where one protocol ends and the other begins is the difference between a multi-agent system that distributes work and one that just answers questions in isolation. Teams we work with at SkyDive consistently run into this friction: complex, multi-step workflows stall not because the tools are missing, but because nothing coordinates who owns what at each stage, and the back-and-forth to fill that gap eats the time the automation was supposed to save.

MCP Is the Toolkit, A2A Is the Org Chart - Why the Distinction Is Not Semantic

Model Context Protocol (MCP), introduced by Anthropic in November 2024 and now widely adopted across the AI ecosystem, governs how a single agent reaches into data sources, tools, and memory stores. It is agent-to-tool communication: the interface between an AI model and the resources it needs to complete a task. A2A sits at a completely different layer. It governs how one agent reaches another agent and hands it a live task with structured state attached. The key point: MCP and A2A are not competing standards for the same problem. They are complementary protocols operating at orthogonal layers, and deploying one without the other produces either isolated specialists or a connected network of agents that cannot actually access anything.

SkyDive is built with MCP support as a first-class capability, which means each teammate in a SkyDive workspace can reach the data sources, APIs, and memory stores it needs through a single, standardised protocol layer rather than a tangle of one-off integrations. That is the toolkit layer handled. The org-chart layer, who owns this task right now, who picks it up next, and what context travels with it, is where A2A operates, and where the discipline of keeping those two concerns separate pays off in practice.

The practical analogy holds up under pressure. MCP is the toolkit sitting on an employee’s desk. A2A is the org chart that tells them who to call when the work exceeds their specialty. Conflating the two is the equivalent of mistaking a power outlet standard for a traffic routing protocol. They are orthogonal, and treating them as redundant is what produces agents that are well-equipped but organisationally isolated, precisely the condition that leaves teams still chasing status updates instead of doing high-impact work.

The Layer Diagram - Where MCP Ends and A2A Begins in a Running Agent System

Think of a running agent system as two distinct planes. The lower plane is resource access: databases, APIs, file stores, memory. MCP operates here, replacing what Anthropic described as an “N×M fragmentation problem” with a single shared protocol layer. SkyDive’s built-in MCP support sits at exactly this plane, giving every teammate structured, permissioned access to the resources it needs without requiring custom connectors for each pairing. The upper plane is task routing: which agent owns this work, who picks it up next, and what state travels with it. A2A operates here exclusively.

Nothing in MCP’s specification tells an agent how to discover a peer, negotiate capability, or transfer task state. That is not an oversight. As Deepak Gupta’s comprehensive MCP guide makes clear, MCP is deliberately scoped to the resource-access layer.

It is a scope decision. The two protocols are designed to be complementary, not competitive. SkyDive’s multi-teammate architecture respects that boundary: granular permissions and per-teammate sandboxes govern what each agent can touch at the MCP layer, while the coordination layer keeps ownership of each task visible across the whole team without anyone needing to forward an email to find out where things stand.

MCP to Pull CRM Data, A2A to Route It to a Specialist

An ops agent flags a high-value order that needs compliance review. Using MCP, it queries the CRM and retrieves the full order record, tool access executed through the same standardised protocol that SkyDive exposes to every teammate in the workspace. Then, using A2A, it discovers a compliance review agent, confirms the agent can accept this task type, authenticates via the declared OAuth method in the Agent Card, and transfers the full order record as a structured task object, including the context that flagged it in the first place.

The compliance agent receives everything it needs to act. No one forwards an email. No context is lost at the seam.

This is the pattern SkyDive is designed around: multi-teammate by default, with memory and persistence so that structured state survives every handoff, and scheduled runs so that the sequence can fire without a human triggering each step. The result is a workflow where ownership is always clear, context never has to be reconstructed from scratch, and the team’s attention stays on decisions that require it rather than on the status updates that used to fill the gaps between them.

A2A Security and Trust - How Agents Verify Who They’re Talking To

Locking down a model’s settings and restricting an API key handles roughly zero percent of the problem once agents start delegating across vendor boundaries. The real exposure is structural: every agent handoff that lacks verified identity is, architecturally speaking, the same as routing sensitive task data to an unknown external party. According to the SecurityScorecard Global Third-Party Breach Report (2024), 29% of all breaches in 2023 involved a third party. Unchecked delegation is structurally identical to the third-party access patterns that already account for a significant share of documented breaches.

Why Agent Delegation Is a Trust Problem Before It Is a Capability Problem

The failure mode that security teams keep hitting isn’t a model problem. It’s an identity problem. When one agent hands a task to another, the receiving agent has no native way to confirm who is asking, what they’re authorized to request, or whether the delegating agent is who it claims to be.

This is precisely the impersonation risk that practitioners working inside agentic infrastructure face most acutely: A2A protocol surfaces are vulnerable to malicious agents or services posing as legitimate ones when robust identity verification is absent. A rogue service doesn’t need to break encryption; it only needs to intercept a handoff where identity is assumed rather than verified.

Capability without verified identity is an open door.

This trust gap compounds in multi-teammate environments, the kind SkyDive is built for by default. When you are coordinating a team through complex, multi-step workflows and tracking who owns what at each stage, every agent-to-agent handoff is a potential identity assumption. The more teammates, the more handoff surfaces, and the wider the window for impersonation to slip through undetected. Keeping judgment and accountability persistent across those handoffs requires that identity be verifiable at every delegation point, not just at the perimeter.

How the Agent Card Establishes Verifiable Identity Before Any Task Is Accepted

Before A2A allows any task delegation, the remote agent publishes an Agent Card: a machine-readable declaration of identity, capabilities, accepted inputs, and verification method. The orchestrating agent reads that card before it sends a single byte of task data.

*Key takeaway: A2A’s discovery mechanism and its security model are the same mechanism; you cannot delegate a task without first receiving a verifiable declaration of who you are delegating to.*

Deepak Gupta’s enterprise MCP adoption guide frames the broader problem precisely: most organizations grant third-party access based on implicit, static trust rather than declared, continuously verifiable capability metadata. Agent Cards force the explicit declaration that security teams have demanded from human vendors for years.

In practice, this matters most when workflows span multiple teammates and tool boundaries simultaneously, the multi-channel, multi-teammate architecture SkyDive operates in by default. Granular permissions and team collaboration controls mean that each teammate’s scope is declared and bounded before a task is accepted, not negotiated mid-handoff. The Agent Card pattern extends that same discipline into the protocol layer: every delegation carries a verifiable identity record, so accountability doesn’t dissolve the moment a task crosses a boundary.

Standard Enterprise Auth - OAuth 2.0, OIDC, and API Keys

A2A doesn’t mandate a single authentication method; it accommodates the standards enterprise security teams already require. The protocol declares which method an agent requires in its Agent Card, so the calling agent knows before the first byte of task data is sent whether it can meet the authentication bar. Security posture is declared, not assumed.

Auth method	Role in A2A
OAuth 2.0	Handles delegated authorization
OpenID Connect (OIDC)	Handles identity verification
API keys	Available for simpler service-to-service integrations

The same analysis underscores why this matters operationally: static, implicit trust granted at onboarding is the pattern that repeatedly fails organizations when third-party access is later abused. Declared, verifiable authentication requirements, surfaced before any task is accepted, close the gap between the access a teammate was granted and the access it is actively exercising. That is the structural shift from assuming identity to proving it, at every handoff, across every vendor boundary.

Related Reading

• How to Measure AI Agent ROI Before You Scale
• 13 Best Agentic AI Platforms in 2026 for Autonomous Work
• The Future of Agentic AI For Customer Support Explained
• 13 Best AI Agent Integrations to Automate More in 2026
• How To Measure AI Agent ROI With Proven Metrics
• 14 Best Browser Use Agent Tools for AI Web Automation 2026
• The Ultimate AI Automation Tutorial for Beginners (2026)
• AI Agent vs Assistant: Key Differences Compared (2026)
• What Are Parallel AI Agents? A Complete 2026 Guide
• 13 Best AI Agents for Marketing Teams in 2026
• How to Set AI Agent Permissions Without Losing Control

Real-World A2A Usage - What Agent-to-Agent Communication Looks Like Across an Ops Stack

Recruiting is one of the clearest places to see A2A stop being theoretical. The handoff problem is concrete, the cost is measurable, and the workflow already exists in most ops stacks. It just has a person bridging every gap.

Four Specialist Agents Replace the Human Relay

Picture a sourcing agent that scans job boards and returns qualified profiles. Without A2A, someone downloads that list, pastes it into a screening tool, waits for results, copies the shortlist into a calendar app, and manually flags the hire in the HR system. The work isn’t hard. It’s just relentless, and it belongs to whoever happens to be paying attention.

With A2A as the coordination layer, each handoff is a structured task object passed between agents: sourcing to screening, screening to scheduling, scheduling to offer generation. No one forwards a spreadsheet. The agents discover each other’s capabilities, authenticate, and transfer state. According to the Asana Anatomy of Work Index (2023), knowledge workers spend 60% of their time on work about work, including searching for information and shuttling outputs between systems, rather than on skilled tasks. That 60% is exactly where the four-agent sequence operates.

SkyDive is built to eliminate that relay entirely. Because every teammate runs in its own per-teammate sandbox with browser access and carries memory and persistence across sessions, context doesn’t evaporate between steps. The ops leader stops forwarding spreadsheets and starts coordinating a team through complex, multi-step workflows without losing track of who owns what at each stage; SkyDive tracks that ownership automatically.

Why Cross-Platform Doesn’t Mean Cross-Compatible

The honest frustration among teams building multi-agent systems is that “cross-platform” usually means “we have an API.” APIs are not enough. They tell you how to send data; they say nothing about how one agent discovers what another can do, how it establishes trust before delegating, or how it handles a task that runs for 40 minutes instead of 400 milliseconds.

One of the sharpest pains practitioners building in this space consistently run into is the search for a single, unified implementation path, something like one protocol to govern all agent coordination cleanly. That search feels endless because most platforms treat cross-agent communication as an afterthought bolted onto single-purpose tools. The result is a patchwork of point-to-point integrations that breaks the moment a new tool enters the stack.

A2A standardizes the handoff language itself. A broad and growing cohort of enterprise AI partners had joined the protocol, meaning the vendor diversity is already broad enough that cross-platform collaboration is a procurement criterion worth checking today. SkyDive addresses this directly through native MCP (Model Context Protocol) support alongside its multi-teammate architecture, giving teams a concrete, unified path rather than another integration project. The protocol layer is already there; you’re not building it from scratch.

The Seam Tax - Quantifying the Time That Lives Between Tools

Industry productivity research consistently frames the problem the same way: time is consumed not in doing work but in shuttling state between tools. The Speakwise Team corroborates the Asana data: knowledge worker time is disproportionately lost to coordination overhead rather than skilled execution. Teams that eliminate that overhead commonly report recovering multiple hours of focused work time each week per person. The seam tax is invisible because it’s distributed. Every person on the team absorbs a fraction of it, so no single role ever sees the full cost, and it never appears on a roadmap because no one owns it as a line item.

SkyDive is designed around this reality. Granular permissions and team collaboration controls mean each teammate operates within defined boundaries without requiring a human to referee every handoff. Scheduled runs keep sequences moving without anyone watching the clock. The back-and-forth communication overhead that eats into focused work shrinks because the agents handle status propagation. Your team stays on high-impact work instead of status updates.

From Single-Purpose Bots to a Coordinated Bench

The shift A2A enables is from a collection of single-purpose bots that each stop at their own edge to a coordinated bench of specialists that hand work to each other with full context intact. SkyDive is multi-teammate by default, not multi-teammate as an upgrade. The architecture assumes coordination from the start. Productive on day one. Templates for inbox triage, lead enrichment, CRM hygiene, deck updates, content drafting, research, support triage. Library expands as customers build and share.

The ops leader stops being the integration layer. The agents become one, and the output is real work completed across every function, not a list of suggestions waiting for a human to act on them.

What A2A Protocol Means for Teams Building on AI Today and Where SkyDive Fits In

Buying AI tools by feature checklist is rational. It’s also how most ops teams end up with three capable agents and a fourth teammate: themselves, manually bridging every handoff. The real question is whether agents can hand work to each other without you standing in the relay.

Why “What Can This Agent Do?” Is the Wrong Buying Question

Most teams discover the coordination gap after deployment, not before. They evaluate agents on capability, acquire several that each perform well individually, then realize the workflow still stalls at every seam because nothing governs how one agent finds, trusts, or transfers work to another. Industry analysis consistently surfaces a sharp gap: the majority of organizations have experimented with agentic AI in some form, yet a much smaller share have a coordinated multi-agent workflow running in production. That gap is a coordination problem dressed as a capability problem.

The underlying pain is familiar to ops and GTM teams at scale: status updates crowd out judgment-heavy work, handoffs stall in Slack threads, and the people best positioned to make decisions are instead running relay legs between tools. The back-and-forth doesn’t disappear when you’ve added AI; it relocates to the seams between agents.

Capability per agent is table stakes. The protocol layer underneath determines whether your agents form a team or a collection of isolated performers waiting for a human to connect them.

The Protocol Layer Is Already Deciding Whether Your AI Teammates Can Collaborate

The A2A protocol defines how agents discover each other, establish trust, and transfer task state. Without it, every multi-step workflow requires a human to interpret one agent’s output and feed it to the next.

Agent-to-agent coordination isn’t a feature you toggle on. It’s infrastructure. Most tools being sold today as “multi-agent platforms” quietly skip it, because building a compliant coordination layer is harder than building a capable single agent. Enterprise deployment research confirms this pattern: organizations that move beyond single-agent pilots to genuine multi-agent production consistently cite coordination architecture, not raw capability, as the deciding variable.

SkyDive is built multi-teammate by default, so the coordination layer ships with the product rather than arriving as a later configuration problem. Each teammate gets its own sandboxed browser environment and memory persistence, so task state doesn’t evaporate at the handoff; it travels with the work. Granular permissions and team collaboration controls mean you can define who owns what at each stage of a complex, multi-step workflow without reverting to manual oversight to enforce it. Your highest-judgment people, the ones who should be doing work only they can do, like planning high-impact offsites or driving GTM decisions that require real context, stay focused on that work instead of triaging status updates between agents.

Pre-built teammate templates, scheduled runs, MCP (Model Context Protocol) support, and multi-channel access mean teams can move from zero to coordinated workflow without building the scaffolding from scratch. That matters because the teams most harmed by the coordination gap are often the ones with the least capacity to engineer around it.

The honest trade-off: if your workflows rarely cross functional boundaries, a single well-scoped agent may be all you need. A2A-based coordination is worth understanding, but SkyDive is not the right fit today if:

• Your organization has 100 or more people with an established BPO or offshore VA contract already managing workflow coordination
• You operate in a heavily regulated industry, healthcare, federal government, or regulated finance, where agent delegation requires formal compliance review

For everyone else, the buying question to ask is: when this agent finishes, where does the work go, and do you have to carry it there yourself?

Next steps

If your agents are each doing their job but the workflow still stalls every time one finishes and another needs to start, the path forward starts with recognizing that the gap is architectural, not a capability problem. The human relay between tools is not a temporary workaround. It is what fills the absence of a shared handoff layer, and it compounds silently every time another agent joins the stack. Start with our AI teammates.

When time savings from AI are steadily consumed by rework from disconnected systems, adding more capable agents without a coordination layer actively cancels the productivity gains that justified deploying AI in the first place. And the AI initiatives that do reach production are structurally differentiated by whether their agents can discover, delegate, and synchronize without a human in the relay, which makes coordination architecture the decision, not an implementation detail. Together, they point to evaluating platforms not by what each agent can do in isolation, but by whether the handoff layer ships with the product.

Start with AI teammates to see what a coordinated bench of specialists looks like when task state travels with the work instead of waiting for someone to carry it.

Frequently Asked Questions

What exactly is in an Agent Card and how does one agent find another’s?

An Agent Card is a structured JSON document each agent publishes at a well-known URL (/.well-known/agent.json) that declares the agent’s name, description, capabilities, skills, authentication requirements, and endpoint URL. A calling agent queries that card before sending any work, so discovery is dynamic rather than hardcoded in advance.

What happens to a task after it’s sent, how does the calling agent track progress, and know when it’s done?

Once the calling agent sends a Task object via JSON-RPC 2.0, the remote agent acknowledges with a task ID that ties every subsequent update to the original request. For long-running work, the calling agent can invoke tasks/sendSubscribe to receive real-time TaskStatusUpdateEvent and TaskArtifactUpdateEvent messages via server-sent events instead of polling. When work completes, the remote agent returns a structured artifact attached to that same task ID, along with full provenance, which agent produced it, under what identity, and against which input.

What transport options does A2A support and do I have to pick just one?

The A2A spec supports three transport options, synchronous HTTP request/response, server-sent events for streaming, and asynchronous push notifications via webhook, all over a single data model, so the transport can be matched to the task without changing the underlying protocol.

Why isn’t a regular API call enough when one agent needs to hand work to another?

Standard REST APIs move data but don’t coordinate agents, a cross-agent handoff requires discovery (does the receiving agent exist and can it do this?), trust (is it authorized to accept delegation?), and state transfer (what context does it need?) simultaneously, something REST APIs were never designed to carry. Without A2A, every cross-agent handoff defaults to a bespoke custom connector that breaks whenever either agent updates, scales, or gets replaced, turning maintenance into a recurring cost rather than a one-time build.

Who governs the A2A protocol and how widely has it actually been adopted?

A2A was announced by Google in April 2025 and handed to the Linux Foundation for stewardship, the same neutral body that governs Kubernetes and Node.js. According to the Linux Foundation’s report, the protocol surpassed 150 organizations in enterprise production use and landed in major cloud platforms within its first year.