AI Engineer building production systems across automation, ML, and applied AI — with a business operator's mind.
Background
I didn't come to engineering through a computer science degree. I studied Business Administration, spent years as an IT contractor solving whatever a business actually needed solved, and somewhere in that work found the pattern I still build around: the systems that matter aren't the impressive ones — they're the ones an operation quietly runs on.
That path shaped how I build now. Two-plus years in n8n and the automation stack, more than twenty systems in production, and a growing body of applied AI work — multi-agent pipelines, ML models, the infrastructure underneath them. The business degree turned out not to be a detour. It's the reason the engineering holds up in rooms where budgets and deadlines live.
What I build
Automation & Orchestration
n8n-centred workflow systems that run unattended and fail loudly.
Machine Learning & Applied AI
Models in service of decisions, not demos.
Multi-Agent Systems
Specialized agents behind verification gates — Groundwork is the public proof.
Infrastructure & DevOps
Self-hosted, inspectable, owned — deployment pipelines included.
Business Systems Design
The operator's layer: what a system costs, saves, and changes.
Currently
Harvard's Data Science certificate and a TinyML specialization, both targeted for August 2026. Groundwork — the multi-agent cold-email system documented in the case study — went public in July 2026 and is free to download, prompts included.
How I think
Affordable Enterprise AI is the one idea underneath everything on this site: production-grade AI systems don't require enterprise budgets. The discipline that separates dependable systems from demos — research that gets verified, outputs that get judged, failures that surface loudly — was never expensive because of the technology. It was expensive because of the headcount it took to enforce.
That's what changed. A few model APIs and a well-designed harness can now hold a discipline that used to need a team. The engineering work — the real work — is making sure the discipline survives the automation instead of being flattened by it. Every architecture decision I publish, including the ones that failed, is in service of that argument.
In practice that means I optimize for legibility over spectacle: systems a reviewer can open and read, decisions with named trade-offs, numbers reported at the sample size they were measured on. The kind of engineering you can hand to someone.