dirk-menkveld-freelance-ai-engineer.jpg

Freelance AI & Agentic Engineer

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.


What I Build

1. MCP Servers

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.

2. Agents That Own a Workflow

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.

  • Tool-using agents with clear boundaries on what they may and may not do.
  • Human-in-the-loop checkpoints where the cost of being wrong is high.
  • Retries, fallbacks and graceful degradation, because models fail differently than code does.
  • Cost and latency budgets that survive contact with production traffic.

3. Retrieval and Context

Getting the right information in front of the model, which is usually where quality actually comes from:

  • Retrieval over your own documents, tickets, code or product data.
  • Chunking, embedding and ranking chosen for your content, not copied from a tutorial.
  • Evaluation sets so “we improved the prompt” becomes a measurable claim.

4. Evaluation and Observability

An agent without evaluation isn’t in production — it’s on the loose.

  • Test sets built from real cases, run on every change.
  • Tracing so you can see what the model saw and why it chose what it chose.
  • Regression detection when a model or prompt update quietly breaks something.
  • Monitoring in the same stack as everything else: Sentry, Grafana, alerting that reaches a human.

5. Agentic Automation

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.


Why Me Rather Than an AI Consultancy

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.


Where Agents Are Usually a Bad Idea

Worth saying out loud, because few people selling this will:

  • When the rules are actually deterministic. If you can write the logic down, write the logic down. It’s cheaper, faster and testable.
  • When being wrong is unrecoverable and you can’t afford a human check.
  • When you have no evaluation data and no way to get any — you’ll be shipping on vibes.
  • When the real problem is your data, which no amount of model will fix.

Typical Engagements

  • Build an MCP server exposing your systems to agents, safely and with an audit trail.
  • Take one manual workflow agentic end to end, with evaluation, as a proof of value.
  • Rescue a stalled AI project — usually an impressive demo that never survived real data.
  • Set up evaluation and observability for agents you already run but can’t measure.
  • Advise on where to start, then build the first one with your team so they own the pattern.

Ready to Start?

Check my availability, read the blog, or get in touch and tell me what you’re trying to automate.


FAQ

What is agentic engineering?

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.

Which models and tools do you work with?

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.

Have you shipped agents in production?

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.

Can you work with our existing engineers?

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.

Do you do AI strategy as well as building?

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.