## TL;DR
Varying tolerance feels like searching, but without a memory or a stop rule it is just wandering: the agent retries near-identical settings, re-finds the same matches, and never declares the residue unmatchable. Define a small ladder of tolerance settings in advance, from strict to loose, run each once, keep the incremental matches each level adds, and stop at the ladder's end. What remains is an exception list for humans, which is a legitimate outcome, not a failure to keep looping over.

```text
agent loop detected: re-running auto-match with slightly different tolerances forever
```

## Use this when
- Agent logs show repeated auto-match runs with incrementally changed tolerances and little new match yield.
- The same transactions are rescored across runs while the unmatched set barely shrinks.
- No maximum attempts or parameter history exists in the job design.

## Not for this skill when
- Tolerances change because a human is actively tuning them in a session. That is supervised tuning, not a loop, though the ladder still helps.
- Each run matches a genuinely different data set, such as new daily transactions. Repetition across data is normal operation.

## Steps
1. Extract from logs the sequence of tolerance settings tried and the new matches each produced. Verify: the diminishing yield curve is visible, proving the loop's futility
2. Define the ladder in configuration: three to five named levels from strict to loosest acceptable, with the business meaning of each. Verify: the ladder is finite and each level is justified
3. Make the job record settings tried and matches found per level, skipping levels already run for the same data. Verify: a rerun with no new data performs no repeated scoring
4. Run the ladder once over the stuck data set, keeping incremental matches per level. Verify: each level's added matches are reported separately
5. Stop at the ladder's end and emit the residue as a human exception queue with the levels already attempted noted. Verify: the job terminates with a residue report instead of another parameter tweak

## Variant phrasings
### auto match loop changing tolerances never stops agent
The tolerance-wandering phrasing.
### match tolerance ladder stop rule exception residue
When defining the ladder.

Compatibility: Agent auto-match jobs in reconciliation tooling with configurable amount and date tolerances.

## Why it happens
Tolerance is a policy decision disguised as a parameter: it states how much difference the business accepts as the same transaction. An agent allowed to invent tolerances is silently making policy, and because looser settings always find some match, the loop has a perverse reward that never reaches zero. A pre-agreed ladder moves the policy back to humans and converts the agent's job into executing it faithfully, then honestly reporting what policy could not match.

## Edge cases / pitfalls
- Beware the loosest level matching genuinely different transactions that happen to fit. Ladder levels should tighten evidence requirements as amounts loosen.
- Record which level matched each pair; auditors and reviewers weight a strict match differently from a loose one.
- If the same residue survives every ladder run month after month, the residue is a data problem upstream, and the exception queue is the evidence to fix it.

## Provenance

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