Agent-to-Agent Protocol (A2A) is an open communication framework that allows autonomous AI agents to talk to each other in a standardized, predictable way. In practice, each agent exposes an HTTP API (with endpoints like tasks or send) and a public agent card (metadata describing its capabilities) so that other agents can discover it and request its services. A2A was released by Google and adopted by others including Arize to enable multi-agent collaboration on complex tasks (for example, one agent can delegate a sub-task to another) without custom integrations.
Key takeaways
- A2A defines how agents advertise capabilities and exchange task requests over HTTP instead of ad hoc wrappers per vendor.
- Agent cards carry discovery metadata so orchestrators can route work without hard-coded endpoint lists.
- Standard endpoints reduce glue code when you add specialists, but they do not replace auth, policy, or evaluation layers.
- Multi-agent flows need tracing across agent boundaries to debug delegation failures and latency spikes.
- Treat A2A as a transport and discovery contract; your harness still owns prompts, tools, memory, and quality gates.
Core components
Agent card. A machine-readable document listing the agent name, skills, input and output schemas, authentication requirements, and endpoint URLs. Clients fetch the card before sending work so they know what the agent accepts.
Task endpoints. Operations such as creating a task, streaming status, or sending a message follow shared patterns so a coordinator agent can call unfamiliar agents without bespoke SDKs for each one.
HTTP transport. Requests and responses use familiar web semantics, which helps teams reuse load balancers, API gateways, and observability middleware they already operate.
How A2A fits multi-agent systems
Single-agent loops struggle on workflows that span research, execution, and verification. An orchestrator agent can read agent cards, pick a specialist, and delegate a sub-task through A2A while retaining the overall plan.
That pattern mirrors human teams: a lead breaks work into pieces and assigns them to people with the right skills. The protocol standardizes the handoff envelope so you spend less time writing one-off REST clients.
It does not specify how agents reason, which model they run, or how they store memory. Those remain application decisions inside each agent implementation.
Discovery and routing
Discovery starts with agent card URLs published in a registry, config store, or service mesh. Orchestrators match required capabilities to advertised skills, then open tasks against the chosen endpoint.
Routing policies still belong to your platform: rate limits, allowed agent lists, cost caps, and data residency rules must wrap raw A2A calls. A card describes what an agent can do, not whether this tenant may invoke it.
Security and governance
Agent cards may declare auth schemes, but you must enforce identity, authorization, and audit logging at the gateway. Never expose unauthenticated task endpoints on open networks.
Validate payloads against declared schemas before forwarding user content to downstream agents. One compromised or over-permissive agent in a chain can exfiltrate data from peers.
Log correlation IDs across delegations so incident response can reconstruct which agent passed which artifact.
Observability and evaluation
Multi-agent failures often show up as silent retries, duplicated work, or wrong specialist selection rather than HTTP 500 errors. Instrument each A2A hop with spans that include task IDs, agent names, and payload hashes where privacy allows.
Compare delegated runs to single-agent baselines on the same eval set. Regression tests should cover card parsing, auth refresh, and timeout behavior when a specialist is slow or unavailable. The AI agent handbook covers architecture patterns where orchestration, tools, and eval hooks sit above raw protocol calls.
Resources on agent harness evaluation and tracing explain how to connect protocol-level logs with task success criteria and human review queues.
When you scale agent fleets, centralize eval results and traces alongside deployment metadata. Hubs comparing LLM and agent evaluation platforms describe how teams store multi-step trajectories for regression analysis.
Limitations and tradeoffs
Standardization reduces integration cost but may lag vendor-specific features. Teams sometimes wrap proprietary agent APIs behind A2A-compatible facades.
Latency adds up across chains. Parallelize independent sub-tasks where possible and set per-hop deadlines.
Agent cards can drift from actual behavior if teams update code without refreshing metadata. Automate card generation from source definitions when feasible.
FAQ
Is A2A the same as MCP?
No. Model Context Protocol (MCP) focuses on connecting a model to tools and context providers. A2A focuses on agent-to-agent task delegation and discovery. Systems may use both.
Do I need A2A for a two-agent workflow?
Not strictly. Two agents with a private API contract can work. A2A pays off when agent count, teams, or external partners grow and discovery must stay consistent.
What should an agent card include at minimum?
Identity, version, supported task types, input and output schemas, endpoint URLs, and authentication expectations. Optional fields can cover pricing hints, rate limits, or ownership contacts.
How do I debug a failed delegation?
Trace the orchestrator span, verify the card fetched matches the live endpoint, inspect auth tokens, reproduce with a minimal task payload, and compare specialist logs to declared schemas.
Can A2A agents call human approval steps?
Yes, if your orchestrator models human gates as tasks with blocked status until review completes. The protocol describes machine agents; your workflow engine adds human nodes.
