Everyone has heard the stories. The pilot that never left the meeting room. The agent that ran up a bill nobody could explain. 95% of enterprise AI pilots delivering nothing to the bottom line. What almost nobody can tell you is why it keeps happening. Here is why. AI tore up the operating playbook, and most companies are responding by writing AI in as one more chapter of the old one. The old playbook cannot hold it. It needs rewriting from scratch, and that is what I am doing: in public, one working paper at a time.
One weekend in February, an agent I built hit its iteration cap reasoning over schedules it claimed to have checked. It had checked nothing. The bill was £60 in tokens: ten per cent of the monthly budget, spent on confident fabrication. The model was not the problem. The memory layer had dropped the evidence, and the model filled the gap the way models do. The fix was not a better model. It was a layer. That failure, and the four versions of architecture it forced, are documented in the research.
Every failed rollout you have heard about passed its demo. A demo is a clean room: curated data, no volume, no deadline, nobody off sick. Production is a Tuesday night, ten thousand orders, and one part that matters more than all the rest. The gap between the two is where the money goes, and I have stood in it. Two architectures, same starting workflow, different consequences once volume, cost, and time start applying pressure. Here is the difference.
A wrapper around a frontier model, prompted into a workflow it was never trained for. Plausible-sounding output. Brittle in production.
Task-specific small language models embedded as infrastructure. Right-sized to the problem. Composable across the stack.
Lookups, filters, constraint checks, arithmetic. Rules that return the same answer on the thousandth call as the first. A model settles that work by reasoning, at GPU prices, and might not settle it the same way twice. Plain code settles it for a fraction of a penny, the same way every time. A model is for judgement: the one decision in the workflow no rule can hold. I draw that line before anything gets built. Most consultancies will sell you more AI. I will show you how little you need.
I sit inside your operation and map where the judgement actually lives: what should be plain code, what deserves a model, what should not be automated at all. You leave with a costed roadmap whether or not you hire me to build it. No free demo. A demo is a clean room, and your operation is not one.
Book the diagnosis →The EU AI Act's enforcement provisions arrive on 2026-08-02. This architecture assumes the regulation from the first decision. Your data stays in your jurisdiction. The audit trail is yours end to end. Nothing is handed to a third party to reason over, and nothing you own trains someone else's model. The industry defaults to the cloud because the industry built the cloud; for work this bounded, you are not obliged to follow it there. The model is small enough to run on hardware you own.
That is the direction the architecture commits to, stated plainly: I have not shipped a self-hosted deployment yet, and I will not claim one until I have.
Two working papers so far. The first names the architecture: why the model should be the smallest part of your stack, and the five primitives that make it so. The second follows the money down to the silicon: why where a computation runs fixes what it costs, and why the industry is hammering screws. Both flag what is proven and what is not, in the text, as they go. That is a standard marketing copy does not hold itself to. It is the standard here.
FIG P.01 · Why the Model Should Be the Smallest Part of Your Stack →
THK Digital is one person. The research is public, the failures are documented, and everything that ships carries my name. When a system I designed runs in your stack, "Tom was behind this" is the warranty.