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 embedded as a component inside production software, running 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 is a component, not a product. It reads and judges; 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?


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.


Who it’s 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.

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. More about me.


Deciding what to do about AI? Get in touch.