How the A2A Protocol Works in Version 1.0

How the A2A Protocol Works

The Agent2Agent Protocol gives one independent agent system a standard way to discover another, send it work, follow a task, and receive results without learning how the remote agent is implemented.

In A2A 1.0, that exchange revolves around an Agent Card, messages, tasks, task states, parts, and artifacts. The protocol creates a coordination contract. It does not prove that an agent is trustworthy, that two agents mean the same thing, or that a completed task produced the right business result.

A2A begins at an ownership boundary

Imagine a customer-service agent that needs a specialist logistics agent to propose delivery windows. The two agents may use different models, frameworks, clouds, and internal tools. The service agent should not need the logistics agent's prompt, memory, source code, or tool graph.

It needs a public contract for asking, "Can you do this work, under these conditions, and how will I know what happened?"

The current A2A specification identifies 1.0.0 as the latest released version. The explanation below is pinned to its 1.0 task and discovery model.

sequenceDiagram
    participant C as Client agent
    participant D as Discovery origin
    participant S as A2A server agent
    participant P as Policy and identity
    C->>D: Retrieve Agent Card
    C->>C: Verify identity, version, interface, and skill
    C->>P: Obtain scoped authorization
    C->>S: Send Message with A2A-Version 1.0
    S-->>C: Return direct Message or Task
    S-->>C: Stream or publish status and artifact updates
    C->>S: Supply input, authorize, poll, or request cancellation
    S-->>C: Complete, fail, cancel, or reject
    C->>C: Validate the artifact and business outcome

The Agent Card describes the available contract

An A2A server must make an Agent Card available. The card can be retrieved through the standard /.well-known/agent-card.json path, a registry, or direct configuration.

The card describes the agent's identity, provider, skills, capabilities, supported interfaces, protocol bindings and versions, media types, extensions, and security requirements. A client uses those declarations to decide whether it knows how to communicate with the server. The project's Agent Discovery guide separates well-known, registry, and direct-configuration strategies.

The current specification can describe JSON-RPC, gRPC, and HTTP+JSON interfaces. A client selects a compatible interface and sends the requested A2A Major.Minor version. If the server cannot honor that version, it should return a version-not-supported error.

This is negotiation, not trust. A card says what an agent claims to support. A client still has to verify the origin, signature when present, approved provider, endpoint, policy, and observed behavior.

A Message may stay simple or become a Task

The primary operation sends a Message. A Message contains one or more Parts, which can carry text, a file, or structured data.

For a short exchange that does not need tracking, the server may return a direct Message. For asynchronous, interruptible, or otherwise stateful work, the server returns a Task.

A Task is the durable unit of action. It includes an identifier, a current status, optional context, output artifacts, optional message history, and metadata. The task lets both systems talk about the same piece of work even when it lasts longer than one network request.

Task state makes long-running work observable

An A2A 1.0 task can be submitted or working. It can pause because more input or authorization is required. It can end as completed, failed, canceled, or rejected.

Those distinctions are useful. A rejected task is not the same as a failed attempt. A task waiting for input is not still making progress. A task waiting for authorization should not quietly acquire broader credentials from message history.

The client can receive updates in several ways. It can poll with Get Task, subscribe to a stream, or register for push notifications when the Agent Card declares support. Streaming can carry status changes and incremental artifact updates. Push delivery requires its own endpoint authentication, replay handling, expected task matching, and idempotent processing.

The client must design for missed and duplicate updates. The canonical task state belongs to the server, while the client needs enough local state to reconcile what it has seen.

Artifacts are results, not truth

When a logistics agent completes the example task, it might return a structured set of delivery windows as an Artifact. The client should validate the media type and schema, but that is only the first check.

It should also confirm that the windows apply to the requested address, products, service level, date range, and policy. If the task reserved inventory or booked a slot, the client must distinguish a proposal from a committed side effect.

A protocol can make the envelope interoperable while the contents remain ambiguous. Application-level schemas, identifiers, units, policy versions, provenance, and acceptance tests create semantic interoperability.

Authentication stays outside the message payload

The Agent Card declares the server's supported security schemes. The client obtains appropriate credentials and sends them through the selected transport's security mechanism.

When a task needs additional authorization, A2A 1.0 can place it in an authorization-required state. The specification recommends that credentials be delivered out of band and warns that in-band forwarding can expose them to every agent in a delegation chain.

The safer pattern is a short-lived credential issued for the receiving service, intended action, permitted data, and task lifetime. A broad user token should not be copied into a message or artifact.

Cancellation is a request, not an undo button

The client can request cancellation of an ongoing task. The server may be unable to cancel because work has already finished, entered a noncancelable stage, or created an external side effect.

This creates two different operating paths. Cancellation asks the remote agent to stop future work. Compensation addresses work that already happened, such as voiding a reservation, reversing a change, or opening a review case.

Every workflow with external effects needs both a cancellation policy and, where possible, a compensation plan.

What A2A deliberately leaves to the application

A2A standardizes discovery, versioned interfaces, messages, tracked tasks, updates, artifacts, and related security declarations. It does not select an agent, approve a provider, define business semantics, assign authority, evaluate output, set retention, cap cost, settle payments, resolve disputes, or accept liability.

That boundary is the most useful way to understand the protocol. A2A can remove custom coordination plumbing between independently operated agents. It cannot remove the product, security, and operating work that makes delegation safe and useful.

Before using A2A in production, implement one bounded task against a pinned 1.0 interface. Exercise a direct response, a tracked task, input required, authorization required, failure, rejection, timeout, cancellation, a duplicate update, and an invalid artifact. Record which layer owns each outcome. The A2A project repository links the official SDKs, samples, inspector, and conformance work, but each selected implementation still needs version-specific testing.

This page was developed with AI assistance and reviewed against the A2A 1.0 specification and the primary episode evidence linked above. Dalton Anderson is responsible for the final editorial judgment.