The Agent2Agent (A2A) protocol — an open standard for letting independently built AI agents discover each other, negotiate tasks, and exchange results — has reached v1.0. Where Model Context Protocol (MCP) standardised how a single agent talks to its tools, A2A standardises how separate agents, often built by different vendors on different models, talk to each other. For platforms like ApiSpi that run multiple specialised agents per customer, this is the piece that's been missing.
MCP and A2A Are Complementary, Not Competing
It's worth being precise about the layers here, because the two protocols solve different problems:
- MCP (agent → tool) — gives an agent a standard way to call external tools and data sources: a CRM, a document store, a search index. We covered this in depth in our MCP deep dive.
- A2A (agent → agent) — gives one agent a standard way to discover another agent's capabilities, hand off a task to it, and receive structured results back — without either agent needing to know the other's internal implementation, model, or hosting provider.
Together, they form a two-layer interoperability stack: MCP connects agents to the world's data and systems, and A2A connects agents to each other.
What's New in v1.0
The jump from the earlier draft specifications to v1.0 brings four changes that matter for production deployments:
- Agent Cards — every A2A-compliant agent now publishes a signed capability manifest describing what tasks it can perform, what input/output schemas it expects, and its pricing or rate-limit model. Discovery is now a simple HTTP fetch rather than bespoke documentation.
- Stateful task delegation — a requesting agent can hand off a long-running task (e.g. "research these 12 competitors and summarise pricing") and poll or subscribe to streaming progress updates, rather than blocking on a single request/response cycle.
- Standardised auth handshake — OAuth2-based delegation tokens let an agent act on a user's behalf when calling another vendor's agent, with scoped permissions and full audit trails.
- Error and refusal semantics — a common vocabulary for "I can't do this", "I need more information", and "this requires human approval", so orchestrating agents can handle failure gracefully instead of treating every non-200 response the same way.
Why This Matters for Multi-Agent Workspaces
ApiSpi's Workspaces feature already lets a team bring multiple subscribed agents together around a shared conversation. Until now, coordination between agents in a workspace has relied on ApiSpi's own internal routing. A2A v1.0 opens the door to a much bigger idea: workspaces that include agents from outside ApiSpi entirely — a specialist legal-research agent from one vendor, a finance-data agent from another, and an ApiSpi agent orchestrating the conversation — all communicating through a shared, open protocol.
Concretely, picture our Bid & Tender Response agent working an AusTender submission. Today it handles compliance matrix extraction, CV-to-criteria matching, and drafting end-to-end using ApiSpi's own pipeline. With A2A, that same agent could delegate a niche sub-task — say, verifying a subcontractor's ABN and insurance status against a government registry agent maintained by a specialist compliance vendor — as a discrete, auditable hand-off, then fold the result back into the main response without any custom integration code.
Practical Implications for Agent Builders
For teams building or customising agents on ApiSpi, A2A v1.0 changes a few defaults:
- Capability discovery becomes declarative. Instead of hardcoding which agent handles which task, orchestrators can query Agent Cards at runtime and route accordingly — useful when new specialist agents are added to a workspace mid-project.
- Long-running tasks need streaming-aware UI. If an agent can delegate a multi-minute research task to another agent, the front end needs to show meaningful progress rather than a spinner — the same pattern ApiSpi already uses for Aria's longer tool-calling sessions.
- Permission scoping matters more. Delegation tokens mean an agent acting on your behalf has exactly the access it needs for that task and nothing more — a meaningful improvement over the all-or-nothing API keys most integrations use today.
What's Next
Expect the next twelve months to look a lot like the early days of MCP adoption: a wave of "A2A-compatible" badges across agent marketplaces, a handful of reference implementations becoming de-facto standards, and — eventually — the protocol fading into the background as just how agents are expected to talk to each other. For ApiSpi customers, the immediate benefit is optionality: the specialist agent you need doesn't have to be one we built, as long as it speaks A2A.
We'll be publishing a follow-up technical guide as ApiSpi's own A2A endpoints roll out across the agent catalog — subscribe to the blog or check your dashboard for updates.