Changed state
A write, checkout or other observable state change means an old repetition proof may no longer apply.
Repeated tool calls
Same tool call.Different value.
Counting retries is easy. Deciding whether a retry produced progress requires state, outcomes and evidence.
- Open source
- Local first
- Shadow first
- Fails open on ambiguity
Repeated tool calls
The second read may be verification. The fourth identical read may not be.
Repeated tool calls are not inherently pathological. An agent may legitimately re-read a file after a write, rerun a test after changing code, or repeat a search because the environment changed. A useful detector therefore needs more than call counts.
Three questions before calling a repeat waste
- Was the previous outcome proven? Unknown outcomes should not be promoted into evidence for blocking.
- Did observable workspace state change? A changed repository state can make the same action valuable again.
- Did the action add evidence? New evidence resets repetition pressure even when the tool name looks identical.
read config.py → new evidence
read config.py → verification
read config.py → same state, no new evidence
read config.py → no-progress candidateMARGINAL turns this into a provider-neutral evidence model. The model can stay purely observational, or—only where an adapter has real control and local evidence supports promotion—participate in narrow Tool Enforcement.
Design rule
Useful retries must survive.
Unknown outcome
If the runtime cannot prove success or failure, MARGINAL does not manufacture certainty.
Verification
Repeated work can be rational when it acquires or confirms evidence needed to complete the task safely.
Same action, same state
Successful work with no observable progress is the narrow pattern worth escalating.
FAQ
Fast answers.
Why do AI coding agents repeat tool calls?
Retries can come from verification, uncertainty, changing state, tool failures or genuine no-progress loops. The same surface behavior can have different causes.
Can repeated reads be useful?
Yes. A read after a write or a read that yields new evidence can be useful. MARGINAL is designed not to treat repetition alone as proof of waste.
What does MARGINAL persist?
Its privacy model uses derived structured evidence; raw prompts, source, commands, outputs, transcripts and credentials are not default evidence fields.
Try it
Observe first. Prove waste. Earn enforcement.
Install MARGINAL in Shadow Mode, inspect what your agent actually repeats, and contribute traces that make the governor harder to fool.
Why duplicate calls are not enough
Read the deeper model for action identity, outcome evidence, workspace state and useful verification.