A2A Hit 1.0 and Moved In With MCP: What Agent-to-Agent Handoff Actually Adds to Deploy-from-Chat

In March 2026, Google's Agent2Agent protocol hit 1.0. In August, it moved under the same Linux Foundation roof as MCP. If you run a deploy-from-chat surface — one agent calling your MCP server's deploy tool — the question those two milestones force is concrete, not philosophical: what does agent-to-agent handoff actually buy you that one more MCP tool doesn't, and what would you have to build to support it?

Here is the answer up front:

The rest of this post is the reasoning behind that table: where both protocols actually stand in September 2026, the same deploy worked through both shapes so you can see the real delta, the exact extra surface a self-hosted PaaS must expose beyond one MCP server, and a verdict on whether any of this belongs on your near-term roadmap.

Where both protocols stand in September 2026​

A2A's path to stability moved fast. Google published it in April 2025, donated it to the Linux Foundation in June 2025, merged IBM's rival Agent Communication Protocol into it that August, and shipped v1.0 on March 12, 2026, followed by a 1.0.1 patch in May. More than 150 organizations now participate — AWS, Cisco, Google, IBM, Microsoft, Salesforce, SAP, ServiceNow among them — and A2A support is shipping in the major clouds' agent frameworks. Then came the governance consolidation: on August 17, 2026, A2A joined the Agentic AI Foundation (AAIF), the Linux Foundation body formed in December 2025 that already houses MCP, Block's goose framework, OpenAI's AGENTS.md, Solo.io's Agentgateway, and the AGNTCY multi-agent standards. Both halves of the agent stack now answer to one vendor-neutral foundation.

The protocol itself is deliberately small. Three primitives do almost all the work. An Agent Card — a JSON document at /.well-known/agent-card.json — advertises an agent's identity, capabilities, and skills the way a business card advertises a person. A Task is a stateful unit of delegated work with an explicit lifecycle: submitted, working, optionally input-required, then completed, failed, or canceled. A Message is one turn inside that work, with a user or agent role and typed parts — text, file, or structured data. Discovery is a GET, delegation is a message send, long work streams back over server-sent events or webhooks, and execution stays opaque by design: peers see capabilities and messages, never each other's internals.

MCP matured on a parallel track. The 2026-07-28 specification release made the protocol core stateless — the initialize handshake and session IDs are gone (SEP-2575, SEP-2567), every request carries its own version and capabilities, and servers expose a server/discover RPC plus cacheable tool lists. The March 2026 roadmap's four priority areas then pointed at what comes next: stateless transport hardening, enterprise auth, Server Cards (.well-known metadata so registries can discover a server's capabilities without a live connection), and — explicitly — agent-communication primitives that coordinate with A2A rather than competing with it.

The industry shorthand for the split is orientation: MCP is the vertical layer (agent down to tools and data), A2A is the horizontal layer (agent across to agent). The standard advice follows from that geometry: start with MCP, layer A2A on as your agent ecosystem grows. That advice is correct as far as it goes. What it skips is the part a platform operator actually needs: what "layer A2A on" concretely means for a deploy surface, and where the line falls.

One deploy, two shapes​

Make it concrete. The job: deploy repo@sha to production after tests pass, then announce the result in chat. Here is that job in the MCP-only shape most deploy-from-chat setups run today:

user → agent: "deploy main@a1b2c3 to production"
agent → MCP server: tools/call deploy { repo, sha, target: "production" }
MCP server → agent: { status: "live", url: "https://app.example.com" }
agent → user: "Live at https://app.example.com"

One agent, one trust domain, one tool call. The agent holds the whole plan in its own context window: check tests, call deploy, report back. Everything the platform exposes is a tool on a single MCP server, and the July stateless spec means that server is just another HTTP workload behind a load balancer. This shape handles the overwhelming majority of real deploy-from-chat traffic, and nothing about A2A's 1.0 changes that.

Now the same job as an A2A-coordinated pipeline, the kind of split you get when separate teams own separate steps — a release-policy agent owned by platform, an executor owned by the app team, a reporter owned by whoever runs chatops:

user → planner agent (A2A message): "ship main@a1b2c3 to production"
planner → executor agent: fetch Agent Card, message/send Task
  { goal: "deploy", repo, sha, target: "production",
    constraint: "tests green + policy check passed" }
executor → MCP server: tools/call deploy { repo, sha, target }
executor → planner: Task status working → completed,
  artifact { url: "https://app.example.com" }
planner → reporter agent: message/send "announce this deploy"
reporter → user: "Live at https://app.example.com"

Three things changed, and all three are A2A's actual contribution. First, discovery: the planner found the executor by fetching its Agent Card, not through a hardcoded tool binding — swap executors (staging vs production, team A's vs team B's) without reconfiguring the planner. Second, delegated state: the Task lifecycle (submitted → working → completed, with input-required and failed as first-class states) gives a long-running deploy a shared, pollable status object instead of one agent's private context. Third, opaque execution: the planner never sees how the executor deploys — which MCP server it called, which credentials it used. Each agent keeps its own tools, its own secrets, its own trust domain.

The Agent Card that makes discovery work is intentionally boring infrastructure — JSON over HTTPS:

{
  "name": "prod-deploy-executor",
  "description": "Deploys validated releases to production",
  "version": "1.4.0",
  "capabilities": ["task-delegation", "streaming"],
  "skills": [
    {
      "name": "deploy",
      "description": "Deploy a validated repo@sha to a target environment"
    }
  ]
}

Notice what the card does not contain: no MCP tool schemas, no API keys, no deployment internals. It is a directory entry plus a handshake, and that thinness is the point. A2A standardizes finding an agent and handing it work; what the agent does with the work — usually calling MCP tools — stays MCP's job. The two protocols meet exactly at the executor: A2A above it, MCP below it.

The surface delta: what a PaaS exposes beyond one MCP server​

That meeting point is where the roadmap question gets concrete. A self-hosted PaaS with a deploy-from-chat MCP server already owns the bottom half. Supporting A2A pipelines means adding the top half, and the delta is specific enough to checklist:

Two rows deserve emphasis because they are where teams underestimate the work. The task receiver is a genuinely new server: unlike an MCP tool call, which completes inside one request or a bounded extension, an A2A task is a long-lived object another agent polls, subscribes to, and may cancel. That means persisted task state, lifecycle transitions your deploy pipeline must actually drive (a deploy stuck in "working" forever is now a protocol-visible lie, not a slow tool call), and timeout and cancellation semantics you have to define. And cross-agent auth is the item that turns a demo into a project: one MCP server means one credential relationship, while A2A's whole premise is agents that don't share credentials delegating across a boundary. OAuth or mTLS between agents, scoped to "this planner may ask this executor to deploy," is enterprise-identity work wearing a protocol costume.

The cheap rows matter too, though, because they set up a useful sequencing: publishing an Agent Card for your deploy surface and mapping your deploy states onto the task lifecycle cost little, break nothing about your MCP story, and leave you A2A-readable the day a tenant's planner comes knocking.

Verdict: near-term roadmap or later problem?​

Apply the checklist to the tenants a self-hosted PaaS actually serves today, and the line from the opening table sharpens into a rule: if one agent and one trust domain can see the whole deploy, MCP alone is the complete answer. A developer telling their coding agent to ship to production, a chatops bot redeploying staging — these never touch a second agent, so A2A adds a task receiver, a lifecycle mapping, and a cross-agent auth story in exchange for nothing. The honest cost of adopting A2A early isn't just the build; it's operating a second protocol surface (versioning, auth rotation, task-state storage) for pipelines that don't exist yet.

A2A earns its place when the organizational shape of a deploy outgrows one agent's context. The realistic triggers, in order of likelihood: a tenant running a genuine planner/executor split (policy agent validates, deploy agent executes, audit agent records); a platform team exposing its executor to other teams' planners without sharing credentials; and cross-organization releases, where your executor takes delegated work from a partner's agent you will never share a tool server with. Note the common thread — every trigger is about trust boundaries and team boundaries, not about deploy complexity. A fiendishly complex single-team deploy still wants richer MCP tools, not A2A.

So the recommended sequence for a self-hosted PaaS in H2 2026: keep the MCP server as the deploy surface and finish the stateless baseline if you haven't. Publish an Agent Card for it and align your deploy states with the task lifecycle — cheap, compatible, and genuinely useful the moment any A2A traffic arrives. Build the full task receiver and cross-agent auth when a tenant actually runs a planner/executor split against you, not before. A2A's 1.0 and the AAIF consolidation mean the protocol is stable enough to build on; they don't mean every deploy surface needs it this quarter. The protocol wars ended with convergence instead of fragmentation — which is exactly why you can afford to adopt each layer when its shape matches your tenants, rather than all at once on announcement day.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.