Betting on a moving standard
Five sessions in, you can spot MCP work, keep it safe, and make the business case. The last skill is temporal: MCP is not finished, and it never will be - it ships a dated revision roughly twice a year through an open process. A leader who treats that as instability will under-invest and get lapped. A leader who treats it as a published roadmap - because that is what it is - can fund the parts that are settling, wait on the parts that are not, and never be surprised. That literacy is what you walk out with tonight.
How MCP evolves 15 min live
MCP versions are dates, not marketing numbers - 2025-11-25, not "MCP 4.0." That is a tell about how it is run: changes flow through a public SEP process (the same shape as Python's PEPs), proposed in the open, debated, and merged into a dated revision about twice a year. Since December 2025 the whole thing sits under the Agentic AI Foundation at the Linux Foundation, with OpenAI and Block as co-founders - so no single vendor can steer it toward their own lock-in. For you, that combination - dated cadence plus neutral governance - means the roadmap is legible in advance. You are not waiting for a vendor's surprise announcement; you are reading a public changelog.
LiveReading a spec changelog as an executive5 min▶
You do not need to read the spec. You need to read its Key Changes page the way you read an analyst note - looking for three things, ignoring the rest.
- What got deprecated? Deprecations are the only entries with a deadline. Each one is a migration your teams will have to budget for before its removal window closes - find these first.
- What got easier or cheaper? Look for anything that reduces what a server has to track or a team has to operate. Those are the tailwinds you can lean into now.
- What is newly possible? New capabilities open new product surfaces - but only once the hosts you use actually support them. Note these as watch items, not build orders.
Everything else in a changelog - internal routing, schema versions, error codes - is your engineers' concern, not yours. Three questions, five minutes, twice a year. That is the entire executive discipline for a moving standard.
Self-studyWhy "dates, not versions" is a governance signal3 min read▶
A vendor who owns a standard ships "3.0" and asks you to upgrade. A neutral community ships a dated revision and lets you decide when it matters to you. The date scheme is deliberate: it removes the marketing pressure of a big version number and signals that no revision is a rewrite - just the standard as of that day. Combined with the Linux Foundation's neutral stewardship and the co-founding of OpenAI and Block, this is the property that lets you bet real budget on MCP: the thing you are standardizing on cannot be yanked out from under you by one company's roadmap.
The 2026-07-28 revision, decoded 12 min live
Here is the next revision in the only language a leader needs - implications, not protocol detail. Four themes matter. The core goes stateless, which is a cost story. MCP Apps arrive, which is a product-surface story. Tasks and Extensions formalize, which is a maturity story. And several capabilities are deprecated, which is a budget story. Take them one card at a time.
LiveStateless core - the cost story3 min▶
Today, a remote server has to remember each conversation - it holds a session while you talk to it. The revision removes that: the opening handshake and the session identifier disappear, and everything a request needs travels with the request. In plain terms, servers become like a well-designed website that does not care which server answers you - which means they are cheaper and simpler to scale. For you: the operating cost of the "expose" and remote-server postures from a5 goes down, and reliability at scale gets easier for your platform team to promise.
LiveMCP Apps - the new product surface3 min▶
Until now, a server returned data and the AI app decided how to show it. MCP Apps let a server ship its own user interface - a small, sandboxed panel that renders inside the host. Think a booking calendar, a chart, an approval button, delivered by the server itself. This is a genuinely new surface: your product could present interactive UI directly inside someone else's AI assistant. It is also the least mature item here - exciting, first-class in the spec, and not something to bet production on until the hosts your customers use actually render it.
LiveTasks and Extensions - the maturity story3 min▶
Two signs the standard is growing up. Tasks - the way a server handles long-running work that does not finish in one reply - graduates into a proper extension. And an Extensions framework becomes first-class, meaning MCP now has an official way to add capabilities without bloating the core everyone must implement. For you this reads as reassurance: the protocol can grow at the edges while its center stays small and stable. That is exactly the shape you want in something you are standardizing on - a stable core, optional extensions, no forced churn.
Self-studyDeprecations - the migration-budget story3 min read▶
The revision deprecates Roots, Sampling, and Logging - older client-side capabilities - with a twelve-month removal window. If none of your servers use them, this is a non-event. If some do, you have a year to migrate, and the honest move is to put that on a roadmap now rather than discover it at month eleven.
- The action: ask your teams "do any of our servers rely on sampling, roots, or logging?" A no closes the topic. A yes starts a small, unhurried migration plan.
- The principle: deprecations are the one changelog entry with a deadline. Treat every one as a line item, never as a surprise.
What to fund, what to wait on 10 min live
Decode is useless without allocation, so here is the whole roadmap as three lanes. Fund the things that are settled and compounding: your teams' server-building skills, the governance you built in a4, and a presence in the official registry so you are discoverable. Wait on production bets that depend on things not yet real - MCP Apps in particular, until the hosts you rely on support them. Watch the things that will decide next year's plan: host adoption of the new capabilities and each spec revision's Key Changes page. Money into the fund lane, patience in the wait lane, attention in the watch lane.
LiveThe 12-month horizon plan4 min▶
Turn the three lanes into a plan you can hand to a leadership team. One row per lane, one owner each, revisited at the next revision.
| Lane | Move this year | Owner |
|---|---|---|
| Fund | Train a small team to build and maintain servers; adopt the a4 governance; list your first server in the registry. | Eng lead + your sponsorship |
| Wait | Run one contained MCP Apps experiment only if it maps to your product; hold production promises until host support is real. | Product lead |
| Watch | Assign someone to read each Key Changes page and report the three questions; track your Roots/Sampling/Logging exposure. | A named individual, not a committee |
The fund lane is where the durable advantage compounds - skills and governance survive every revision. Wait and watch keep you from over-committing to what is still moving.
Stress-test your plan against the spec ★ 8 min · use your a5 candidate
Take the first-server candidate you circled in a5 and run it forward through the roadmap. The point is to find the assumption that the next revision changes - before it changes for you.
State your plan in one line: "we will build a ___ server, remote, this year." Write it where everyone can see it.
Apply the stateless core: does your plan assume anything about server sessions or per-conversation memory? If yes, note that it gets simpler - and cheaper - under the revision, not harder.
Check deprecation exposure: would this server use roots, sampling, or logging? If yes, add a migration line with a date inside the twelve-month window.
Check MCP Apps temptation: is anyone assuming this server will ship its own UI soon? Move that to the wait lane until host support is confirmed.
Re-state the plan with those three adjustments. If it barely changed, your plan was already roadmap-proof - which is the outcome you want.
Write your MCP position memo ★ 7 min · one page, circulate it
Everything in these six sessions collapses into one page your leadership team can align on. Draft it now while the frameworks are fresh; a memo written tonight beats a strategy deck promised for next quarter.
Our stance: one sentence on how your org treats MCP - "a standard we are adopting deliberately, starting read-only." No hedging.
Our first bet: the a5 candidate and its one-slide case, in two lines. What we build first and why.
Our guardrails: the a4 governance in one line - scope policy, allowlists, human approval on the irreversible ring.
Our fund/wait/watch: the three lanes with their owners, from Part 3.
Our review date: "we revisit this after the next spec revision." Name the date. That single line makes the memo a living document instead of a filed one.
Questions to ask your teams this week ◐ 25 min total
- Revisit after 2026-07-28. The next revision finalizes just days after this course shipped - re-open the official Key Changes page once it lands and confirm the four themes decoded here match the published text, then update your memo's review date.
- Ask your teams: "do any servers we run or plan to run use roots, sampling, or logging?" Turn any yes into a dated migration line inside the twelve-month window.
- Assign one named person - not a committee - to read each future Key Changes page and report back the three executive questions: what got deprecated, what got cheaper, what is newly possible.
- Circulate your one-page position memo to your leadership team and book the review-date meeting now, so the strategy stays alive as the standard moves.
Official sources covered
This session reads the spec's own change record as a strategy document. The full technical delta - what actually changes in the protocol - is builder session b8; the pages below are your canonical reference as the standard evolves.
Three questions before you go 🎯 ◐ 90 seconds
1 · Reading an MCP spec changelog as an executive means looking for...
Deprecations carry deadlines, tailwinds you lean into now, new capabilities you watch until hosts support them. The rest is your engineers' concern. Dates, not versions - so there is no marketing name to find.
2 · The stateless core in the 2026-07-28 revision is, for a leader, primarily a...
Dropping per-conversation session state makes servers scale like a stateless website - lower operating cost for the remote and expose postures. It is invisible to end users and does not touch auth.
3 · MCP Apps belongs in which roadmap lane this year?
MCP Apps is genuinely new and exciting - servers shipping their own UI - but the least mature item on the roadmap. Experiment small; do not promise customers a UI-in-their-AI feature until host support is widespread.