An agent reads infrastructure state, then commits a mutation, and something changes in between. Blocking on that change is safe — three guards, three granularities, zero unsafe commits across 3,456 replayed proposals. They differ in what else they stop. The freshness guards block 94.6% of the changes that leave the action’s preconditions intact, taking safe completions from 73.3% down to 41.7% at exactly the same check cost. The contract guard re-evaluates the predicate instead, blocks nothing harmless, and leaks exactly one fault family for each clause its author forgot. Asking the model is not the escape hatch: confidence sits at 0.37 calibration error, agreement matches a coin flip, and 31.9% of agents that retry after a block commit unsafely from the refreshed read.
An agent restarts a failed job, promotes a validated snapshot, deletes an orphaned artifact, grants a role. Each is a read followed by a commit, and the two are not simultaneous: replicas lag, a response times out after the write already landed, another actor touches the same resource. The state the agent planned against is not necessarily the state it commits into.
The obvious defence is a guard at the commit that refuses the write when the resource has changed since the read. But staleness and unsafety are different things. An audit counter ticking, an unrelated committed write, a concurrent observer — each advances the version while leaving the conditions the action actually depends on completely intact.
Step through the paper’s own worked example. One mutation, one visible read, three different things that could happen before the commit lands.
Read the rows: the guards agree on the change that genuinely breaks the action and disagree on the two that do not. A guard blocking the middle row is buying nothing and costing a task.
All three guards eliminate unsafe commits. On this benchmark, any atomic re-check at commit time is enough for safety — and that is the least interesting thing about them. What separates them is the benign traffic they destroy.
Those block rates are fixed properties of the guards. What they cost you depends on the mix of concurrent changes your system actually produces. Move the two sliders and watch how much harmless work each guard lets through.
Macro-averaged over the three model families, that difference lands as safe task success of 73.3% under the predicate guard against 41.7% under the version guard and 34.1% under the epoch guard — one authoritative check each. The predicate guard also matches uniform strong verification on safety and availability at a quarter of the cost; the break-even is a fourfold premium on the semantic check, not cost parity.
A benchmark that hands the guard its own ground-truth predicate is flattering it, so the paper deletes one declared clause at a time and re-runs. The declared contract has four parts: the resource is in the right operational status, policy authorizes the change, integrity is intact, and the effect has not already been applied.
Switch clauses off and see what comes through the guard.
Each deletion converts exactly the fault family that clause covered into unsafe commits and touches nothing else. Deleting the integrity clause leaks nothing at all, because the duplicate check already subsumes it — clause redundancy, not clause count, decides how a contract degrades. Which makes the useful artifact the list of clauses you did not write down.
If the runtime will not hold the contract, the tempting alternative is to ask the agent. Direct execution is unsafe on 39.3% of proposals. Pick a gate and see what the alternatives buy.
The confidence number discriminates at roughly chance, with an expected calibration error near 0.37 on all three families. A cautionary prompt telling the model to think about staleness, ambiguous commits and concurrency leaves two of the three bit-identical.
Nor does blocking transmit what a guard knows. On the matched population where a version guard fires, the agent gets a block notice and an ordinary refreshed read — and the refreshed read shares the blind spot that misled the original proposal.
Returning authoritative evidence instead of a bare block is better and still leaves 19.2% unsafe re-commits — against zero when the runtime gates on that same evidence itself. The pattern differs by model and never disappears: Phi-4-mini heeds the block and stops on 82.6% of them, then is unsafe on 40.0% of the re-commits it does make; Gemma4-8B mostly retries and is unsafe on 34.0%. A coarse guard that cannot say why it blocked converts its own intervention into a retry loop.
You are probably not restarting Spark jobs from a 4-billion-parameter model. You probably do have an agent that writes: it closes tickets, updates records, flips flags, revokes access. Every one of those is a read and a commit with a gap in between, and the guard at that commit decides two numbers a week.
The block rates below are the paper’s. The volume, and how much of your concurrent traffic actually breaks a precondition, are yours.
The cheap version of this paper’s advice: the guard you already have is a compare-and-swap, and it is the one that throws work away. Writing the preconditions into the write itself costs an afternoon and one conditional update, and it is the only configuration here that is both safe and available.