Agent-to-agent protocols in outline: A2A agent cards, tasks and where MCP fits

What it is

The Agent2Agent (A2A) protocol is an open specification for communication between independent, possibly opaque agent systems built by different vendors on different frameworks; its stated aim is a common language and interaction model without agents sharing internal state, memory or tools. Version 1.0.0 is the current release, published under the Linux Foundation with the protocol buffer definition as the normative source. Its building blocks: an Agent Card, a JSON document a server publishes (fetched from /.well-known/agent-card.json) that describes identity, capabilities, skills, the service endpoint and the security schemes a client must use (API key, HTTP authentication, OAuth 2.0, OpenID Connect or mutual TLS), plus an optional authenticated extended card; tasks, the unit of work, with states submitted, working, input-required, auth-required, completed, failed, canceled and rejected, where the two interrupted states hand control back to the client; messages exchanged during a task and artifacts produced by it, both composed of parts that are text, files or structured data; and operations to send a message, stream it, get, list, cancel or subscribe to a task, and manage push-notification configurations for webhooks. Three bindings are specified: JSON-RPC 2.0 over HTTP, gRPC and HTTP with JSON; blocking calls wait for a terminal or interrupted state, non-blocking ones return at once and the client polls, streams or receives webhooks.

Why it matters

An agent that delegates to another agent needs discovery (what can it do, how do I authenticate), a task identity that survives long-running work and human input, and a way to receive results without holding a connection open. The specification's guiding principles name exactly these concerns: reuse of HTTP, JSON-RPC and Server-Sent Events, asynchronous-first design for long tasks with a person in the loop, and opaque execution. Its appendix on MCP draws the line the two projects agree on: MCP standardises how a model or agent connects to tools, APIs and data sources; A2A standardises how agents discover each other, negotiate interaction and manage shared tasks as peers, and an A2A server may use MCP internally to do its work.

How to apply

• Publish an Agent Card only for capabilities you actually serve, and keep skills descriptions concrete enough for a client to route on.
• Model long work as tasks and use input-required for clarifications instead of failing; clients should handle both interrupted states.
• Pick one binding per deployment and document it in the card; do not expect clients to try several.
• Treat received parts as data, exactly as tool results are treated; the protocol carries content, not trust.

Pitfalls

Version 1.0.0 changed structures against earlier releases (the specification's migration appendix lists breaking changes such as the removed kind discriminator and the relocated extended-card field), so libraries written for 0.2 or 0.3 need checking. A card describes what an agent claims; verifying behaviour is still the client's job.