Dora NodaOne year after Google launched the Agent2Agent protocol, the Linux Foundation announced the scorecard: more than 150 organizations behind the standard, a stable v1.0 spec, and production deployments inside Azure AI Foundry, Amazon Bedrock AgentCore, Salesforce, SAP, and ServiceNow. The agent-to-agent layer of the stack just got its TCP moment — and if you run a platform whose agents deploy and operate apps rather than chat, the question is no longer whether agent interoperability standardizes, but what your own agent-facing surface owes the standard.
The short answer: your MCP server covers agent-to-tool. A2A covers agent-to-agent. They are different axes, the most common architecture mistake of 2026 is treating one as a substitute for the other, and a self-hosted PaaS should track the A2A spec now but ship an endpoint only when a tenant workflow actually fields two independent agents. This post shows the milestone table, the routing rule, a worked deploy-agent-to-monitoring-agent delegation, the minimal-vs-full build cost, and the exact triggers for the build decision.
One year in: the A2A scorecard
A2A's first year compressed the usual five-year standards slog into twelve months. The milestones that matter for a platform operator:
| When | Milestone | Why it matters to a PaaS |
|---|---|---|
| Apr 2025 | Google launches A2A as an open protocol | Agent-to-agent messaging gets a vendor-neutral starting point instead of N proprietary handoff APIs |
| Jun 2025 | Donated to the Linux Foundation | Governance stops being "whatever Google's roadmap says" — the precondition for competitors to build on it |
| Aug 2025 | IBM's Agent Communication Protocol merges into A2A | One rival spec exits the field; the landscape stops being a bet and starts being a standard |
| Dec 2025 | Linux Foundation forms the Agentic AI Foundation (AAIF) with MCP, goose, and AGENTS.md as founding contributions | MCP (agent-to-tool) and A2A (agent-to-agent) end up under one neutral roof, which is the institutional version of "you need both" |
| Sep 2025 – Apr 2026 | AP2 payments protocol emerges as an A2A/MCP extension (signed mandates for agentic commerce); Google donates it to the FIDO Alliance in 2026 | Money movement gets verifiable authorization; relevant the day your agents transact, not before |
| Mar–Apr 2026 | A2A v1.0 ships; Apr 9 one-year announcement: 150+ organizations, production use at Microsoft, AWS, Salesforce, SAP, ServiceNow | The "is it real" question is settled with named production deployments, not logos on a slide |
The v1.0 feature set is what moved A2A from interesting to deployable: cryptographically signed Agent Cards (JWS signatures, so a card fetched from a domain actually proves that domain published it), multi-tenancy primitives for scoping operations per tenant, version negotiation via an A2A-Version header, gRPC transport alongside JSON-RPC over HTTPS, and extended client support in the Python SDK. Point releases since have hardened rather than reshaped that surface.
Note the adoption shape, because it differs from MCP's in a way that matters. MCP spread bottom-up: developers wiring one agent to tools. A2A's first year spread top-down through platforms — Azure AI Foundry and Copilot Studio, Bedrock AgentCore Runtime, Salesforce, SAP, ServiceNow — because agent-to-agent delegation only pays off once there are agents worth delegating to, and those live inside platforms first. Your PaaS is on the producing end of that dynamic, not just the consuming end.
The axis that matters: tools go down, peers go sideways
The entire protocol landscape reduces to one routing rule:
Orchestrator to tool: MCP. Agent to peer agent: A2A.
MCP standardizes how one agent calls a server's tools: pre-configured integrations, stateless request/response, success or failure. A2A standardizes how independent agents discover and delegate work to each other: dynamic discovery via Agent Cards served at /.well-known/agent-card.json, and a stateful task lifecycle — submitted, working, input-required, completed or failed — that survives the long-running, multi-step delegations tool calls never needed.
| MCP (Model Context Protocol) | A2A (Agent2Agent) | |
|---|---|---|
| Direction | Vertical: agent down to tools and data | Horizontal: agent sideways to peer agents |
| Discovery | Pre-configured; the agent is told what tools exist | Dynamic; agents fetch each other's signed Agent Cards |
| Interaction model | Stateless tool call: invoke, get result | Stateful task: submit, track states, handle input-required, complete or fail |
| Trust question it answers | "May this agent call this tool?" | "Is that agent who its card claims, and what happened to my delegated task?" |
| Breaks when you substitute it | An agent pretending a peer is a tool loses task state and must poll a fake synchronous result | An agent pretending a tool is a peer pays discovery + lifecycle overhead for a function call |
The failure mode to avoid is the one practitioners keep flagging: forcing one protocol to do both jobs. A deploy agent that treats a monitoring agent as "just another MCP tool" has nowhere to put task state — no submitted/working/completed lifecycle, no input-required pause while the monitor gathers evidence, no task handle to hand to a human approver. Conversely, wrapping a deterministic tool (restart this container) in A2A task machinery buys nothing but latency and state to manage. The PaaS surface that gets this right exposes both and routes by relationship, not by fashion.
Worked example: a deploy agent that asks a monitoring agent before rolling back
Concretely, here is what A2A delegation looks like for the canonical PaaS scenario from the spec: a deploy agent that delegates a rollback decision to a separate monitoring agent instead of deciding alone.
- Discovery. The deploy agent fetches the monitoring agent's card at
https://monitor.internal/.well-known/agent-card.json. The card advertises arollback-assessmentskill with its input/output schema, the agent's endpoint, and a JWS signature the deploy agent verifies — this is the step that turns "some HTTPS endpoint" into "the monitoring agent we trust." - Task submission. The deploy agent submits a task: "deployment X canary error rate is 4.2%, assess whether to roll back," with the relevant trace and metric references attached as task data. It gets back a task handle in
submittedstate — not a synchronous answer, because assessment takes minutes. - Lifecycle. The task moves to
workingwhile the monitor correlates the canary against baselines. If the monitor needs something — say, the previous release's error budget window — the task moves toinput-requiredand the deploy agent supplies it. States, not vibes: at any point a human operator can read the task and see exactly where the decision stands. - Completion. The task reaches
completedwith a verdict ("roll back: error rate 6x baseline, correlated with deploy timestamp, no matching upstream incident") that the deploy agent acts on — orfailed, in which case the deploy agent falls back to its own policy.
Notice the clean split between wire behavior and platform policy. A2A owns discovery, the task states, and the signature verification. Your platform owns everything that makes the verdict trustworthy: which agents' cards you accept, what evidence a rollback-assessment must cite, and what happens on failed. Standardizing the envelope does not standardize the judgment — it just means the judgment can travel between agents from different vendors without custom glue.
One explicit scoping note: AP2, the payments extension, does not appear in this flow, and that is correct. AP2 answers "is this agent authorized to spend this money" with chains of signed mandates — the hard question in agentic commerce, where the agent, the merchant, and the payment network all need verifiable authorization. A rollback delegation moves a decision, not funds, so AP2 stays out of the deploy/operate path entirely. Track it for the day your agents provision paid resources on a tenant's behalf; until then it is a separate standard solving a separate problem.
What shipping an A2A surface on a self-hosted PaaS concretely costs: minimal vs full
"Support A2A" is not one project. It is a range, and the range spans an order of magnitude:
| Minimal: same-vendor agent pairs | Full: cross-vendor, multi-tenant A2A citizen | |
|---|---|---|
| Agent Card | Static JSON file served at the well-known path | Dynamically generated cards with per-tenant skills, versioning, and JWS signing via your JWKS |
| Task API | One JSON-RPC endpoint: submit task, poll state | Streaming updates, push notifications, input-required round-trips, task history and cancellation |
| Auth | API keys you already issue | v1.0 tenant scoping on every operation, signed-card verification of remote agents, a trust policy for whose cards you accept |
| State | In-memory or existing queue; tasks die with the process | Durable task store with the full state machine, retry and timeout policy, operator-visible task inspection |
| Effort | Days, mostly serialization shapes | Weeks, mostly state durability and cross-tenant trust — not the JSON-RPC envelope |
The hard part deserves emphasis because it surprises teams: the wire protocol is the easy 20%. JSON-RPC request shapes and Agent Card JSON are an afternoon with the SDKs. The expensive 80% is what the protocol deliberately leaves to you — durable task state that survives restarts, a trust policy for which remote agents your agents may delegate to, and tenant isolation so one tenant's monitoring agent cannot be tricked into assessing another tenant's deployment. If your threat model already handles "tenant A's workload must never see tenant B's data," extending it to "tenant A's agent must never delegate to tenant B's agent" is the same muscle, but it is real work.
The good news is that the minimal end is genuinely cheap if you keep your internal task shapes compatible with A2A's Task states from the start. An internal queue with submitted/working/completed semantics can grow an A2A endpoint later as an additive translation layer. An internal queue with bespoke states ("queued," "claimed," "done-ish") needs a rewrite at the seam. This is the cheapest decision in the whole post: name your states the standard way even before you speak the standard.
Verdict: track the spec now, ship the endpoint when tenants bring a second agent
Here is the decision, stated plainly:
- Now: track A2A v1.x as a supported-input spec. Keep internal task states aligned with the A2A lifecycle, serve no endpoint yet, and make sure your MCP server is the excellent agent-to-tool surface tenants need today. Your tenants' first agent talks to your platform through MCP; there is no delegation partner for it yet, so an A2A endpoint would be a discovery surface with nobody to discover.
- Ship the endpoint when: a tenant workflow fields two or more independent agents that need to find and delegate to each other — especially agents from different vendors or frameworks, where bespoke glue stops scaling. The deploy-agent-to-monitoring-agent rollback flow above is the shape to watch for: the day a tenant wants their assessor agent to talk to your deploy agent (or vice versa) without you writing a custom integration, the endpoint pays for itself.
- Keep AP2 out until agents move money. Signed payment mandates are a compliance surface, not a feature flag; adopting them early buys audit obligations with no delegating pair to use them.
This is not "wait and see" — it is conditional commitment with the condition written down. The standard is real, the governance is neutral, the production footprints are named, and the migration path from an A2A-shaped internal queue to an A2A-speaking endpoint is additive. The only thing missing is the second agent. Build the MCP surface your tenants' first agents need, keep your task states standard-shaped, and the day a tenant shows up with a monitoring agent that wants to argue with your deploy agent, you will be one endpoint away from saying yes.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with agent-facing surfaces built for the operators of tomorrow. Star the repo on GitHub or deploy your first app today.
