A2A Turns One and Hits v1.0: What a Standard Agent-to-Agent Handshake Actually Buys a Deploy-From-Chat Pipeline

Google's Agent2Agent protocol closed out its first year in April 2026 with the numbers vendors love to put in a press release: v1.0 stable, 150+ supporting organizations, five production SDKs, and production deployments inside Google Cloud, AWS, and Microsoft Azure. None of that tells a platform engineer the thing they actually need to know: does a deploy pipeline need this protocol, or is it infrastructure for a problem the pipeline doesn't have yet?

That's the question worth answering concretely, not with adoption stats. A2A standardizes how one AI agent discovers, authenticates to, and delegates work to a different agent — a distinct job from MCP's agent-to-tool model. The place that distinction stops being academic is a deploy pipeline where the agent requesting a rollback and the agent (or human) approving it are deliberately different identities with different permissions. Here's what A2A's handshake actually changes about that flow, worked through step by step, and the honest answer on whether a self-hosted PaaS's MCP server needs to speak it yet.

What v1.0 actually shipped​

A2A reached v1.0 in April 2026 under Linux Foundation governance, with Google, Microsoft, AWS, Cisco, Salesforce, SAP, and ServiceNow among the 150+ supporting organizations — up from just over 50 a year earlier. The SDK ecosystem grew from a single Python implementation to five production-ready languages (Python, JavaScript, Java, Go, .NET). Four pieces of the spec matter for what comes next:

• Signed Agent Cards. An Agent Card is a machine-readable JSON manifest — served at a well-known URL — describing an agent's capabilities, skills, and required auth. v1.0 adds a cryptographic signature to that card, so a receiving agent can verify it was actually issued by the domain that claims to own it, not spoofed in transit.
• A stateful task lifecycle. Every unit of work A2A hands between agents is a Task that moves through defined states: submitted, working, input-required, auth-required, completed, failed, canceled, rejected. input-required and auth-required are explicitly interrupted states — the task pauses, waiting on something outside the requesting agent's control, rather than the connection just hanging or timing out.
• Push notifications for long-running tasks. Instead of a client polling Get Task in a loop, a server can POST a state-change event to a webhook the client registered up front — built for tasks that don't resolve in milliseconds.
• A distinct layer from MCP. MCP operates at the model-to-tool level (JSON-RPC over stdio or HTTP, one agent reaching one server's tools). A2A operates at the application-to-application level (HTTP, one agent's runtime reaching another agent's runtime). The two are designed to compose, not compete.

That's the spec. The interesting part is what it looks like wired into an actual deploy flow.

The worked example: a rollback request between two agents​

Take the concrete case this whole question hinges on — a deploy-from-chat platform where a monitoring agent decides a bad deploy needs rolling back, but doesn't itself hold rollback credentials. Two agents, two identities, two scopes:

• The requester: an on-call monitoring agent watching error rates and health checks. Read-only scope — it can query metrics and logs, nothing that mutates a deployment.
• The approver: a deploy-authority agent that actually holds the credential to call bex's control-plane API and execute a rollback.

Without A2A, this is a bespoke integration: the monitoring agent calls a webhook, waits on a queue, or polls a status endpoint someone hand-built for exactly this handoff — and the two agents typically end up sharing enough context (an API key, a shared queue namespace) that the "different scopes" boundary is more convention than enforcement. With A2A, the handoff has a standard shape:

1. Discovery. The monitoring agent fetches the deploy-authority agent's signed Agent Card and confirms two things before sending anything: the card's signature verifies against the claimed domain, and the card advertises a deploy.rollback skill. Provenance is checked before authority is handed off, not after.
2. Request. The monitoring agent sends an A2A message: roll back app-x to the last healthy revision, with the error-rate data that triggered the request attached as context. This opens a Task in submitted state.
3. Interrupt. The deploy-authority agent doesn't execute immediately. It moves the task to auth-required — the standard state for "this needs a check before I act," whether that check is a policy engine, a spend/blast-radius guard, or an actual human approval click surfaced through a dashboard. This is the same state a human-in-the-loop deploy already needs; A2A just gives it a name and a wire format instead of a bespoke "pending" flag two engineers agreed on in a Slack thread.
4. Resolution. Once the check clears, the deploy-authority agent moves the task to working, executes the rollback, and completes the task with a typed artifact — a job ID, the revision rolled back to, a timestamp — sent back to the requester. If the requester registered a push-notification webhook, it doesn't need to poll; it gets the state change pushed to it.

The monitoring agent never held rollback credentials at any point in that sequence. It held the ability to ask, verified against a signed identity, in a format neither side had to invent.

Where this genuinely buys something over hand-rolling it​

Three concrete things, none of which come for free from an ad hoc webhook:

• Scoped identity is structural, not conventional. Two agents with two Agent Cards means two separately verifiable identities. A hand-rolled integration usually collapses this — both agents end up validating against the same API key or service account because that's the fastest way to wire two internal services together, and the "different scopes" boundary lives in code review discipline rather than the protocol.
• A standard vocabulary for "this needs a pause." auth-required and input-required are wire-level states a client can branch on generically — show a pending-approval UI, wait for a webhook, whatever — instead of every team inventing its own polling loop or bespoke status: pending string that the next engineer has to reverse-engineer.
• Provenance before authority, not after an incident. Verifying a signed Agent Card before sending a rollback request is the difference between "we trust this because it's on our internal network" and "we trust this because we checked." That distinction matters more the moment a rollback-authority agent is reachable by more than one internal team's monitoring bot.

Where MCP still does the actual work​

None of this replaces MCP — it sits one layer above it. In the worked example, step 4's actual rollback still happens as an MCP tool call: the deploy-authority agent, once the auth-required gate clears, calls a deploy.rollback tool against bex's control-plane API exactly the way a human-triggered deploy-from-chat request already does. A2A governs the handshake between the two agents deciding whether that call should happen; MCP governs the call itself once it's authorized.

That division only exists in the first place because the approver in this example is an agent, not a human. Today, on a platform where a human clicks "approve" in a dashboard or a Slack message, that whole handshake collapses to normal MCP tool calls plus an existing UI — there's no second agent identity to hand off to, so there's nothing for A2A to standardize.

Should bex build an A2A Agent Card now, or wait?​

Defer it — but with a specific trigger for revisiting, not an indefinite "later."

The honest read of bex's roadmapped MCP server is that it currently has one agent identity in the loop: whatever agent a tenant is chatting with, calling deploy/rollback/logs tools directly, with a human as the approval step when one exists. That's a single agent-to-tool relationship MCP already covers completely. A2A earns its keep the moment the approver itself becomes an agent — a separate policy agent, a fleet-wide guardrail agent, an orchestrating agent delegating to a specialist — because that's the specific pattern A2A's Agent Cards, task states, and signed identity exist to standardize. Building an Agent Card and a task-lifecycle handler ahead of that pattern showing up in a real tenant workflow is coordination infrastructure for a coordination problem that doesn't exist yet.

The concrete trigger worth watching for: a tenant (or bex's own internal tooling) building a supervising agent that approves or gates another agent's deploy actions, rather than a human doing that gating. That's the moment "agent requests, agent approves" stops being a hypothetical and becomes a real integration bex's MCP surface needs to hand off to.

Deferring doesn't create rework later, either. A well-scoped MCP tool surface with role-based identities — a rollback tool that only certain credentials can call — is the same precondition A2A needs anyway: an Agent Card can't advertise a scoped deploy.rollback skill on top of an API that doesn't already separate who can request from who can execute. Getting the MCP-level scoping right now is the actual prerequisite; the A2A layer on top of it is additive, not a foundation that has to be poured early.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. If your deploy-from-chat setup is starting to involve more than one agent identity, check out the repo on GitHub and see how we're scoping agent authority into the control-plane API from day one.