“You Tried That Already”: What Causes Error Loops and How to Prevent Them

After fighting with this problem for several days before resolving it and deciding to write this article, I proposed a different title, involving the phrase “un-fuck your agent”. My AI agent thought that wouldn’t sound very professional, so this is our compromise.

Colonel Code (as I call the senior officer of my agentic army) says the cleaner version is better, because the problem is not just frustrating — it is diagnosable, preventable, and probably happening to more Agent Zero users than just me.

This came up while developing Tavina, our flagship AI personal assistant project at Hurt Ridge Labs. Tavina is not a hobby project; it has a real codebase, planning docs, deployment routines, experiments, issue branches, and enough moving parts all developed using Agent Zero as a serious development partner. We’re talking a codebase in the hundreds of thousands of lines at this point.

For a while, everything was working beautifully. Then, almost overnight, it started feeling like Colonel Code had been replaced by a squirrel trapped in a coffee can.

The same work that had been moving along smoothly started stalling. The agent would begin a reasonable plan, call a tool, get a result, and then fall into a loop with messages like:

You have sent the same message again. You have to do something else!

If you have seen that kind of error loop, you know how maddening it is. It does not just waste a few seconds. It burns tokens, breaks flow, and turns every development session into whack-a-mole.

At first I wondered if the model had gotten worse. Maybe the context window was too large. Maybe the project instructions had become too complicated. Maybe the chat history had become poisonous. Maybe I had done something dumb (that happens often–just ask my wife).

As usual, the answer was: yes, sort of — but not in the way I first thought.

The Short Version

The main problem was context flooding caused by workspace bloat.

In plain English: my active Agent Zero project workspace had accumulated too much stale, duplicated, generated, and prompt-like material. Agent Zero was not just reasoning over the useful parts of Tavina. It was being passively exposed to a messy project surface full of old worktrees, build artifacts, duplicated source trees, and previous failure patterns. I use Gitea as the source of truth and keep it clean–but every time we work on a new feature or bug fix, duplicates of the repo were getting copied into the workspace and were not always getting cleaned up afterwards.

Once the loops started, the chat histories themselves became part of the problem. Old chats began containing repeated loop warnings and failed assistant turns. Continuing inside those chats made the model more likely to repeat the same failure pattern.

The fix was not simply “use a smaller context window.” The better fix was:

• clean up the active project root;
• keep only one canonical checkout visible to Agent Zero;
• move temporary worktrees outside the active project context;
• ignore generated artifacts and prompt-like clutter;
• stop continuing loop-poisoned chats;
• add a recurring workspace health check;
• turn the cleanup process into a reusable Agent Zero skill.

What Went Wrong in Tavina

Our Tavina development workflow had picked up a bad habit.

When working issues, temporary TavinaCore worktrees were created for issue branches, deployment tests, wrap-up work, and parallel development. That is normal enough. Git worktrees are useful. Multiple branches can be useful.

The problem was where they lived.

They were accumulating inside the active Agent Zero project root.

Conceptually, it looked like this:

project-root/
  tavina-core/
  tavina-core-issue-610/
  tavina-core-issue-611/
  tavina-core-issue-612/
  tavina-core-epic-wrapup/
  tavina-core-deploy-run/
  docs/
  planning/
  experiments/

That might look harmless if you are thinking like a human developer browsing folders manually. But Agent Zero projects expose a filtered file-structure overview to the agent. Even with caps and ignore rules, a bloated root can pollute the model’s passive context.

Each duplicate worktree may bring along:

• source files;
• dependency directories;
• Rust target/ directories;
• frontend node_modules/ directories;
• build outputs;
• test artifacts;
• Git metadata;
• project docs;
• prompt-like files such as AGENTS.md or *prompt*.md.

Multiply that by several stale worktrees and the active project stops being a clean working surface. It becomes a swamp.

In our case, the active project root had grown to roughly 18 GB and contained multiple duplicate TavinaCore worktrees. After cleanup, it dropped to about 5.7 GB, with only the canonical checkout remaining visible inside the project root.

That was the smoking gun.

Context Flooding Is Not Just “Too Much Context”

A large context window is not automatically bad. In fact, for agentic coding, a large context window can be wonderful — if the context is relevant.

The problem is when the context window gets filled with the wrong things:

• duplicated source trees;
• old branches;
• generated files;
• irrelevant artifacts;
• repeated instructions;
• stale prompt files;
• prior error loops.

At that point, the model is not thinking with “more context.” It is thinking with more noise.

That distinction matters. If you simply reduce the context window, you may reduce the symptoms, but you have not fixed the workspace. You have just made it less likely that the worst parts of the workspace get pulled into view.

The better answer is context hygiene.

The Loop Becomes Part of the Loop

One of the more interesting findings was that the poisoned chat histories were probably both a symptom and an amplifier.

Here is the pattern:

workspace bloat
  → noisy project context
  → repeated failed agent actions
  → loop guard messages
  → polluted chat history
  → even more repeated failure patterns

Once a chat contains a bunch of messages saying some version of “you tried that already,” the model may start seeing that failure pattern as part of the working context. It is like trying to debug a program while your terminal keeps replaying yesterday’s stack traces into today’s prompt.

That is why starting a fresh chat after cleanup matters.

Do not delete the old chats. They are useful forensic records. But do not keep asking the agent to do serious development while standing in the ashes of its previous doom loop.

The Fix That Worked

For Tavina, we made the active Agent Zero project root boring again.

The policy is now:

project-root/
  tavina-core/     # one canonical visible checkout
  docs/
  planning/

Temporary worktrees belong outside the active project context, for example:

/worktrees/project-name/issue-123/
/archive/project-name/old-issue-122/

That means we can still use Git worktrees when they are genuinely helpful. We just do not let them pile up where Agent Zero treats them as passive project context.

We also tightened the project’s file-structure ignore rules to exclude common bulk and context-risk patterns:

# Temporary duplicate worktrees/checkouts
/*-issue-*/
/*-feature-*/
/*-epic-*/
/*-deploy-*/

# Generated bulk
**/target/
**/node_modules/
**/dist/
**/build/
**/.next/

# VCS metadata and caches
**/.git/
**/.pytest_cache/
**/.mypy_cache/
**/.ruff_cache/
**/__pycache__/

# Prompt-like files that should not be passively surfaced unless intentional
**/AGENTS.md
**/*prompt*.md
**/*.promptinclude.md

Then we added a report-only health check. It does not delete anything. It simply tells us whether duplicate worktrees are creeping back into the active project root.

That daily report is the important part. Cleanup should not be heroic, it should be boring maintenance.

Agent Zero Workspace Hygiene Checklist

If Agent Zero starts looping in a large project, here is the checklist I would use first:

[ ] Diagnose from outside the flooded project context if possible (I am a big fan of having multiple A0 instances for mutual support).
[ ] Measure the active project root size.
[ ] List the largest top-level directories.
[ ] Look for duplicate worktrees or cloned repos.
[ ] Check whether build artifacts are visible to project context.
[ ] Check whether prompt-like files are repeated throughout the tree.
[ ] Verify file-structure ignore rules.
[ ] Move temporary worktrees outside the active project root.
[ ] Remove only clean linked worktrees.
[ ] Archive clean standalone clones with a manifest.
[ ] Start a fresh chat after cleanup.
[ ] Add a recurring report-only health check.

The key principle is simple:

Treat your Agent Zero project root as an active context surface, not a storage closet.

A Downloadable Skill

I packaged the cleanup workflow as a generic Agent Zero skill called Painless Workspace Cleanup (my last name is Hurt, thus…ok fine, I will put away the finger puppets).

Placeholder download link:

The skill is designed to guide Agent Zero through a safe, report-first cleanup workflow. It covers duplicate worktree detection, generated artifact ignores, rollback manifests, and fresh-chat recommendations for loop-poisoned histories.

It is not Tavina-specific. The Tavina incident was just the field test that made the pattern obvious.

Is This a Bug?

Sort of. But I would not frame it as “Agent Zero is broken.”

I would frame it this way:

Long-running agentic projects need context hygiene guardrails.

Agent Zero could probably help users more by warning when:

• a project root becomes huge;
• duplicate Git worktrees are visible;
• common generated directories are not ignored;
• prompt-like files are repeated across the workspace;
• a chat history appears loop-poisoned.

That is not one magic bugfix, but rather a class of operational guardrails for serious, long-running agentic development.

What I Learned

This was a useful reminder that agentic development has a new kind of technical debt.

We already know about code debt, test debt, documentation debt, and infrastructure debt.

Now we also have context hygiene debt.

If you let your agent’s working environment accumulate stale branches, duplicate checkouts, generated files, and failed histories, eventually the model starts tripping over the mess. Not because it is stupid. Because you handed it a junk drawer and asked it to perform surgery.

For Tavina, cleaning up the workspace got us back toward stable development. More importantly, it gave us a repeatable maintenance pattern for future large projects.

That is the real takeaway:

If your agent gets caught in a doom loop, do not only blame the model. Audit the context you are feeding it.

Sometimes the right tool to un-fuck your agent is not a better prompt.

Sometimes it’s just a broom.

Related Reading