
I’m Dirk Menkveld, a freelance AI and agentic engineer. I build systems where models don’t just answer questions — they do work: read from your tools, take actions, and hand off to a human when they should.
The interesting problem in 2026 isn’t calling an LLM. That’s a afternoon’s work. It’s everything around it: giving a model safe access to real systems, deciding which steps it should own, catching it when it’s wrong, and making the whole thing something your team can still operate in six months.
That’s an engineering problem. I’ve been doing engineering for twenty years.
The Model Context Protocol is becoming the standard way to connect models to real systems. I build MCP servers that expose your data and actions to an agent deliberately — scoped tools, real authentication, an audit trail of what the model did.
Most “AI integration” projects fail here, by giving a model either too little access to be useful or too much to be safe. I wrote about the organisational side of this in MCP Servers: What They Are and Why Organisations Need Them.
Not chatbots. Agents that take a process a person currently does by hand — triage, enrichment, reconciliation, drafting, routing — and run it end to end, escalating when confidence is low.
Getting the right information in front of the model, which is usually where quality actually comes from:
An agent without evaluation isn’t in production — it’s on the loose.
Where agents meet the tools a business already runs — n8n, Zapier, HubSpot. Often the highest-value work isn’t a bespoke agent at all, it’s an existing workflow with one intelligent step added in the right place.
I ship with agents daily, not as a topic. Claude Code is my primary pair programmer; I use Codex and Cursor alongside it. My opinions about where agents help come from using them on real codebases under real deadlines, not from a conference talk.
I can build the boring 90%. An agent is a small part of a working system. The rest is APIs, queues, auth, deploys and monitoring — which is what I’ve done for twenty years in Laravel, Python and Kubernetes. Most AI projects die on that part, not the model part.
I’ll tell you when the answer is no. Fifteen years as a product owner at ANWB, Essent, Coinmerce and ID&T means I’ve had to justify spend. A lot of proposed agent work is a rules engine with worse margins and no audit trail. I’d rather say so in week one than bill you for discovering it in month three.
Worth saying out loud, because few people selling this will:
Check my availability, read the blog, or get in touch and tell me what you’re trying to automate.
Building systems where a model takes actions rather than only producing text — calling tools, reading and writing to real systems, chaining steps, and deciding when to stop or escalate. The engineering is in the boundaries, the failure handling and the evaluation, not in the prompt.
I’m deliberately model-agnostic — the interesting decisions are architectural and outlive whichever model is currently best. Day to day I work with Claude, and I build the surrounding systems in Python and Laravel, deployed on Kubernetes.
I use agentic tooling every day in my own engineering work, and I build and operate the production infrastructure — APIs, queues, deploys, monitoring — that agent systems need underneath them. If you want a reference implementation of how I build and run software generally, the Koppa architecture write-up is the honest version.
Yes, and that’s usually the point. Agent patterns are new enough that the lasting value is your team knowing how to build the next one. I’d rather leave a team that can than a system only I understand.
Yes — see CTO as a Service. Often the most useful first engagement is a short piece of work to decide what’s worth building at all.