What Happens When an AI Agent Gets Stuck?

An AI agent can write code, run commands, install dependencies, inspect files, execute tests, and keep working toward a goal without someone sitting beside it.

But eventually, something breaks. A dependency refuses to install. A test keeps failing.

The agent edits one file, creates another error, then fixes that error and brings the first one back.

Or worse, nothing technically crashes. The agent simply keeps making changes that look reasonable while moving further away from the actual goal.

That is where autonomy gets interesting. The important question isn't whether an AI agent can fail. Of course it can.

The question is:

What does the agent do after it fails?

Because a useful autonomous system needs more than execution. It needs some form of failure detection, diagnosis, recovery, and stopping behavior.

---

Failure Isn't One Thing

When we say an agent is "stuck", we're usually collapsing several very different problems into one word.

An agent can fail because the code is wrong.

It can fail because its reasoning about the code is wrong.

It can fail because the environment is broken.

It can fail because a dependency changed.

It can fail because a tool returned an unexpected result.

And sometimes the agent isn't technically failing at all. It is solving the wrong problem.

A useful way to think about agent failure is:

These failures matter because different failures require different recovery strategies.

A syntax error may be fixed by reading the compiler output.

A dependency conflict may require changing versions.

A wrong architectural assumption may require abandoning the current approach entirely.

Giving every failure the same instruction — "try again" — is not recovery.

It's repetition.

---

Can an Agent Tell That It Is Stuck?

This is harder than it sounds.

A failed command is easy to observe.

A failed strategy isn't.

Imagine an agent working on a bug:

1. Modify auth.ts
2. Run tests
3. Three tests fail
4. Modify auth.ts again
5. Run tests
6. The same three tests fail
7. Make another small change
8. Run tests
9. The same three tests fail again

Technically, the agent is still doing things.

It is producing actions.

It is consuming tokens.

It is calling tools.

But from the outside, it is stuck.

This distinction is important:

Execution is not progress.

A useful agent therefore needs signals that help it distinguish between:

• a new failure that provides useful information,
• a known failure that needs a different approach,
• and repeated failure that indicates the current strategy is no longer working.

Recent research is beginning to study this problem directly. Microsoft's AgentRx work, for example, focuses on identifying the critical failure step in long agent trajectories rather than simply observing whether the final task succeeded. Their benchmark contains 115 manually annotated failed trajectories and reports improvements in failure localization and root-cause attribution over prompting baselines.

That shift is significant.

Instead of asking:

"Did the agent finish?"

we start asking:

"Where did the agent become unrecoverable, and why?"

---

The Recovery Loop

A robust agent should not treat failure as a simple instruction to retry.

A better model looks more like this:

The important step is diagnosis.

Without diagnosis, recovery becomes random search.

The agent changes something, retries, observes another failure, changes something else, and continues until either it accidentally succeeds or its budget runs out.

Recent research on diagnosis-guided recovery makes a similar point: self-correction becomes more useful when the system first identifies what type of failure it is dealing with and then selects an appropriate recovery mechanism, rather than simply adding more context or repeatedly prompting the model.

---

Why Tests and Logs Matter So Much

This is where the environment becomes more than a place to run code.

Suppose an agent changes a function and the application crashes.

With only the model's context, the agent has to reason from a relatively weak signal:

Something broke.

With a proper execution environment, it may have:

• compiler errors,
• stack traces,
• test failures,
• command output,
• dependency versions,
• environment variables,
• git diffs,
• process state,
• previous checkpoints,
• and reproducible test commands.

Now the failure becomes evidence.

That's a huge difference.

This is one of the strongest arguments for giving autonomous agents their own environments.

The environment provides observability.

Without observability, an agent has very little to reason about when things go wrong.

---

The Dangerous Part: Repeated Retries

Retries sound harmless.

They're not.

Imagine an agent has a 10-minute task budget.

It encounters an error and retries.

The second attempt fails.

It retries again.

The third attempt changes something unrelated.

The fourth attempt partially fixes the original problem but introduces another one.

Eventually, the agent has spent most of its budget modifying a codebase that was closer to correct at the beginning.

This creates a dangerous failure mode:

The agent doesn't crash. It drifts.

A recovery system therefore needs boundaries.

For example:

• maximum retries,
• maximum time,
• maximum tool calls,
• repeated-error detection,
• unchanged-test-result detection,
• state checkpoints,
• rollback capability,
• and explicit escalation rules.

The goal isn't to make the agent never stop.

The goal is to make it stop intelligently.

---

When Should a Human Take Over?

Human intervention should not mean:

"The agent made one mistake."

That would destroy the point of autonomy.

A better boundary is reached when the system no longer has enough evidence to safely choose its next action.

For example:

Recoverable

A dependency installation fails because of a known version conflict.

The agent can inspect the package requirements, change the version, reinstall, and run the tests again.

Potentially recoverable

A test fails, but the failure provides a clear stack trace and the agent has not tried the obvious repair path.

Let it continue.

Escalation-worthy

The agent has repeatedly attempted different fixes and the same underlying failure persists.

At this point, another retry may have little value.

Immediate human intervention

The agent encounters an ambiguous requirement, destructive operation, missing credential, production-impacting decision, or a situation where the available evidence is insufficient to determine a safe action.

The important principle is:

Human intervention should be a recovery mechanism, not a permanent execution dependency.

---

A Research Experiment We Can Actually Run

The interesting question isn't simply whether an agent can recover.

We can measure it.

A reproducible experiment could give an AI coding agent the same development task under several controlled failure conditions.

Experiment setup

Use an isolated repository and a fixed task.

Run the agent under four conditions:

1. Clean environment
2. Injected code failure
3. Injected dependency/environment failure
4. Injected repeated test failure

For each run, capture the complete trajectory:

• agent actions,
• tool calls,
• commands,
• errors,
• test results,
• file changes,
• retries,
• time,
• token usage,
• final state.

Then measure:

Metric	What it tells us
Recovery rate	Did the agent eventually recover?
Detection latency	How long before it recognized the failure?
Recovery attempts	How many actions were required?
Repeated-failure rate	Did it keep making the same mistake?
Recovery cost	How much compute/time was consumed?
Final correctness	Did the recovered solution actually work?
Escalation quality	Did it stop when intervention was appropriate?

Importantly, these would be Causly experiment metrics, not existing benchmark results.

We should not publish numbers until we actually run the experiment.

---

Existing Benchmarks Have a Blind Spot

Coding benchmarks such as SWE-bench are useful because they test whether an agent can resolve real software-engineering tasks.

But a simple success percentage doesn't tell us everything about recovery.

An agent that solves 70% of tasks cleanly and an agent that solves 70% only after chaotic, expensive trajectories could have very different production characteristics.

And benchmark results themselves need careful interpretation.

OpenAI reported in 2026 that SWE-bench Verified had significant test-quality and contamination problems and stopped using it as a frontier capability measure. Later, an audit of SWE-bench Pro estimated that roughly 30% of its tasks were problematic.

That doesn't make these benchmarks useless.

It shows something more important:

Even measuring agent success is an infrastructure problem.

The workload, environment, tests, execution trace, and evaluation process all influence what the final number actually means.

---

Recovery Changes What "Autonomy" Means

In the previous article, we asked how much an AI agent can build without a human continuously guiding it.

This article adds another dimension.

An agent isn't truly autonomous simply because it can execute 100 steps without asking a question.

What happens on step 37 when something goes wrong?

Can it understand the failure?

Can it gather evidence?

Can it change strategy?

Can it recover without damaging the work it already completed?

And, perhaps most importantly:

Can it recognize when recovery is no longer safe or useful?

That's a much stronger definition of autonomy.

The loop is what makes autonomous execution reliable.

Without it, autonomy is just uninterrupted execution.

---

What Reliable Failure Recovery Requires

If autonomous agents are going to build and operate real systems, their environment needs to provide more than compute.

It needs the machinery around failure.

At minimum:

1. Observability

The agent needs access to useful evidence: logs, errors, tests, diffs, and execution results.

2. State

The system needs to preserve enough context to understand what changed and what the current environment looks like.

3. Isolation

Failures should happen inside a controlled environment rather than directly damaging unrelated systems.

4. Checkpoints

The agent should have recoverable states it can return to when an approach goes wrong.

5. Verification

Changes need an objective way to determine whether they actually worked.

6. Recovery boundaries

Retries need limits.

7. Escalation

The system needs a clear mechanism for saying:

"I don't have enough evidence to continue safely."

That last capability might be the most underrated one.

A system that knows how to stop can be more useful than a system that always tries something else.

---

The Bigger Picture

The natural instinct when building autonomous agents is to focus on capability:

Can it code?

Can it use tools?

Can it deploy?

Can it build an application?

But capability is only half of the problem.

The other half is failure.

Real environments are messy. Dependencies break. APIs change. tests are incomplete. State becomes inconsistent. Requirements are ambiguous. Tools return unexpected results.

A useful autonomous system therefore can't be designed around the assumption that execution will go perfectly.

It has to be designed around the assumption that execution will eventually go wrong.

And that's where infrastructure starts becoming part of the intelligence loop.

The environment doesn't just give the agent somewhere to work.

It gives the agent somewhere to fail, inspect, recover, and continue.

That is the difference between an agent that can execute independently and an agent that can operate reliably.

---

Limitations

This article separates published evidence from proposed experimentation.

The failure taxonomy and recovery model presented here are conceptual frameworks informed by existing agent research; they are not presented as a universal taxonomy.

The proposed experiment has not been run as part of this article. Therefore, no recovery rates, retry counts, latency measurements, or performance improvements are claimed.

Benchmark results should also be interpreted carefully because current coding-agent evaluations have documented issues involving task quality, test validity, contamination, and evaluation methodology.

The next useful step is therefore not another claim about how reliable agents are.

It is to measure what happens when we deliberately make them fail.