AI solutions architecture and advisory. I evaluate, design, and build AI systems, and I tell you when you shouldn’t.
Twenty years building enterprise software as an engineer and architect, now doing AI systems work inside a Fortune 500. Independent assessment, architecture, and technical talks for companies deciding what to do about AI.
How I think about it
Most companies are investing in the two lowest-return ways to use AI (a chat window on every desk, assistants for the developers) and have barely touched the one that pays the most: a model running as a component inside production software, unattended, at scale. It doesn’t get attention because it doesn’t demo well. It’s also where the return is.
The discipline behind it is easy to state and hard to do: the model reads, and the code decides. The model is a component, not a product — it reads and judges, and deterministic code decides, checks, and keeps the record. Every flag carries its evidence, and anything the system cannot verify routes to a person instead of passing silently.
That is what it means to control for model variance, and done right it takes an unstructured, manual process and makes it structured, scalable, and controllable. It is the opposite of handing the model the controls and hoping the guardrails hold. Before any of it, one question sorts the high-return work from the low-return work: can this process be boxed?
None of this is a new category with new rules. It’s software with one unusual component, and the same estimation, testing and delivery discipline that applies to everything else applies here — which is why the failures are recognisable and the fixes aren’t exotic.
Chasing a system that’s a hundred percent automated and a hundred percent accurate is chasing an asymptote. The last few percent costs more than everything before it, and buying it strips out exactly the work that keeps experienced people sharp. The prize is the ninety to ninety-five percent that’s pure grind: the same document, read the same way, ten thousand times. Take that, and let the exceptions reach a person who now has time for them.
What I do
Assess. Evaluate AI decisions before the budget is committed: proposal and vendor due diligence, readiness, architecture review. A straight answer, including when it’s “don’t.”
Architect & build. Design the systems and build the proofs of concept: deterministic-first, evaluated, cost-routed pipelines that hold up in production, past the point where a laptop demo breaks.
Train. Technical talks and workshops for leadership, operations, and engineering teams: from a 60-minute executive briefing, to a half-day operations workshop, to a full-day engineering intensive. See the catalog.
When you shouldn’t
I don’t sell a platform, a licence, or seats. That’s worth knowing before the rest of this section, because none of what follows costs me a sale.
A fair amount of what arrives labelled as an AI problem is a process problem, a data problem, or something ordinary software solved years ago. Where that’s the case I’ll say so, and write down why.
Most work pitched as agentic doesn’t need to be. The version that hands the model less control is usually cheaper, steadier, and far easier to audit, and I’ll tell you when that’s the one you want.
Some value is real and close to unprovable. I’ll tell you which side of that line a project sits on, because a framework that prices the unprovable half is selling you a number rather than measuring one.
And the return shows up as throughput, capacity you don’t have to hire for, lower cost per item, and less rework. Not as a smaller team. If someone is modelling it that way, they’re understating what you’d get.
Who it’s for
If you’re being asked to show what the AI spend bought and the only number you have is how many people are using it, that’s the conversation I’m built for.
Leadership teams weighing what to spend on AI, the operations and department leaders whose teams use AI for their daily work, and the engineering teams who have to build it. For events, there are conference cuts of two of these.
My depth is in document-heavy, regulated work (financial services, insurance, healthcare) where being wrong has consequences and “mostly works” isn’t good enough.
Why me
I’m a Principal AI Solutions Architect. In a Fortune 500 R&D group I build AI systems end to end, on my own, and take them past the point where the question is whether the capability works. The question that decides things is whether the output is consistent, controllable, and auditable enough for the business to stand behind — and answering it is what convinces stakeholders and subject-matter experts that a system is worth building. When a development team commits, I advise them. Independently, I do that same work for other companies. I came into this skeptical, having watched earlier technology cycles oversell what survived contact with production, and I still am. Most of what I know about how these systems fail, I learned by hitting it myself — which is why the examples I teach from are my own systems rather than a client’s. More about me.
Deciding what to do about AI? Get in touch.