A2A: agent cards and tasks

Why it matters

Inside one team, agents cooperate by sharing code: the orchestrator imports the worker and calls it. Across teams, companies or vendors that stops working. A buyer's procurement agent and a supplier's onboarding agent were built by different people on different frameworks, and neither side will hand over its prompts, tools or memory. The agent-to-agent protocol, A2A, is the agreed way: find out what another agent can do, hand it work, and follow that work to completion without seeing inside. Interviewers raise it when a design crosses an organisational boundary, and the question underneath is whether you know what to keep private.

The idea

A2A is at version 1.0 and has been governed under the Linux Foundation's Agentic AI Foundation since August 2026. It has three ideas: the card, the task, and opacity.

The agent card

An agent publishes an agent card, a small document at a known address that says what the agent is, what it can do, where to reach it, and how to authenticate. A caller reads the card before sending anything, the way a client reads an MCP server's discovery response. The card lists skills in plain language, because the reader is often a model deciding whether this agent fits the job.

{
  "name": "Supplier onboarding agent",
  "url": "https://agents.supplier.example/a2a",
  "capabilities": { "streaming": true },
  "skills": [
    { "id": "vet-supplier", "description": "Check a supplier against sanctions lists and credit data" },
    { "id": "collect-documents", "description": "Request and verify tax and insurance documents" }
  ],
  "auth": { "schemes": ["oauth2"] }
}

Tasks, messages and artifacts

The unit of work is a task. The caller creates one by sending a message: "vet supplier Acme Ltd, registration 0412". The remote agent accepts it and the task moves through a lifecycle: submitted, working, input required, completed, failed, with cancelled as a side exit. Messages are the conversation inside the task; either side can send them, and a task in the input-required state is the remote agent asking the caller for something, a missing document or a decision, which the caller answers with another message on the same task. Artifacts are the outputs: a report, a file, a structured record. A task can produce several, and they are what the caller keeps.

submitted -> working -> input-required -> working -> completed
                                      \-> failed | cancelled

Long tasks stream. A caller that supports it subscribes to status updates and partial artifacts as they appear rather than polling, so a twenty-minute document-collection task can show progress and ask its question the moment it has one.

Opacity

The caller never sees the remote agent's tools, memory, prompts or model. It sees the card, the task state, the messages and the artifacts. This is the point, not a limitation. The supplier's agent can swap its model or add a tool, and the buyer's agent notices nothing as long as the card and the task contract hold. It also means the caller cannot reach past the boundary to fix things, which is why the input-required state and clear artifacts matter so much.

Discovery and auth between agents

Finding agents is reading cards: a company registry, a partner's documented address, or a catalogue the orchestrator is configured with. Authentication is whatever the card declares, usually OAuth or an API key, and the call carries the caller's identity so the remote agent can decide what this caller may ask for. Authorisation lives on the remote side, per caller and per skill, the same rule as per-user authorisation on an MCP server.

Beside MCP

The two protocols do not compete. MCP connects an agent to tools; A2A connects it to other agents; a real system uses both. The supplier's agent reaches its sanctions database through an MCP server; the buyer's agent reaches the supplier's agent through A2A. The MCP versus A2A versus a plain API lesson works through the decision.