When to Adopt A2A vs Build a Custom Handoff Protocol
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 agentsDecision 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 | Your score |
|---|---|---|---|---|
| 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 underneathAnti-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.
Related
- What A2A Solves That MCP Doesn't
- Agent-to-Agent Protocols Basics
- Agent Cards: How Agents Advertise Their Capabilities
- Cross-Cloud Agent Interoperability: Azure, Bedrock, and Google Cloud
- Agent-to-Agent Protocols Best Practices
- Architecture Guide: Designing a Multi-Agent System's Communication Contract
- Context Handoff: Passing State Between Agents Cleanly
- Multi-Agent Handoff: Specialist Agents Passing Work to Each Other
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.