I got to Amsterdam running on fumes. The week before, our head of field engineering Chris Urwin and I were in Shanghai and Tokyo for the AAIF MCP Dev Summits, and I’m not sure my body ever figured out which time zone it was supposed to be in. I spent the first morning walking along Zuid with a coffee, trying to convince myself it was actually morning.
Then the show opened, and I completely forgot about being exhausted.
I’ve been to a lot of conferences over the last 26 years. Very few of them feel like the start of something. Early DockerCon did. Early KubeCon did. This one did too, even more so than the MCP Dev Summit last year. Sessions were packed, and ours had well over 200 people in it. The booth was three, four, five people deep for most of the show, with people craning to see a demo and asking what exactly these open source projects do. More than 500 people came by over the week. Most were engineers, architects, SREs and platform people from banks, telecoms, energy companies, carmakers, healthcare and plenty of software shops. A lot of them were already building something and wanted to compare notes.
A few things came up over and over.
1. Everybody is building the same thing
Whatever they called it (control plane, AI platform, orchestration layer), almost everyone I talked to was trying to put some structure around the agents, MCP servers, Skills, CLIs, APIs and models showing up across their company.
Sheng made the point in his keynote (watch here) that controlling what agents can reach has turned into a distributed computing problem. Lots of agents, lots of protocols, lots of data sources, running all over the place and often acting with somebody’s user identity. That’s pretty much the problem Kubernetes took on for workloads, which is probably why the whole event felt so familiar to me.
The stacks people described were mostly assembled from open source. An LLM proxy, an MCP gateway, some scripts to hold it together. Plenty of people told me they’d like to get down to fewer pieces. What I didn’t expect was how many people walked up already running Obot. I’d never met them. They’d found the project on their own, deployed it, and wanted to tell us how it was going for their teams. After a while we stopped writing down every “we use Obot” and just made a note when someone mentioned a different project. I had that feeling a lot in the early Rancher days, and it was nice to have it again.
2. It’s less vibe coding than people think
Vibe coding comes up in every one of these conversations. What I heard in Amsterdam was mostly that engineering teams are moving a lot faster and doing a lot more. And much of what gets called vibe coding is people outside engineering using tools like Claude Code to get their jobs done.
I think that’s great. It does mean you have agents with access to important data running on someone’s laptop, which makes security teams nervous for good reason. I had a lot of conversations about moving that work into isolated sandboxes where you can control what the agent reaches and look back at what it did.
I asked a lot of people what made governance urgent. Some had an incident. Most talked about audit. Someone went looking and couldn’t answer simple questions about who was using what, or what their agents had touched. Some teams want controls in place before they roll anything out. Others shipped first and are catching up. Both seem fine to me. The teams I found most interesting weren’t treating it as a choice between moving fast and being careful.
One team at a large organization I’ve been talking with is a good example. They own APIs, MCP, integrations and AI SDKs, and their job is to help the rest of the company build faster. Teams in regional offices are shipping apps in weeks that used to take years, and nobody wants to slow that down. What they want is one place that shows what’s approved, a clear path for a team to take an agent, a Skill or an MCP server into production, and a way to see who’s using what. They see governance as the thing that lets them keep that pace.
Try Obot today — the open-source MCP gateway. Self-hostable, MIT licensed, full audit trail at every tool call.
Under almost all of these conversations was the same problem. The old setup assumed developers used APIs and everyone else used an app. Now people reach data and systems through MCP servers, APIs, desktop clients, agents working on their own, and agents being driven by users. Teams need a way to bring on new integrations and new agents, and a way to give agents their own identities and permissions instead of borrowing a person’s. Most existing stacks weren’t built with any of this in mind.
Sheng’s curate, monitor, isolate framing held up well against what I heard. Curating is the part people have started on: approved integrations, agents, Skills and models that users can pick from. Monitoring is what keeps them up at night, because they know there’s a lot happening they can’t see yet. Isolation is the newest. People know they’ll need it, but most haven’t worked out what to isolate or where. I expect we’ll all learn a lot about that over the next year.
Licorice, stroopwafels and some advice
I did get some time to wander. Dutch licorice is world class and I will not be taking questions on that. I had another warm stroopwafel, and I’m still not sure they deserve to be the global phenomenon they’ve become. Good, sure. Global phenomenon? I have doubts.
Walking back to the hotel one night, I was thinking about the people I worked with during the container wave. Plenty of the engineers who jumped in early on Docker and Kubernetes, including a lot of early Rancher users, now run engineering and IT organizations. A few are CIOs. They got in early, and now they are making decisions for their companies.
This feels like that moment all over again. If you want to have a real impact at your company, now’s a good time to get involved. Don’t wait for things to settle. Download an open source control plane like Obot, stand it up, and start working out how your company is going to handle agents, MCP servers, Skills and models. The people who do that now are going to end up shaping how everyone else does it.
If you were one of the people crowded around our booth last week, thank you. You can find us on GitHub at github.com/obot-platform/obot.
