Loop detection: stopping an agent from calling the same tool forever

Agents don't get bored, and that's the bug: a stuck agent will retry the same failing call forever. Rysh's circuit breaker: 3 identical calls, blocked.

Humans have a built-in circuit breaker for futility. Run the same failing command three times and something in you says this is stupid, try something else. That feeling — boredom, frustration, the itch of repetition — is doing real engineering work.

Agents don't have it.

An LLM agent stuck in a rut will re-run the same failing tool call with the serene confidence of a process that has never known doubt. Same grep that returned nothing. Same test that failed identically. Same file read, over and over, as if the eleventh look will reveal new bytes. Every lap burns real tokens (your API bill), real time, and — the worst part — real context window, pushing useful history out to make room for transcripts of failure.

Everyone who has run agents in anger has watched this happen. Rysh assumes it will happen, and ships the boredom the model lacks.

The mechanism: small, dumb, effective

Rysh's orchestrator — the loop that turns an agent's intentions into tool executions — keeps a sliding window of the last 20 tool calls, each recorded as a pair: the tool's name and a hash of its parameters.

Before executing a call, it checks the window. Three identical calls — same tool, same parameter hash — and the third repeat is blocked. The execution doesn't happen; the agent gets told, in effect: you've done exactly this already, twice, and you're not doing it again.

That's the whole design, and every piece is deliberate:

• Params hash, not just tool name. Calling grep twenty times is an agent doing its job — grep for different things. Calling it three times with identical arguments is a rut. The hash is what separates diligence from perseveration.
• A sliding window, not forever-memory. Twenty calls of history means an agent that legitimately returns to a file after substantial intervening work isn't punished for it. The breaker targets tight loops — the pathological kind.
• Three, not two. A single retry is often correct (flaky network, race with a build). Two identical attempts is suspicious. A third is a pattern, and patterns of futility get interrupted.

Why blocking beats warning

The naive fix is to append a gentle note: "you seem to be repeating yourself." Anyone who's tried it knows how that goes — a stuck model is great at acknowledging the warning and then doing the thing anyway.

Rysh blocks at the execution layer, not the persuasion layer. The orchestrator simply refuses the call. This matters for a principle that shows up all over rysh's design: the model is the thing being governed; it can't also be the governor. Approval gates don't ask the model whether a command is dangerous; the allowlist classifies it structurally. Loop detection doesn't ask the model whether it's stuck; the window says so, arithmetically.

Hard constraints where it counts, model judgment everywhere else.

And a blocked call isn't a crash — it's a fork in the road. The agent is still running, still has its context, and now has one option removed. In practice that forced detour is often exactly the shove a stuck run needs: can't re-read the file a fourth time, so it finally greps for the caller instead. When the agent genuinely can't route around the block, the failure is visible in the pane — a stopped agent with a clear reason beats a spinning one with a growing bill.

The honest limits

Circuit breakers have a scope, and it's worth stating plainly.

The window catches literal loops — identical tool, identical params. It does not catch semantic loops: an agent alternating between two failing approaches, or mutating one character of a grep each lap. Detecting "this plan isn't working" in the general case is judgment, not arithmetic — that's what pane observability (you, glancing) and rysh's budget layer are for. Loop detection is the cheap tripwire that catches the most common failure mode by construction; budgets — hard token/pass ceilings with a human-takeover threshold — bound everything the tripwire can't see. Tripwire for the sharp failure, budget for the slow one.

Why this belongs in the platform

You could bolt retry-limiting onto your own agent scripts. Everyone says that; nobody maintains it. The point of a governed agent platform is that the unglamorous safety machinery — approval gates, secret redaction, and the futility breaker — is in the runtime, on by default, identical for every agent in every pane. Not a best practice you remember; a floor you stand on.

Rysh runs on Claude with your own API key, self-hostable on your own machines — so the tokens loop detection saves are, concretely, your money.

Agents bring the persistence. The platform brings the boredom. Together they finish tasks.

Watched an agent chase its tail at your expense? Help us kill that failure mode for good — become a design partner: rysh.ai/design-partner.

More in this series: Pages, books, and shelves: budget your agents like a library · takeover_when: the 90% threshold where a human steps in