Two days at RAI Amsterdam (17–18 September), nearly a hundred sessions, and energy throughout the hallways. AGNT Con + MCPCon Europe is the Agentic AI Foundation's flagship event under the Linux Foundation, and this year it consolidated the European MCP content that previously lived at MCP Dev Summit Europe.
If you care about MCP, this was the place to be. The sessions spanned diverse concerns: stateless infrastructure for engineers, enterprise governance for CTOs, and compliance frameworks for security teams. My colleague Jeremy Frenay, Field CTO at Lenses.io, presented his research on MCP's new Tasks extension.
Here's what stuck with me.
TL;DR
- MCP is now stateless at the protocol layer, so you can scale it like any other HTTP service.
- Once MCP and skills reach the whole company, a gateway stops being optional.
- OpenTelemetry traces are the fastest feedback loop for improving an agent.
- MCP Tasks make long-running work first-class, but durable storage is your job. An event log is a natural fit.
1. Stateless MCP changes the game
David Soria Parra, co-creator of MCP at Anthropic, opened with his keynote "MCP and the Era of Connectivity", and the new specification threaded through the whole event.
The 2026-07-28 spec is the largest revision of the protocol since launch. The initialize/initialized handshake and the Mcp-Session-Id header are gone. Every request now carries its own protocol version, client identity, and capabilities – and clients can call server/discover if they want capabilities up front. New Mcp-Method and Mcp-Name headers expose the operation on HTTP, so load balancers and gateways can route without parsing the body.
This means no more sticky sessions or shared session stores. Any server instance can answer any request, which unlocks horizontal scaling: you add instances instead of hitting a wall. Without session affinity tying requests to a single server, deployments become truly serverless, multi-instance, and edge-ready. MCP now behaves like the rest of the web, which is exactly what makes it a serious foundation for enterprise AI.
The catch is that the state doesn't disappear. It moves out of the protocol and into your application, where you reference it explicitly with IDs or handles. Keep that in mind for takeaway 4.
2. Gateways are not optional in the enterprise
MCP on a handful of developer laptops is one thing. Rolling out MCP servers and skills to hundreds of developers and thousands of non-technical users tells a different story – one was explored by Anushka Bhandari in "From MCP Playground to Org-Wide Infrastructure: Lessons From Building Booking.com's Agent Foundry".
At that scale you need a single control point that answers a few critical questions for every call: which servers and skills are approved, who is allowed to use them, what data can flow through, and what really happened.
That means a central catalog, OAuth-based authentication with fine-grained permissions, audit logs, request filtering, and rate limits.
The market has caught up. Mature MCP gateway products were on the expo floor and in workshops (Solo.io ran a hands-on session on the agent gateway pattern). The stateless spec helps here too: routing headers make policy enforcement at the gateway much simpler. The AAIF is even incubating an open source agentic gateway project
3. O11y accelerates the agent feedback loop
Agents fail in ways you can't fully predict with unit tests or evaluations. The same prompt takes a different path through tools on Tuesday than it did on Monday. The only reliable way to improve an agent is to learn from what it did.
Marcelo Trylesinski from Pydantic (also a maintainer of Starlette and Uvicorn) explored this in "Self-Healing Agents Need Observability". OpenTelemetry is the de facto standard for collecting that telemetry. With enough traces, your prompts, tool calls and their results are all linked together, giving you the context you need to fix your agent based on real-world outcomes instead of guesses.
The theme echoed across the conference. Cisco shared approaches to tracing multi-agent workflows with OpenTelemetry, and Microsoft showed the path from "works on my prompt" to production SLOs – both reinforcing that observability is the feedback loop agents need to improve.
4. MCP Tasks need somewhere durable to live
The new MCP spec also ships the Tasks extension, which answers a long-standing question: what do you do with work that takes minutes or hours, waits for a human, or has to survive a client disconnecting?
The problem is clear: a travel agent workflow books two flights because it doesn't know a ticket is already on hold. A shopping workflow you prompt before work can't resume at lunch, so you start over. These aren't edge cases, they're the failures that break multi-step, multi-agent workflows in production.
Instead of blocking, a server returns a task handle straight away. The client then polls with tasks/get, sends input with tasks/update if the task needs it, and can cancel with tasks/cancel. That makes workflows durable.
But the spec deliberately leaves storage to implementers, and that's where things go wrong. You delegate an action to an agent and it loses track of the context.
Jeremy Frenay's talk, "Call Now, Fetch Later: Durable MCP Tasks on an Event Log," covered exactly this issue. His argument: a Task is a state machine, and a state machine's history is just an ordered log of its transitions. Store creation, status updates, and completion as events in an append-only log, and recovery becomes replay. The "ticket on hold" is an event, so a restarted worker sees it and doesn't book again. The MCP server itself stays stateless, in line with the new spec.
He also walked through the failure modes likely to trip you up in production: orphaned tasks, duplicate side effects, at-least-once versus exactly-once delivery. The same log lets several clients subscribe to one task's result. The reference architecture works on any log or queue – Apache Kafka is one obvious candidate, especially if your company already has Kafka infrastructure. The backend for durable agent workflows is probably already in the building.
5. What's next: XAA to enable governed MCP in the enterprise
One session stood out for its direct relevance to enterprise security: "ID-JAG: Solving OAuth Sprawl for Enterprise AI Agents" with Aaron Parecki (Okta, editor of the IETF OAuth working group), Joey Orlando (Archestra.AI), and Paul Carleton (Anthropic).
The problem: OAuth sprawl
Today, connecting an agent to an MCP server usually means one of two things. Either every user clicks "Allow" on a consent screen for every server, or someone hands the agent a long-lived access key. Multiply that by a thousand employees and a dozen MCP servers and you get consent sprawl, credentials scattered across tools, and no central place for IT to see what is connected to what. Offboarding someone turns into a service by service key hunt.
The fix: Cross App Access (XAA)
XAA is Okta's name for the Identity Assertion JWT Authorization Grant (ID-JAG), an IETF draft. Instead of inventing a new protocol, it chains two existing OAuth flows:
- The agent's client exchanges the user's ID token at the enterprise identity provider for an ID-JAG, a short-lived grant bound to one specific resource. Before issuing it, the IdP checks policy: this is where IT decides which app may talk to which.
- The resource's own authorization server trades that ID-JAG for its own access token. The API keeps its token format and revocation model, and only ever trusts its own issuer.
The result is single sign-on, no consent screens, and every agent connection governed, audited and revocable from the IdP your company already uses for SSO. As Aaron put it, approving these connections should be decided "by the IT admin, not the employee."
This is no longer theoretical. MCP shipped enterprise-managed authorization built on ID-JAG in June, Okta has Cross App Access in early access, and gateways such as agentgateway already support it. This is the other half of takeaway 2: gateways and XAA together are how MCP becomes something a CISO can sign off on.
One nuance: ID-JAG decides whether an agent can connect to a resource on behalf of a user. It does not decide what the agent can do once connected. Fine-grained permissions still live in the resource itself.
How Lenses addresses this
Kafka carries some of the most sensitive, business-critical data a company has. Our enterprise customers already sign into Lenses through their identity provider. With XAA, that same IdP can decide which agents may reach the Lenses MCP server, for which users, and manage that access centrally. Lenses then keeps doing what it already does: enforcing RBAC and data policies on which topics, schemas and actions the agent is actually allowed to touch. IdP-level governance for the connection, Lenses-level governance for the data.
To play this video, accept functional cookies in your privacy settings.
YouTube video
The bigger picture
Across two days the message was consistent: agents are moving from demos to production, and production needs the unglamorous parts. Stateless scaling, governance, telemetry and durable state are what separate a cool prototype from something you can roll out to a whole company.
Recordings are being published on the Agentic AI Foundation's YouTube channel, and the next edition is AGNT Con + MCPCon North America in San Jose on 22–23 October .
Further reading
- The 2026-07-28 MCP specification release candidate
- MCP Tasks extension
- Lenses: agentic engineering for data streaming
- Aaron's post Cross-Domain API Access: Beyond the "Obvious" Shortcuts explains the design in a few minutes, and the spec itself is the IETF ID-JAG draft.
To play this video, accept functional cookies in your privacy settings.
YouTube video
