A2A Protocol Explained: The Agent Card JSON, Discovery, And Tasks

What A2A Is Actually For

A2A — Agent-to-Agent — is the open protocol for cross-vendor agent coordination. Google originated it in 2025 and donated it to the Linux Foundation in 2026. Where MCP is "agent talks to a tool," A2A is "agent talks to another agent" across vendors and organizations.

The 30-second mental model:

• MCP: agent ↔ tool. Stripe is a tool. Postgres is a tool. Your internal API is a tool.
• A2A: agent ↔ agent. A Workday agent coordinates with a Salesforce agent. A consumer Hatch agent coordinates with a CallSphere voice agent. Cross-vendor, cross-org.

This post walks through the Agent Card JSON, the discovery handshake, the task lifecycle, and what to publish if you want to be reachable by other agents.

The Agent Card JSON

Every A2A-compliant agent advertises itself via a JSON Agent Card. The Agent Card lives at a well-known path (analogous to /robots.txt or /.well-known/openid-configuration) and tells other agents:

• Who the agent is (name, version, vendor)
• What the agent can do (capabilities, supported task types)
• How to reach it (endpoint, auth, supported transports)
• What it costs (optional pricing or rate-limit metadata)
• What guarantees it offers (latency targets, data residency, compliance)

A minimal Agent Card looks roughly like this:

{
  "agentId": "callsphere-voice-receptionist",
  "displayName": "CallSphere Voice Receptionist",
  "version": "1.0.0",
  "vendor": "CallSphere",
  "endpoint": "https://a2a.callsphere.ai/v1",
  "transports": ["https"],
  "auth": ["oauth2", "api-key"],
  "capabilities": [
    {
      "task": "schedule.appointment",
      "modes": ["voice", "chat", "sms", "whatsapp"],
      "languages": ["en", "es", "fr", "de", "ja", "..."],
      "verticals": ["healthcare", "real-estate", "salon", "it-helpdesk"]
    },
    {
      "task": "lookup.crm.contact",
      "scope": "tenant"
    }
  ],
  "guarantees": {
    "latencyP50Ms": 800,
    "hipaaCompliant": true,
    "dataResidency": ["us-east-1"]
  }
}

The exact schema evolves under Linux Foundation governance; the field-set above is representative of the early 1.0 spec.

Discovery: How Agents Find Each Other

There are three discovery patterns in A2A:

1. Well-known URL. Each agent publishes its Agent Card at https:///.well-known/agent-card. Anyone who knows the host can fetch it.
2. Registry. Public or private registries index Agent Cards by capability. The Linux Foundation is expected to host a reference public registry; enterprises will run private ones.
3. Out-of-band exchange. The two agents' operators share Agent Card URLs over a procurement or partnership channel, no registry needed.

Discovery returns enough metadata for an inviting agent to decide whether to engage. The actual task negotiation happens after.

Task Lifecycle: The A2A Handshake

A single A2A task moves through five stages:

1. Negotiate — caller agent proposes a task; callee acknowledges and either accepts, rejects, or counters with a refined scope.
2. Authenticate — caller authenticates via OAuth, mTLS, or pre-shared key. Auth scope is usually tenant- or user-bound.
3. Execute — caller streams context (history, user info, prior tool calls) and the callee performs the task. Long-running tasks support progress events.
4. Return — callee returns a structured result and any artifacts (URLs, IDs, follow-up tasks).
5. Audit — both sides log the interaction with shared task IDs so downstream observability tools can correlate.

The negotiate step is what distinguishes A2A from a plain HTTP API: the agents agree on the shape of the work before anyone authenticates or executes.

A2A vs MCP: The Clean Boundary

A common confusion: "isn't A2A just MCP with extra steps?" No.

• MCP is for tools — they don't reason. A Postgres MCP server runs a query and returns rows.
• A2A is for agents — they reason. A Workday agent reads its calendar, makes a judgment call, and decides what to do.

If the thing you are calling reasons, plans, or owns state across calls, it is an agent — use A2A. If the thing you are calling is a stateless capability, use MCP.

Publishing Your Own Agent Card

If you operate an agent and want to be reachable, publish an Agent Card. Steps:

1. Decide your tasks. What can the agent do for callers? Keep the list small and concrete. "Schedule an appointment" is a task; "be helpful" is not.
2. Define your auth surface. OAuth 2.1 with tenant-scoped tokens is the most portable option.
3. Document your guarantees. Latency, data residency, compliance posture. Cards without guarantees get treated as best-effort and lose enterprise traffic.
4. Host the JSON. Serve it at /.well-known/agent-card with CORS appropriate to your discovery model.
5. Register if relevant. List in a public or private registry if you want passive inbound discovery.

CallSphere's voice and chat agent platform — covering voice, chat, SMS, and WhatsApp across 57+ languages and 6 verticals — is exactly the kind of receiving-side agent that benefits from publishing an Agent Card. A consumer agent like Meta Hatch or an enterprise agent like Workday can then schedule an appointment, look up a contact, or trigger a follow-up call without a custom integration. With $149/$499/$1,499 monthly tiers, HIPAA-friendly deployment, and 3–5 day launch, the integration cost is small relative to the inbound coverage.

Talk to us about A2A and multi-agent integrations — book a demo.

What To Watch In A2A 1.0

• Schema finalization under Linux Foundation governance.
• First public registries with reasonable signing and provenance guarantees.
• First enterprise procurement that requires an Agent Card from every vendor.
• First cross-vendor agent failure that surfaces governance gaps.

FAQ

Q: Do I need an Agent Card if I'm just building an internal multi-agent system? You can use A2A internally without publishing publicly. The Agent Card lives in your private registry and is consumed by your other agents. This is the most common starting point for enterprise A2A.

Q: How is A2A different from a plain REST API? A2A standardizes capability advertisement, discovery, auth, and a multi-stage task lifecycle. A REST API has none of those. You could build A2A on top of REST as the transport, and the early spec does.

Q: When does A2A 1.0 freeze? Linux Foundation governance kicked off after Google donated the spec at Cloud Next 2026. A 1.0 freeze is expected over the next two quarters; production adopters are pinning to current draft revisions in the meantime.

Sources

• A2A protocol GitHub — https://github.com/a2aproject
• Google Cloud Next 2026 announcement — https://cloud.withgoogle.com/next
• Linux Foundation working group page — https://www.linuxfoundation.org