AI Engineering & Architecture

Most AI initiatives do not fail because the model is weak. They fail because nobody designed the system around the model: how context is assembled and budgeted, how knowledge is retrieved and kept fresh, how outputs are checked, and how the whole thing runs when the demo laptop is closed.

Why this matters now

Large language models are now a commodity. The differentiator is engineering discipline. A well-built retrieval pipeline on a mid-sized open model routinely outperforms a frontier model fed with a badly assembled context window — at a fraction of the cost and with data that never leaves your infrastructure. Tokenization, chunking strategy, metadata design and context ordering are not implementation details; they are the architecture.

The same is true for agents. Tool-using systems can automate real work, but only when their scope, permissions, memory and failure modes are designed explicitly. An agent that “mostly works” is a liability in a regulated environment.

How I approach it

I start with your data and your constraints, not with a vendor’s reference architecture. That means measuring: token distributions across your documents, retrieval quality on questions your people actually ask, latency and cost per task under realistic load. From there we choose the smallest architecture that meets the requirement — often simpler than what the market suggests.

Every system I build ships with an evaluation harness. It is the only way to know whether a prompt change, a model swap or a new data source made things better or worse, and it is the artefact your risk function will ask for.

Where it typically starts

Engagements usually begin with a two- to four-week assessment of an existing pilot or a planned use case: what would it take to make this production-grade, sovereign and measurable? The answer is a decision memo with an architecture, a budget and a plan — which we can then build together.