Technical work
Engineering intelligent systems
Four areas that keep overlapping in practice. An agent needs retrieval; retrieval needs evaluation; evaluation needs infrastructure; and none of it counts until it survives production.
Applied AI
Systems built on language models that have to be right, and have to keep being right after they ship.
- Large language models
- AI agents
- RAG and retrieval systems
- Evaluation systems
- AI orchestration
- Structured extraction
- Reasoning pipelines
- Production AI systems
Machine Learning
The modelling work underneath the product — and the measurement that keeps it honest.
- Model development
- Data pipelines
- Prediction systems
- Ranking systems
- Evaluation
- ML experimentation
Computer Vision
Reading sport from video: who, where, what happened, and in what order.
- Object detection
- Player tracking
- Ball tracking
- Sports video analysis
- Movement analysis
- Temporal video understanding
Software & Infrastructure
The unglamorous half that decides whether any of the above survives contact with users.
- Backend systems
- APIs
- Cloud infrastructure
- Production deployment
- Data systems
- Scalable AI architecture
How I work
Principles I keep returning to
Not a methodology. Just the things that have repeatedly turned out to matter more than the model choice.
Evaluation before ambition
The first thing I build for any AI system is the way to tell whether it is working. Without that, every subsequent decision is taste. With it, you can be aggressive — you'll know immediately when you've broken something.
Ground every claim
In high-stakes domains, an answer without a traceable source is a liability. Retrieval isn't a performance optimisation; it's what makes the output checkable by the person who has to act on it.
Design for the failure mode
The useful question about a model isn't how good it is on average, it's how it fails: silently or loudly, recoverably or not. Systems that fail loudly and recoverably can be shipped into serious domains. Systems that fail silently cannot.
Production is the point
Architecture and experimentation are the interesting part of the work; deployment is the part that decides whether it mattered. Latency, cost, reliability and monitoring are not someone else's problem downstream of the model.
Domain understanding is leverage
Knowing what a pattern means on a squash court, or what a clinician actually needs from a drug question, changes what you build. The best modelling decisions I've made came from understanding the domain, not the framework.
Marginal gains compound
A habit from sport. Most systems don't improve through one breakthrough; they improve through a long series of small, measured changes that each look too minor to bother with.
Domains
I've applied the same toolkit to three domains that look unrelated and aren't.
Healthcare information. Dense, fragmented, frequently contested, and read by people making consequential decisions. The engineering problem is grounding and verification, not fluency.
Sports video. Continuous, noisy, and meaningful only in sequence. A detection tells you nothing; a rally tells you everything. The engineering problem is recovering structure over time.
Operational data. Sparse and messy, with users who need a decision rather than a distribution. The engineering problem is making a prediction actionable.
Underneath all three: extract structure from unstructured input, measure whether the structure is correct, and put it somewhere a person can act on it.
Contact
Building something at the intersection of AI and the real world?
I'm glad to hear from engineers, founders, researchers, coaches and athletes — and from anyone working on AI systems that have to be right rather than merely impressive.