Where this starts
My first job was designing and maintaining DCS and SCADA systems — the control layer of industrial plant. You sit in front of a wall of readings, and the readings are correct. Every sensor is reporting what it was asked to report, inside tolerance, and the log is clean.
The thing nobody teaches you quickly is that a correct reading and a correct plant are different claims. A transmitter can be perfectly calibrated and mounted on the wrong side of a valve. The instrumentation says nominal because the instrumentation was asked a narrower question than the one that mattered. You learn to distrust a green board, and to ask what the board is not in a position to know.
That is the habit I brought to enterprise AI, and it is most of what this publication is. A model passes its evaluation. An agent completes its task. The pilot reports success. Each instrument is answering the question it was given, and the programme can still be heading somewhere nobody designed it to go, because the question that mattered was a wider one.
What I do, and what this covers
By day I am a technical architect, working on Agentforce and Data 360. Before that I spent a decade designing enterprise platforms: the data, integration and access models that everything else, AI included, ends up sitting on.
Out of True is wider than that job. It covers the models and what their new capabilities change, agents and the applications they live inside, the data and infrastructure underneath, and the economics and operating models that decide whether any of it is worth running. My architectural experience is the vantage point, not the boundary.
The pieces are written for people already doing this work: architects, engineers, technical leaders and the people who fund them. They are positions and analysis, not tutorials. Where I am arguing, I say so, and I set out the strongest reading against me.
Why “Out of True”
A structure is out of true when it no longer sits square to its reference line. Still standing, still passing inspection, but carrying load along a line it was not designed for. The work is measuring the gap and deciding what it means.
Enterprise AI is full of gaps worth measuring: between what a capability is said to do and what it has been shown to do, between how a system was designed and how it behaves, between where the budget goes and where the value turns up. Sometimes the gap is a warning. Often it is an opening.
How this site is written
Every technical claim is either rebuilt in a personal development environment, outside work, or rests on a public source a reader can check. If it can be neither, it does not publish. No client is named. No employer system is described. Where an example is assembled from several situations, the piece says so.
I work inside the Salesforce platform every day, and that is a fact you should weigh rather than ignore. It sharpens the examples and it biases the instincts, and I would rather say so than perform a neutrality I do not have. Nothing here is reviewed, approved or requested by my employer, and nothing here is written on anyone’s behalf.
What I am not
Not a model researcher. I write about models from the point where they meet enterprise systems, not from inside a lab. Not available for client or advisory work; I am employed full time, and that is a sequencing decision rather than a permanent one.
Not vendor-neutral. I work inside one platform family daily, and my living depends on it. Read accordingly, and tell me when you think it is showing.
Read the full disclosure →