Agents in Production at AI House and HOPE 2025

Wednesday 19 November 2025 was a two-venue day for me. In the morning and afternoon I was at HOPE 2025, the HCS Open Platform Experience, which my calendar puts at the Meervaart in Amsterdam. In the evening I crossed the city to AI House Amsterdam for Agents in Production (In Person), MLOps x Prosus.

The two events looked unrelated on paper: one about running internal platforms, one about running AI agents. The talks I photographed made the same argument from two sides. The technology is rarely what holds an organisation back. Adoption, habits and ownership are.

This is a throwback post built from my photos, the slides on screen and short recordings of some sessions and stand interviews. I only name speakers whose names appeared on a slide or in the event invite; others are described by role or company. Numbers from the stands and stages are the speakers’ own claims.

The HOPE 2025 expo floor before the sessions started, with the Portworx, Red Hat and HCS company stands.

HOPE 2025: the HCS Open Platform Experience

HOPE is organised by HCS company (the “Tech Tribes” logo was on every screen). The sponsor screen at registration thanked Red Hat, Portworx by Pure Storage, GitLab, Chainguard, GRN.CLOUD, Grafana, Ingram Micro, EDB Postgres AI and SUSE. The stands had the usual one-line pitches. Portworx had “Any Application. Any Cloud. Any Infrastructure.”, SUSE had multi-Linux support and “no vendor lock-in”, and EDB had “Just solve it with Postgres”. Between sessions the main hall screen read “We HOPE you’re enjoying yourself! Where to go next? Check out our awesome programme!”, and there was a photo booth with the hashtag #HOPE2025.

Opening and the charity

The day opened with a welcome in Dutch from the HCS company host. This was the second edition (the first was last year), and the pitch was that platforms matter more every year, but that success is about more than technology: the question is how a platform team becomes successful inside its organisation. The programme mixed deep technical sessions and hands-on workshops (the GitLab one was nearly full) with a strategic session on platform maturity. The host said the aim had been 200 visitors and they had almost reached it, and thanked the partners and about 90 colleagues who had submitted talks or promoted the event. In a stand interview an organiser later told me about 175 people were there, around half-way through the day.

The entrance fees went to Enable Nederland, a volunteer organisation that 3D-prints hand and arm prostheses. Its chair thanked HCS and the audience from the stage. A volunteer at the stand told me the community uses volunteers’ own printers and a matching platform (EnableWebCentral, in the speaker’s words) to link makers with people who need a hand. Their talk covered the history (a first design shared as a video in 2011, then chapters worldwide, with more than 200 today and a Dutch group since 2017). The designs are mechanical: a wrist-driven hand for people who keep part of the palm, and an elbow-driven arm for people who keep part of the forearm. They quoted 53 volunteers in the Netherlands and Belgium and 51 hands and arms delivered there, plus 21 in Ethiopia, and said the printers have also been used for splints and face-shield frames. It is the best advert for a 3D printer I have heard.

Red Hat on OpenShift AI, and Portworx on persistence

The first technical session I recorded was a Red Hat solution architect on navigating AI and machine learning adoption with OpenShift AI. The speaker (not named on a slide I photographed) framed adoption as three stages: trial (evaluate models), experimentation (ground them in your own data) and production (scale and integrate). Their platform-team argument was the one I make to clients: AI adoption tends to happen in pockets, so a platform team should offer a governed, secure, easy-to-consume place to run models, otherwise shadow IT fills the gap. Technical points I noted:

• GPUs are onboarded to Kubernetes with operators: node feature discovery labels a new node’s hardware and the NVIDIA GPU operator installs drivers and monitoring.
• vLLM was called the de facto way to serve open models, with compression tooling to cut memory use for a small accuracy loss (one or two percent against several times fewer resources, as they put it).
• A model registry is the first step towards governance, and models as a service should be easier to consume than a public cloud API.
• Stage two used a pipeline in which Docling converts PDFs and Word files, then embeddings go to a vector database. They described Kubeflow as the Swiss army knife for Kubernetes-native ML.
• Stage three added guardrails and Llama Stack as a stable API layer, with MCP servers for OpenShift, a database and Slack in the demo.

The session was 30 minutes for material prepared for much longer, and the host handed out a joke award for the fastest OpenShift AI presentation.

Next came a Portworx cloud-native architect (name unclear on the recording) on persistence. The argument: the 12-factor idea of stateless processes pushes everything persistent into “backing services”, yet even Notepad remembers its word-wrap setting, virtual machines on Kubernetes need volumes, and AI workloads need stores. He walked from in-tree volume drivers to the Container Storage Interface. In the Q&A-style wrap-up he said customers at the booth usually do not care whether the storage layer is open source as long as it works with their tools, while parts of the solution are open source.

Dagger: CI/CD pipelines as code

A third session was an introduction to Dagger by a speaker with about five and a half years in IT, mostly cloud native. The pain points were familiar: complex YAML pipelines, the push-and-wait debugging loop, and declaring artifacts per job. According to the talk, Dagger is an open-source, fully containerised runtime where you write functions in Go, Python, TypeScript, PHP or Java (with .NET, Elixir and Rust experimental). Functions run in a graph, in parallel where they have no dependencies, with layer, volume and function caching. Modules are plain source that you pin by version. Secrets are handled so they do not leak into logs or caches.

The demo built an image, scanned it with Trivy, pushed it and signed it with Cosign. The feature that stood out was the interactive shell: when a step fails you land in a shell inside that step’s container, and you can also set breakpoints.

My take: the Dagger pitch is persuasive for teams with many pipeline variants. Being able to run the same pipeline locally and in CI removes the slowest part of pipeline work, which is waiting for the runner. The trade-off is another abstraction to learn and a runtime to operate. For simple builds, plain YAML in GitLab or GitHub Actions is still easier to review.

AI-assisted observability

In the afternoon I recorded a session on AI-assisted troubleshooting. From the product names used (Grafana Cloud, Loki, Prometheus, profiles), it was a Grafana Cloud demo, but I did not capture the speaker’s name. The scenario was a web shop whose recommendation service had stopped. An alert led to a service view in a knowledge graph linking services, front end and Kubernetes. The pod had been killed for running out of memory, the CPU and memory profile showed no code change, and the assistant read the flame graph and pointed at too many threads for the growing customer load. The demo then showed an investigation mode in which a lead investigator agent asks metrics and logs specialists for evidence and does not simply trust them. The result is a report with a confidence score, recommendations and a tree of the hypotheses that were rejected. The presenter’s main point was that front-end engineers, SREs and new hires should use the same tools and share links, built on OpenTelemetry rather than separate tools per team.

”We have a platform. It’s running. Now what?”

The session I came for had the best title of the day: “We have a platform. It’s running. Everyone’s enthusiastic. Right? So… now what?” The subtitle was “Maturity Model – IT platforms”, with the case study named as a Dutch government IT service organization. The slide carried the HCS company logo. In my recording of the start of the talk, the presenter (in Dutch) said the topic was process and people as much as technology, and that the story began when they were called just before the summer by an organisation that had already been running a platform for six years.

The question most platform teams reach about a year after go-live.

Later in the talk the presenter put the full model on screen as one canvas: a PDF named “HOPE 2025 - We have a platform - now what”, on page 34 of 37. I photographed it because it is one of the more complete platform maturity frameworks I have seen on a single slide:

• Maturity levels: absent, emerging, exploratory, operational, institutionalised and leading.
• Vision & strategy at the centre: purpose and value, direction and alignment, evaluation and recalibration.
• Governance & evolution around it: platform ownership and management, principles and policies, shaping and realisation, reflection and adjustment.
• Organisation & collaboration: platform organisation, platform engineering, platform enablement and organisational embedding.
• Capabilities & architecture: core capabilities, AI capabilities, capabilities for applications and data, architecture and design, technology integration.
• Engagement & adoption: onboarding, effective usage, experience and participation, modernisation and migration.
• Participants: platform teams, platform customers, ecosystem teams and management.
• The process: initiate, kick-off, assessment, interviews, analyse, compose the model, discuss, finalise and present.
• Outputs: artefacts (scorecards, analysis, a dashboard) and a maturity profile (current state, growth potential, ecosystem opportunities, fresh perspectives).

The whole maturity model on one page. Note that “AI capabilities” sits next to core capabilities, and that adoption is a whole area of its own.

My take: the canvas gives adoption and governance as much space as capabilities, and I think that is the right proportion. Most platform assessments I see score the tooling and stop there. A platform that is “running” but has no ownership model, no onboarding path and no feedback loop doesn’t stay healthy for long. I described a similar ladder in my platform engineering maturity model post. The useful addition here is the explicit interview-based process, and the “participants” box, which includes platform customers and management, not only the platform team.

AI brings out the human side

A later session on AI showed a news headline on screen, “Klarna’s AI bot is doing the work of 700 employees. What will happen to their jobs?”, and ended on a one-line conclusion slide: “AI brings a lot aspects of mankind to the surface”.

The conclusion slide of the afternoon AI session at the Meervaart.

The session was in Dutch, and the speaker’s name was not on a slide I photographed, so I describe it rather than name him. From my recordings he was sceptical about hype and about doom alike. He made a joke about checking the Nvidia share price before the company’s results that evening and concluding that “there is no AI bubble”. He argued that the real question is productivity: services and especially government have barely improved their labour productivity over decades, so if an assistant saves half an hour, what do people do with it? He mixed in lessons from sport about data and simulation, a story about digital twins and how hard human behaviour is to simulate, and a plea that Europe’s rules (he mentioned GDPR and the Data Act) should be simple enough for companies to follow without a stack of documents. I could follow only parts of the Dutch audio, so I leave the examples there.

That line turned out to be a good bridge to the evening.

On the expo floor

I recorded a handful of short stand interviews. The interviewees knew they were being filmed for publication, and I describe them by company and role.

• Ingram Micro: a representative described a partner enablement programme for AI planned for next year, with four milestones so that newcomers and advanced partners can join at the right step, delivered with HCS through inspiration sessions. A first kickoff was planned for the end of the year with a few selected partners.
• Kangaroot (an open source consultancy in Belgium and the Netherlands): the interviewee said two themes dominate, sovereignty and AI. Open source is a route back to your own or European data centres, and the company was preparing an on-premises “AI foundation” offer.
• GitLab: an ecosystem sales manager for the Netherlands and the Nordics described the newly launched GitLab Duo Agent Platform as a helper across the software lifecycle from idea to deployment, and said she was not technical and would put people in touch with colleagues for demos. She also said the HOPE audience is open and diverse, with public and private sector people willing to discuss what they use.
• Chainguard: representatives said Chainguard Libraries had just become generally available, claiming 98% malware prevention, alongside container images with a claim of zero known CVEs (about 1,800 images, 55 of them free). It is their pitch against supply-chain attacks.
• EDB: a representative said the company develops and supports Postgres, maintains the CloudNativePG operator (a CNCF sandbox project), offers WarehousePG as an open-source alternative to Greenplum, and describes itself as one of the largest independent Postgres contributors, including the majority of the code for Postgres 18 (EDB’s own claim).
• HCS company: a recruiter said they look for engineers in containerisation, observability and automation, and at the stand people mentioned OpenShift AI as a growing topic for staff.

Agents in Production at AI House Amsterdam

Agents in Production is the MLOps Community’s conference on AI agents. According to the invite in my calendar, the in-person evening at AI House was the companion to the community’s 6th Annual Virtual Conference (30+ talks online), with 200 seats at AI House, Gustav Mahlerplein 5. It was billed as “MLOps x Prosus”, and the invite listed one headline talk: Mert Öztekin, CTO, Just Eat.

The sponsor area had a few stands. A Kilo Code banner said “#1 on OpenRouter”, “500k+ Kilo coders” and “Kilo Code is the fastest growing coding agent because it is open. Open models. Open pricing. Open source.” Those are Kilo’s own claims. The demo screen next to the banner had Kilo Code building “a fully functional todo application using only frontend technologies”, testing it in a browser itself, with auto-approve switched on for read, write, execute, browser and MCP, and Claude Sonnet 4.5 selected as the model. Toqan (“Enterprise Scale, Start-up Speed powered by Agents”) showed a chart titled “Toqan Adoption and seniority of Agents” with a Prosus footer, and Redis had a board reading “Build AI apps with more speed, memory, and accuracy”.

Kilo Code’s banner: openness as the selling point (vendor claims, as printed).

Mert Öztekin: “Cultural Lag”

The host introduced him (after joking that anyone could sign up to give a seven-minute talk later in the evening) as the CTO of Just Eat. He started by asking the room who had an engineering background and who managed people, found that almost everyone was an engineer, and warned that his talk would not be engineering-focused. The headline talk was “Cultural Lag: AI is evolving fast. Organizations aren’t. How can we solve the problem?” by Mert Öztekin, Chief Technology Officer, Just Eat Takeaway.com.

The headline talk of the evening.

He opened with the company in numbers, on a slide titled “Empowering Everyday Convenience”: 356K partners, 61M active customers, 2.5K people in the technology organisation, 17 countries and 653 million orders processed in 2024. The footnote dated the numbers to December 2024. A Prosus logo was marked “part of Prosus since Q4’25”. The brand logo rotated while I was taking photos: one shot shows Menulog, the next Pyszne.pl.

The core of the talk was one diagram, “The difference in the Speed of Evolution”. Three vehicles stand for three speeds: an excavator for regulation development, a saloon car for culture development and a sports car for technology development. The gap between the last two is labelled “Cultural Lag”. The next slide backed this up with a McKinsey chart, “Use of AI by respondents’ organizations”, plotting organisations that use AI and gen AI in at least one business function, with both lines climbing steeply in the last years.

Left: the scale of the organisation the talk was about. Right: the cultural lag diagram, with regulation slowest and technology fastest.

Why does culture move slowly? The answer slide was “Why Organization Culture Evolves Slower: culture moves slowly because behavior moves slowly”, with three causes:

• Habits: “Our daily work is automatic. We do what we already know.”
• Fear / bias: internal psychology, fear of the unknown.
• Psychological safety: external factors, “created by team, manager, leader”.

For the way out, he went back to Everett Rogers’ Diffusion of Innovations: innovators (2.5%), early adopters (13.5%), early majority (34%), late majority (34%) and laggards (16%), with “the chasm” marked between early adopters and the early majority and a “50% inflection” point after that.

Left: three reasons behaviour changes slowly. Right: the adoption curve used as a change-management map.

The practical part covered what the company did. An “AI ambassador programme” slide described a volunteer-based, cross-functional network “to support, challenge and inspire”, shown as a wall of people’s photos (which I’m not reproducing here). An “Enterprise Chatbot Adoption” dashboard showed an overall adoption rate of 69.44%, up 1.9% from the previous month, with a monthly trend running up to October and a breakdown per department.

The last slide I captured was addressed to managers, “What Team Managers should do?”, tagged with the same three causes (habits, fear/bias, psychological safety):

1. Show encouragement: walk the walk.
2. Recognize your AI talent: encourage and unblock them.
3. Focus on your mission: your mission is not your task or process.
4. Review objectives and incentives: people respond to incentives.
5. Take the initiative: don’t wait for direction, go get what your team needs.

Five manager actions, each tied back to habits, fear and psychological safety.

My take: this was the most useful talk of the day for me because it treated AI adoption as a change-management problem with a measurable output (that 69.44% adoption rate), not as a tooling rollout. The ambassador network is the same pattern that works for internal developer platforms: a volunteer group in each team does more for adoption than a mandate from the top. Point 4 is the one I see skipped most often. If performance reviews still reward the old way of working, the chatbot dashboard will plateau, whatever the training budget. I wrote more about this in People and Culture in Technology Transformation.

A panel, FINI and “Not all context is good context”

After the keynote came a panel. The stage screen showed Luciana Ledesma (CEO and founder, MeaningStack) and Alex Salazar (co-founder and CEO, Arcade.dev), plus a third panellist whose name card I didn’t capture in full.

The panel on the AI House stage.

Later in the evening, two shorter talks went into the mechanics. The first was titled “This is how FINI works behind the scene”. Its architecture slide placed an LLM supervisor behind safety guardrails, in front of a stack of numbered layers, with a live evaluation and feedback loop at the bottom. The outputs were framed as “insights like” trust metrics (escalation reasons, user sentiment) and product analytics (feature requests, bugs, user intents).

The second, a talk with Redis branding in the slide footer, was “Not all context is good context: bigger input sizes hurt performance, and your budget.” It showed a social media post (the author’s name blurred on the slide) arguing that GPT-5’s usable context stays effective at a 256K window where o3 degraded at 128K, next to a long-context benchmark chart. The price line underneath was the punchline: “GPT-5 API Price: $1.25 / 1M input tokens – $10 / 1M output tokens”.

A bigger context window is not free: every token you send is paid for, and long inputs can still hurt answer quality.

The Redis speaker followed with a live demo of semantic caching, with about a minute and a half left on the clock. The first attempt, a local Redis container and a notebook, stalled while loading a file of question-and-answer pairs, so they switched to Redis’s managed semantic cache service (LangCache). They stored the prompt “How does semantic caching work?” with an answer, then asked “What is semantic caching?”, a similar but different question, and the cache returned the stored answer. The audience cheered when it worked. That is the point of semantic caching: it matches on meaning rather than exact text, so repeated questions skip the model call. The speaker also mentioned a Redis stand and a talk in Eindhoven the next evening.

My take: “not all context is good context” is the agent-era version of “garbage in, garbage out”. A long context window is a limit, not a goal to aim for. Retrieval, memory and caching layers exist to keep the prompt small and relevant, and they pay for themselves in both cost and accuracy. I cover the practice in Context Engineering vs Prompt Engineering. The live demo also showed the sensible order of work: a semantic cache in front of the model is one of the cheapest savings, as long as you tune the similarity threshold so that near-identical questions with different answers are not merged.

What linked the two events

Platforms in the morning, agents in the evening, but the slides I kept were nearly all about people. The HOPE maturity model gives adoption and governance as much space as capabilities. The Just Eat Takeaway.com talk put culture between regulation and technology as the bottleneck. As a consultant who builds both platforms and AI infrastructure, I see the same thing in my projects. The deployment is the easy part. The adoption curve after it is where most of the work is.

Related

• MongoDB Day Amsterdam 2025 and the AI House Opening
• Platform Engineering Maturity Model
• People and Culture in Technology Transformation
• AGNTCon + MCPCon Europe 2026 Recap: Agents in Production