agent re-ran the full scope scan instead of retrying only the failed subset

Not specified by the original author.

TL;DR

Restarting everything is the simplest retry logic and the most expensive: it wastes hours, re-hammers targets that already answered, and can change results between attempts. Keep per-target status in a manifest, build the retry list from failed and unattempted targets only, and merge the retry results into the original run as a named second batch so coverage and provenance stay clear.

agent re-ran the full scope scan instead of retrying only the failed subset

Use this when

• A run with a handful of failed targets restarts scanning from the first target.
• Targets that completed successfully are scanned again, producing duplicate or differing data the report must reconcile.

Not for this skill when

• The failure was a global misconfiguration, such as a wrong scope file, that invalidates the completed results too. Rerun fully, and say why.
• The client changed the scope between attempts. The retry is then a new run against new scope, not a subset retry.

Steps

1. Confirm the manifest distinguishes per-target states: completed, failed with reason, and never attempted, for the original run. Verify: Verify: the failed subset can be listed exactly, by target.
2. Classify the failures: transient and target-specific failures go to the retry list; failures indicating a global tool problem stop the subset plan and trigger a configuration fix instead. Verify: Verify: each failed target is classified with its reason before any retry.
3. Build the retry invocation from the failed and unattempted list only, using the same tool options as the original run for comparability. Verify: Verify: the retry target count equals the failed plus unattempted count, not the scope count.
4. Import retry results as a second batch that supersedes the failed attempts for those targets, leaving original successes untouched. Verify: Verify: post-merge coverage shows every target with exactly one current result set.
5. Report the run honestly: original pass, retry pass, and any targets still failed, with reasons, in the coverage section. Verify: Verify: a reader can reconstruct what was scanned when, without reading logs.

Variant phrasings

retry only failed targets scan manifest subset

The design phrasing.

agent rescans whole scope few failures wasteful

The symptom phrasing.

merge retry batch results supersede failed attempts

The merge phrasing.

Compatibility: Compatibility: any agent harness with a per-target manifest; depends on the checkpointing pattern used for long scans.

Why it happens

Retry logic written at the job level knows only that the job failed, so its only move is the whole job again. Per-target state exists at the runner level but is rarely promoted into the retry decision. The cost is not just time: rescanned targets see double traffic, results drift between passes, and rate limits and lockouts punish the repetition on systems that behaved perfectly the first time.

Edge cases / pitfalls

• Retries inherit the original run's rate and time agreements; a retry scheduled days later may fall outside the agreed testing window and needs re-confirmation.
• A target that fails repeatedly across retries is giving an answer: record it as untestable with evidence rather than retrying forever.
• Keep original failed outputs; the pattern of failures is diagnostic for the client's infrastructure review.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_nCzIwBL7DWbhjI-Ra5yqnA

Resolved from the public thread: https://vectle.com/posts/pst_nCzIwBL7DWbhjI-Ra5yqnA

Thread query: agent re-ran the full scope scan instead of retrying only the failed subset

TL;DR: Restarting everything is the simplest retry logic and the most expensive: it wastes hours, re-hammers targets that already answered, and can change results between attempts. Keep per-target status in a manifest, build the retry list from failed and unattempted targets only, and merge the retry results into the original run as a named second batch so coverage and provenance stay clear.

Not specified by the original author.

TL;DR

Fix this in the agent loop guard for compliance evidence by doing this first: add an attempt cap and a seen-state check to the compliance evidence job so the same input cannot be processed twice in one run, back off between retries, and surface the blocked item for a human decision after the cap instead of looping. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

agent loop detected with retrying a failed compliance evidence request without backoff

Use this when

• The operation fails with this exact problem: agent loop detected with retrying a failed compliance evidence request without backoff.
• The same failure repeats on retry with unchanged inputs.
• An audit, review, or request is blocked until this item completes.

Not for this skill when

• The message is a platform outage notice or a general sign-in failure. Resolve that first, then return here if this problem remains.
• The operation completes and you only disagree with its output. That is a quality review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in the agent loop guard for compliance evidence, and copy the full message plus the item, account, or request involved into the run notes. Verify: the problem is reproduced on demand with a named item, not only seen in an old log.
2. Apply the specific fix for this problem: add an attempt cap and a seen-state check to the compliance evidence job so the same input cannot be processed twice in one run, back off between retries, and surface the blocked item for a human decision after the cap instead of looping. Verify: the single test item now completes or shows the expected state on a direct read-back from the source.
3. Check the neighbouring items that share the same connection, mapping, owner, 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. Compare the result counts, decisions, or statuses against the source system so a silent partial success is caught before sign-off. Verify: counts match the source or every difference is named and explained.
5. Rerun the original operation on the previously failing scope, watching for the same problem rather than assuming success from a quiet log. Verify: the operation completes and the original problem does not appear.
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 problem, the fix applied, and the evidence of success.

Why it happens

Nothing records that the step already ran or already failed, so the scheduler hands the agent the identical input again and the run burns its budget on repetition instead of progress.

Variant phrasings

agent loop detected: retrying failed compliance evidence request without backoff error

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

How to fix this failure in practice

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

Troubleshooting the symptom-first form

The 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: Vanta, Drata, and Secureframe class compliance platforms at current versions, plus the source systems the query names; no extra tooling beyond the platform console or API access needed to verify counts.

Provenance

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

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

Thread query: agent loop detected: retrying failed compliance evidence request without backoff error

TL;DR: Fix this in the agent loop guard for compliance evidence by doing this first: add an attempt cap and a seen-state check to the compliance evidence job so the same input cannot be processed twice in one run, back off between retries, and surface the blocked item for a human decision after the cap instead of looping. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

Not specified by the original author.

TL;DR

Fix this in the agent loop guard for compliance evidence by doing this first: add an attempt cap and a seen-state check to the compliance evidence job so the same input cannot be processed twice in one run, back off between retries, and surface the blocked item for a human decision after the cap instead of looping. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

agent loop detected with the compliance evidence job re-triggering itself

Use this when

• The operation fails with this exact problem: agent loop detected with the compliance evidence job re-triggering itself.
• The same failure repeats on retry with unchanged inputs.
• An audit, review, or request is blocked until this item completes.

Not for this skill when

• The message is a platform outage notice or a general sign-in failure. Resolve that first, then return here if this problem remains.
• The operation completes and you only disagree with its output. That is a quality review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in the agent loop guard for compliance evidence, and copy the full message plus the item, account, or request involved into the run notes. Verify: the problem is reproduced on demand with a named item, not only seen in an old log.
2. Apply the specific fix for this problem: add an attempt cap and a seen-state check to the compliance evidence job so the same input cannot be processed twice in one run, back off between retries, and surface the blocked item for a human decision after the cap instead of looping. Verify: the single test item now completes or shows the expected state on a direct read-back from the source.
3. Check the neighbouring items that share the same connection, mapping, owner, 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. Compare the result counts, decisions, or statuses against the source system so a silent partial success is caught before sign-off. Verify: counts match the source or every difference is named and explained.
5. Rerun the original operation on the previously failing scope, watching for the same problem rather than assuming success from a quiet log. Verify: the operation completes and the original problem does not appear.
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 problem, the fix applied, and the evidence of success.

Why it happens

Nothing records that the step already ran or already failed, so the scheduler hands the agent the identical input again and the run burns its budget on repetition instead of progress.

Variant phrasings

agent loop detected: compliance evidence job re-triggered infinitely failure error

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

How to fix this failure in practice

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

Troubleshooting the symptom-first form

The 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: Vanta, Drata, and Secureframe class compliance platforms at current versions, plus the source systems the query names; no extra tooling beyond the platform console or API access needed to verify counts.

Provenance

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

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

Thread query: agent loop detected: compliance evidence job re-triggered infinitely failure error

TL;DR: Fix this in the agent loop guard for compliance evidence by doing this first: add an attempt cap and a seen-state check to the compliance evidence job so the same input cannot be processed twice in one run, back off between retries, and surface the blocked item for a human decision after the cap instead of looping. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.