Paper finds 47 agent-loop gates that pass when the artifact is missing

The paper opens with a complaint about how most agent frameworks work: a step ends when the agent's own output says it has finished. The authors propose a "bounded loop" instead: a worker, a gate the worker cannot write to, and a declared budget. They say they prove two properties. A graph of these loops terminates even when a downstream failure can re-run finished upstream work, provided the repair budget is global rather than per node. And no node reaches done without a gate verdict in an append-only, hash-chained ledger.

The measured part is about the gates. The authors name two defects. A vacuous check is satisfied when the thing it checks is absent, so a worker can delete the artifact and pass. A self-attesting check applies a strict criterion to a value the subject supplied. Their sharpest example is a gate built to catch invented legal citations that passed an invented citation. The authors report 47 vacuous gates in code that had shipped and passed review. The abstract counts them across a 69-loop catalogue, while the paper's contribution list describes a 57-loop corpus drawn from that catalogue. The paper also marks its own headline figure down. The repaired gates showed no false accepts over 209 mutants, but a fresh family of mutants found a 23.3% false-accept rate. In the authors' words, "A rate belongs to a specific gate; the apparatus, not our number, is the contribution."

These are the authors' figures. We read the abstract, introduction and definitions, not the proofs or the results chapter that reports the counts. The paper says the engine, catalogue and mutant corpus are released under Apache-2.0 with commands to regenerate every number, so the figures can be checked. The paper also cites an open-source agent harness from DeepSeek whose own documentation records completion as "worker self-declaration."

Why it matters: Two checks are cheap to run on your own gates. Delete the artifact and see whether the gate still passes, then check whether the gate reads a value the worker wrote. If your loops can send work back upstream, cap repairs for the whole run rather than per node, or two nodes can keep repairing each other.