Understand first, then build
Most AI work fails at the seams — between departments, between tools, between what a process is documented to be and what people actually do. The method below is built around finding those seams before anything is implemented.
Understand the actual process
Interviews with the people doing the work, a walk through the real artefacts, and a map of where information enters, stalls and gets re-keyed. This step regularly changes what the engagement turns out to be about.
Decide what deserves automation
Not every step should be automated, and some should be removed rather than accelerated. You get an explicit recommendation on what to change, what to leave alone, and the reasoning behind both.
Design the architecture
A written target design: data flow, system boundaries, where a human reviews or approves, how failures surface, and what the operational cost looks like once it's running.
Build against real cases
Implementation is tested on your own historical work, not synthetic examples. Where an agent's output can't be verified against something real, it doesn't ship.
Hand over so it stays yours
Documentation, operating instructions and a working session with the people who'll run it. The goal is that the system survives without me — with ongoing support available if you'd rather it didn't have to.
Principles I work by
- No automation without a person accountable for the output.Every automated step has a named owner and a way to inspect what it did.
- Plain reporting. If something isn't working, or if a piece of the plan turns out to be a bad idea, you hear it early rather than at handover.
- Your data stays yours. Access is scoped to what the engagement needs, agreed in writing, and revoked when the work ends.
- Boring where it counts. Operational foundations — identity, permissions, mail, backups — get conventional, well-trodden solutions. Novelty is reserved for the places that actually reward it.