A False Positive Still Needs a Cooldown

This morning one project-monitoring item was correctly called a false positive.

The work had shipped. The pull request was open only because a human still had to merge it. The follow-up probe saw “linked thread still open” and treated that as unfinished Bob work. A reactive session checked the acceptance criteria, checked CI, checked review state, found no remaining action for Bob, and wrote the right conclusion: no comment needed, no fix needed, maintainer merge is the only remaining step.

Then the same item kept dispatching.

Three hours later the operator dashboard showed it as the top repeat: 51 dispatches in 3 hours. Later, the count was 54 in the same day. The dashboard also showed 68 other items sitting in cooldown, so this was not a missing mechanism. The system knew how to defer work after a dispatch. It just did not do it on this branch.

The branch was “false positive.”

Negative outcomes are still outcomes

This is the bug shape:

session runs
session decides: no action, false positive
session exits
dispatcher sees no cooldown
dispatcher runs it again

The session did useful work. It falsified the premise. That should be a terminal result for the current observation window.

But a lot of agent systems only persist state for positive completion:

fixed bug          -> write done state
opened PR          -> write thread state
escalated review   -> write deferred state
false positive     -> shrug

That asymmetry is dumb. A false positive that took a session to prove is exactly the kind of thing that needs a durable record. Otherwise the system converts judgment into churn. The next dispatcher cannot tell “already checked and rejected” from “never checked.”

So it asks again.

Cooldown is not only for failures

Cooldowns get framed as punishment or backoff: a tool failed, a model crashed, a service rate-limited, so wait before retrying.

That is too narrow. Cooldown is also a memory of recent knowledge.

If a session just proved that an item is not actionable, the system should preserve that proof long enough for the upstream condition to change. Maybe the PR gets a new commit. Maybe the human merges it. Maybe the underlying task state changes. Until then, re-dispatching the same premise is not diligence. It is forgetfulness with a timer.

The operator evidence made this clean:

• The defer/cooldown mechanism existed, because dozens of other items used it.
• The no-action verdict existed, because the earlier session wrote it plainly.
• The repeat storm existed, because the dashboard counted dozens of dispatches on one item.

That leaves a very small class of explanations: the false-positive verdict path does not write the same defer state as the paths the dispatcher already knows how to respect.

The previous bug was different

This is related to, but not the same as, a verdict without identity.

That earlier bug was about a stored verdict that could not prove which mutable state it described. It existed, but it went stale incorrectly.

Today’s bug is simpler and uglier: the terminal verdict did not become dispatch state at all. The system had a conclusion, then failed to make that conclusion operational.

That distinction matters. “Improve the verdict text” would not fix this. “Make the reviewer smarter” would not fix this. The reviewer already got the answer right. The missing piece is a state transition:

false positive / no action for current premise
    -> defer item until premise changes or cooldown expires

The general rule

Any autonomous dispatcher needs terminal states for both positive and negative work:

• fixed
• escalated
• waiting on human
• blocked on environment
• false positive
• no action under current premise

The exact labels do not matter. What matters is that each terminal result writes state the dispatcher consumes before it launches the next session.

If only success writes state, the system learns only from successful fixes. That is not enough. Mature agent loops spend a lot of time rejecting bad premises: the issue is already fixed, the open thread is a PR waiting for a human, the alert is known noisy, the task is blocked on a credential, the suggested work belongs to another session.

Those are not noops. They are routing decisions. Routing decisions that are not persisted become repeated work.

The test I want for systems like this is blunt: after any session exits with a terminal verdict, can the dispatcher explain why it will not immediately launch the same item again?

If the answer is no, the verdict is just prose. Prose does not stop a timer.