On this page
The short answer
Detect agent loops through repeated work that makes no progress toward the task contract. Track tool outcomes, evidence additions, state changes, and elapsed budget. Repeated wording can be legitimate, while differently phrased searches can still form a loop. Test that the stop rule prevents further work and gives the user a useful next step.
What to take away
- Define progress using task evidence or state.
- Test paraphrased loops as well as exact repeats.
- Verify stopped tasks admit no new work.
Sources checked . Research synthesis and Rubrex recommendations. Examples and local experiments are labeled; they are not client results.
Choose a progress signal before a step limit
Google SRE’s overload chapter discusses controlling excess work when a service is strained. For an agent, Rubrex recommends applying an explicit work budget alongside a task-specific progress signal. A maximum step count bounds work but does not explain whether the preceding steps were useful.
Consider a synthetic policy-search assistant that must identify an exception clause. Progress means retrieving a new relevant clause, resolving an ambiguity, or obtaining needed user context. A different query string returning the same irrelevant passages is not progress. Define those distinctions in the evaluation labels before reviewing traces.
Evidence: Site Reliability Engineering: Handling Overload [1]
Create loops with different visible shapes
Return the same irrelevant document for an exact repeated query, then for several paraphrases. Create a second loop in which the agent alternates between two tools that refer it back to each other. Finally, create a legitimate two-step lookup that revisits a document after new context arrives.
Require a bounded response to the first two patterns: stop, clarify, or return a precise evidence gap within the configured budget. The legitimate revisit should remain possible. Otherwise, an overaggressive duplicate detector can suppress necessary verification and make the assistant appear efficient by avoiding the task.
Measure useful work and post-stop activity
Capture evidence identifiers, unresolved requirements, tool-call count, model attempts, and wall-clock duration per task. Classify why the stop occurred: solved, clarified, evidence exhausted, repeated state, or hard limit. A task that hits the limit should not be reported as a normal evidence-based abstention.
After the assistant says it stopped, inspect queued and in-flight work. A loop detector that only changes the final message while background calls continue has not enforced the work boundary. Test a slow tool and a delayed duplicate result to check that late events cannot restart the same exhausted task.
| Case | Evidence to retain | Acceptance condition |
|---|---|---|
| Paraphrased search loop | Returned evidence IDs | Stop within configured budget |
| Two-tool cycle | Alternating call sequence | Cycle identified or bounded |
| Useful revisit | New context and final clause | Valid continuation allowed |
Tune the stop rule against missed useful paths
Accept a rule when it stops the authored no-progress loops and preserves the legitimate follow-up case. Review false stops with a person who understands the task labels, then adjust the progress representation or allowed recovery path. Do not simply raise the global limit whenever a complex task fails.
Retain a small replay suite of loop shapes and useful revisits. Re-run it when adding tools or changing query rewriting, because those changes can create new cycles. State the remaining bound clearly: the fixture covers specific loops and budgets, not proof that the agent can never become unproductive.
Limits of the evidence
The policy searches and loop labels are proposed synthetic cases. No agent throughput or savings were measured. Progress definitions are task-specific, and any detector needs tests for false stops as well as repeated-work failures.
Common questions
Is the same tool twice a loop?
Not necessarily. Check whether the second call adds required evidence or confirms changed state.
Can a step cap replace progress checks?
It bounds worst-case work but cannot distinguish useful effort from a loop.
Sources & further reading
Primary sources behind this briefing. A source’s findings apply to its own study conditions; publication on arXiv does not establish peer review.
- Site Reliability Engineering: Handling Overload Google · 2016 · Engineering book chapterReviewed: foundational overload and excess-work control; historical foundation checked today. Accessed October 16, 2026.
Questions or corrections? Write to Rubrex. Read our editorial approach.