When to Adopt A2A vs Build a Custom Handoff Protocol

Q: Is A2A always "more enterprise"?

It is more standard. Enterprise value comes from ops discipline around any protocol.

Q: How does this relate to MCP?

MCP is tools/context. This checklist is about peer agents. You can choose custom/A2A for peers independently of MCP for tools. See What A2A Solves That MCP Doesn't.

Not every multi-agent system needs A2A on day one.

A custom handoff (shared JSON over your internal HTTP/queue) can be the right answer for two services you own. A2A becomes valuable when discovery, long-running tasks, and multi-party interop start to dominate cost.

How to Use This Cheatsheet

Walk the decision checklist top to bottom; stop when a hard yes/no appears.
Use the scorecard when stakeholders disagree.
Use migration paths if you already shipped custom JSON.
Revisit after the number of peer agents or owning teams changes.

At a Glance

Choose	When
In-process framework handoff	Same deployable, shared memory OK, one team
Custom HTTP/queue handoff	2-3 stable internal peers, simple sync jobs
A2A	Separate deployables, multiple owners/vendors, need cards/tasks/streaming
A2A + MCP	Peers plus portable tools inside each peer
Wait / do nothing extra	Still validating single-agent product value

Same process?  → framework edges
Few internal peers, simple? → custom handoff
Many peers / external / long tasks? → A2A
Need tools too? → MCP inside agents

Decision Checklist

1. Topology and ownership

A. All "agents" are functions/nodes in one runtime → prefer framework handoffs (LangGraph, Agents SDK, etc.).
B. Two services, both owned by one team, private network only → custom handoff is acceptable.
C. Three or more peer services or more than one owning team → bias to A2A.
D. Any external vendor/partner agent → A2A (or another shared open standard), not a one-off partner JSON.

2. Capability discovery

Peers never change skills → hardcoded client routes may suffice.
Skills change monthly or clients must choose peers dynamically → Agent Cards pay off.
You need machine-readable modality/auth ads → A2A-style cards beat wiki pages.

3. Task shape

Request/response under a few seconds, no resume → custom POST is fine.
Jobs run minutes to hours, need cancel/resume/progress → need task lifecycle (A2A or a careful custom equivalent).
Human-in-the-loop pauses inside the remote agent → async task model required.
Streaming partial artifacts matter to UX → prefer A2A streaming profile over ad hoc SSE.

4. Security and compliance

Same trust domain, coarse auth OK → custom may pass audit if documented.
Cross-org or regulated boundary → standard protocol + gateway controls easier to explain.
Opaque execution required (partner must not see your tools) → A2A skill surface, not shared MCP admin tools.

5. Ecosystem pressure

All clients are your code forever → custom possible.
Third parties will call you, or you will call marketplace agents → A2A reduces N×M adapters.
Cloud platform direction already standardizes A2A → align unless you have a strong reason not to.

6. Team cost

Can you staff protocol edge cases (streaming timeouts, idempotency, card versioning)? If no, minimize peer count or buy an SDK.
Is custom "simpler" only because it omits cancel, audit, and versioning? Price those features before claiming savings.

Scorecard (0-2 each)

Score each row: 0 = favors custom/framework, 2 = favors A2A.

Factor	0	1	2
Number of peer agents	1 in-process	2 internal services	3+ or external
Owners	One team	Two teams	Org boundary / vendor
Task duration	Seconds	Minutes	Hours / HITL
Discovery needs	Static routes	Occasional config	Dynamic skills
Streaming / push	None	Nice-to-have	Required UX
Interop roadmap	Never	Maybe next year	Active this quarter

Interpretation:

Total	Guidance
0-4	Stay on framework or tiny custom handoff
5-8	Custom OK if you implement task ids + auth seriously; design so you can swap to A2A later
9-12	Adopt A2A (or an adapter to it) as the peer contract

Custom Handoff: Minimum Viable Shape

If you stay custom, do not ship free-form chat strings only.

Minimum fields:

{
  "handoff_id": "01J...",
  "from_agent": "orchestrator",
  "to_agent": "billing",
  "skill": "invoice_status",
  "input": { "invoice_id": "INV-1001" },
  "deadline_ms": 30000,
  "traceparent": "00-..."
}

Minimum behaviors:

Behavior	Why
Idempotency key	Safe retries
Terminal states	completed/failed/canceled
Size limits	Protect models and logs
Authn/z	Service identity
Schema version	Non-breaking evolution

If your custom protocol grows Agent Card clones + SSE + push, you are reinventing A2A - adopt the standard.

A2A Adoption: Minimum Viable Slice

You do not need a full mesh on week one.

One remote agent with a real Agent Card.
One client allowlisted to its URL.
Sync message/send (or SDK equivalent) for a single skill.
Task id logged end-to-end.
Contract test in CI.
Add streaming only when UX requires it.

See Agent-to-Agent Protocols Basics.

Migration Paths

From	To	Move
In-process multi-agent	Custom or A2A services	Extract specialist; freeze handoff schema first
Custom HTTP JSON	A2A	Map handoff_id → task id; wrap old API in an A2A facade
MCP-only "agent tools"	A2A peers	Stop exposing peer admin tools; publish skills
Multiple vendor SDKs	A2A	One interop profile; adapters at the edge

Facade pattern:

Legacy clients → old /handoff
New clients    → A2A
                  └─ same application service underneath

Anti-Patterns

Anti-pattern	Better
A2A because of a blog post, one agent total	Ship product value first
Custom protocol with no version field	Add version now
Agent Card listing 100 internal tools	Publish few outcome skills
Dual stacks forever (custom + A2A for same peer)	Hard cutover plan
Shared database as "handoff"	Explicit messages; DB is not a protocol

FAQs

Is A2A always "more enterprise"?

It is more standard. Enterprise value comes from ops discipline around any protocol.

Can custom handoff be secure?

Yes, with real auth, schemas, and audits. Security does not require A2A; interop usually does.

What if partners refuse A2A?

Offer an adapter. Do not fragment your internal core for one partner's quirks.

Should greenfield startups start with A2A?

Only if multi-agent multi-owner is already on the critical path. Otherwise framework handoffs first.

How does this relate to MCP?

MCP is tools/context. This checklist is about peer agents. You can choose custom/A2A for peers independently of MCP for tools. See What A2A Solves That MCP Doesn't.

Queues instead of HTTP?

Fine for custom internal handoffs. If you need open interop, keep an A2A HTTP edge even if internals are queued.

When do we revisit a "custom is fine" decision?

New owning team, first external peer, first multi-hour task, or third client implementation of the same handoff.

Is Microsoft/Google/AWS support mandatory before adopting A2A?

No. You can run open SDKs and facades. Managed support only changes how much glue you write. Verify at build.

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.

When to Adopt A2A vs Build a Custom Handoff Protocol

Not every multi-agent system needs A2A on day one.

How to Use This Cheatsheet

Walk the decision checklist top to bottom; stop when a hard yes/no appears.
Use the scorecard when stakeholders disagree.
Use migration paths if you already shipped custom JSON.
Revisit after the number of peer agents or owning teams changes.

At a Glance

Choose	When
In-process framework handoff	Same deployable, shared memory OK, one team
Custom HTTP/queue handoff	2-3 stable internal peers, simple sync jobs
A2A	Separate deployables, multiple owners/vendors, need cards/tasks/streaming
A2A + MCP	Peers plus portable tools inside each peer
Wait / do nothing extra	Still validating single-agent product value

Same process?  → framework edges
Few internal peers, simple? → custom handoff
Many peers / external / long tasks? → A2A
Need tools too? → MCP inside agents

Decision Checklist

1. Topology and ownership

A. All "agents" are functions/nodes in one runtime → prefer framework handoffs (LangGraph, Agents SDK, etc.).
B. Two services, both owned by one team, private network only → custom handoff is acceptable.
C. Three or more peer services or more than one owning team → bias to A2A.
D. Any external vendor/partner agent → A2A (or another shared open standard), not a one-off partner JSON.

2. Capability discovery

Peers never change skills → hardcoded client routes may suffice.
Skills change monthly or clients must choose peers dynamically → Agent Cards pay off.
You need machine-readable modality/auth ads → A2A-style cards beat wiki pages.

3. Task shape

Request/response under a few seconds, no resume → custom POST is fine.
Jobs run minutes to hours, need cancel/resume/progress → need task lifecycle (A2A or a careful custom equivalent).
Human-in-the-loop pauses inside the remote agent → async task model required.
Streaming partial artifacts matter to UX → prefer A2A streaming profile over ad hoc SSE.

4. Security and compliance

Same trust domain, coarse auth OK → custom may pass audit if documented.
Cross-org or regulated boundary → standard protocol + gateway controls easier to explain.
Opaque execution required (partner must not see your tools) → A2A skill surface, not shared MCP admin tools.

5. Ecosystem pressure

All clients are your code forever → custom possible.
Third parties will call you, or you will call marketplace agents → A2A reduces N×M adapters.
Cloud platform direction already standardizes A2A → align unless you have a strong reason not to.

6. Team cost

Can you staff protocol edge cases (streaming timeouts, idempotency, card versioning)? If no, minimize peer count or buy an SDK.
Is custom "simpler" only because it omits cancel, audit, and versioning? Price those features before claiming savings.

Scorecard (0-2 each)

Score each row: 0 = favors custom/framework, 2 = favors A2A.

Factor	0	1	2
Number of peer agents	1 in-process	2 internal services	3+ or external
Owners	One team	Two teams	Org boundary / vendor
Task duration	Seconds	Minutes	Hours / HITL
Discovery needs	Static routes	Occasional config	Dynamic skills
Streaming / push	None	Nice-to-have	Required UX
Interop roadmap	Never	Maybe next year	Active this quarter

Interpretation:

Total	Guidance
0-4	Stay on framework or tiny custom handoff
5-8	Custom OK if you implement task ids + auth seriously; design so you can swap to A2A later
9-12	Adopt A2A (or an adapter to it) as the peer contract

Custom Handoff: Minimum Viable Shape

If you stay custom, do not ship free-form chat strings only.

Minimum fields:

{
  "handoff_id": "01J...",
  "from_agent": "orchestrator",
  "to_agent": "billing",
  "skill": "invoice_status",
  "input": { "invoice_id": "INV-1001" },
  "deadline_ms": 30000,
  "traceparent": "00-..."
}

Minimum behaviors:

Behavior	Why
Idempotency key	Safe retries
Terminal states	completed/failed/canceled
Size limits	Protect models and logs
Authn/z	Service identity
Schema version	Non-breaking evolution

If your custom protocol grows Agent Card clones + SSE + push, you are reinventing A2A - adopt the standard.

A2A Adoption: Minimum Viable Slice

You do not need a full mesh on week one.

One remote agent with a real Agent Card.
One client allowlisted to its URL.
Sync message/send (or SDK equivalent) for a single skill.
Task id logged end-to-end.
Contract test in CI.
Add streaming only when UX requires it.

See Agent-to-Agent Protocols Basics.

Migration Paths

From	To	Move
In-process multi-agent	Custom or A2A services	Extract specialist; freeze handoff schema first
Custom HTTP JSON	A2A	Map handoff_id → task id; wrap old API in an A2A facade
MCP-only "agent tools"	A2A peers	Stop exposing peer admin tools; publish skills
Multiple vendor SDKs	A2A	One interop profile; adapters at the edge

Facade pattern:

Legacy clients → old /handoff
New clients    → A2A
                  └─ same application service underneath

Anti-Patterns

Anti-pattern	Better
A2A because of a blog post, one agent total	Ship product value first
Custom protocol with no version field	Add version now
Agent Card listing 100 internal tools	Publish few outcome skills
Dual stacks forever (custom + A2A for same peer)	Hard cutover plan
Shared database as "handoff"	Explicit messages; DB is not a protocol

FAQs

Is A2A always "more enterprise"?

It is more standard. Enterprise value comes from ops discipline around any protocol.

Can custom handoff be secure?

Yes, with real auth, schemas, and audits. Security does not require A2A; interop usually does.

What if partners refuse A2A?

Offer an adapter. Do not fragment your internal core for one partner's quirks.

Should greenfield startups start with A2A?

Only if multi-agent multi-owner is already on the critical path. Otherwise framework handoffs first.

How does this relate to MCP?

MCP is tools/context. This checklist is about peer agents. You can choose custom/A2A for peers independently of MCP for tools. See What A2A Solves That MCP Doesn't.

Queues instead of HTTP?

Fine for custom internal handoffs. If you need open interop, keep an A2A HTTP edge even if internals are queued.

When do we revisit a "custom is fine" decision?

New owning team, first external peer, first multi-hour task, or third client implementation of the same handoff.

Is Microsoft/Google/AWS support mandatory before adopting A2A?

No. You can run open SDKs and facades. Managed support only changes how much glue you write. Verify at build.

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.

When to Adopt A2A vs Build a Custom Handoff Protocol

Search Documentation

When to Adopt A2A vs Build a Custom Handoff Protocol