Forecasting the 2026 AI Agent Economy at Zoku Amsterdam

On Monday 19 January 2026 I went to “Forecasting the 2026 AI Agent Economy” at Zoku Amsterdam. The title slide listed four speakers, all co-founders: Philip Gast (AdamI), Dale Wesdorp (miyagami), Lennard Kooy (Lleverage) and Sohrab Hosseini (Orq.ai). Someone from Zoku opened the evening, said the venue had offered the space because people building AI should meet face to face, and thanked the four companies for organising it.

The room was full. The format was a series of short talks: one speaker at the front, the others on stools at the side of the stage, then a shared Q&A at the end. Here is what was on the slides, and who presented it.

The line-up: four co-founders from four Amsterdam AI companies.

Opening talk: what works with enterprise clients

The opening talk had no speaker name or company logo on its slides, so I’ll describe what it covered without attributing it.

He started by asking for a show of hands: product owners, enterprise software builders, founders. Founders were the majority. His opening line was: “Every big software out there is now building AI capabilities.” A “Market Insights: AI in 2026: What the market is saying” slide followed, with four headlines:

• Agents go mainstream in enterprise apps (with a Gartner projection in the small print)
• Enterprise software shifts to a “digital workforce”
• Systems beat models
• The back office matters (ERP, process, governance)

Then came the slide I’d most like executives to read, the “Executive Pattern Library: What we see consistently working with clients”. Its subtitle said that across automotive, healthcare and heavy industry “constraints differ, but the playbook converges on these four principles”:

1. Start with a high-friction workflow & measurable KPI. Focus on specific metrics (time, quality, risk) rather than general “AI adoption”.
2. Put controls where risk lives. Implement permissions, audit trails, human gates and fallbacks directly in the loop.
3. Treat quality as an engineering discipline. Rigorous evals before launch and continuous monitoring after launch are non-negotiable.
4. Design for adoption. Fit into existing tools and decision processes.

Four principles from client work: KPIs first, controls where the risk is, evals as engineering, and adoption by design.

The next slide, from the “Product Management Framework”, was “Technical PMs orchestrate the LLM lifecycle”. Its point was that the product lifecycle has expanded to Product + Platform + Governance, in three phases:

• 01. Build (Foundation): workflow design and architecture, tool access and API integration, roles and permissions setup, and a “Definition of Done” for AI output.
• 02. Prove (Validation): rigorous evals and benchmarks, red-teaming for safety, reliability targets (SLA), cost and latency guardrails.
• 03. Scale (Operations): continuous monitoring, human feedback loops, change management, portfolio roadmap.

Build, Prove, Scale: the PM now owns evals, red-teaming and cost guardrails as well as the roadmap.

“Definition of Done for AI output” is the line on that slide I’d pass on first. Many teams ship an LLM feature without writing down what a correct answer looks like. Without that, the “Prove” column can’t be done.

Lleverage: the year of the “Why?”

The next slot was Lleverage’s, and Lennard Kooy is the Lleverage name on the line-up. The only slide I photographed from it carried the Lleverage logo and one sentence: “2026 will be year of the ‘Why?’”. I didn’t capture the rest of that talk, so I won’t guess at its argument. On its website, Lleverage says it uses AI agents to automate back-office operations for companies that make, distribute or sell physical products.

“2026 will be year of the ‘Why?’”, one sentence on a white slide.

miyagami: the Intent Revolution

Dale Wesdorp, co-founder of miyagami, presented “The Intent Revolution: Designing for Machines, Leading as Humans” (his name and logo were on the title slide). He opened with a quote the slide credited to Matt Garman (CEO of AWS) in 2024: “If you go forward 24 months from now… it’s possible that most developers are not coding.”

A “Forecast: Adaptation of Agentic AI” slide set out three stages: The Chatbot (LLMs), The Workflow (HITL) and The Agent (Autonomy). Hands went up across the room while that slide was on screen. Then came the four 2026 Predictions, each with a one-line definition on the slide:

1. AI Workflow Adoption: the move from using AI for isolated tasks to building it into end-to-end business processes.
2. Death of the Prompt Box: a move away from manual text entry towards proactive systems that anticipate user intent without explicit instructions.
3. Machine Legibility: optimising data structures and digital interfaces so that AI agents can read them and act on them with high precision.
4. Unbundling of SaaS: a disruption of traditional SaaS models as autonomous agents perform specialised tasks across several platforms.

Dale Wesdorp’s Intent Revolution talk and his four predictions for 2026.

The workflow-adoption slide showed a page of agent integrations for an issue tracker: Cursor turning issues into pull requests, GitHub Copilot converting issues into PRs, Devin scoping issues and drafting PRs, and Sentry running root-cause analysis. The Machine Legibility slide showed an ordinary admin dashboard (revenue, subscriptions, recent sales). I took the point to be that this is the kind of interface an agent now has to read, not only a human.

“Machine legibility” is the prediction I agree with most, because it’s already happening on the web. I wrote about the practical side in Is Your Website Ready for AI Agents?.

Orq.ai: controlling fleets of agents

Sohrab Hosseini of Orq.ai gave the last talk. All his slides carried the orq.ai logo. His starting point was the slide “As more agents are deployed, new layers of complexity surface”:

• Agents move from pilot to production operations.
• Fleets emerge across teams, domains and vendors.
• Autonomy at scale creates a new operational risk surface.

A diagram under the bullets showed three stages of growth: one human with one agent (manual oversight), a small stack (multi-agent coordination, analytics), then a grid of agents (agent lifecycle management, governance at scale, continuous optimisation).

From one agent under manual oversight to fleets across teams, domains and vendors.

“The agent lifecycle requires control on many dimensions” put Agent Control in the middle of six concerns: end user feedback, cost and benefits, data security and privacy, governance and ownership, quality control, and risk and compliance. The slide added that “teams need a unified perspective to make trade-offs”.

The last slide I photographed was the most concrete: “Hierarchical capabilities provide control mechanism throughout the agentic enterprise”. It’s a three-layer pyramid:

Agent icons sat along the bottom with platform logos, Salesforce Agentforce among them. As I read it, the agents can come from many vendors, and the control layers sit above all of them.

Observability, alerts and guardrails at the agent level; red-teaming and dashboards at the fleet level; FinOps and compliance at the top.

The evening closed with a Q&A, with Dale Wesdorp and Sohrab Hosseini on the slide and the other speakers on stools beside the stage. I saw the same miyagami and Orq.ai teams again in March, at The Future of Product #3.

My take: running agent fleets in production

The Orq.ai pyramid is close to how I’d structure this. In my view, problems start the moment there is a second team running agents, not the moment there are a hundred agents. This is how I’d map its three layers to work an infrastructure team can actually do:

• Agent layer: guardrails in the execution path, not in the prompt. A system prompt saying “don’t delete production data” is a suggestion. A policy check that runs before every tool call and can deny it is a control. That’s the idea behind Claude Code PreToolUse hooks, and it applies to any agent framework. Add blast-radius limits, approval gates for irreversible actions and an audit log, as in Guardrails for AI Agents in Production. This is AdamI’s “put controls where risk lives” seen from the platform side.
• Agent layer: trace every step. Each LLM call and tool call should be a span with the agent’s identity, model, token count, cost and outcome attached. Use OpenTelemetry so the traces end up next to the rest of your telemetry instead of in a separate vendor silo. The pillars are in Model Observability: Monitoring LLM Performance in Production.
• Fleet layer: an inventory before a dashboard. You can’t red-team or govern agents you don’t know exist. Each agent needs an owner, a list of the tools and credentials it can use, and a version, the same way a microservice has a service catalogue entry. Then run evals and red-team suites against the fleet on a schedule, not once at launch: the “Prove” column from the PM framework, done continuously.
• Control tower: cost and ROI per agent, not per model. FinOps for agents means tagging spend by agent and by workflow, so a CFO can ask “what does this agent cost per resolved ticket?” and get an answer. That only works if the agent layer emits the right attributes from day one.

Teams that skip the bottom layer end up with a control-tower dashboard full of numbers nobody trusts. I’d start with guardrails and tracing on the first production agent, then add the fleet and executive views on top of that data. For patterns that coordinate several agents, see Multi-Agent Orchestration Patterns for Production Systems.

Related

• The Future of Product #3: AI Product Meetup Amsterdam
• Guardrails for AI Agents in Production
• AgentOps in Production: Hands-On Lab at Red Hat Summit 2026
• What ‘Agent Engineering Platform’ Actually Means for Production AI