Where we deleted the AI: five times determinism was the right answer

There is a version of this company that would never publish this article. It would be bad for business to admit that the thing we sell is sometimes the wrong answer. But the thing we actually sell is judgement about where AI belongs, and that judgement is worth nothing if we only ever say yes.

So here are five places in our own production systems where we removed a model and put plain code in its place. The rule we now apply before building anything is the same one behind our agent or automation tool. Each one was working. Each one got better when the AI came out.

1. The nightly check that researched the wrong country

We run a private platform for group events. One of its jobs is a nightly scan that looks for gaps in the plan: a night with no venue, a guest with no arrival time, a booking with no deposit recorded.

The first version asked a model to look at the plan and suggest what was missing. It was clever, and clever was the problem: a scheduled check for missing facts needs to be right and cheap, not creative. A model in that seat can only add ways to be wrong, and a wrong suggestion at five in the morning wastes the one thing the scan exists to protect, the organiser's attention.

The fix was to delete the model call entirely. The scan is now a list of rules: for each night, is there a venue; for each guest, is there a flight; for each booking, is there a deposit. It runs in milliseconds, it costs nothing, and it cannot invent anything.

The lesson, which we now write into every scope: a scheduled check for missing facts needs to be right and cheap, not clever. If the question has a yes-or-no answer that the database already holds, there is no job for a model.

2. The daily bulletin that could not be allowed to improvise

The same platform sends guests a short message each morning: what is on today, where, when, what to wear. An obvious place for a model to write a warm, natural paragraph.

We built it without one. The bulletin is assembled from database rows by code. The event name comes from the event row. The time comes from the time column. The dress note comes from the dress field. If a field is empty, the line is left out.

Why? Because twenty people were going to read that message at seven in the morning and act on it. If a model rounded "doors at 23:30" to "late evening", or softened "formal" to "smart", someone would turn up wrong. A model cannot be told "never paraphrase a time" with certainty. Code can.

The principle generalises: when the output is an instruction someone will follow, compose it from facts, not prose.

3. The moved event time that is updated by substitution

When an organiser moves an event from nine to ten, every piece of text that mentions nine has to change. The description, the reminder, the guest-facing note.

The tempting approach is to ask a model to rewrite the text with the new time. We did the boring thing instead. The system stores the time as a value, renders it into text with a template, and when the value changes, the text is regenerated by substitution. No model in the path.

This sounds trivial, and it is. That is the point. It was a decision to not reach for the clever tool, made once, and it has removed an entire class of bugs in which a regenerated sentence quietly drops a detail that was in the original.

4. The counselling practice with zero client-facing AI

We built the intake system for a private psychology practice. Screening questionnaires, scored reports, follow-up sequences, a crisis page with real helpline numbers.

There is no AI anywhere a client can meet it. No chatbot. No model reading a questionnaire and summarising the person. No triage by a model.

The screening instruments are scored by arithmetic against the published clinical cutoffs, because that is what the instruments are for. Every clinical screening result carries a non-diagnosis notice, because software that sounds like a clinician is a liability. The highest-risk question is stored in its own database column so it can never be averaged away inside a score.

The only AI in the whole project writes blog posts, in a separate pipeline, and even that runs through a validator that rejects any statistic without a source link and forces a crisis link onto any article that touches crisis terms.

We put this case on our website because it is the clearest example of the rule we build by. Some domains get no AI at all where a person could meet it, and knowing which domains those are is most of the skill.

5. The group dashboard where the model extracts and a person ratifies

We built a marketing dashboard for a group with nine operating companies. It pulls from Google Analytics, Google Ads, Meta, LinkedIn and X, snapshots the numbers every day, and produces a weekly memo for the board.

The document-reading step makes exactly one call to a model. It reads contract documents and proposes the dates and values it finds. Its output is always marked as proposed, a human ratifies it with one click, and underneath it sits a plain rules parser that produces the same fields without the model at all. The model's answer is laid over the parser's answer, so the reliable fields can never be made worse.

Everything else is code. The numbers, the comparisons, the rankings, the pacing against budget. And in the engine this work grew into, every figure in a sentence the model writes has to already exist in the data the code computed. If the model writes a number that is not in that set, the sentence is thrown away and a template is used instead.

We call this the rule: code computes the numbers, the model only narrates or extracts, and the boundary is enforced by a test. The group dashboard is where we learned to write it down.

What the five have in common

None of these decisions came from distrust of the technology. We use models every day and we build agents that run in production for months. The decisions came from asking one question each time:

Does this step need judgement, or does it need to be right?

Judgement is what models are for. Drafting a reply, summarising a document, suggesting a venue, writing a sentence around a number. Being right is what code is for. Checking a fact, composing an instruction, updating a time, scoring a questionnaire, computing a total.

Most AI projects that fail in production fail because they put a model where a rule belonged. The demo worked because nobody was checking. The product failed because someone was.

What this means if you are buying

Ask any vendor, including us, three questions:

1. Where in this system does a model produce a number, a time, a price or a name, and what checks it?
2. Which parts of this system have you deliberately kept AI out of, and why?
3. What happens when the model is wrong? Not if. When.

A vendor who cannot answer the second question has never taken AI out of anything. That usually means they have never run anything long enough to need to.

We have. Five times. We expect the number to go up.