AGNTCon Day 2: Stateless MCP, Agent Identity, Multi-Agent

AGNTCon + MCPCon Europe 2026: Day 2 — The Agentic Stack in Production

Day 2 recap — Stateless MCP goes to production, agent identity takes center stage, and the reality of multi-agent orchestration in the real world.

Day 2 at AGNTCon + MCPCon Europe opened with a clear theme: the agentic stack is no longer a vision — it’s a production reality. Each session built on Day 1’s announcements, diving deeper into the practical challenges of running agentic systems at scale.

In the main auditorium at RAI Amsterdam for the AGNTCon + MCPCon Europe keynotes.

Keynote: Welcome — Angie Jones, VP, Agentic AI Foundation

9:00 AM | Auditorium (Ground Floor)

Day 2 kicked off with Angie Jones returning to the stage for the welcome keynote. If Day 1 was about proving that agentic AI works in production (81% of teams report production deployment), Day 2 was about proving it works reliably — across frameworks, models, and deployment targets.

Angie’s message: the standards wars are over. MCP, A2A, Skills, and AGENTS.md are now the shared vocabulary of the agentic stack. The question is no longer which protocol to use, but how to make them work together.

Keynote: Catch Them Early — Manik Surtani, Agentic AI Foundation

9:07 AM | Auditorium (Ground Floor)

Next up was Manik Surtani, introduced on his title slide as CTO and co-founder, Agentic AI Foundation. The session abstract set out the problem: the foundation wanted to be the neutral referee for the agentic layer, then found it had inherited CNCF’s entry bar, a bar built for a mature industry, while this field is only just over a year old.

Manik Surtani opening “Catch Them Early” on the Day 2 main stage.

His “Why we started” slide asked “Who keeps it open?” It was about goose: the project “found its people”, and then its community asked a question he “couldn’t answer well”. The slide’s diagnosis: “Open code. Permissive licence. But the trademarks and the roadmap still belonged to one company.”

The fix, a few minutes later, was “Sandbox: a second door”: a new first step in a Sandbox → Growth → Impact path. Projects are still judged on the same three axes (adoption, community, foundation commitment), and the bar rises at each step:

• What it takes: a working implementation, plus early interest or a credible thesis, and a named, active maintainer.
• What you get: infrastructure and a neutral flag. No funding, no marketing.
• Reaching Growth: production use by two unaffiliated organisations, commits from two organisations over six months, and a written plan that a Technical Committee (TC) sponsor accepts.

The AAIF’s own post on the Sandbox phase, written by Manik Surtani and published on 1 September 2026, adds the timing. There’s a six-month checkpoint, and a project has twelve months to apply for Growth. After that, the TC discusses archiving it. The post treats archival as part of the design, not as a failure.

The slides around it filled in the rest of the story. A “Where we are now” slide put the foundation’s first year in three numbers: 3 → 6 projects (agentgateway, agentrouter and A2A listed as the new ones), 7 → 8 working groups “and a queue behind them”, and 270+ member companies, “about 4x CNCF’s pace at this age”. His next line was the hook for the talk: “But the most useful thing I learned this year came from the projects we turned away.” Those projects, as one slide put it, were “Technically real. Failing a metric built for a mature industry.”

“Where we are now”: six projects, eight working groups and 270+ member companies.

Two more changes came after Sandbox:

• Working groups are open. “They started closed: member organisations only. That isn’t how open source works, and the demand made the point for us.” Now anyone can participate (“No membership. No paperwork. Turn up and do the work.”), while members propose and chair, because “someone must be accountable for a group’s existence”. In the slide’s words: “The line is drawn at accountability, not access.”
• No new groups until there’s a way to close them. There’s real demand, with agentic memory and context management and physical and embodied AI waiting, but “a foundation that only knows how to start things accumulates zombies”. A working group lifecycle (propose, form, operate, review, wind down) was due to ship that month, retrofitted onto the existing eight groups.

“The line is drawn at accountability, not access.”

He closed with two calls to action. If you maintain something, apply, “even if you’re the only one”, because a single maintainer with sudden traction is the highest-risk position in open source. And if you depend on this layer, show up: “Participation now is cheaper than a fork later.”

Interview: Manik Surtani on why the AAIF exists

I sat down with Manik after the keynotes. He told the origin story in more detail. As head of open source at Block, he saw his team build goose, a coding harness that predates Claude Code, and open source it under the Apache licence. It took off, but some organisations wouldn’t contribute their changes back while one company still owned the trademarks and the roadmap. They looked at the CNCF, the Apache Software Foundation and the Eclipse Foundation, and nothing quite fit. At the same time, Anthropic was looking for a neutral home for MCP for similar reasons. That’s when, as he put it, he and David Soria Parra decided to “just go create one”. OpenAI joined soon after, then Google, Microsoft, AWS and others.

A few other points from the conversation:

• Events. Amsterdam was the foundation’s first event in Europe, after Tokyo and Shanghai. Next was San Jose, and later an event in Nairobi in partnership with the Gates Foundation (see Gates Foundation joins the AAIF).
• Sovereignty. He believes people should “own their own AI destinies” and sees open-weights models as key, because most LLMs are natively trained in only a handful of languages. In his view the European sovereignty debate is still early, with “not many answers yet”.
• Embodied AI. Member companies want robotics and embodied AI working groups. The lifecycle he mentioned in the keynote is the thing holding them back, and those groups come next once it’s live.
• Careers. He drew a line between programming and software engineering. We stopped writing assembly when high-level languages arrived, and now the actual programming can be delegated too. But someone still has to understand what’s being built, how the pieces fit together and the architecture.
• Getting involved. Use the projects, come to events, join or start a local chapter through the ambassador programme, contribute projects, or propose a working group if enough people want to explore a new idea.

My take: this reads like the CNCF Sandbox lesson applied a lot earlier. For platform teams the useful part is the signal. A Sandbox project has a named maintainer and a neutral home, and that’s all it promises. Before you build on it, check its phase and whether it has reached the two-organisation production bar yet.

Keynote: Getting to Stateless MCP — In Production

9:19 AM | Auditorium (Ground Floor)

Shaun Smith from Hugging Face — MCP and Transport Working Group Maintainer — delivered the keynote that many attendees had been waiting for: a deep dive into stateless MCP in production.

This directly follows yesterday’s announcement that MCP is graduating to enterprise infrastructure with a stateless core, new extensions, and stronger authorization. Shaun walked through what the stateless transport actually means in practice:

• No persistent sessions — each MCP request is independent, enabling horizontal scaling without sticky sessions
• Reduced memory footprint — servers don’t need to maintain connection state
• Simplified failover — stateless servers can be load-balanced and scaled independently
• Clear migration path — existing MCP implementations can adopt stateless mode with backward compatibility

The “Deployment Tips” slide from the stateless MCP keynote.

The practical checklist fit on one slide, “Deployment Tips”: migrate to the latest SDK versions, enable list caching, and for stateless deployments ask whether you really need discover or subscribe.

What the slides showed

Shaun told the story of the transport in four steps:

1. “In the beginning”: locally running STDIO servers, MCP clients and servers closely coupled, and a simple remote transport (SSE).
2. “Streamable HTTP”: remote connectivity became practical, with a single URL to connect and authenticate, and simpler distribution through connectors and plugins.
3. “Practical Challenges”: shared state between client and server, connection management, and compatibility with HTTP infrastructure.
4. “Stateless MCP (2026-07-28)”: the new spec version changes both the STDIO and HTTP transports, removes the lifecycle handshakes, adds caching and HTTP-native features, and improves support for elicitations.

“1 tool call. 73 other messages.” Overhead on the Hugging Face MCP server under the old protocol.

The slide that made the case was “1 tool call. 73 other messages.” For Hugging Face’s MCP service in June 2026 (the slide notes it’s “not a literal message sequence”), a single tool call came with 39 listing messages, 7 others, and initialization traffic making up the remaining 27. The diagram for the new version, “2026-07-28 MCP Communications”, showed the client-side Roots and Sampling features crossed out, with Elicitation kept alongside the server’s Tools, Resources and Prompts.

The 2026-07-28 protocol: Roots and Sampling crossed out, Elicitation kept.

He also showed adoption. A “2026-07-28 Protocol Adoption (Tool Calls)” chart put the new version at 50.8% of tool calls over the trailing seven days (9–15 September 2026), with 53.6% on the latest day. A per-client breakdown for the same week ranged from 100% for Hugging Face Chat UI, 99.5% for Anthropic/ClaudeAI and 95.3% for claude-code, through 32.6% and 15.3% for the two OpenAI MCP clients, to 0% for Codex CLI.

Interview: Shaun Smith on elicitations, cadence and evals

Later that morning Shaun gave me more detail on camera. The release removes the session handshakes and makes responses cacheable, which matters most for “big customers” that run horizontally scaled servers. Elicitations (a server asking the human, out of band, a question the model doesn’t see) were the clearest example. Before, the server had to remember which question it had asked which client, so traffic had to be routed back to the same node. Now the client sends back both the question and the answer, so any server node can handle the reply as if it were fresh, without the timeouts and robustness issues of the old design.

Other points from the conversation:

• Release cadence. MCP is moving to twice-yearly releases, with a two-month overlap for preparing the next roadmap. He expects the next jump to be smaller than this one.
• Context engineering. Tool search and programmatic tool calling let you offer more tools without loading everything into context up front, as long as the tools stay discoverable.
• Evals over intuition. He wants benchmarking to be more accessible (he mentioned Terminal-Bench), so teams can measure whether a big AGENTS.md file or a set of skills actually helps with a new model. His rule of thumb: start with less and add guidance only where the model struggles, because interventions that helped six to nine months ago can now get in the way.
• Getting involved. Visit modelcontextprotocol.io, join the Discord, read the GitHub repository, and find the maintainers working in your area.

Keynote: Three Doors to One Tool — MCP vs WebMCP vs CLI

9:29 AM | Auditorium (Ground Floor)

Frédéric Barthelet (CTO & Co-founder, Alpic) and Dominic Farolino (Editor of the WebMCP Specification & Software Engineer, Google) presented the third keynote, comparing three ways for an agent to act on a product or service: MCP, WebMCP and a CLI.

They framed the problem with two halves: agentic discovery (an agent finds your product or service) and agentic action (an agent needs a way to act). To show why it matters, they put up a slide citing Cloudflare’s agentic internet report: “more than 50% of traffic on the Internet is now non-human”, and a 1,700%+ increase in daily AI-agent requests on Cloudflare’s network between June 2025 and May 2026.

Three doors, one tool: MCP, WebMCP and CLI all leading to the same product.

The demo used Alpic’s own product as the “one tool” behind all three doors:

• CLI: an alpic deploy command with a root directory, project name, runtime (node24) and environment file, run non-interactively.
• MCP: Alpic’s own app inside ChatGPT. Asked for performance insights on an “MCPCon” app, it came back with sessions, tool invocations, p95 latency per tool and the error rate.
• The app itself was built live too: a coding agent (Claude Code, in auto mode) was told to build an MCP app for browsing the AGNTCon and MCPCon agenda on Alpic’s Skybridge template, then typecheck it, run the tests and read the deploy guide.
• WebMCP: a page’s existing <form> and <button> elements become WebMCP tools that an in-browser agent can call (see Chrome’s WebMCP documentation).

The trade-offs slide: only the shell composes, only MCP has a standard auth story.

The comparison slide summed it up:

The two “Distribution” and “Composability” slides made the same point visually. WebMCP is distributed through the web itself (search engines, DNS), CLIs through package registries such as npm, and MCP servers through directories such as ChatGPT’s, Claude’s and Cursor’s. Shell tools compose by piping into each other, while WebMCP tools and MCP servers each sit behind their own agent. They closed with checklists for each door. For MCP: design around features rather than API endpoints, use polymorphic tools and explicit errors, and avoid meaningless property values. For WebMCP: JavaScript and form registration, security annotations, support for chat widgets and JavaScript framework integration.

The takeaway was that these doors are complementary, not competitors. Each one fits a different context, and a product that wants to be usable by agents may need more than one.

Frédéric also discussed the announcement from yesterday’s Alpic AI news: AI assistants are becoming a new business channel, with MCP running in production at consumer brands like PGA of America and AirHelp. The “three doors” framework helps teams choose the right connectivity model for each use case.

Keynote: State of the Software Factory — Dex Horthy

9:41 AM | Auditorium (Ground Floor)

The last keynote of the morning came from Dex Horthy (@dexhorthy on his slides), with the footer “state of the software factory”. The official schedule puts it on Day 2 at 9:41. This section covers what the slides showed.

The first slides I photographed set up two warning signs:

• Loop engineering. A slide pairing two posts, one from Addy Osmani and one from Peter Steinberger, made the same point: stop prompting coding agents yourself and design the loops that prompt them.
• The cost of speed. Faros AI’s AI Engineering Report 2026, “The Acceleration Whiplash”, was summarised on the slide as: “Engineering throughput is up. However, bugs, incidents, and rework are rising faster.” The slide said it drew on two years of data from 22,000 developers.

Two diagrams followed:

• “A Software Factory Circa 2022”: users send complaints and feature requests to the CEO, product managers and engineers. That becomes “stuff to do” in Linear, Jira or another issue tracker. Then “someone builds the thing” with automated and manual testing, opens a pull request, passes CI/CD checks (unit tests, static scanning, security checks), a human tests and reviews the change, and it rolls out to production.
• “The Agentic Software Factory”: the same loop with “someone builds the thing” replaced by a stack of orchestration, harness, sandbox, model. Agentic testing (for example computer use) sits alongside automated testing, agentic code review and agentic regression testing sit next to the pull request, and a monitoring box feeds incidents back into the loop. The two human steps, testing and reviewing the change, are still there.

Then came “enter SlopCodeBench”. SlopCodeBench is a community benchmark for coding agents. Its paper (v2, May 2026) describes 36 problems and 196 checkpoints in which an agent keeps extending its own earlier solution as the specification changes. Besides pass rates, it measures two kinds of degradation: structural erosion (complexity piling up in a few functions) and verbosity (redundant code). The paper’s abstract says no agent solved any problem end to end, the best agent passed 14.8% of checkpoints, and erosion rose in 77% of trajectories.

Dex Horthy’s “Strict checkpoint pass rate” slide: no model on it got past 16.3%.

The “Strict checkpoint pass rate” slide had two panels:

The last slide I photographed, “Problem to Solve”, explained why a factory needs more than a better model. Every coding-agent session “starts cold”. Users type the same instructions into session after session (one example was bun --bun run test). They keep reminding the agent of facts it can’t get from the code, such as “the payments team owns that service, don’t touch it”. Nothing notices when “five engineers all told the agent the same thing” and turns that into shared, reusable steering, so new teammates don’t benefit from what the team has already worked out.

More from the software factory slides

Going back through my photos, I’d missed a few slides that carry the argument.

The title slide: “There’s no Dark Factory Without Better Verifiers”.

• The real title. The opening slide read “There’s no Dark Factory Without Better Verifiers”, and the rest of the talk explained why.
• “The lights-off software factory”: no thanks. A version of the agentic factory diagram with the human steps (human tests, human reviews of the change) scribbled out was stamped “NO THANKS”. The reason came next: “unattended, models can’t maintain / improve codebase quality over time”. Another slide set “solving one-off problems” against “improving codebase quality” on a 2025–2026 timeline.
• Verifiers are the bottleneck. The slide just before “enter SlopCodeBench” read: “in RL you need an oracle / verifier”. The benchmark measures code quality over many iterations, not only whether the tests pass.

The lights-off factory, with the human checks removed: “NO THANKS”.

Then came “Twelve-ish great practices for software factories”. The ones I photographed:

• “Plan before you build: 30 minutes up front saves hours during review.” An expected pain curve (expected pain = P(you have to change it) × how painful the change is) fell steeply as time spent up front grew, with points marked at 2 minutes, 5 hours and 20 hours. One annotation said “~80% of the expected pain, gone up front”.
• “Help Agents test their work: Screenshots, Browsers, Videos, cURL.”
• Fix cold starts. The “Problem to Solve” slide above, about steering that every session forgets.

“~80% of the expected pain, gone up front”: the case for planning before the agent builds.

He closed with a four-layer factory stack, each layer marked buy or build:

The software factory stack: control plane, harness, dev environment, infrastructure.

My take: the agentic factory diagram is a CI/CD pipeline with the “builder” box swapped out. That’s good news for platform teams, because the gates (tests, scanning, review, monitoring) are things we already know how to run. The SlopCodeBench numbers argue for keeping those gates strict. When even the top models pass well under a fifth of iterative checkpoints, a single green run tells you little. Steering that teams keep repeating belongs in the repository, in AGENTS.md, Skills and CI policy, where every session and every new teammate picks it up.

Breakout: What IS an Agent’s Identity?

Thursday 17 September, 1:10 PM | Auditorium (Ground Floor). The official schedule puts this talk on Day 1; I’ve kept my notes here with the other identity and orchestration sessions.

Christian Posta (Chief Architect, Solo.io) tackled one of the most fundamental questions in agentic AI: if agents have write access to systems, who is acting?

The session covered:

• How to establish agent identity in distributed systems
• The difference between authentication (who is this?) and authorization (what is this allowed to do?)
• Practical patterns for agent identity in Kubernetes, service meshes, and zero-trust architectures
• Integration with the Sovereign Trust Plane announced yesterday by Traefik Labs

Breakout: Agents Talking to Agents

1:50 PM | G102 + G103 (1st Floor)

Willem Berroubache (Orange) presented on the reality of multi-agent orchestration in production. With 60% of teams now running multi-agent systems (per the AAIF survey), the question is no longer whether agents can talk to each other — but whether they can do it reliably.

Key takeaways:

• A2A (Agent2Agent) provides the protocol, but semantic alignment is still a human problem
• Tool consistency across agents — if Agent A calls an MCP tool that Agent B doesn’t have, the handoff fails
• Error propagation — agent failures cascade differently than human task failures
• Observability — AgentCat’s new AX platform (announced yesterday) is starting to address this with session replay and goal detection

Breakout: MCP Apps and The Agentic Web

1:50 PM | Auditorium (Ground Floor)

Liad Yosef (MCP Apps) presented on the emerging category of MCP-powered applications — apps designed to work with both humans and agents simultaneously.

The concept: instead of building separate interfaces for human users and AI agents, build one application that serves both through MCP. A developer tool might expose its functionality through the same MCP interface that both a CLI user and an agent can use.

Breakout: From API Catalogs To Agent Catalogs

1:50 PM | Emerald Room (1st Floor)

Vyshnavi Gadamsetti and Sebastian Wennemers (SAP) presented on agent catalog discovery — solving the problem of finding the right MCP server among thousands of community-contributed options.

The session introduced Open Resource Discovery — a protocol for discovering, rating, and versioning MCP servers. This is critical infrastructure as the MCP ecosystem grows: with 89% of teams using MCP, the ability to find and evaluate the right tool server has become a first-order concern.

Hallway Track: Day 2 Interviews

Day 2 was my busiest day for interviews. Manik Surtani and Shaun Smith are covered with their keynotes above. Here’s what the others told me, in their own words, summarised. Product claims are the companies’ own.

Max Körbächer, Liquid Reply. The day started with a breakfast side event before the keynotes. Max, managing director and founder at Liquid Reply, organised it because a friend had run the same format at KubeCon, and he thought starting the day with a good conversation beat starting it with a keynote. He also organises community events in Munich and Amsterdam.

Alex Salkever, Editor-in-Chief, Agentic AI Foundation. Alex writes the AAIF newsletters, and his workflow is a good example of using agents for real work. Every Sunday, about nine agents of his own curate the week’s agentic AI news down to roughly 300–400 items. He then picks around 90 for a newsletter of about 3,000 words. Other scripts pull in RSS feeds, translate, and summarise long changelogs, GitHub PRs and issue threads across the protocols the foundation tracks. He still reads anything controversial in full, because the AI “was lazy and didn’t read the whole site” often enough. A GitHub project can trend in stars without being news.

Shannon Williams, co-founder of Obot AI (his co-founder Sheng Liang gave the Day 1 keynote on AI control planes). Obot is an open source control plane for how agents connect to data, systems, models and skills. It works at three levels: MCP and model gateways, sandboxed hosted agents on a company’s own infrastructure, and controls and audit for what runs on users’ laptops, including the CLI, API and Bash calls coding assistants make. Because the founders previously started Rancher, Obot runs on Kubernetes and uses it to spawn MCP servers per run and to lock down agent sandboxes. An agent built on Obot gets an identity plus an API key and URL, and everything it does after that is audited and filtered. He expects most employees to have “Hermes-style” always-on agents within the next 12 to 24 months. In his view the biggest limits are token cost and governance: an agent that spends hours and $250 to book a flight is not a win.

Simon Emms, Staff Solutions Architect, EMEA, Temporal. Simon explained durable execution with a bank transfer: validate the details, move the money into a holding account, then send it to a third-party bank you don’t control. If that last step fails, you don’t want to restart from the top and debit the customer twice. Temporal remembers where the workflow stopped and resumes from there. For agents, the same property means a model outage doesn’t force you to burn the same tokens again. Compared with a queue, Temporal can also pause a workflow for 20 minutes, or for years, without using worker resources. Because it’s code-first, the developers writing a workflow also configure it, rather than waiting days for a platform team. He used to be a platform engineer, so he said he was “as guilty of this as anybody”. Temporal is open source, with a managed cloud service for large scale.

Ugo Pollio, Director of Sales Engineering, Cockroach Labs (interview in Italian). Ugo talked about Cockroach Continuum, which Cockroach Labs had announced a few days earlier (launched on 15 September 2026, according to press coverage). The engine is still CockroachDB, but the focus has moved to agent workloads. His argument: agents hit databases 24/7, concurrently and in bursts, so they need consistent transactions and elastic scale. The database also becomes where agent state, metadata and logs persist. Vector search inside the same database means you don’t have to move transactional data elsewhere to use it for AI. He mentioned growth in quantitative finance and with AI-native companies. I covered Cockroach Labs’ wider agent strategy in The Database Reckoning.

Vladimir Vučković, Founding AI Engineer, moyai. Moyai sits on top of an existing observability stack and looks for anomalous behaviour in production agent traces: hallucinations, loops and orphan tool calls. It runs statistical analysis on the traces first. Then its own multi-agent system digs for evidence, forms hypotheses and confirms or refutes them, before producing a report with a suggested fix. It’s agnostic about the agent and prefers OpenTelemetry-native traces. Vladimir described the design as a “macro ReAct loop”, where each agent in the system plays one step of reasoning and acting.

Maisie, Anaconda. Anaconda, known for Python package management and security, acquired Kilo Code (announced in July 2026). Kilo is an open source coding agent with access to 500+ open-weights and frontier models, model benchmarking, cost optimisation and routing to Bedrock, Azure, on-prem or air-gapped targets, available in VS Code, JetBrains and the CLI. Anaconda adds governance on top: audits of which models are pulled in, and role- and team-based restrictions. She said Anaconda Desktop would integrate with Kilo by the end of the month, for local development and testing.

Roman Swoszowski, VP of Product Development, Grape Up (Aiboostr). Aiboostr, which Grape Up presented publicly for the first time at the conference, gives an enterprise a single catalogue of its AI systems, agents, MCP tools and public and private models. Users request access and get it approved automatically, and each entry carries attributes such as risk classification, intended users and review status. That makes EU AI Act work “a side effect” of keeping the catalogue, and the data can feed an external GRC system. It’s deployed on-prem on any Kubernetes cluster for data residency, usually starting with a proof of concept.

Andrew, Runlayer. Runlayer starts with discovery. IT pushes a script through mobile device management that hooks into the coding agents and AI clients on each machine, so the company can see prompts, tool lists, tool calls and reasoning steps across the “five or six different coding harnesses” a typical company uses. Policies and guardrails come next. Agents can then be moved to Runlayer-managed agents or given agent accounts, non-human identities scoped to specific tools so “the blast radius” stays small.

Patrick, Palma. Patrick, who introduced himself as Palma’s CEO, described its job as governing MCP and skills for very large enterprises where 99% of staff aren’t technical. Everyone gets a single MCP connector, and central IT manages policies, audits, security scanning and which tools each role gets. The part he was most excited about was skill collaboration at scale: who owns a skill, how thousands of people suggest changes, and whether everyone who receives a skill also has the MCP access it needs.

Angela Brown, Linux Foundation. Angela runs events for the Linux Foundation, the home of the AAIF, and has been there for 18 and a half years. She pointed out that the foundation was only nine months old and had already passed 270 members, a pace of growth the LF had never seen. For scale: MCP Dev Summit, which Obot started and donated to the AAIF when the foundation formed, had about 450 people in London the year before, against more than 2,000 in Amsterdam. Her two themes of the week matched what I kept hearing: composability and accountability. Since the 28 July MCP release, the question has moved from “is this in production?” to “how do we run it well?”, with compliance, governance and security on top in Europe. She expects open source AI governance to land in companies’ existing open source programme offices (OSPOs). Next on the calendar were MCP Dev Summit Toronto and AGNTCon + MCPCon North America in San Jose on 22–23 October, plus the Nairobi event with the Gates Foundation, which, she said, is helping invite government representatives from across Africa.

Two attendees summed up the mood. Bala, who had flown in from Bangalore, wanted to dig into security: how to keep agent boundaries trusted as more agents are exposed to the world. Another attendee, leaving the last session, said every talk ended up at the same place, whatever was being built: “we need to be able to manage the agents”, stay in control, govern them and observe what they do.

My take: listen to the vendors on this floor side by side (Obot, Runlayer, Palma, Aiboostr, Traefik on Day 1) and you hear the same product category described five ways: a control plane for agent access, identity and evidence. For platform teams, the questions to ask are boring and familiar. Where does it run (on Kubernetes, on-prem)? Which identity standards does it speak? Can an auditor verify its records? Can you leave without rewriting every agent?

Key Data Points from Day 2

• Stateless transport in use: Shaun Smith’s adoption slide showed 50.8% of tool calls on the 2026-07-28 protocol version over the trailing seven days (9–15 September).
• AAIF growth: Manik Surtani’s “Where we are now” slide showed hosted projects going from 3 to 6, working groups from 7 to 8, and 270+ member companies.

What This Means

Day 2 confirmed what Day 1 suggested: the agentic stack is real. The announcements weren’t just product launches — they were infrastructure pieces clicking into place:

1. MCP goes stateless — Shaun Smith’s keynote proved it scales
2. A2A joins AAIF — agent-to-agent communication now has a standards home
3. Agent identity has working patterns: at least one vendor (Solo.io) showed one, though other sessions still called identity an open problem
4. Agent experience is emerging — AgentCat’s AX platform gives us tools to understand our agent users
5. Governance is maturing — Traefik’s Sovereign Trust Plane, WSO2’s Agent Manager, and Grape Up’s Aiboostr provide concrete paths to production

Related Content

• AGNTCon + MCPCon Europe 2026: Day 1 Recap
• AGNTCon PreDay: Agentic AI in the Wild
• Agentic AI in Enterprise Kubernetes
• AGNTCon + MCPCon Europe 2026 (Media Partner)
• CTO Network State of Agents 2026 at Databricks Amsterdam