One Governed Turn: How LoopX Decides Whether to Act
LoopX's most important per-turn question is not whether some quota remains. It is whether this exact Goal, Agent, frontier, workspace, and authority boundary make one bounded action legal and useful now. The mechanism that answers it is quota should-run, which compiles current state into an interaction contract. Understanding that contract lets a reader distinguish delivery from waiting, repair, or replan, and see why validation and durable writeback must come before accounting for a turn.
Quota is a decision compiler
A simple scheduler might ask whether a counter is greater than zero. If so, it starts the model. That rule fails as soon as long-running work encounters a human decision, an asynchronous external job, or a stale workspace. The Goal may have compute budget left while the next useful action is to wait for CI. It may have an open Todo while the current host lacks a required capability. It may have a high-priority task that is blocked by a scoped approval and a lower-priority task that can proceed safely. Treating all of these states as “run” or “do not run” throws away the information needed to choose correctly.
LoopX's quota should-run is therefore better understood as a decision compiler. It reads the current project facts and produces a packet describing what the current turn may mean. The input includes the exact Goal and Agent identity, the Goal boundary, open Todos and their claims, user Gates, capability declarations, workspace state, recent evidence, monitor timing, vision or replan obligations, quota policy, and host execution context. The output includes the interaction contract, the selected or selectable work, the applicable boundary, the capability and workspace gates, and a scheduler hint.
The ordering is part of the safety model. In the current architecture, the decision moves through these questions:
- Identity: Is the requested Goal present, and is the Agent a recognized peer? Ambiguity fails closed rather than selecting the first available identity.
- Goal boundary: Which repository, write scope, authority sources, private/public rules, and orchestration limits apply?
- User decision: Does an open Gate cover the action being considered, and is its scope concrete and compatible with this Agent or Todo?
- Repair obligation: Is there a stale projection, missing Vision checkpoint, repeated surface activity, or other condition that must be repaired before ordinary delivery?
- Capability: Can the current host perform the selected work, or is a bridge or owner-held capability missing?
- Workspace: Is the Agent in the correct repository and worktree for the selected write scope?
- Frontier: Which Todo survives dependency, claim, lease, priority, monitor, successor, and freshness rules?
- Interaction contract: What should the user, Agent, and CLI each do on this turn?
- Scheduler: When should the host look again, and what cadence change or acknowledgment is required?
The sequence prevents a lower-level signal from masquerading as a higher-level authorization. A runnable Todo cannot override a Gate. A capability cannot grant permission. A scheduler cannot create delivery authority. A previous turn's recommendation cannot replace a fresh decision when the Goal or environment has changed.
This is also why shouldrun: false is not a sufficient explanation. False may mean that the Goal is waiting for a user, waiting for external evidence, throttled, paused, not yet due for a monitor, outside the current Agent's scope, or allowed only to remain quiet. Each case has a different recovery path.