Field note · Protocols · July 2026
A2A v1.0: the enterprise boundary between agents
A2A does not replace MCP. It creates a separate contract for independent agents to discover one another, coordinate long-running work and exchange results across organisational boundaries.
Why this matters now
Agent platforms are moving beyond one framework and one organisation. A2A v1.0 aligns agent interaction with web-friendly patterns such as HTTP, gRPC, polling, streaming and webhooks. That makes familiar gateways, identity, observability and scaling patterns relevant again.
The architecture boundary
Use MCP inside an agent to access tools and resources. Use A2A between agents when the remote capability remains an opaque, independently operated system. This distinction prevents every remote specialist from being reduced to a giant tool definition.
Production design
Treat Agent Cards as discoverable contracts, not trust. Add identity, tenant boundaries, capability allow-lists, task deadlines, idempotency, trace propagation, artifact validation and compensation for partial failure. Long-running A2A tasks should be durable workflows rather than fragile request chains.
My engineering perspective
The same principles used in event-driven order orchestration apply: stable contracts, correlation IDs, retries, dead-letter handling, replay and operational ownership. Agent interoperability is new; distributed-systems failure modes are not.
Executive takeaway
A2A creates optionality across vendors and platforms, but open communication without governance creates a larger attack and failure surface. Adopt the protocol together with an enterprise agent control plane.