Why Your 20-Step AI Agent Is Less Reliable Than You Think

Your agent can call a tool successfully. Great. But can it complete 20 tool calls in sequence without losing state, duplicating writes, or making a bad recovery decision?
That's a different question.
Let's walk through a small example and the fixes that matter.
Step 1: Understand compounding failures
If every step has a 99% chance of success and all failures are independent:
for steps in [1, 5, 10, 20, 50]:
print(steps, f"{0.99 ** steps:.1%}")
Output:
1 99.0%
5 95.1%
10 90.4%
20 81.8%
50 60.5%
This is a toy probability model, not a measurement of real agents. Real-world dependencies, correlated failures, retries, and fallback paths make actual results more complicated.
Still, the intuition holds: more required operations mean more opportunities for something to go wrong.
Step 2: Stop treating the agent like one giant prompt
Consider an agent that:

1. Retrieves a customer record.
2. Validates the record.
3. Generates a recommended action.
4. Requests approval.
5. Updates a CRM entry.
6. Sends a notification. The dangerous approach is to let the model improvise the entire sequence without durable state or execution rules. Instead, define explicit steps and persist their status. A run should be resumable from the last confirmed checkpoint. Step 3: Build retry rules around the operation type A minimal retry helper for transient read failures might look like this: import time

class TransientError(Exception):
pass

def retry_read(fn, attempts=3):
for attempt in range(attempts):
try:
return fn()
except TransientError:
if attempt == attempts - 1:
raise
time.sleep(2 ** attempt)
Notice the name: retry_read.
Do not apply this blindly to writes. A timeout does not prove a write failed. It may have succeeded before the response was lost.
For writes, prefer provider-supported idempotency keys, a durable outbox, or a reconciliation check before retrying.
Step 4: Track side effects explicitly
Suppose your agent sends a customer notification. Give that logical operation a stable ID:
operation_id = f"{run_id}:customer-notification"
Record the operation's intent and outcome in durable storage. If the worker restarts, it can check whether the notification was already sent—or whether the result is ambiguous and needs reconciliation.
An idempotency key only works if the receiving API actually enforces it. Don't assume every connector does.
Step 5: Gate consequential actions
A model-generated recommendation is not the same as permission to act.
Before updating records, sending sensitive messages, or triggering financial actions, validate:

• Inputs and output schema
• Source evidence and freshness
• User/agent permissions
• Policy constraints
• Whether human approval is required If a check fails, stop or escalate. Don't let the model “reason around” an authorization failure. Step 6: Test the unhappy paths Here are five tests worth running before you ship: Failure injected Expected behavior API returns a rate limit Bounded retry with backoff Email sends, response times out No duplicate notification Customer data is missing Stop or request more information Write permission is denied Block and report clearly Worker crashes after step 4 Resume without replaying completed side effects

The exact response depends on your application's risk model, but each scenario needs a defined outcome.
Step 7: Measure what users actually care about
Don't report only “tool calls succeeded.” Measure whether the whole requested task completed correctly.
Track completion rate, recovery rate, duplicate actions, human escalations, latency, and cost per successful workflow.
This is why agent reliability becomes an orchestration concern as soon as workflows touch real systems. Platforms such as Nuroen focus on governed execution, approvals, and auditability because those controls matter as much as model capability in production.
Takeaway
A 20-step agent isn't just a smarter chatbot. It's a workflow engine coordinating uncertain decisions and real side effects.
Design for failure before you scale the number of steps.
Have you run into a duplicate action, broken retry, or state-recovery bug while building agents? Share the failure mode—those are usually the most useful lessons.