Agent-to-Agent Protocols Best Practices

Ten practices for adopting A2A-style interoperability so multi-agent systems gain real peer contracts without turning a single-team prototype into a protocol science project.

How to Use This List

Use items 1-3 when deciding whether A2A belongs in the design at all.
Use items 4-7 when publishing cards, securing edges, and shaping tasks.
Use items 8-10 for production ops, testing, and evolution.
Jump to sibling pages when an audit item fails; this list is a control checklist.

Start from a peer job story, not a protocol fashion cycle. Adopt A2A when you have separately deployed or separately owned agents that must exchange tasks. Keep in-process specialists on framework handoffs until that boundary is real. See When to Adopt A2A vs Build a Custom Handoff Protocol.
Keep MCP and A2A on different seams. Use MCP (or in-process tools) for systems of record; use A2A for opaque peer agents. Do not re-export a partner agent's admin tools into your host "as MCP" just to avoid learning tasks. See What A2A Solves That MCP Doesn't.
Prefer one peer protocol per edge. If you must speak a second agent protocol (platform mandate, partner ACP-class stack), isolate it behind a gateway. Dual native clients everywhere is how N×M returns. See The Broader Protocol Stack.
Publish sharp Agent Cards, not tool dumps. Skills should be outcome-oriented, versioned, and few. Advertise only modalities and streaming/push features you implement. Never put secrets in cards. See Agent Cards: How Agents Advertise Their Capabilities.
Allowlist peers the way you allowlist tools. Clients should not fetch arbitrary internet cards in production. Pin card URLs, expected skill ids, and auth audiences per environment (dev/stage/prod).
Design tasks for failure, cancel, and time. Assume at-least-once delivery, partial artifacts, and hung streams. Set deadlines, support cancel, and define client behavior on non-terminal states. See A2A's Transport Layer: HTTP, SSE, and JSON-RPC 2.0.
Authenticate at the gateway; authorize by skill risk. Terminate TLS and identity in infrastructure you understand. Split read-like skills from write/send skills; require stronger policy or human approval for irreversible peer actions.
Bound context crossing the wire. Pass the minimum message parts needed for the skill. Prefer references over huge inline blobs. Treat remote artifacts as untrusted text for prompt-injection purposes before they re-enter your model.
Contract-test cards and golden tasks in CI. For each peer: fetch card → assert skills → send one golden message → assert terminal state and artifact shape. Run the suite when either side deploys. Add a staging peer per cloud you claim to support. See Cross-Cloud Agent Interoperability.
Operate with traces, budgets, and owners. Log task id, skill, latency, and cloud/region; propagate traceparent. Cap concurrency and spend per peer. Publish an owner for every Agent Card the same way you publish on-call for a service.

FAQs

Why only ten practices?

This page is an adoption control set. Sibling pages cover cards, transport, cloud interop, and MCP comparisons in depth.

Is A2A required for every multi-agent demo?

No. Same-process graphs should stay simple. Add A2A when agents become real services or external peers.

What is the highest-ROI safety habit?

Peer URL allowlists plus skill-level authorization. Most incidents start with over-broad trust, not missing JSON fields.

Should every microservice publish an Agent Card?

No. Only peer reasoners that should accept collaborative tasks. Ordinary APIs stay OpenAPI/MCP.

How do these practices relate to custom handoffs?

If you stay custom, still apply items 5-10 (allowlists, task failure modes, authz, bounds, tests, owners). See the decision cheatsheet when considering a switch.

Do foundation or vendor logos replace our reviews?

No. Standards help interop. You still review each peer endpoint, skill, and credential path you enable.

When should we add streaming?

When UX or ops need incremental progress. Sync task create + poll is fine until that need is proven.

How often should we re-audit peer agents?

On skill/version changes, auth changes, new write skills, and on a scheduled cadence for high-data peers.

Stack versions: Pins from the category manifest (verify at build): OpenRouter (~315+ models, July 2026 pricing/fees); LangGraph 1.0+; CrewAI 1.14+; Microsoft Agent Framework 1.0; Vercel AI SDK 6; Pydantic AI (latest); LlamaIndex (latest); OpenAI Agents SDK (latest + MCP); MCP (Linux Foundation governance); A2A (HTTP+SSE+JSON-RPC 2.0); Solana @solana/web3.js + @solana/spl-token.

How to Use This List

Use items 1-3 when deciding whether A2A belongs in the design at all.

Use items 4-7 when publishing cards, securing edges, and shaping tasks.

Use items 8-10 for production ops, testing, and evolution.

Jump to sibling pages when an audit item fails; this list is a control checklist.

Start from a peer job story, not a protocol fashion cycle. Adopt A2A when you have separately deployed or separately owned agents that must exchange tasks. Keep in-process specialists on framework handoffs until that boundary is real. See When to Adopt A2A vs Build a Custom Handoff Protocol.

Keep MCP and A2A on different seams. Use MCP (or in-process tools) for systems of record; use A2A for opaque peer agents. Do not re-export a partner agent's admin tools into your host "as MCP" just to avoid learning tasks. See What A2A Solves That MCP Doesn't.

Prefer one peer protocol per edge. If you must speak a second agent protocol (platform mandate, partner ACP-class stack), isolate it behind a gateway. Dual native clients everywhere is how N×M returns. See The Broader Protocol Stack.

Publish sharp Agent Cards, not tool dumps. Skills should be outcome-oriented, versioned, and few. Advertise only modalities and streaming/push features you implement. Never put secrets in cards. See Agent Cards: How Agents Advertise Their Capabilities.

Allowlist peers the way you allowlist tools. Clients should not fetch arbitrary internet cards in production. Pin card URLs, expected skill ids, and auth audiences per environment (dev/stage/prod).

Design tasks for failure, cancel, and time. Assume at-least-once delivery, partial artifacts, and hung streams. Set deadlines, support cancel, and define client behavior on non-terminal states. See A2A's Transport Layer: HTTP, SSE, and JSON-RPC 2.0.

Authenticate at the gateway; authorize by skill risk. Terminate TLS and identity in infrastructure you understand. Split read-like skills from write/send skills; require stronger policy or human approval for irreversible peer actions.

Bound context crossing the wire. Pass the minimum message parts needed for the skill. Prefer references over huge inline blobs. Treat remote artifacts as untrusted text for prompt-injection purposes before they re-enter your model.

Contract-test cards and golden tasks in CI. For each peer: fetch card → assert skills → send one golden message → assert terminal state and artifact shape. Run the suite when either side deploys. Add a staging peer per cloud you claim to support. See Cross-Cloud Agent Interoperability.

Operate with traces, budgets, and owners. Log task id, skill, latency, and cloud/region; propagate traceparent. Cap concurrency and spend per peer. Publish an owner for every Agent Card the same way you publish on-call for a service.

FAQs

Why only ten practices?

This page is an adoption control set. Sibling pages cover cards, transport, cloud interop, and MCP comparisons in depth.

Is A2A required for every multi-agent demo?

No. Same-process graphs should stay simple. Add A2A when agents become real services or external peers.

What is the highest-ROI safety habit?

Peer URL allowlists plus skill-level authorization. Most incidents start with over-broad trust, not missing JSON fields.

Should every microservice publish an Agent Card?

No. Only peer reasoners that should accept collaborative tasks. Ordinary APIs stay OpenAPI/MCP.

How do these practices relate to custom handoffs?

If you stay custom, still apply items 5-10 (allowlists, task failure modes, authz, bounds, tests, owners). See the decision cheatsheet when considering a switch.

Do foundation or vendor logos replace our reviews?

No. Standards help interop. You still review each peer endpoint, skill, and credential path you enable.

When should we add streaming?

When UX or ops need incremental progress. Sync task create + poll is fine until that need is proven.

How often should we re-audit peer agents?

On skill/version changes, auth changes, new write skills, and on a scheduled cadence for high-data peers.

Agent-to-Agent Protocols Best Practices

How to Use This List

FAQs

Related

Search Documentation

Agent-to-Agent Protocols Best Practices

How to Use This List

FAQs

Related