A2A Protocol Implementation Checklist for Production Agent Systems

Decide whether A2A belongs at this boundary

A2A is designed for independent, potentially opaque agents that need to discover capabilities, exchange messages or artifacts, and manage collaborative tasks without sharing their internal memory or tools. Use it at a service boundary where one agent delegates work to another agent owned by a different team, platform, or organization. Do not introduce it merely because one application has several internal functions.

Keep the layers distinct. An agent framework can orchestrate components inside one application. MCP can expose tools and resources to that agent. A2A provides a common interface between agent applications. This separation makes ownership clearer: the remote A2A server decides how it reasons and which tools it uses, while the client relies on the advertised contract and observable task results.

Before implementation, write a one-page boundary statement. Name the requesting and serving organizations, intended skills, data classifications, allowed artifacts, maximum task duration, approval points, and consequences of a wrong or duplicated action. If both sides cannot agree on those basics, protocol compatibility will not rescue the workflow.

• Use A2A for delegation across an agent service boundary
• Use MCP for an agent's tool and resource connections
• Use framework-native calls for tightly coupled internal orchestration
• Keep consequential business authorization outside model judgment

Treat discovery as metadata, not trust

An Agent Card describes the server's identity, endpoint, supported interfaces, capabilities, security schemes, and skills. A public card can live at the standardized well-known location, while sensitive detail can be placed in an authenticated extended card or a curated registry. Publish only what a legitimate client needs. Internal hostnames, privileged skills, tenant structure, debug examples, and secrets do not belong in a public document.

Validate a discovered card before use. Confirm the HTTPS origin, apply an allowlist or registry policy, check required fields and supported versions, constrain redirects, and record the card version used for each connection. Version 1.0 supports signed Agent Cards, but a valid signature establishes integrity and signer association—not the truth of every capability claim or the safety of the service.

Cache cards using ordinary HTTP semantics, but plan for change. Authentication requirements, interfaces, and skills can be revised. Respect cache headers and ETags, set a maximum acceptable staleness for high-risk workflows, and fail safely when a formerly approved interface changes to an unapproved origin or security scheme.

Choose a binding and negotiate versions explicitly

A2A v1.0 defines a canonical model with three standard bindings: JSON-RPC, gRPC, and HTTP+JSON. Pick one according to existing infrastructure, observability, client support, and payload needs. Multiple bindings expand the test matrix because equivalent operations, errors, authentication, streaming, and task states must behave consistently across them.

Do not infer compatibility from a URL. In v1.0, each advertised interface carries its protocol binding and version, and HTTP clients send the A2A version with requests. Reject unsupported versions predictably. During migration, publish separate supported interfaces or an explicitly tested compatibility path rather than translating silently at an edge proxy.

The move from v0.3 to v1.0 includes breaking changes: operation names, enum representations, part discrimination, Agent Card structure, paths, and several task and push-notification objects changed. Build migration fixtures from real v0.3 messages and cards. Test them against the intended SDK versions and preserve a rollback path until production traffic confirms which versions are actually in use.

Separate authentication, authorization, and content trust

The card advertises acceptable security schemes, but credentials are acquired out of band. Production transports use TLS, and every protected request must be authenticated. Authentication answers who is calling. It does not answer whether that caller may invoke a skill, see a task, download an artifact, cancel work, register a callback, or act for a tenant.

Perform authorization on every operation and object lookup. Scope task visibility to the authenticated principal and tenant before returning whether an identifier exists. Apply least privilege to skills and data, short-lived credentials to services, and an explicit delegation model when an agent acts for a human. Never accept a tenant field, task ID, artifact URL, or claimed user identity as authorization evidence by itself.

Treat all remote content as untrusted even after authentication. Text can contain prompt injection; structured data can violate business invariants; file and URL parts can carry malware, oversized payloads, unsupported types, or references to internal services. Validate outside the model, scan or transform files in isolation, restrict fetch destinations, and require deterministic policy checks before external actions.

Engineer the complete task lifecycle

A production integration is more than SendMessage returning a result. Define what creates a task, when a direct message is sufficient, which state transitions are legal, how clients poll or subscribe, how history is bounded, and what cancellation means after downstream work has begun. Terminal states must be stable and observable.

Specify timeouts and retries at each layer. A client that loses a response may not know whether a server accepted the task. Use stable client correlation and application-level idempotency for operations that could send money, publish content, create accounts, or trigger another system. Cancellation should be best-effort where effects cannot be reversed, with the final task record explaining what completed.

Streaming clients need ordering, reconnection, duplicate-event handling, and a way to reconcile against the current task. Push notifications require authenticated delivery, destination validation, egress restrictions, rotation, replay protection, and lifecycle cleanup. Never let a caller turn the server into an unrestricted request proxy.

Test interoperability, isolation, and recovery

Start with conformance fixtures for cards, messages, parts, tasks, artifacts, errors, timestamps, extensions, and each selected binding. Then cross-test independent SDKs or implementations. Two services generated from the same library can share the same bug and still appear interoperable.

Exercise malformed cards, unsupported versions, expired credentials, forbidden tasks, cross-tenant identifiers, oversized artifacts, hostile URLs, interrupted streams, repeated notifications, timeouts, cancellation races, and server restarts. Confirm that logs show the negotiated version, authenticated principal, authorization decision, task transition, error mapping, and sanitized artifact metadata without storing secrets or unnecessary prompt content.

Roll out in observation or low-consequence mode. Limit task duration, cost, concurrency, artifact size, and downstream authority. Establish service-level objectives for completion, cancellation, error rate, stream recovery, and notification delivery. Rehearse disabling one agent, revoking credentials, draining tasks, preserving evidence, and switching back to a known-compatible version. This guidance is based on the public specification and project documentation; it is not a hands-on certification of any product's A2A implementation.