Autonomous Agents
Agents that monitor, prepare, route, and act without waiting for a prompt. Scheduled analysis, tool use, escalation, and communication.
This is what I build.
Belgium
I came up through IT, then built an esports talent agency from scratch. That work trained the habits I still use now: move quickly, work from evidence, and stay close to the real decision instead of the abstract plan.
I now work as Chief AI Engineer inside a pan-European consulting enterprise of roughly 2,000 people. I build applied AI systems, agent workflows, and internal tooling that have to work in production. Alongside that, I contribute upstream to the tools I use and still represent select professional tennis players through Surge.
What I Build
The recurring work sits in three layers: autonomous agents, workflow systems, and internal tooling for the teams using them.
Agents that monitor, prepare, route, and act without waiting for a prompt. Scheduled analysis, tool use, escalation, and communication.
AI embedded in the actual process: intake, matching, document review, and multi-step coordination. The workflow matters as much as the model.
Interfaces and operator software for people doing the work every day. Clear, fast systems for teams who cannot afford friction.
Proof
Current role. Chief AI Engineer inside a 2,000 FTE consulting enterprise. Built and shipped an AI-native replacement for legacy software into production.
Open-source personal AI platform and conversation-first agent console. Multi-channel messaging, persistent identity, and autonomous execution. The trace above runs on it.
Contributed a fix to Anthropic's Claude Code after a bad release left the tool unusable. Merged upstream.
PR #16683 ↗Built and open-sourced an MCP server for Databricks so coding agents can inspect and operate Databricks environments.
github.com ↗Podcast appearance on MCP servers, agent architecture, and personal AI infrastructure.
latent.space ↗Through Surge BV, I still represent select professional tennis players. The operating discipline started in esports, where more than $50M was negotiated across contracts before the work extended into tennis.
surge.tennis ↗Approach
Not with what is possible. The interesting problems are always in the gap between the tool and the work.
Demos are easy. Systems that survive Monday morning are hard. I build for Monday morning.
Don't make the model decide what it shouldn't. Don't make rules handle what they can't. Know the boundary.
A working system on one workflow beats a prototype across ten. Prove it works, then expand.
If the system needs me to run, I failed. Documentation, handover, and operational clarity are part of the build.
The best starting point is concrete: what is failing, what is slow, or where the team is losing time.