Why agents fail at long tasks.

You build an AI agent. You give it a three-step task in a demo, and it nails it.

Then you put it in production, hand it a twenty-step task, and it falls apart.

What happened? Did the model get worse?

---

Small errors multiply

The model didn't get worse. The task got longer.

Let's walk through it. Say each step of a task, like reading a document, calling a tool, or deciding what to do next, succeeds 95% of the time.

That sounds pretty reliable, right?

But a task only succeeds if every step does. So the probabilities multiply. Over twenty steps, that's 0.95 multiplied by itself twenty times, which is about 0.36.

Roughly two tasks out of three contain at least one error.

Here's what that curve looks like:

Figure 1Task reliability falls with every step

Tasks completed correctly

0%25%50%75%100%

81.8%35.8%12.2%

151015202530

Number of steps

99% success per step95% success per step90% success per step

Task success by number of steps

Number of steps	99% success per step	95% success per step	90% success per step
1	99%	95%	90%
2	98%	90%	81%
3	97%	86%	73%
4	96%	81%	66%
5	95%	77%	59%
6	94%	74%	53%
7	93%	70%	48%
8	92%	66%	43%
9	91%	63%	39%
10	90%	60%	35%
11	90%	57%	31%
12	89%	54%	28%
13	88%	51%	25%
14	87%	49%	23%
15	86%	46%	21%
16	85%	44%	19%
17	84%	42%	17%
18	83%	40%	15%
19	83%	38%	14%
20	82%	36%	12%
21	81%	34%	11%
22	80%	32%	10%
23	79%	31%	9%
24	79%	29%	8%
25	78%	28%	7%
26	77%	26%	6%
27	76%	25%	6%
28	75%	24%	5%
29	75%	23%	5%
30	74%	21%	4%

And it's unforgiving in both directions. At 90% per step, a twenty-step task succeeds about one time in eight. At 99% per step, it still fails nearly one time in five.

So even a very good model, left to run a long chain on its own, will produce a steady stream of wrong results.

Before you put an agent in front of real work, understand this arithmetic. I think it's the single most useful thing a team can do.

Now, I'll be honest: real systems aren't quite this simple. Some errors are harmless. Some steps are much easier than others. And a capable model sometimes notices its own mistake and fixes it.

But the direction holds. It's also what teams see when they move from a demo to production volume. The problems show up in the long tail of tasks that need many steps.

---

Two levers

Here's the good news. The same arithmetic tells you how to fix it.

Reliability depends on two things:

1. How many steps you leave to the model.
2. What happens when one of them fails.

That gives you two levers to pull.

Give the model fewer steps

Here's something people (me included) tend to forget: much of what an agent does in a loop doesn't need a language model at all.

Fetching a record? Calling an API with known parameters? Formatting a file? Writing to a database?

That's just code. It's deterministic, testable, and effectively 100% reliable.

Every step you move from the model into code makes the chain shorter.

In practice, this means you design a workflow instead of handing an open goal to an agent. The model handles the parts that actually need judgment or language, like reading an unstructured document, classifying a request, or drafting a reply. Code handles everything around them.

Only ask the model to do what only the model can do.

Check every step that remains

The second lever is to catch errors before they spread.

After each model step, check what it produced. You could:

1. Validate it against a schema.
2. Reconcile the numbers against the source.
3. Run the tests for the code it generated.
4. Ask a second model to review it against explicit criteria.

If a check fails, retry the step once. If it fails again, escalate.

Do the checks need to be perfect? Not at all.

In the worked example below, a check that catches four errors out of five raises the effective reliability of each step from 95% to almost 99%. Across twenty steps, that moves the task from 36% to 79%.

Here's how the two levers compare, alone and together:

Figure 2What design choices change

Free-running agent20 steps left to the model35.8%

Fewer model steps6 model steps, the rest in code73.5%

Check and retryevery step verified78.5%

Both6 model steps, verified93.0%

Combined, they turn a system that's wrong most of the time into one that's right more than nine times in ten.

And there's a quieter benefit. The failures that remain are no longer silent. They surface at a check, where a person can look at them.

---

What this looks like in production

If you put all of this together, a reliable agent ends up looking less like an autonomous assistant and more like a well-designed process with a few intelligent steps in it.

I hope you'll forgive the metaphor, but it's a bit like a kitchen. The chef doesn't wash the dishes or count the deliveries. The chef cooks, and everything else is set up so the chef can do that well.

Here's the shape we use at Admeliora for document-heavy back-office work, such as processing supplier invoices:

Figure 3An agent workflow designed for production

1. CodeFetch the invoice and its purchase orderPlain API calls, no decisions.
2. ModelExtract amounts, dates and line itemsOutput constrained to a strict schema.
3. CheckValidate the schema and reconcile totalsOn failure: one retry, then escalate.
4. ModelExplain differences from the purchase order
5. HumanApprove differences above a thresholdRoutine cases pass straight through.
6. CodeWrite to the ERP and log every step

CodeModelCheckHuman

The specific steps matter less than three properties.

• The model's output is always structured. Free text is hard to check. A strict schema, with required fields, types and allowed values, turns "is this right?" into a test that code can run.
• Escalation is part of the design. A person reviews the cases the system can't settle: a failed check after a retry, an amount above a threshold, a supplier it has never seen. Routine cases pass straight through, and people spend their time on the exceptions.
• Every step is logged. When something goes wrong, you need to know which step failed, with what input, and what the model returned. Without that trace, you can't debug, audit or improve an agent.

---

Measure the task, not the step

How do you know if any of this is working?

Agent quality is usually reported per answer or per step. But that's not what the business experiences. The business experiences the success rate per task.

So before you deploy, I'd do this:

1. Build a set of real tasks with known correct outcomes.
2. Measure how many the system completes correctly from start to finish.
3. Measure how many it escalates.
4. Keep tracking both over time.

That last part matters more than it seems. A rising escalation rate is often the first sign that your inputs have changed.

This measurement also helps you make decisions. Say a new model comes out with better per-step accuracy. Does it matter? The task-level number tells you. Say one step fails a lot. Should you improve the prompt, add a check, or move that step into code? Now you can see.

If you only measure one thing, measure whole tasks.

---

Where to start

Pick one workflow. It should be repetitive, have clear correct answers, and take real time today. Triaging inbound requests, extracting data from documents, or reconciling records are good examples.

Then:

1. Map its steps.
2. Decide which ones actually need a model.
3. Design the checks before you write a prompt.

That's it. It's less magical than an autonomous agent, but it works.

Our applied AI work follows exactly this approach. If you have a workflow in mind, tell us about it and we'll help you figure out whether it's a good candidate.