Designing for the wrong answer.

Every AI demo works. That isn't a compliment — it's a design choice. The demo path is the path the presenter has already verified. The question comes in as planned, the model responds correctly, and somewhere in the meeting room someone makes a note to put this on the proposal.

Production is the answer to a different question: what happens when the inquiry isn't the one from the demo? What happens when the model is wrong, when the API times out, when someone asks something that should go to a human, when the answer it gives is fluent and plausible and completely made up? Those cases happen in production. The engineering is designing for them, not around them.

Language models produce wrong answers with the same confident, polished tone as correct ones. There is no built-in flag for uncertainty, no natural hesitation. A model that hallucinates a fact formats it in exactly the same way it would format a fact it has right. This is the property that makes AI useful — fluency — and the same property that makes it dangerous under a client's brand without the right infrastructure around it.

The engineering response is to build the confidence layer the model lacks: routing logic that detects low-confidence responses and diverts them before they reach the customer; topic guards that refuse to answer questions outside the defined scope; validation passes that check outputs against known facts before they're displayed. None of this is magic. It's defensive engineering applied to a new kind of input.

The single most useful question in production AI design is: if this output is wrong, how expensive is it to fix? Displaying information on a screen is cheap — the user can refresh, the operator can update. Sending an email is not. Processing a payment is not. Posting publicly is not. The category the output falls into determines everything about how the system should handle it.

We call this the reversibility test, and it's the first question we apply to every AI feature in scope. Irreversible actions — anything that writes to the world rather than reads from it — get a gate. Reversible outputs get fast paths. The threshold between them isn't always obvious, and getting it wrong is how AI projects become the war story an agency tells about why they don't do AI anymore.

A human gate isn't a vague promise to add a review step. It's a concrete mechanism: the model drafts; something else approves. That something else might be a human, a rule, a confidence threshold, or a combination. An events system we run uses AI to draft customer communications, but nothing sends until an operator or an automated rule clears it. The model works at scale; the gate carries the liability.

The gate also sets the floor for what the AI system costs in human time. A gate that requires review on every message isn't automation — it's a proofreader with a fancier input. Good gate design identifies the operations that can safely run automatically, and reserves human attention for the ones where it genuinely adds protection. That calibration is where most of the interesting engineering lives.

When something goes wrong — and it will, in any system at scale — the trail is what protects the agency. What did the model output? What was the confidence score? Which human, if any, approved it? What did the system do next? Without this, the post-mortem is a guess, the client conversation is adversarial, and the agency absorbs blame with no evidence.

The audit trail is also what makes AI trustworthy to clients who are rightfully sceptical. A system that can show every decision it made, and why, is a system you can explain to a board. For anything in a regulated space, that isn't a nice-to-have — it's the table stake.

The agencies that get burned by AI projects aren't usually burned by bad models. They're burned by systems that had no answer for what happens when things go wrong. The model, the prompt, the product — all of that matters. The failure modes, the gates, the audit trail — those are what make it safe to put under a client's brand.

If you have an AI brief and you're not sure whether the proposed approach is production-ready, send it over. The first thing we'll do is apply the reversibility test.