A2A (Agent2Agent) protocol

The Agent2Agent (A2A) protocol is an open standard for communication between independent AI agents, originally developed by Google and maintained under the Linux Foundation. With this skill the agent publishes an Agent Card, implements A2A operations on one or more protocol bindings, and calls remote A2A agents, following protocol version 1.0.

Follow the workflow below step by step. Every rule here comes from a source in Sources, with the section it cites (§ numbers refer to the A2A specification). When a rule and the pinned source disagree, the source wins; when the source has a newer revision than the pin, follow the refresh steps.

Inputs (fill in, or ask before starting)

• Role: A2A server (remote agent), A2A client, or both (an agent that is a client of other agents).
• Bindings: which of JSONRPC, GRPC and HTTP+JSON to expose or call (§ 5, § 9 to § 11).
• Authentication: the security schemes the server accepts (API key, HTTP auth, OAuth 2.0, OpenID Connect, mutual TLS) and the scopes per skill (§ 4.5, § 7).
• Revision: protocol version 1.0, specification release v1.0.1, unless the user names another.
• Sources: when refreshing this skill or when a rule looks out of date, re-read every URL in Sources, check the A2A GitHub releases and the "Latest Released Version" banner on the specification page, and update the pins.

Invariants

1. The proto is normative. a2a.proto is the single authoritative definition of all data objects and request and response messages; JSON Schema and SDK types are derived and must be regenerated, never hand-edited (§ 1.4). Where prose or an example disagrees with the proto, follow the proto.
2. Publish an Agent Card (§ 8.1). The well-known location is https://{server_domain}/.well-known/agent-card.json (§ 8.2, § 14.3).
3. Declare every supported interface in supportedInterfaces, in preference order, each with a correct url, protocolBinding and protocolVersion (§ 5.2, § 8.3.1). All bindings an agent supports must offer the same operations, behavior, errors and authentication (§ 5.1).
4. JSON uses camelCase field names and ProtoJSON enum names such as TASK_STATE_COMPLETED and ROLE_USER (§ 5.5). Timestamps are ISO 8601 strings in UTC (§ 5.6.1).
5. Authenticate every request and authorize every operation (§ 7.4, § 13.1). Scope GetTask, ListTasks and task-related operations to the caller, and do not reveal resources the caller may not access (§ 3.3.2, § 13.1).
6. Version every request. Clients send A2A-Version (Major.Minor, such as 1.0); servers treat an empty value as 0.3 and return VersionNotSupportedError for unsupported versions (§ 3.6).
7. Honor declared capabilities. Streaming, push notifications, the extended Agent Card and required extensions each have a mandated error when not supported (§ 3.3.4).
8. Use TLS in production (§ 7.1, § 13.4). Webhook URLs are validated against SSRF (§ 13.2).
9. Signed cards are JWS over the RFC 8785 canonical card, with the signatures field excluded and default values removed (§ 8.4).

Workflow

1. Write the Agent Card. Fill the required fields, the capabilities, the skills and supportedInterfaces; serve it at the well-known URI with caching headers. -> references/agent-card.md ✓ The card has every REQUIRED proto field, validates against the A2A JSON Schema, and is reachable at /.well-known/agent-card.json with Cache-Control and ETag (§ 8.6.1).
2. Declare security. Add securitySchemes and card-level and per-skill securityRequirements; decide what the authenticated extended card adds. -> references/agent-card.md, references/security.md ✓ Each scheme uses one of the five proto scheme types; OAuth flows are authorizationCode, clientCredentials or deviceCode, not the deprecated implicit or password (§ 4.5.7).
3. Implement the operations on each binding. Map the eleven operations to JSON-RPC methods, gRPC RPCs or REST endpoints, with the service parameters and error mappings of that binding. -> references/operations-and-bindings.md ✓ Every A2A error maps to the code in § 5.4, and HTTP+JSON errors carry a google.rpc.ErrorInfo with domain: "a2a-protocol.org" (§ 11.6).
4. Model tasks, messages and artifacts. Return a Task or a direct Message from SendMessage, drive task states, put outputs in artifacts, and handle multi-turn contextId and taskId rules. -> references/tasks-messages-streaming.md ✓ Terminal states reject further messages with UnsupportedOperationError (§ 3.1.1), and task outputs are artifacts, not messages (§ 3.7).
5. Add streaming and push notifications if the card declares them. -> references/tasks-messages-streaming.md ✓ Streams start with a Task or a single Message, keep event order, and close on a terminal state (§ 3.1.2, § 3.5.2); webhooks receive StreamResponse payloads with the configured credentials (§ 4.3.3).
6. Sign the card and review security if cards are signed or extended cards are offered. -> references/security.md ✓ A client can rebuild the canonical payload and verify at least one signature (§ 8.4.3); the extended card requires authentication (§ 13.3).

Verify before done

• The Agent Card validates against the published A2A JSON Schema and uses securityRequirements (proto field 9), not the older security name that still appears in some prose and examples.
• supportedInterfaces[0] is the preferred interface, and clients set tenant exactly as declared (§ 8.3.2).
• Each operation returns the § 5.4 error code on every binding the card declares.
• ListTasks returns only the caller's tasks, sorted by last update descending, and always includes nextPageToken (§ 3.1.4).
• Requests without A2A-Version are treated as 0.3 (§ 3.6.2).
• Push notification webhook URLs reject private, loopback and link-local addresses (§ 13.2).
• Card signatures use a protected header with alg, kid and typ: "JOSE" (§ 8.4.2).

Reference index

• references/agent-card.md: every Agent Card field, interfaces, skills, security schemes and requirements in JSON, extensions, caching, and a full example. Load for steps 1 and 2.
• references/operations-and-bindings.md: the eleven operations, the JSON-RPC, gRPC and HTTP+JSON mappings, service parameters, versioning and error codes. Load for step 3.
• references/tasks-messages-streaming.md: task states, messages, parts, artifacts, multi-turn rules, streaming, push notifications and in-task authorization. Load for steps 4 and 5.
• references/security.md: authentication, authorization scoping, extended card access, Agent Card signing and verification, push notification security. Load for steps 2 and 6.

Related skills

• ap2 for agent payments carried over A2A (intent, cart and payment mandates): npx skills add ScaleDockHQ/scaledock-skills --skill ap2.
• owasp-agentic for reviewing inter-agent communication and delegated identity against the OWASP Top 10 for Agentic Applications: npx skills add ScaleDockHQ/scaledock-skills --skill owasp-agentic.
• ag-ui for the agent-to-user-interface event stream that complements A2A: npx skills add ScaleDockHQ/scaledock-skills --skill ag-ui.

Sources

Status uses the publishing body's own maturity term. Checked is the date the source was last read.

• Agent2Agent (A2A) Protocol Specification: Released, protocol version 1.0 (page banner "Latest Released Version 1.0.0"), checked 2026-10-02.
• A2A release v1.0.1: Released, v1.0.1 (2026-05-28), checked 2026-10-02.
• a2a.proto at v1.0.1: Released (normative data model), v1.0.1, checked 2026-10-02.
• A2A JSON Schema bundle: Released (non-normative, generated from the proto), schema version v1, checked 2026-10-02.