Engagements organised around outcomes, not technologies

Most businesses do not have an AI problem. They have five or six process problems, one of which happens to be a good fit for a model — and no reliable way to tell which one.

I spend time with the people doing the work and map how it actually runs, including the manual steps that only exist in someone’s head and the spreadsheet that quietly holds the whole thing together. Then I sort every opportunity I can see into automation, integration, AI, process redesign or data work, and rank them on impact against effort.

You get the ones worth doing, the ones that are not, and a recommended first move small enough to prove out before you commit to anything larger. If the honest answer is that nothing here justifies the spend right now, that is what the assessment will say.

Every team has work that quietly eats hours: copying data between applications, sending the same status update, chasing an approval, assembling the same report every Monday. It is rarely difficult work. It is just work that nobody has had time to take away.

I build automations that watch for the trigger, do the intermediate steps, put the result where it belongs and tell the right person — with logging and alerting, so when something does go wrong you find out from the system rather than from a customer.

Much of this needs no AI at all, which is usually the point. A well-built workflow is cheaper to run, easier to reason about and far more predictable than a model, and I would rather spend your budget on the parts that genuinely need one.

A chatbot answers a question. An agent finishes a job. Given a goal, it decides what to do next, runs that step, looks at the result and decides again — calling search, databases, internal APIs and whatever else the task needs along the way.

That is genuinely useful, and it is also where most AI projects go wrong. An agent with real tool access and no supervision is a system that can take real actions you did not intend. I design them the way I would design any other production system: bounded permissions, retries, timeouts, logging, and explicit checkpoints where a person approves the moves that would be expensive to get wrong.

The result is something that runs unattended where unattended is safe, and asks where it is not.

Most organisations are sitting on a mountain of material — policies, contracts, manuals, support history, wikis — that contains the answers but cannot be read at the speed anyone needs them.

Retrieval-augmented generation turns that pile into something you can ask. Documents are split, embedded and stored in a vector index; a question retrieves the passages that actually bear on it; the model answers from those passages and cites them. When the source material does not support an answer, a well-built system says so instead of inventing one.

The hard part is not wiring it up — it is retrieval quality. How documents are chunked, what metadata rides along, how results are re-ranked, and how you evaluate whether answers are getting better or just getting different. That is the part I spend the time on, because it is the part that decides whether people trust the thing enough to keep using it.

AI that lives in its own tab gets used for a fortnight. AI that appears inside the tool someone already has open gets used for years.

I connect models and automations to the systems a business actually runs on — customer platforms, internal databases, operational tooling, messaging channels, third-party APIs — so a result arrives where the decision is made rather than somewhere it has to be fetched from.

This is unglamorous work with a lot of edge cases: authentication, rate limits, retries, partial failure, schema drift, and what the system should do when the other end is simply down. Doing it properly is the difference between an integration that quietly runs for years and one that everybody has learned to work around.

AI and automation both depend on being able to get at your data and act on your systems. When that is hard, every project on top costs more than it should — and quite often the honest first recommendation is to fix the foundation rather than build another floor on it.

I design and modernise the layer underneath: service boundaries, data flow, queues and events, storage choices, API design, and the integration points that decide how expensive the next five years of work will be. Fourteen years of building and leading this work means I have seen how these decisions age, which is the only thing that really qualifies anyone to make them.

Where a rewrite is not justified — which is most of the time — the work is incremental: carve off what is blocking you, leave the rest running, and keep the business operating throughout.