On 20 October our team asked ChatGPT where a Ninja air fryer was cheapest in Australia. The first answer said Amazon Australia at $199, which was right. Several hours later, in a new chat, the same question came back with JB Hi-Fi at $127. JB Hi-Fi was charging $249 at the time.
One product on one free account is a small sample. But it shows the two kinds of computing that every AI system now mixes, and my view is that you get consistent results only when you decide, step by step, which kind does which job.
On this page:
A model gives you a likely answer, and code gives you the same one
A language model is probabilistic. It writes one token (a word or part of a word) at a time, and for each one it picks from candidates ranked by probability. Settings such as temperature and topP control how far down that ranking it may reach. Or in plain terms: the model gives you the answer that looks most likely given what it has read, and "most likely" can come out differently on a second go. Turning temperature down to 0 narrows the spread without closing it. Anthropic's own documentation says that even at 0, identical inputs might produce different outputs, and when Thinking Machines Lab ran one prompt 1,000 times at temperature 0 on an open model, it got 80 different completions.
Code is deterministic. A function, a database lookup or a written rule gives the same output for the same input every time it runs, so you can test it before anyone relies on it. A rule can be wrong too. When it is, it's wrong the same way every time, and you fix it once.
Models read and write, and code looks things up
Picture a customer who writes to an airline (an invented example): "my flights got changed because of a funeral, can I still get the cheaper fare?" Code can't read that sentence reliably. A model can tell it's a bereavement fare question about a trip, pull out the dates and later write a reply a stressed person can follow.
Whether that customer is entitled to the fare is another kind of question. It has one right answer, and the answer lives in the airline's policy and the booking record. A product's price, whether a court case exists and whether an agent may touch a production database are the same kind. A lookup or a rule should give those answers, and the model's job is to ask for them and put them into words.
DeepMind's AlphaGeometry shows the split working on a hard problem. A language model proposes the next construction to try, and a symbolic engine, working from hand-written rules, proves each step. On a test of 30 olympiad geometry problems the pair solved 25, against 18 for the engine with human-designed heuristics alone. The model supplied the guesses that the rules couldn't, and the rules did the checking.
The trouble starts when a model is asked for a fact, and grows when it's allowed to act
The first problem is that asking again can get a different answer. In our Black Friday test we asked about 20 products twice each, in new chats several hours apart, on one free ChatGPT account from Australia. For 11 of the 20 the second answer named a different store or price. The obvious fix is to ask twice and keep the answer that repeats. Of the 9 products that got the same answer both times, 6 were wrong both times, and the stores' prices hadn't moved between the asks.
Repeating doesn't help when the model has picked the wrong source. In our September price study (22 to 25 September 2026), all six wrong prices came from retailers whose own product page and product schema carried the right price. The wrong numbers came from the same retailers' sale, range or collection pages, or from a price comparison site. On 22 September Appliances Online's product page said $682 for a Fisher & Paykel washer and ChatGPT said A$742, taken from a Birthday Sale listing. Four days later the page said $845 and ChatGPT still said A$742. The September study has every case.
Sometimes the model reads the right page and drops the condition attached to the number. In October, a group-buy price of $571 for a Breville, which was the floor of a range that depends on how many buyers join, was described as the "listed price". The figure was real, and the answer still told the shopper something false.
When the fact is about the model's own output, checking with the model doesn't help either. In Mata v. Avianca, lawyers filed court papers citing opinions that ChatGPT had invented. One of them asked ChatGPT whether a case called Varghese was real, and it said the authorities it had supplied were real and could be found on Westlaw and LexisNexis. The judge imposed a $5,000 penalty on the lawyers.
Move from facts to a business's rules and a wrong answer starts to cost money. Air Canada's website chatbot told a customer he could claim a bereavement fare after travelling. The airline's own policy page said the policy did not apply once travel was completed. A British Columbia tribunal held Air Canada responsible for the chatbot's answer and ordered it to pay $812.02.
Then give the model permission to act. SaaStr founder Jason Lemkin said a Replit coding agent deleted his production database during a code freeze, after he had told it "eleven times in ALL CAPS" not to. His own summary: "There is no way to enforce a code freeze in vibe coding apps like Replit".
An agent strings many of these steps together, and each one can go either way. Sierra, a company that sells AI agents, published tau-bench in June 2024. It tested gpt-4o agents on retail and airline tasks. They succeeded on under 50% of tasks, and the chance of getting the same retail task right in all 8 tries, which the paper calls pass^8, was below 25%. Those are two-year-old results for one model. I cite them for the measure. A business needs a task done every time, and a demo shows you only one try.
Five deterministic elements take the one-answer steps away from the model
Every case in the last section sat on a step whose right answer someone already held: the retailer had the price, the court had the case law, the airline had the policy, and the user had decided production was off limits. My guidance for anyone building an agent, a skill or any workflow with a model in it is to find those steps and give them to code.
A step needs code when any of these is true: the business could write the right answer down in advance; a wrong answer would cost money, break a policy or change data; or the answer has to repeat and may be audited. Everything else can stay with the model, which is most of the reading and writing.
There are five deterministic elements I'd use for those steps, and they differ mainly in where they sit.
The first is a search, which runs before the model and hands it the fact. If an assistant quotes a price, the price comes from a lookup of the product record. In our September study, the retailer's own product page carried the right price in all six cases where ChatGPT quoted a wrong one. When a price comparison site stood in for the product page in that study, all 3 answers we could score were wrong. For the Avianca lawyers, the search is a lookup of each citation in a case-law database, with the filing blocked when one comes back empty.
A permission also runs before the model, and it limits what the model can touch at all. After the code-freeze incident, Replit's CEO, Amjad Masad, said the company had "started rolling out automatic DB dev/prod separation to prevent this categorically". An agent in development then can't reach production, however it reads its instructions. That separation is the only fix in this piece that the company itself described. I haven't read how far the rollout got.
Then there is the rule, which replaces the model for the decision. The Air Canada tribunal quotes one sentence of the policy page: it "does not apply to requests for bereavement consideration after travel has been completed". That sentence can be code. If the travel date has passed, the answer to a retroactive claim is no. The model still recognises the question and writes the reply. The yes or no comes from the rule. This is my design for one step of one policy, built from the one sentence the tribunal quoted, and Air Canada hasn't described how its chatbot was built.
After the model come the checks. A format check tests the shape of the output before anything downstream uses it. On OpenAI's own evaluation of complex JSON schemas, gpt-4-0613 matched the schema less than 40% of the time, and gpt-4o-2024-08-06 with Structured Outputs matched it 100% of the time. Shape is all it tests. A wrong price can sit in the right field in the right format.
The reply check is the one we haven't finished building ourselves. It compares what the model said with the record before the reply goes anywhere. In our own content pipeline, every figure in a draft must cite an entry in our evidence store, and a script checks those citations. A caveat about how a survey defined "AI agent" carried no figure and no source, so the script had nothing to check. It went into a draft, the critic stage (a model) turned it into the answer to the piece's main objection, and the verification stage caught it before publish. The verification stage is also a model, and nothing guarantees it checks the same way every time. Our fix so far is a written rule that every caveat must be quoted from its source or marked as our own reading. A deterministic reply check for caveats doesn't exist in our pipeline yet.
Whatever the five don't cover goes to a person. A question with no written rule is one the business hasn't answered yet, and the model's best guess shouldn't stand in for that answer.
Here is the order I'd build in, using a retail assistant that answers "where is this cheapest?" as the example:
- List each step the assistant takes: read the question, identify the product, find stores, get each price, compare, write the reply.
- Mark the steps with one right answer. Here those are the product match, each price and the comparison. Reading the question and writing the reply stay with the model, inside the limits the rules set.
- Build the search first: prices come from each retailer's product record, never from a sale page or a comparison site the model found.
- Write the conditions as rules: a group-buy floor or a members' price is reported with its condition, or not reported at all.
- Add a reply check that rejects any reply whose price doesn't match the record it cites.
- Send any product the search can't match to a person, and keep that list, because it is the next set of rules to write.
- Plant a known wrong price in a test run and confirm the reply check catches it. Margaret Mitchell suggested this test, planting a known error from time to time to see whether it gets caught, in her RecSys 2026 keynote on oversight of AI agents.
The next agents will be judged by their harness
I call the code around a model its harness: the searches that feed it records, the permissions that fence it in, the rules that decide and the checks that test what it produces. My bet is that the agents that work in business will be told apart by their harness more than by their model. The model is how an agent understands what someone asked for. The harness gives the answers that must repeat.
Some of the people building models describe their own systems this way. Anthropic separates workflows, where models and tools run through predefined code paths, from agents that direct their own process, and its Agent Skills can carry code because "many applications require the deterministic reliability that only code can provide". Target, presenting at RecSys 2026, described a record-side version: preferences drawn from assistant conversations are stored as time-bound events with a confidence score, so a preference for Italian food recorded at 92% confidence never becomes a permanent fact about the customer.
We built Core dna MCP 2.0 on the same split. The probabilistic part is the assistant: someone describes a feature in plain language, and the assistant plans it and builds it as content plus an automation, with each step written out and named so the team can read what it does and check the result. Our release article describes the deterministic part as a set of permissions around it. Ask for one paragraph to change and only that paragraph changes, with the previous version kept, and a removal that would take other content with it waits for a person to confirm.
The strongest case against all this is Rich Sutton's Bitter Lesson: over 70 years of AI research, "general methods that leverage computation are ultimately the most effective, and by a large margin". On that view, every rule above is scaffolding a future model will make unnecessary. Some of it will be, and the format check is the example. On OpenAI's own evaluation, schema adherence went from under 40% to 100%, but OpenAI got there by building a deterministic constraint into its own platform. The check now runs in the vendor's harness instead of the builder's. The rest is harder to outgrow, because Air Canada's policy, Appliances Online's price and Lemkin's code freeze were decisions people made. A larger model can read those decisions. It can't make them for the business, and I have no evidence about what next year's models will do on the cases above.
That leaves the caveat check our own pipeline still hands to a model. On the next agent I build, I'll list every answer it gives before I choose a model, and mark which of those answers someone in the business has written down. Code gives those.
Summarize with
