01 · From answers to effects
The hard governance problem begins after an agent can change the world.
An assistant that only drafts an answer can be reviewed at the interface. An agent that issues a refund, reserves inventory, provisions cloud capacity, changes a shared calendar, or initiates a purchase creates a durable effect. That effect can change the facts every other agent is using.[1]
A request-time policy decision may be entirely correct when it is made. The problem is that time passes between checking the rule and committing the effect. During that interval another operation can change a budget, quota, inventory balance, approval status, or risk signal that justified the decision.[1]
02 · The smallest useful race
Nine units are gone. Two agents each ask for the last one.
A team has a 10-unit rolling limit and has already consumed 9 units. Agent A proposes a 1-unit action. Agent B proposes another 1-unit action at nearly the same time. Each request fits if it is considered alone against the same old state: 9 + 1 is 10.
One valid check, then another—but both use the same old state
Without a protected decision-effect interval, both agents observe 9 of 10 units consumed, both receive allow, and both effects commit. With scoped coordination, the first effect moves the state to 10 before the second policy evaluation is allowed to decide.
The two application effects can even touch different records. Their hidden conflict is the mutable policy state: both consume the same team's remaining budget. If the system protects only the application writes, it can miss the dependency that matters to the rule.[1]
03 · A correctness target
Policy-state serializability asks whether the completed history still has a valid explanation.
Policy-state serializability, or PSS, does not require every operation in the whole system to run one at a time. It requires the terminal governed operations to fit a real-time-respecting serial order in which every decision is evaluated against the policy state immediately before its position, every allowed operation applies its governed effect there, and every denied operation applies no effect.[1]
In the 9-of-10 example, a valid serial explanation commits one 1-unit effect and denies the other. A history that commits both cannot be explained by the policy: after either effect, the state is already 10, so the second request no longer fits.
04 · What the runtime connects
The policy remains reviewable; the boundary preserves its meaning through effect commit.
MasuGate keeps the policy as a bounded program, then asks a provider contract to name the certified state views and logical scopes that the policy and effect may touch. The runtime protects the relevant scopes while it evaluates the policy and handles the result. The provider still owns the actual state and effect implementation.[1]
A decision stays connected to the state and effect it governs
The request enters with trusted identity and typed arguments. The policy declares certified state dependencies. The provider resolves those dependencies to logical scopes. Coordination protects the policy evaluation and governed effect, and the operation record retains the linkage.
- Reviewable policy program: declares the rule and the registered state it may inspect.
- Provider-certified state views: return policy-visible facts from the system that owns them.
- Logical scopes: name policy-state dependencies that overlapping operations must agree about.
- Scoped coordination: protects the decision-effect interval only where dependencies overlap.
- Provider-owned effect: performs the consequential action through the governed path.
- Governance record: connects request, policy revision, decision, state evidence, effect outcome, and final status.
05 · When a person needs time
Approval can also go stale, so the system must reserve or revalidate.
Human review lengthens the same check-then-act interval. A request may be reasonable when it enters review, but another operation can consume the last capacity while the approver is deciding. The approval then reflects an old state rather than the state in which the effect would occur.[1]
Check current state at resolution
Treat approval as one input to a fresh governed evaluation. The operation may still be denied if intervening work consumed the relevant capacity.
Preserve capacity while review waits
Atomically remove reserved capacity from what other operations can consume, then commit, release, or expire it through a governed lifecycle.
Neither path turns a human click into a detached effect token. Revalidation may reject the operation after approval; a reservation is meaningful only if its provider contract prevents double consumption and handles cancellation, retries, and recovery correctly.[1]
06 · Evidence, with its boundary
The paper isolates stale authorization in controlled workloads.
In a PostgreSQL-backed prototype, arXiv v1 reports that the tested MasuGate transaction and reservation modes prevented stale authorizations in minimal and multiprocess shared-budget races while satisfying PSS. It also evaluates delayed approval, policy-evolution fixtures, and a scripted, LLM-free procurement workflow over shared budget and inventory state.[1]
The useful conclusion is narrow: the experiments exercise the policy-state conflict that request-local checks can miss and test whether the declared boundary preserves the policy under those workloads. They are not a general benchmark of agent quality, model intelligence, or production readiness.
07 · Assumptions and limits
The guarantee is only as sound as the boundary around it.
The provider must return the promised policy-state facts, name every relevant logical dependency, apply effects consistently with visible outcomes, preserve reservations, and make retries safe. Governed routes must not be bypassed by an unmediated copy of the original consequential tool.[1]
The paper's prototype covers central execution paths with PostgreSQL-backed state, pending approval, reservations, scoped holds, and evaluation harnesses. It does not establish production deployment tooling, policy-bundle signing, a concrete dependency on every agent framework API, or the general protected-execution protocol needed by external APIs that cannot join a transaction.[1]
Publication boundary
Evidence and limitations
Stateful Governance for Concurrent Agentic Systems, arXiv:2608.02764v1
The article summarizes the paper's model and controlled evaluation; this website has not promoted the results to release-backed Verified evidence.
- The reported workloads are controlled benchmarks and a scripted, LLM-free procurement workflow—not open-ended production deployment traces.
- The prototype evaluates one concrete PostgreSQL-backed policy-state provider; production use needs additional certified views, adapters, hardening, and operational review.
- Policy-state serializability depends on sound provider contracts, complete mediation of governed routes, and correct effect, reservation, idempotency, and recovery behavior.
- A general protected-execution protocol for external APIs that cannot join a database transaction remains future work in arXiv v1.
Primary sources
Sources and further reading
- Stateful Governance for Concurrent Agentic SystemsarXiv:2608.02764v1 · 3 August 2026
Canonical v1 record and primary source for the definitions, architecture, Figures 2–4, evaluation, assumptions, and limitations; arXiv also provides PDF and HTML full text.