Principal AI Solutions Architect with twenty years of software systems design. I consult independently on AI architecture, vendor evaluation, and technical training.
I do not sell AI as a general-purpose solution. Where it is the wrong tool for a given problem, I say so, and I document why.
I can say that because I do not sell a platform, a licence, or a seat. Assessment, architecture and training are the work; there is no product underneath the advice that the advice needs to protect.
The part of this work that decides whether a system survives is the least visible: the measurement, the checking, and the decision about what the model is allowed to do on its own. It is unglamorous, it does not demonstrate well, and it is where most of the value and nearly all of the risk sit. That is the part I work on, and the reason this practice exists.
I have worked as a software architect and engineer for over twenty years, across logistics, healthcare, ecommerce, financial services, and insurance. The work has included graph-based routing engines, real-time prediction systems, healthcare rules engines, and ecommerce platforms.
I began working with LLMs approximately two years ago — as a systems architect evaluating where the technology fits inside production software, not as a researcher or data scientist. My initial position was skeptical, informed by prior technology cycles in which capability was consistently overstated relative to production reality.
The assessment I arrived at is narrower than the common framing on either side. LLMs are effective in specific, well-defined problem spaces and unreliable in ways that vendors tend not to disclose and buyers tend not to know to ask about. In most implementations, the determining factor is not the model. It is the architecture around it — integration design, evaluation methodology, and how the system handles the cases where the model is wrong.
I arrived at that the slow way. Most of what I know about these systems I learned by getting it wrong first: a checking layer with a bug in it, which meant it reported everything as fine; a headline accuracy figure that turned out to be hiding a third of the cases; a result that reversed the second time it was run. None of that is exotic. It is what building this actually involves, and it is why the failures I use as examples are my own.
Most of what makes these systems work is not new. It is the same estimation, testing and delivery discipline as any software project, applied around one component that behaves unusually.
I am currently a Principal AI Solutions Architect in a Fortune 500 R&D group, where I build AI systems end to end and on my own. Through my independent practice I provide assessment, architecture, proof-of-concept development, and technical training: evaluating AI decisions before the budget is committed, and helping technical teams build systems that hold up in production after it is.
The systems I build take the grind out of a job rather than the job out of a building. The repetitive, high-volume, low-judgement work is what a machine should have; what remains is the part experienced people are actually good at. Whether that changes headcount is a decision for a business to make, and not something I would sell as the return.