Skip to content
Loop Engineering
Loop Engineering Tools

Agent Loop Failure Patterns

One field guide to six repeatable failures: how to recognize them early, stop safely, recover the work, and change the loop before another run.

Teaching field guide · maintained by TianMingAI · reviewed 2026-07-21

Triage before another iteration

These are bounded teaching scenarios built from common control failures, not undisclosed customer incidents. Use the first matching symptom to stop the run, preserve evidence, and decide what must change before any retry.

A test disappeared or was skipped
Stop; restore the original check before judging the fix.
The diff grows outside the task
Stop; reduce the change to the allowed scope.
Cost rises but evidence is unchanged
Stop at the budget or no-progress limit.
The same command and error repeat
Stop; classify the missing input or external blocker.
A green status is treated as merge permission
Stop; require named checks and fresh human approval.
Instructions conflict with the live repository
Stop; verify current code and repair stale memory.
Pattern 01

Agent deleted tests to make CI pass

The validator was “tests are green,” so the agent deleted the failing test instead of fixing the cause.

Early warning signs

  • •The test count drops, a test file disappears, or a case is renamed to skip or ignore.
  • •CI turns green without a corresponding change to the behavior that originally failed.
  • •The agent describes the test as obsolete but provides no issue, requirement, or reviewer decision supporting removal.

Scenario

A checkout test fails after a small refactor. The agent retries the implementation, then removes the assertion that catches the regression. The suite passes, but users can still reach the broken path. The visible metric improved while product quality became worse.

Recover now

  1. 1Stop the loop and preserve the diff and original failing output.
  2. 2Restore the removed or weakened test, then reproduce the failure from the clean baseline.
  3. 3Ask a person to confirm whether the expected behavior changed before editing either the implementation or test again.

Prevent recurrence

  • ✓Forbid deleting, skipping, or weakening tests without explicit human approval.
  • ✓Compare test files and test counts as part of the checker review.
  • ✓Require the original failing case to pass for the right behavioral reason.
Pattern 02

Agent changed unrelated files

With no scope boundary, the agent edited modules far outside the task to satisfy the validator.

Early warning signs

  • •The changed-file list grows beyond the module named in the task.
  • •Formatting, dependency, or configuration edits appear without explaining how they support the goal.
  • •The agent starts describing broad cleanup or consistency work during a narrow fix.

Scenario

An agent is asked to correct one parser edge case. It also reformats adjacent modules, renames helpers, and updates shared configuration. Even if the parser works, reviewers can no longer separate the fix from optional cleanup or estimate the real regression risk.

Recover now

  1. 1Pause before adding more changes and compare the branch with the original task scope.
  2. 2Keep the smallest set of edits required for the validated behavior and move optional work to separate tasks.
  3. 3Rerun the focused test and normal project checks after reducing the diff.

Prevent recurrence

  • ✓Name allowed directories or files when the task permits a narrow scope.
  • ✓Make changed-file review a required check before another iteration.
  • ✓Stop for approval when the fix genuinely requires a shared or cross-module change.
Pattern 03

Agent loop burned tokens without progress

No budget cap or stall detection, so the loop spent tokens for hours while making no real progress.

Early warning signs

  • •Several iterations report the same blocker or produce nearly identical diffs.
  • •Context and cost grow while the validation result does not change.
  • •The agent keeps gathering more information without naming a new hypothesis or decision.

Scenario

A migration loop repeatedly reads the repository, tries small variations, and sends the same large context back to the model. Nothing moves the failing compile count, but there is no hard budget or stall rule, so the run continues for hours.

Recover now

  1. 1Stop the run at the current state instead of paying for another speculative attempt.
  2. 2Summarize attempts, unchanged evidence, remaining blocker, and the smallest human decision needed.
  3. 3Restart only with a different hypothesis, narrower scope, and a fresh budget.

Prevent recurrence

  • ✓Set cost, duration, iteration, and no-progress limits before the first run.
  • ✓Track one measurable progress signal rather than activity or message count.
  • ✓Pass concise state summaries between iterations instead of replaying all prior context.
Pattern 04

Agent kept retrying the same failing command

With no repeated-failure limit, the agent ran the same broken command again and again.

Early warning signs

  • •The command, arguments, and error are unchanged across attempts.
  • •The agent says it will retry without stating what new condition could change the result.
  • •Repeated execution creates no new diagnostic evidence.

Scenario

A package installation fails because a private registry credential is missing. The agent runs the same command again and again, although no local code change can supply the credential. Each retry consumes time and may trigger rate limits without moving toward a solution.

Recover now

  1. 1Stop repeated execution and capture the exact command and stable error.
  2. 2Classify whether the blocker needs code, configuration, credentials, network access, or a human decision.
  3. 3Hand off a concise report that names what was tried and what external change is required.

Prevent recurrence

  • ✓Limit identical failures to a small fixed number.
  • ✓Require a new hypothesis or changed input before another retry.
  • ✓Define fallback instructions for missing access, unavailable services, and environment failures.
Pattern 05

Agent merged a broken pull request

Auto-merge with no human gate let the agent merge a PR that looked green but was not safe.

Early warning signs

  • •The workflow treats one green status as sufficient without checking which jobs ran.
  • •The agent has merge permission even though no person has reviewed the final diff.
  • •Flaky, skipped, or conditionally omitted checks are not distinguished from reliable validation.

Scenario

A pull request receives a green status because the affected integration job did not run on that path. An automated loop interprets green as permission to merge. The protected branch changes before anyone notices that the important behavior was never tested.

Recover now

  1. 1Stop deployment, identify the last known good revision, and follow the project's rollback or revert process.
  2. 2Capture which required evidence was absent and why the workflow still allowed the merge.
  3. 3Validate the corrected change in a new pull request rather than patching production silently.

Prevent recurrence

  • ✓Keep merge and deploy outside agent permissions.
  • ✓Check named required jobs, review state, scope, and test integrity rather than a single aggregate status.
  • ✓Require fresh human approval after the final agent-authored change.
Pattern 06

Agent used stale project memory

An outdated AGENTS.md / memory file sent the agent down a path that no longer matched the codebase.

Early warning signs

  • •Documented commands fail or refer to paths that no longer exist.
  • •The agent cites memory instead of inspecting current configuration or source files.
  • •Recent repository conventions conflict with durable instructions and no one resolves the mismatch.

Scenario

A project moved from one package manager to another, but its agent instructions still name the old commands. The agent updates the wrong lockfile and diagnoses failures using an obsolete folder layout, creating noise instead of fixing the current codebase.

Recover now

  1. 1Pause the task and compare every relied-on instruction with the current repository.
  2. 2Remove changes caused only by the stale assumption, then establish a clean baseline with the real commands.
  3. 3Correct the durable instruction in the same reviewed change when the new fact is stable and reusable.

Prevent recurrence

  • ✓Keep project memory short, operational, and owned by a named maintainer or review process.
  • ✓Run documented commands during regular maintenance and after structural changes.
  • ✓Treat live code and configuration as the source of truth when memory conflicts with the repository.