MCP's 2026 roadmap: Tasks, stateless servers, and where it converges with A2A

MCP picked up three big things in its 2026 roadmap that it simply did not have a year ago: async delegation through Tasks, a stateless protocol layer, and discovery you can read without opening a connection. Put them together and MCP suddenly looks a lot more agent-shaped, and if you run it behind a gateway, they change what you should be building for.

In this post I am mainly covering the new capabilities planned for MCP through 2026, and how this is starting to look like a more dominant pattern than Agent to Agent (A2A). There are real gaps today, but they are being closed, and the MCP spec is still changing fast. I also look at where MCP and A2A line up and where they stay separate, because once you can see which is which, you know where your controls belong. For me that is Solo Enterprise for agentgateway. I am biased, but I genuinely believe we have the most complete stack for it.

Everything here comes straight from the roadmap and the 2026-07-28 specification release candidate, the first spec version to turn the roadmap's priorities into real proposals. The roadmap doc is dated 5 March 2026, the release candidate landed on 21 May 2026. Three things matter most.

From release dates to working groups

One quick structural note before the features. The roadmap no longer tracks spec versions. It is now organised around four priority areas, each owned by its own Working Group (set up in SEP-1302 and SEP-2085):

• Transport evolution and scalability
• Agent communication
• Governance maturation
• Enterprise readiness

Tasks: MCP learns to wait

The Tasks primitive landed experimentally in the 2025-11-25 spec, and it is a clear sign of MCP growing past simple tool calls into the kind of delegation A2A was built for.

Before Tasks, MCP was strictly request and response. Great for "read this file". A poor fit for "run this 40-minute migration". Tasks gives you a call-now, fetch-later pattern: the agent kicks the work off, gets a handle back, and comes back for the answer with tasks/get, tasks/update and tasks/cancel. That is not really a tool call any more. That is delegation, and delegation with a lifecycle is exactly the kind of work A2A was built for. One small detail gives the whole thing away: tasks/list was removed, because you cannot scope it safely once sessions disappear. More on sessions shortly.

Running Tasks in production immediately turned up two gaps the Agents Working Group now has to close:

• Retry semantics. A task fails for some transient reason, so who decides whether to retry, and how?
• Expiry policies. How long does a finished result hang around, and how does a client find out its result has expired?

Neither of these is a new problem. Anyone who has built a durable job queue has dealt with both. The interesting part is that MCP is now working through job-lifecycle problems instead of request-and-response problems, and that is a real step up the stack.

And there is more in the release candidate. SEP-2260 tightens up server-initiated requests so a server can only fire one while it is actively handling a client request. No prompts appearing out of nowhere, every interaction traceable back to something a user or agent started. SEP-2322, Multi Round-Trip Requests, changes how those prompts get delivered, swapping held-open SSE streams for a result the client just re-issues with its answers attached. Now put that next to Elicitation, a server pulling a human in for approval mid-call, and you have recursive, human-in-the-loop behaviour happening inside a single MCP exchange. This looks closer to an A2A implementation than the MCP we know today.

One thing worth correcting from the 2025 version of this story. Sampling, where a server asks the model itself to reason mid-call, is on the way out: the release candidate deprecates it and points you at the model provider's API directly. So the interactive muscle is not "Sampling plus Elicitation" any more. It is the server-initiated request flow, with Elicitation riding on top. Same capability, much cleaner plumbing.

Stateless servers, the part the gateway crowd should read twice

This is the section to read twice if you put anything in front of MCP: a mesh, an ingress, a gateway.

Streamable HTTP is what made remote MCP servers practical, and it is what most remote servers run on today. But at scale it keeps running into the same wall, and it is the session that puts it there. Stateful sessions fight with load balancers, horizontal scaling needs workarounds, and there is no standard way for a registry or a crawler to find out what a server does without opening a live connection to it.

The first one is the real headache. A session you cannot move onto another replica has to be pinned, and sticky routing is exactly what you stood up a gateway to avoid. You end up pinning affinity, spreading state across replicas, or adding routing workarounds that undo half the reason the gateway is there in the first place.

The fix in the release candidate is blunt: MCP is now stateless at the protocol layer. The initialize handshake (SEP-2575) and the Mcp-Session-Id header (SEP-2567) are gone. Routing moves into explicit headers, so a gateway can pick a backend off the request line without ever reading the body:

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json

The server rejects the request if those headers and the JSON body disagree, so the routing key cannot lie about what is inside. A server that used to need sticky sessions can now run behind a plain round-robin load balancer. If an application genuinely needs state, it mints an explicit handle, a basket_id or a browser_id, and passes it back. That is a cleaner contract than an implicit session, because the state is now something you named and can reason about, not something the transport is quietly hiding from you.

The maintainers are also clear they are not adding new transports this cycle. They are evolving Streamable HTTP and deliberately keeping the transport set small to protect compatibility.

Server Cards: read a server before you connect

Right now the only way to find out what an MCP server can do is to connect to it and run the initialize handshake. The roadmap's answer is MCP Server Cards: a server publishes a structured, machine-readable description of its capabilities, the tools and resources it exposes, at a .well-known URL, so a client, a registry or a crawler can see what it offers before ever opening a connection. That makes MCP servers discoverable and indexable the way a website is.

And look closely at what Server Cards actually are: capability advertisement with no connection required. A2A already does its discovery through Agent Cards. MCP getting Server Cards is the tool side echoing the very same idea, right down to the name. One more edge where the two quietly move together.

So is MCP becoming A2A?

Short answer, no. But the honest answer has a bit more shape to it, so here it is.

Where the gap really is closing: async delegation (Tasks), bidirectional and human-in-the-loop interaction (server-initiated requests, Elicitation), and discovery (Server Cards). And the most forward-looking idea here, and to be clear this one is my extrapolation rather than something the roadmap promises, is an MCP server behaving like an agent in its own right, negotiating with another MCP server instead of just handing data back. Think of a travel-planning server talking to a booking server. If that ever ships, the line between the two protocols becomes genuinely hard to draw for simple delegation.

Where MCP is deliberately staying out: A2A's core. Peer-to-peer, cross-vendor agent transport. The Agent Card trust handshake. Multi-tenant agent-to-agent messaging. A2A reached v1.0 and was donated to the Linux Foundation, and it is clearly a protocol doubling down on cross-vendor agent trust, not one quietly being absorbed. MCP keeping its transport scope small on purpose is the giveaway. The maintainers are not trying to build the agent mesh. They are building the layer that plugs into one.

The simple mental model still holds up. MCP grounds an agent in tools and data. A2A coordinates agents as peers. What actually changed in 2026 is that MCP grew enough async and server-initiated capability to cover delegation patterns you would previously have reached for A2A, or a message queue, to handle. The two layers did not merge. The seam between them just moved.

If you operate this infrastructure

So what do you actually do about all of this? Two things.

1. Treat enterprise features as extensions, not core. Audit trails, SSO-integrated auth, gateway behaviour, config portability: these are all landing as extensions to keep the base protocol lean, and Tasks itself becoming an extension is that exact pattern in action. SEP-1932 (DPoP) and SEP-1933 (Workload Identity Federation) are already in review, and WIF is the one I would keep an eye on if you run SPIFFE or mesh-based workload identity, which is precisely what Solo Enterprise for Istio gives every workload. It pairs naturally with token exchange at the gateway.
2. Track the Agents Working Group on Tasks. Retry and expiry semantics are going to shape how you build durable agent workflows. Build against the primitive by all means, just do not hard-code assumptions the lifecycle rules have not settled yet.

The real story here is MCP shifting from "prove a common integration standard is even needed" to "make it solid enough to run at production scale". That is a far less dramatic headline than "MCP versus A2A, only one survives", and a far more useful one.

If you want to see any of this applied to live MCP traffic, the labs are right here: enterprise MCP controls at the gateway, elicitation for upstream OAuth, gateway-enforced human approval for tool calls, and A2A delegation in kagent.

When to reach for MCP, when for A2A

The split people try first is "tool versus agent", and it breaks at the edges: a capable MCP server starts to look like an agent, and a trivial A2A peer looks like a tool. What actually settles it is what sits on the other end. If it is a capability surface, a fixed contract of tools, data and prompts that your agent consumes, that is MCP, whether you built the server or you are calling GitHub's or Vercel's. If it is another autonomous agent you hand work to and collaborate with as a peer, that is A2A.

Notice that ownership is not the deciding factor. MCP crosses trust boundaries all the time, calling a vendor's MCP server is completely normal, and securing that boundary is an auth and scoping job at the gateway, not a reason to switch protocols. You move to A2A when the thing on the other end reasons for itself, which is also why A2A carries the Agent Card and the signed handshake: peer agents are usually both autonomous and cross-vendor, so the trust has to be established explicitly.

• MCP when the other end exposes capabilities: tool calls, data access, backend logic, structured context for a single agent. Yours or a vendor's, it does not matter. Most systems need mostly this, so it is the right default to start from.
• A2A when you delegate to an independent agent that has to discover others and collaborate without sharing its internals.
• Both, where most enterprise designs land: A2A negotiates who does what across the boundary, and each agent then uses MCP internally to reach its own tools and data once it has been handed the work.

Tasks blur the line, so be precise about it. Now that MCP can hold a long-running task, async versus sync is no longer the deciding question. A long-running call to a tool or service is still MCP, however long it runs; handing the work to an agent that decides for itself how to carry it out is A2A. Do not reach for A2A because a job takes forty minutes, reach for it because the other end is an agent, not a tool. Two failure modes are worth naming. The common one is an MCP server that "coordinates agents", which is orchestration that should run over A2A. The quieter reverse is A2A between your own services, where the other end is really just a tool and MCP with a job queue would have done the same work without paying the discovery and handshake cost.

From a gateway seat the two enforce differently, which is the part most comparisons skip. MCP enforcement is tool-scoping and the per-call authorisation contract. A2A enforcement is validating the signed Agent Card and the peer's identity at the trust boundary. Same gateway, two policy shapes, and conflating them is how you end up either over-trusting peers or under-scoping tools.

Sources and further reading

1. MCP 2026 roadmap, modelcontextprotocol.io/development/roadmap (updated 5 March 2026). The four priority areas, Working Groups, MCP Server Cards, and the gateway and proxy problem statement; DPoP (SEP-1932) and Workload Identity Federation (SEP-1933).
2. The 2026-07-28 MCP Specification Release Candidate, blog.modelcontextprotocol.io (David Soria Parra and Den Delimarsky, 21 May 2026). The stateless core (SEP-2575, SEP-2567, SEP-2243, SEP-2549), server-initiated requests (SEP-2260), Multi Round-Trip Requests (SEP-2322), the Tasks extension (SEP-2663), and the deprecation of Sampling (SEP-2577).
3. Tasks primitive, SEP-1686. Working and Interest Group model, SEP-1302; succession and amendment, SEP-2085.
4. A2A Protocol v1.0, a2a-protocol.org and the a2aproject/A2A repository. Originally developed by Google, donated to the Linux Foundation.
5. Agentic AI Foundation, aaif.io, where agentgateway joined as the fourth hosted project in June 2026.