MCP's maintainers published a new roadmap naming agent identity as a priority — and confirmed that sessions and the initialization handshake are gone from the shipped spec (Model Context Protocol, 22 Aug 2026)

Why it matters (spine). RDKG's wager is that verified ground truth becomes the scarce input as intelligence collapses toward free, and that machines will be the customer. That wager has an engineering dependency the garden has been tracking since mcp-standardization: the protocol by which a machine asks for the truth, and the identity and payment layer that decides whether it may. This document, written by the protocol's own lead maintainers, moves both of those from adjacent to central — and it is the first first-party MCP governance document in the cabinet that names agent identity as a priority area in its own right.

What the document is. "The New MCP Roadmap", published 22 August 2026, by David Soria Parra (Lead Maintainer) and Den Delimarsky (Lead Maintainer) on the protocol's own blog. It opens: "Today we're excited to publish an updated roadmap for the Model Context Protocol (MCP), covering the next specification release and beyond." It explicitly supersedes the previous roadmap, which it says "came out in March with four priority areas: transport evolution and scalability, agent communication, governance maturation, and enterprise readiness."

What it confirms about the shipped release — which closes a loop the garden left open. The 31 July log parked the 2026-07-28 specification revision on a misreading, and the 21 August log corrected that: the revision is tagged, published and stable. This roadmap is independent first-party confirmation from a second document, and it is more specific than a release tag. "The bulk of the changes landed in the 2026-07-28 specification release - you might've already seen them in our SDKs and documentation. The improvements ranged from minor modifications to major protocol overhauls." Named changes:

• "One of the biggest changes we shipped is that protocol-level sessions and the initialization handshake are gone, so a server can scale horizontally without holding state (SEP-2575, SEP-2567)."
• "Additionally, clients can now call server/discover to learn a server's supported versions and capabilities before doing anything else. List results are also cacheable (SEP-2549)."
• "Tasks were reworked based on early adopter feedback - we moved them into an official extension (SEP-2663). The brand-new Multi Round-Trip Requests pattern (SEP-2322) replaced server-initiated requests so that elicitation and similar flows work on stateless servers."
• Governance: "We formally adopted a Contributor Ladder, Working Groups now triage SEPs in their own area, and the specification has a proper feature lifecycle and deprecation policy that the 2026-07-28 deprecations were the first to follow."
• Authorization: "issuer validation, issuer-bound client credentials, and Client ID Metadata Documents (CIMD) as the preferred registration path for clients, with Enterprise-Managed Authorization available as an extension (which is also now stable)."

The five new priority areas, in the maintainers' own framing.

1. Agentic messaging primitives. "Modern agentic workloads no longer fit the standard request-and-response pattern." Work spans server-initiated events ("webhooks and channels, so clients aren't left polling for results"), a composition review across the Agents, Transports and Triggers & Events Working Groups, and maturing the Tasks extension so it can move into the specification.
2. HTTP-native transport unification and hardening. "With the 2026-07-28 release, a remote MCP server is now no different from any other HTTP workload, making it easy to host and operate one on any infrastructure that developers and organizations already use for their APIs and services." The stretch goal is to cover other deployment modes "including local servers speaking Streamable HTTP over stdio."
3. Agent identity and enterprise-ready security. The problem statement is the load-bearing one: "MCP authorization today is built around a person approving access in a browser. That works well for interactive clients, but more and more of the callers are agents running as cloud workloads with their own identity, acting on behalf of a user who isn't present, or delegating narrower authority to sub-agents. We want MCP servers to have a standardized way to recognize and trust those agent identities, built on existing standards rather than pasted API keys and long-lived tokens." The named work: finalising Demonstrating Proof of Possession (DPoP, RFC 9449) and driving adoption, and "defining an opinionated path for agent identity and delegation through Workload Identity Federation, the ID-JAG grant behind Enterprise-Managed Authorization, and standard token exchange", with continued engagement with the "IETF OAuth and WIMSE working groups."
4. Improved primitives. Two concrete gaps. Result-shape ambiguity: "A tools/call response can carry the same output in more than one form, and a server developer today has no way to know which form a given client will put in front of the model." And catalogue scale: "Connecting to a server with a hundred tools means the model pays for that entire surface before the user has asked a single question, and tool selection tends to get worse as the list grows. We're starting a progressive discovery effort so a server can offer a small entry point and reveal more of its catalog as the conversation narrows."
5. Improved SDK developer experience. "This is even more important now that many developers build MCP clients and servers by pointing an agent at our libraries, where clear APIs and accurate docs decide whether the code will work with minimal friction."

Also named and directly relevant to RDKG: "The Server Card Working Group continues to work through the .well-known metadata conventions for MCP servers, so a server can be discovered and reasoned over without connecting to it."

Why this is verified with low confidence in delivery. Tier measures provenance, not whether the claim will hold (L52). The provenance is a first-party governance document on the protocol's own domain, dated inside the window, read from the main thread, with a falsifier below — so the claim this card actually makes, "MCP's maintainers published these five priority areas on 22 August 2026 and described these shipped changes", is verified. Confidence that the roadmap ships is low and belongs here in prose. The document contains no dates and no version numbers for any of the five areas — deliberately, since the March roadmap had already replaced release milestones with priority areas on the argument that "a release-oriented roadmap implies a level of predictability that open-standards work rarely has." One of the five, agent identity, does not yet have a settled mechanism; the enterprise area's predecessor was described in March as "the least defined of the four."

Where this sits against the cabinet, including where it complicates it. mcp-standardization carries a falsifier with three limbs, pasted here whole rather than truncated (L64): "The final 2026-07-28 spec slips or fragments — major vendors ship incompatible forks, or Tier-1 SDKs miss the ten-week validation window — leaving no single interoperability standard for agents to converge on." Taking the limbs one at a time:

• Limb 1, "slips": closed, and this document is the second independent first-party confirmation. It states that "the bulk of the changes landed in the 2026-07-28 specification release" and enumerates them. The spec did not slip.
• Limb 2, "major vendors ship incompatible forks": open but favourable, and weakly so. This document names no incompatible fork and describes a maintainer group running a functioning SEP, Working Group and deprecation process. That is evidence against fragmentation from an interested party, not a survey of vendors.
• Limb 3, "Tier-1 SDKs miss the ten-week validation window": not closed. The strongest thing this document says about SDKs is the hedge "you might've already seen them in our SDKs and documentation" — not a conformance statement, and it attaches no window. A claim that all four Tier-1 SDKs speak 2026-07-28 circulated during this sweep from a search-engine summary of pages nobody here opened; it is not restated on this card. The right primary to close this limb is the SDK conformance-tier page the roadmap links, which was not opened.

The consequence clause is the part most easily lost in a truncated quote, and it is the part that matters: the falsifier is not "forks appear" but "no single interoperability standard results." On that whole question this document is encouraging and not dispositive.

Garden-code note (L41, flagged not resolved). This card's content is machine-layer, which content/beats/frontier-standing-sweep.md would tag TKG in its own words ("AI & the machine layer (TKG / the moat thesis itself)"), while the Frontier Map reads TKG as Toxicology — and this same run's chestnut card carries toxicology-adjacent content. L41's rule-until-resolved says machine-layer cards in this beat use TKG + RDKG. This card departs from that rule and the departure is stated rather than hidden: tagging both senses of TKG inside one run is the guess L41 forbids, so TKG is left out of gardens and the domains tag machine-layer carries the link — the same abstention ebay-depop-acquisition-closed introduced on 30 July and the corn, Epic, eBay and Etsy cards have followed since. The founder's call is unchanged: give the machine layer its own code and remap, or restate the beat file so TKG means one thing everywhere.

Two cross-links that complicate rather than flatter. First, unreal-mcp-in-uefn-agentic-authoring is dated 20 August 2026 — Epic embedded an MCP server in a consumer creation tool two days before its maintainers published a roadmap saying transport, identity and result-shape contracts are all still being reworked. Adoption is running ahead of the protocol's own settled surface, which is good for reach and bad for anyone who builds against today's shape and expects it to hold. Second, the cabinet's four agent-commerce rails cards — x402-linux-foundation, x402-foundation-operational-launch, ap2-agent-payments-rails, visa-stablecoin-platform-open-usd — describe how a machine pays. This roadmap describes the gap on the other side of that transaction: as of today MCP authorization "is built around a person approving access in a browser." Rails without agent identity is a payment system that cannot name its customer. Whether the identity work lands is therefore a dependency of the whole agent-commerce thesis, not a detail of it.

Money angle and metacrisis lever. Money angle: two of the five priority areas are, in effect, the pricing and metering layer for machine-readable knowledge. .well-known server cards make a verified feed discoverable without a connection, which is the difference between being crawled and being found; progressive discovery and result-shape contracts decide whether a hundred-signal catalogue is affordable for a model to look at. Agent identity decides who can be billed. Metacrisis lever: indirect and worth naming as indirect — an open standard for agent identity built on IETF work is the difference between a machine layer governed in public and one governed by whichever vendor's API key everyone pasted.

What would prove it wrong (falsifier). Three limbs, testable separately.

• The document fails if this post is retracted or materially rewritten, or if the linked roadmap document at modelcontextprotocol.io/development/roadmap does not contain these five areas. (That roadmap document was not opened for this card.)
• The shipped-changes claims fail if the 2026-07-28 specification does not in fact remove protocol-level sessions and the initialization handshake, or does not contain server/discover — testable against the specification text and the named SEPs (2575, 2567, 2549, 2663, 2322), none of which were opened here.
• The roadmap as a prediction fails if the next specification release lands without agent identity or the transport unification work — the specific tell being DPoP and Workload Identity Federation staying in proposal state. Note the shape of the precedent: the March roadmap listed agent identity as merely "on the horizon", and five months later it is a priority. Promotion from horizon to priority is not delivery, and this card should not be cited as though agent identity exists.

Provenance (what I actually read). The post at blog.modelcontextprotocol.io/posts/mcp-roadmap/, fetched from the main thread on 28 August 2026. The date is on the face of the page — the visible byline "August 22, 2026 · 6 min · David Soria Parra (Lead Maintainer), Den Delimarsky (Lead Maintainer)" — corroborated by page metadata article:published_time: 2026-08-22T09:00:00+00:00 (modified 2026-08-23). Every quotation of the roadmap post above is from that page. I separately fetched and read the March roadmap at blog.modelcontextprotocol.io/posts/2026-mcp-roadmap/ to confirm the supersession claim independently: it is titled "The 2026 MCP Roadmap", bylined "March 9, 2026 · 6 min · David Soria Parra (Lead Maintainer)", and carries the four priority areas the new post attributes to it, the "On the Horizon" section, the "least defined of the four" line, and the "a release-oriented roadmap implies a level of predictability that open-standards work rarely has" line — the last two both quoted above and both from the March post, not the August one. A note for anyone re-running this: those two URLs differ by four characters and a search-engine summary attributed the 22 August date to the wrong one, so both were opened. Two files inside this repository were also opened and quoted directly, and neither is a web source: content/signals/mcp-standardization.md, from which the three-limb falsifier above is pasted verbatim, and content/beats/frontier-standing-sweep.md, from which the "AI & the machine layer (TKG / the moat thesis itself)" wording in the garden-code note is quoted. I did not open the roadmap document itself, the specification, any SEP, the SDK conformance-tier page, the Server Card Working Group page, or RFC 9449; the SEP numbers, working-group names and standards references above are quoted as the post gives them.