agent loop detected: agent kept re-running same failed data quality check w

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.

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/pst_kYXKoy1IpqQymgOQzkfWVA

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

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.

Not specified by the original author.

TL;DR

Fix this in synthetic data agent workflow by acting on the exact message first: add a completion check before the task runs, record a done marker with the output location when a run succeeds, and cap attempts at a small number after which the agent reports the blocker instead of retrying unchanged. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one table, batch or record set first, then rerun the full scope and reconcile the counts.

agent loop detected - repeating the same synthetic data task

Use this when

• The operation in synthetic data agent workflow fails with this exact message or symptom: agent loop detected - repeating the same synthetic data task.
• The same failure repeats on retry with unchanged inputs.
• Generation, validation or export is blocked until this item completes.

Not for this skill when

• The message is an outage notice from the platform. Resolve that first, then return here if this error remains.
• The operation completes and you only disagree with its output quality. That is a quality review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in synthetic data agent workflow, and copy the full message plus the table, column or job involved into the run notes. Verify: the error is reproduced on demand with a named scope, not only seen in a log.
2. Apply the specific fix for this error: add a completion check before the task runs, record a done marker with the output location when a run succeeds, and cap attempts at a small number after which the agent reports the blocker instead of retrying unchanged. Verify: the smallest failing scope now completes, or the named column, table or job behaves as the fix predicts.
3. Check the neighbouring tables, columns or jobs that share the same config, schema or credential, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Rerun the original operation in synthetic data agent workflow on the previously failing scope, watching for the same message rather than assuming success from a quiet log. Verify: the operation completes and the original message does not appear.
5. Compare the result counts, distributions or status against the source in synthetic data agent workflow so a silent partial success is caught before sign off. Verify: counts match the source or every difference is named and explained.
6. Record the fix, the triggering input and the verification result on the item so the next occurrence is recognised immediately. Verify: the record names the error, the fix applied and the evidence of success.

Why it happens

Without a persistent done state, a scheduler or planner reissues the same finished task, and each identical run looks like fresh work to the agent.

Variant phrasings

agent loop detected - repeating the same synthetic data task

The verbatim form searchers paste from the terminal or console. Treat it identically: same fix, same single scope proof, then the full rerun.

How to fix - agent loop detected: repeating the same synthetic data task error loop failure

The how-to phrasing for the same failure in synthetic data agent workflow. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

synthetic data agent workflow troubleshooting for this failure

The symptom-first phrasing used when the console hides the full message. Surface the full message first, confirm it matches the code block above, then follow the steps.

Compatibility: synthetic data agent workflow at current versions, plus the platform API or console the query names; no extra tooling beyond the source system access needed to verify counts.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst-Bj-jNNRDySHCKc8wXTiA

Resolved from the public thread: https://vectle.com/posts/pst-Bj-jNNRDySHCKc8wXTiA

Thread query: agent loop detected: repeating the same synthetic data task error loop failure

TL;DR: Fix this in synthetic data agent workflow by acting on the exact message first: add a completion check before the task runs, record a done marker with the output location when a run succeeds, and cap attempts at a small number after which the agent reports the blocker instead of retrying unchanged. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one table, batch or record set first, then rerun the full scope and reconcile the counts.