May 2026 briefing: MCP goes stateless, OpenTelemetry graduates, and the EU agrees to move the AI Act deadlines

The month in one paragraph

MCP published the release candidate for its 2026-07-28 specification, the largest revision since launch, with a stateless core, first-class extensions and tighter authorisation¹. OpenTelemetry became a CNCF graduated project² and published a practical guide to GenAI observability³. In Brussels, the Parliament and Council reached a provisional agreement on the Digital Omnibus on AI⁵. Kubernetes spent the month publishing v1.36 deep dives on accelerators and AI scheduling⁷⁸.

MCP: the session is gone

The release candidate removes the initialize handshake and the Mcp-Session-Id header¹. Protocol version, client information and capabilities now travel with every request, and a new server/discover method returns server capabilities on demand. The post spells out the practical effect: a remote server that used to need sticky sessions, a shared session store and deep packet inspection at the gateway can now sit behind a plain round-robin load balancer, route on an Mcp-Method header, and let clients cache tools/list.

Applications can still be stateful. The recommended pattern is an explicit handle: a tool returns an identifier such as a basket_id, and the model passes it back as an ordinary argument on later calls.

Two other changes matter for enterprise use. Extensions became first-class, with MCP Apps (server-rendered interfaces in a sandboxed iframe) and Tasks moving out of the core into an extension, which means anyone who built on the experimental Tasks API has a migration ahead. And six proposals hardened authorisation, including mandatory validation of the iss parameter per RFC 9207 to counter mix-up attacks¹. The final specification was scheduled for 28 July, with a ten-week window for SDKs to validate. I covered the security side in my MCP security checklist.

Observability: OpenTelemetry graduates, and LLM calls get standard telemetry

The CNCF announced OpenTelemetry's graduation on 21 May². For architecture decisions, graduation is mostly about risk: it is now very hard to argue against OpenTelemetry as the default instrumentation standard.

The GenAI observability post is the one I would hand to any team running agents³. The semantic conventions standardise how a model call is recorded: the model, input and output token counts and, only when you opt in, the content of prompts, completions and tool calls. The default of not capturing content is the right one, because prompts often contain personal data. The post also notes that common coding assistants already emit OpenTelemetry data.

The project also launched Blueprints and Reference Implementations, an opinionated guide to deploying OpenTelemetry for common situations, prompted by users asking why adoption feels so complex⁴. I welcome it. Most of the complexity teams hit is accidental, not essential. A blueprint that says "do it this way" saves weeks of debate in a platform team.

Regulation: a provisional deal on the AI Act timetable

On 7 May the Parliament and Council reached a provisional agreement on the Digital Omnibus on AI. As reported, it sets 2 December 2027 for stand-alone high-risk systems and 2 August 2028 for systems used as safety components of regulated products, adds a new prohibition on AI that generates child sexual abuse material or non-consensual intimate imagery, and still required formal adoption before the original 2 August 2026 date⁵⁶. In May this was a deal, not law. I explain what happened once it was adopted in the EU AI Act after the Digital Omnibus.

Kubernetes: getting serious about AI workloads

The v1.36 deep dives were dominated by AI infrastructure. Dynamic Resource Allocation gained more drivers and features, extending to native resources such as CPU and memory and supporting ResourceClaims in PodGroups⁷. Workload-aware scheduling, which handles gang scheduling for AI and batch jobs, took an architectural step by separating its API concerns⁸. Declarative validation reached GA, replacing a large body of handwritten validation code with markers in the type definitions⁹.

What I'd do with this

1. Design new MCP servers stateless from day one. Use explicit handles for application state and keep sessions out of the transport.
2. Put an AI gateway in front of agent traffic and route on the new MCP headers, so authentication, rate limits and logging live in one place.
3. Instrument every LLM call with the GenAI conventions, metadata only by default, so you can report cost and latency per feature.
4. Treat the AI Act dates as provisional until adoption, but keep building logging and evaluation regardless.
5. If you schedule GPU work on Kubernetes, review DRA and gang scheduling before buying more accelerators. Better sharing is often cheaper than more hardware.

How I can help

I design agent platforms that are observable, secure and cheap to run, from MCP server design to GPU scheduling. See my AI architecture work, or, for investors, how I assess agent companies in technical due diligence. You can also analyse your challenge and bring the result to a call.