**The agent built the stock report on Monday and every number matched. On Tuesday, on the same data, the numbers were different.** Owners usually call this "the AI is hallucinating", but it is a different failure, and not a rare one: by IBM Research's measurement published on 15 September, a strong agent with 77% average accuracy succeeds on every run for only 53% of tasks. Almost one task in four works only sometimes, and a bigger model does not fix it. Below we cover how a hallucination differs from inconsistency, where the 24-point gap comes from, how to check an AI answer in minutes, and how repeatable work is pinned in our product.

## What an AI hallucination is, in short

A hallucination is an answer that looks confident and plausible but rests on nothing. The model does not recall a fact; it completes the text so that it resembles a correct answer. A law number that does not exist, a citation to a nonexistent article, a counterparty's debt taken not from the ledger but "by feel": all of these are hallucinations.

The cause is not stupidity. At every step a language model picks the next word from a probability distribution. When one option is far more likely than the rest, the choice is stable. When several options are nearly tied, the model picks almost at random, and you get plausible text with no data behind it.

For a chatbot this is annoying. For an agent that walks into your accounting system and your marketplace account on its own and does the work without you, it becomes the question of whether you can hand it the task at all.

## Lying, erring, flipping: three different failures

An owner who sees a wrong number usually says "the AI is lying". It is more useful to separate three cases, because they are fixed differently.

| What happened | What it looks like | What helps |
|---|---|---|
| Hallucination | A confident answer with no source: a figure, date or name that is not in the data | Make the agent take data from the system, not from its head, and show where it came from |
| Error on data | The agent computed honestly, but on wrong or incomplete data: wrong export, wrong period | Check the input, not the output: which report it opened, for which dates |
| Inconsistency | Right today, wrong tomorrow, same task and same data | Pin the path: hand the repeatable part to a script and leave the model only the judgement |

The first two have been discussed for years. The third is barely discussed, although for recurring work it is the most dangerous. That is what this article is about.

## 77% accuracy hides a 24-point reliability gap

On 15 September 2026, IBM researchers published a study of a metric almost nobody publishes. Agent quality is usually measured like this: run a task set several times and average the success rate. That number sits on every leaderboard. It answers "how good is this agent on average".

A business owner asks a different question: if I give it this exact task again, will it succeed again? That needs a different metric: the share of tasks the agent solved on every run.

IBM's figures for a typical agent on GPT-4.1 and the AppWorld task set:

| Metric | Value |
|---|---|
| Average success across five runs | 77.4% |
| Tasks solved on all five runs | 53.0% |
| Gap between them | 24.4 points |
| Gap on hard tasks | about 30 points |

Almost a quarter of the tasks the agent solves only sometimes. The task does not change, the data does not change, the result does. The authors call this the consistency gap and stress that a bigger model does not fix it. Capability and consistency are separate axes; an agent can be smart and unreliable at the same time.

## Why the agent takes a different road

The mechanism is the same as in a hallucination, stretched across dozens of steps. Every decision the agent makes, which report to open, which filter to set, whether to retry after an error, is a draw from a probability distribution. Where the distribution is sharp, the choice comes out the same every time. Where it is flat, two options are nearly tied and the smallest noise flips the winner.

Noise is always there: floating-point rounding on GPUs, the order requests are batched on the server, small differences in context. For a sharp decision it changes nothing. For a flat one it flips the choice. A chain of thirty steps, each with a small chance of flipping, has a large chance that at least one run goes differently. That is where the 24 points come from.

An important consequence: the "answer deterministically" setting does not save you. It controls how the model draws from the distribution, not the shape of the distribution. A flat decision stays flat.

IBM proposes a diagnostic: take one recorded run and, at every decision point, ask the model for several continuations. Where they diverge is the weak spot. Turning those spots into written guidelines for the agent cut the gap from 24.4 to 12.0 points without losing average accuracy. Half the problem removed with text, not with a new model.

## What this means for a recurring task

For a one-off task, inconsistency is almost invisible: you get the answer, check it, accept it. For a task that runs every Monday it is different. Nobody will check every run by hand, otherwise why have an agent. So the run that took a different road stays unnoticed until someone makes a decision on it.

The practical conclusion: a recurring task must not be reinvented by the model each time. Part of it repeats verbatim: open the report, export the period, apply the formula. Part of it needs judgement: what to do about an anomaly, whom to write to, whether to hold the purchase. The first part must be pinned; the second is left to the model.

## How to check an AI answer before you trust it

Four checks that take minutes and catch all three kinds of failure.

1. **Ask where the number came from.** A good agent names the source: report, period, row. "According to my calculations" with no source is the signature of a hallucination.
2. **Verify one number against the primary source.** Not the whole report, one row: the stock of one product, the debt of one counterparty. If it does not match, neither does the rest.
3. **Run the task three times in a row.** Compare the path, not the total: which reports it opened, which filters it set. Three different roads to the same number are luck, not reliability.
4. **Break the input.** Give it an export for the wrong period and see whether it notices. An agent that does not stumble on deliberately bad data will not stumble on accidentally bad data either.

The third check is IBM's metric done by hand. It is worth doing once for every task you intend to hand over for good.

## How it works in our product

We reached the same conclusions before reading the IBM study, because we hit the same wall.

**The repeatable part is pinned as a script.** When a task goes on a schedule, the agent first writes a script for the part that repeats verbatim, and the task is bound to it by fingerprint. Every Monday the same code runs, not a fresh guess by the model. The model receives the script's output and decides only what needs judgement.

**A changed script does not pass silently.** If someone edits the script after binding, the task notices: the fingerprint no longer matches. Here we have something to learn. Today the run refuses in that case, and the person finds out hours later. OpenAI's Codex shows a "needs review" card in a similar situation and waits for confirmation; Anthropic's Skills API lets you pin a specific version and run exactly that. We are weighing both.

**Every action is logged.** The log keeps not what the agent said in the chat but what it did: which report it opened, which row it changed, which email it sent. That log is what you compare the paths of the three runs against.

**Irreversible steps wait for a person.** Delete, send, pay: on such steps the agent stops and shows a card. A flipped run at worst brings a wrong draft, not a sent email.

## Summary

A hallucination is a confident answer with no data behind it, and you catch it by asking where the number came from. But an agent that works regularly has a subtler failure: right today, wrong tomorrow, on the same data. By IBM's measurement it affects a quarter of tasks for a strong agent and is not fixed by a bigger model.

It is fixed by how the work is built: the repeatable part pinned in code, judgement left to the model, every action logged, the irreversible waiting for a person. You can test any agent for this in an evening: three runs of one task and a comparison of the paths.

## Sources

- [IBM Research, Your Agent Aced the Task. Will It Do It Again?, 15 September 2026](https://huggingface.co/blog/ibm-research/altk-evolve-consistency)
- [Codex (OpenAI), source code: review of modified hooks before they run](https://github.com/openai/codex)
- Our articles: [an overnight task for an AI employee](/resources/zadacha-na-noch-ii-sotrudnik-rabotaet-poka-vy-spite), [automating routine tasks](/resources/avtomatizaciya-rutinnyh-zadach)