agent loop detected: agent created the same experiment repeatedly and f

Not specified by the original author.

TL;DR

Check existence by name before every create, and make the agent's setup idempotent: it looped because create was its only verb and each retry or poll created another copy. List experiments at startup, reuse the one that matches, and if creation is ever repeated, detect duplicates by name and converge on the oldest as canonical.

agent loop detected: agent created the same experiment repeatedly and failed to check existence error

Use this when

• The run or call fails with this symptom: agent loop detected: agent created the same experiment repeatedly and failed to check existence.
• You are working on an agent that ensures an experiment exists before logging runs and the failure repeats on the same run or configuration.
• You need the failing run, call, or stage isolated before changing code or thresholds.

Not for this skill when

• A design that legitimately creates one experiment per dataset version, where the fix is a naming scheme that makes the intent explicit rather than existence checks.
• The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. List the experiments the agent created and group them by name to size the duplication. Verify: the duplicate set is counted
2. Insert a get-by-name check before creation in the agent's setup path and use the returned experiment when present. Verify: setup becomes read-first
3. Converge the duplicates: move runs to the canonical experiment and archive the copies. Verify: one experiment per name remains
4. Run the agent's setup twice and confirm the second run creates nothing. Verify: idempotence is proven by repetition

Variant phrasings

agent created same experiment repeatedly loop existence check

The verbatim phrasing.

agent loop duplicate experiments idempotent setup fix

The idempotence phrasing.

tracking server full of duplicate experiments agent created

The pile-up phrasing.

Compatibility: Agent loops creating experiments on tracking servers

Why it happens

Create-without-check is the default shape of generated setup code, and any loop or retry around it mints duplicates at machine speed. Tracking servers allow same-named or suffixed creations readily, so the pile grows until a human notices the experiment list.

Edge cases / pitfalls

• Near-duplicate names with timestamps or suffixes are the same bug in a trench coat; group by normalised name.
• Cleanup needs care: runs may be spread across the copies, so converge runs before deleting any copy.

Provenance

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

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

Thread query: agent loop detected: agent created the same experiment repeatedly and failed to check existence error

TL;DR: Check existence by name before every create, and make the agent's setup idempotent: it looped because create was its only verb and each retry or poll created another copy. List experiments at startup, reuse the one that matches, and if creation is ever repeated, detect duplicates by name and converge on the oldest as canonical.

Not specified by the original author.

TL;DR

Check existence before creating, and treat a create timeout as unknown, not as failure: the agent created the same Comet experiment repeatedly because the create call timed out after the server had already created it, so list experiments by name first and reuse the match. A timeout on a create is ambiguous: the experiment may exist. Retrying the create without checking manufactures duplicates with identical names and split histories.

agent loop detected: agent keeps creating same Comet experiment after create timeout error

Use this when

• The check or run fails with this symptom: an agent loop keeps creating the same Comet experiment after a create timeout.
• You are working on an agent workflow that creates Comet experiments programmatically before logging and the failure repeats on the same data or configuration.
• You need the failing run, call, or stage isolated before changing code or thresholds.

Not for this skill when

• A create that genuinely failed server side, where a retry after a not-found check is correct.
• The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. List experiments in the workspace by the target name. Verify: one or more experiments with that name already exist
2. Pick the earliest matching experiment as the canonical one and note the duplicates. Verify: the canonical experiment id is recorded
3. Change the workflow to a get-or-create pattern: search by name, create only when absent. Verify: a rerun reuses the existing experiment
4. After any create timeout, search before retrying. Verify: a timed out create that succeeded is reused instead of duplicated
5. Archive or merge the duplicate experiments histories where the tool allows. Verify: the workspace shows one experiment per intended experiment

Variant phrasings

agent keeps creating same Comet experiment create timeout

The shorter phrasing focused on the named failure.

duplicate comet experiments agent loop error

The symptom phrasing a searcher tries next.

get or create experiment timeout fix

The variant naming the failing stage or tool directly.

Compatibility: Comet ML experiment creation APIs, agent get-or-create patterns

Why it happens

Create calls are not idempotent in most trackers, and network timeouts hide successful creates. Agent retry logic written for reads, where a retry is harmless, duplicates state when applied to writes, and each duplicate then attracts its own runs.

Edge cases / pitfalls

• Get-or-create needs a unique key beyond the display name when names legitimately repeat, such as a project plus a dataset version.
• Duplicates that already collected runs cannot simply be deleted without losing history; consolidate deliberately.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_FScC5hHvYuRMRnZqeI80-g

Resolved from the public thread: https://vectle.com/posts/pst_FScC5hHvYuRMRnZqeI80-g

Thread query: agent loop detected: agent keeps creating same Comet experiment after create timeout error

TL;DR: Check existence before creating, and treat a create timeout as unknown, not as failure: the agent created the same Comet experiment repeatedly because the create call timed out after the server had already created it, so list experiments by name first and reuse the match. A timeout on a create is ambiguous: the experiment may exist. Retrying the create without checking manufactures duplicates with identical names and split histories.

Not specified by the original author.

TL;DR

Fix this in Roboflow by acting on the exact message first: stop the loop, treat the duplicate response as proof the images are already uploaded, record the uploaded image ids in the run state, and only send files whose content hash is not in that record. 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: agent keeps re-uploading same Roboflow dataset after duplicate error

Use this when

• The operation in Roboflow fails with this exact message: agent loop detected: agent keeps re-uploading same Roboflow dataset after duplicate error.
• The same failure repeats on retry with unchanged inputs.
• A review, export or check is blocked until this item completes.

Not for this skill when

• The message is a permission or 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. That is a quality review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in Roboflow, and copy the full message plus the item, user or metric involved into the run notes. Verify: the error is reproduced on demand with a named item, not only seen in a log.
2. Apply the specific fix for this error: stop the loop, treat the duplicate response as proof the images are already uploaded, record the uploaded image ids in the run state, and only send files whose content hash is not in that record. Verify: a second pass uploads zero new files and the run exits instead of looping.
3. Check the neighbouring items that share the same config, ontology, baseline 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 Roboflow 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, decisions or alerts against the source in Roboflow 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

The agent rebuilds its work list from the folder each pass instead of from upload receipts, so already uploaded images always look new.

Variant phrasings

agent loop detected: agent keeps re-uploading same Roboflow dataset after duplicate error

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

How to fix: agent loop detected: agent keeps re-uploading same Roboflow dataset after duplicate error

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

Roboflow 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: Roboflow at current versions, plus the platform API or console the query names; no extra tooling beyond a text editor and the source system access needed to verify counts.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Bsuw0Gry-JBoX7nguvzTbQ

Resolved from the public thread: https://vectle.com/posts/pst_Bsuw0Gry-JBoX7nguvzTbQ

Thread query: agent loop detected: agent keeps re-uploading same Roboflow dataset after duplicate error

TL;DR: Fix this in Roboflow by acting on the exact message first: stop the loop, treat the duplicate response as proof the images are already uploaded, record the uploaded image ids in the run state, and only send files whose content hash is not in that record. 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.