agent loop detected: agent kept re-running same failed data quality check without fixing schema

Not specified by the original author.

TL;DR

Break the loop with a state rule, not a bigger retry budget: the agent must record the failing check, the input hash, and the attempted fix, and must stop and escalate when the same check fails twice with the same input and no intervening change. Re-running an unchanged check cannot produce a different result, so the loop is a policy bug.

agent loop detected: agent kept re-running same failed data quality check without fixing schema

Use this when

• The check or run fails with this symptom: the agent repeats the identical failed check without changing anything between runs.
• You are working on an agent re-running the same failed data quality check in a loop and the failure repeats on the same data or configuration.
• You need the failing rows, rule, or stage isolated before changing thresholds or code.

Not for this skill when

• A legitimate retry after a real fix was applied, where rerunning is the correct verification instead.
• The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Inspect the agent's run history and confirm the check, its inputs, and its failure are identical across iterations. Verify: the loop's identical iterations are documented
2. Add a guard: hash the check inputs and the target schema state, and block a rerun when the hash matches the previous failed run. Verify: the guard blocks an unchanged rerun in a test
3. Require the agent to state the change it will make before any retry, and log that change with the attempt. Verify: each retry in the log names its intervening change
4. Cap retries at a small number and route further failures to a human or a ticket with the failure history attached. Verify: the cap and the escalation path are configured
5. Replay the original scenario and confirm the agent stops, escalates, and preserves the evidence instead of looping. Verify: the replay ends in escalation with the history intact

Variant phrasings

agent loop re-running same failed data quality check

The verbatim loop phrasing.

agent retry loop identical check no change guard

The guard phrasing for input hashing and retry caps.

data quality agent stuck loop escalate failure

The escalation phrasing for routing repeated failures.

Compatibility: Agent loops around Great Expectations, Soda, or dbt checks with unchanged inputs

Why it happens

Agents optimise for eventual success and checks are deterministic, so without an explicit stop rule the agent repeats a failing check forever, burning time and sometimes masking the failure's age. The missing piece is memory of what was already tried against which inputs.

Edge cases / pitfalls

• Distinguish transient failures, such as a warehouse busy error, which deserve a bounded retry with backoff, from deterministic check failures, which do not.
• Log the fix hypothesis per attempt. A loop with changing hypotheses is debugging; without them it is spinning.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstqxgujjJf5qeDCPuqmTRFw

Resolved from the public thread: https://vectle.com/posts/pstqxgujjJf5qeDCPuqmTRFw

Thread query: agent loop detected: agent kept re-running same failed data quality check without fixing schema

TL;DR: Break the loop with a state rule, not a bigger retry budget: the agent must record the failing check, the input hash, and the attempted fix, and must stop and escalate when the same check fails twice with the same input and no intervening change. Re-running an unchanged check cannot produce a different result, so the loop is a policy bug.