When Context Gets Poisoned, Cut Your Losses

Three prompts.

Same broken tool call.

Zero forward progress.

The poison pattern

You're debugging a failing integration test. The agent makes a tool call that doesn't quite work. You correct it, nudge it back on track, and for a moment it seems to recover.

Then it makes the same mistake again. Or a variation of it. You correct it again. It drifts back.

This isn't the model being dumb. This is the model being consistent with its own context. Every failed tool call in that conversation is now part of the model's "suggestions for future consideration." The bad outputs aren't just errors - they're training data for the rest of the session.

Why recovery rarely works

The intuition is to fix the mistake and keep going. You've already invested tokens. You've already built up context. Starting over feels wasteful.

But here's the mechanism: once the context window contains a pattern of broken tool calls, the model treats those patterns as valid examples. Even if you successfully redirect it, the poisoned examples are still there, exerting gravitational pull.

"Once your context has been poisoned with those tool calls, they act like suggestions for future consideration. So even if you get it back on track, there's a decent chance that it's going to actually pull it right back."

Hannes Rudolph, Office Hours S01E06

You can fight this. You can spend another ten prompts trying to steer the conversation. Sometimes it works. But the odds are against you, and every additional prompt adds tokens to a context that's already compromised.

The heuristic

The practical rule: stop trying to save a poisoned context. End the task, tell the orchestrator it didn't work, and start fresh.

This feels counterintuitive. You've invested time and tokens. But the math usually favors a clean restart over an extended recovery attempt.

"My general rule is that I'm using orchestrator and I just end that task and, you know, prompt it, tell it that one didn't work, try it again and go from there."

Hannes Rudolph, Office Hours S01E06

The orchestrator pattern makes this explicit: treat each task as disposable. If a subtask fails in a way that corrupts its context, terminate it and spawn a fresh attempt. The parent task keeps the high-level goal; the child task starts with a clean slate.

The tradeoff

This heuristic has a cost. You lose whatever valid context you'd built. If you were three-quarters through a complex refactor, restarting means re-explaining the goal.

But compare that to the alternative: spending another twenty minutes and another dollar in tokens trying to coax a poisoned context back to productivity, only to watch it drift again.

The restart is usually cheaper. Not always. But usually.

Why this matters for your team

For a team running multiple agentic workflows per day, context poisoning is a silent tax. Developers who try to "save" a broken session end up burning time and tokens on recovery attempts that have low success rates.

The compounding effect: if two developers per day each spend thirty minutes fighting a poisoned context instead of restarting, that's five hours per week of unproductive debugging. Time that could have gone into the next feature.

The shift is cultural. Restarting a task shouldn't feel like failure; it should feel like good hygiene. A clean context is worth more than a recovered one.

If you notice the model repeating the same broken pattern, stop. End the task. Tell the orchestrator what went wrong. Start fresh.

The tokens you "save" by restarting are almost always less than the tokens you'd spend on a failed rescue.

How Roo Code closes the loop on context management

Roo Code's orchestrator mode treats context hygiene as a first-class concern. When you run complex, multi-step tasks, the orchestrator spawns subtasks that each operate with their own isolated context window. If a subtask's context becomes poisoned, you terminate that specific task and let the orchestrator spawn a fresh attempt - without losing the parent task's high-level understanding of your goal.

This architecture means you spend tokens intentionally on outcomes rather than burning them on recovery attempts. Combined with BYOK (bring your own key), you maintain full visibility into token costs and can make informed decisions about when to cut losses versus when to persist.

The pattern that works: Use orchestrator mode for multi-step work. When you detect context drift, end the subtask cleanly and restart. The orchestrator preserves your goal while giving the next attempt a clean slate.

Context recovery: old approach vs. new approach