Production AI, not proofs of concept

Most AI projects die somewhere between the demo that impressed everyone and the system that has to answer correctly at 2am on a Tuesday. The gap is rarely the model — it is retrieval quality, evaluation, permissions, cost control, failure handling and the unglamorous integration work with systems you already run.

How I work on AI projects

I come at AI from fourteen years of building and operating production systems rather than from research. That shapes the priorities: what gets measured, what gets logged, what happens when a call times out, and who is accountable when an answer is wrong. An assistant that is right 95% of the time and silently confident the other 5% is a liability, not a feature.

Start with the decision, not the model

The first question is never which model to use. It is which decision or task is costing you time, and whether a language model is genuinely the right tool for it. Plenty of problems presented as AI problems are search problems, data quality problems, or process problems wearing a costume — and solving them that way is cheaper and more reliable. I will tell you when that is the case.

Ground everything in your own content

For anything customer- or staff-facing, the system answers from your approved documents and data, with citations back to the source. That means real work on ingestion, chunking, embeddings, hybrid retrieval and re-ranking — the parts that determine answer quality far more than model choice does. It also means the system can decline to answer, which is a feature worth designing for deliberately.

Respect the permissions you already have

If a document is restricted in your CMS, intranet or file store, it stays restricted in the assistant. Retrieval is filtered by the requesting user's access, not applied as a cosmetic layer afterwards. This is the most common serious gap I find in AI pilots built without platform experience, and it is much harder to retrofit than to design in.

Evaluate before and after launch

Every engagement includes a test set of real questions with known-good answers, scored automatically on each change. Without it there is no way to know whether a prompt tweak, a model upgrade or a new document set made things better or worse — you are just moving things around and hoping. Monitoring, cost tracking and trace logging continue after launch.

Integrate with what you already run

Most of this work lands inside an existing platform: Drupal, WordPress, a SaaS application, an internal tool. Having spent over a decade in those codebases means the AI layer fits the architecture instead of sitting awkwardly beside it — proper modules and plugins, cache behaviour, queue workers, deployment and rollback.

Have a project in mind?

Describe the problem in your own words — I will tell you what I would actually build, and what I would not.

Start a conversation