## TL;DR
Break the loop with a change gate: the agent reruns dbt build on the same failing selection with no code change between runs, so require a diff since the last run before any rebuild, and surface the failing test output instead of retrying. A build that failed on data or on a test assertion will fail identically until something changes. The loop exists because the agent treats a rerun as a fix action.

```text
agent loop detected: agent keeps running dbt build on same failing select without changes error
```

## Use this when
- The check or run fails with this symptom: an agent loop where dbt build runs repeatedly on the same failing selection without changes.
- You are working on an agent workflow that builds and tests dbt models and retries on failure 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 transient warehouse outage where a rerun after recovery is the correct action and the build inputs did change.
- The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

## Steps
1. Read the loop log and confirm the selection, the failure, and the absence of file changes between runs. Verify: the runs are identical in inputs and outcome
2. Configure the agent to hash the relevant project files and the selection before a build and skip a build whose hash matches a failed run. Verify: the duplicate build is refused with the reason logged
3. Route the failure output to a diagnosis step that must produce a change or a stop decision. Verify: the next action after a failure is analysis, not a rerun
4. Cap retries for the same failure signature at one, after any real change. Verify: the loop terminates with the failure summary
5. Record the failing test and its output in the run summary. Verify: a human sees the blocker without replaying the loop

## Variant phrasings
### agent keeps running dbt build same failing select loop
The shorter phrasing focused on the named failure.
### agent loop detected dbt build no changes error
The symptom phrasing a searcher tries next.
### dbt build retry loop agent fix
The variant naming the failing stage or tool directly.

Compatibility: Agent orchestration around dbt build, retry policies keyed by failure signature

## Why it happens
Agents retry because the tool result looks like an instruction to try again. Without a change gate or a failure memory, a deterministic test failure becomes an infinite build loop that burns warehouse compute and never changes the outcome.

## Edge cases / pitfalls
- Hashing only model files misses schema file and macro changes; include everything dbt parse would read.
- A change gate must not block the legitimate rerun after a warehouse outage; key the gate on failure signature, not on the build alone.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_yt1s6SWIBxNgrI-LKAyl2Q