From Checklist to Work Graph: Who May Do What?
LoopX becomes operational only when a durable Goal is translated into work that a particular Agent may perform under current conditions. The focus here is the work graph: how Todo identity, task class, dependencies, authority, capability, workspace, and continuation combine to form a real frontier. By the end, an open item should no longer look synonymous with a runnable item, and a claim of ownership should no longer look like permission.
An open Todo is not an executable Todo
A normal checklist answers one question: has someone remembered the item? LoopX asks several more. What outcome does the item advance? Who owns the action? What must already be true? Which human decision covers it? What evidence will prove completion? If the current attempt cannot proceed, how will the system know when to look again?
That is why a LoopX Todo carries more than text and a checkbox. It has a stable identity, a role, a priority, a task class, and often an action kind that tells the control plane what sort of work it represents. It can declare dependencies and a machine-readable resume condition, required capabilities, a repository and write scope, an owner claim or lease, evidence, a successor, or a supersession relationship. These fields are not decorative metadata. They determine whether the item can enter the current frontier at all.
The durable lifecycle is deliberately small: open, done, blocked, and deferred. A fifth status such as running would blur a temporary execution attempt with a durable fact. In LoopX, running is derived from the current decision, claim or lease, and recent execution evidence. A claimed item is not necessarily being executed, and an unclaimed item is not necessarily idle. Keeping those concepts separate makes recovery possible when a process disappears after claiming work.
Task class supplies another independent axis. An advancement_task is work intended to move the Goal forward: implementing a change, validating an artifact, analyzing evidence, or repairing a known condition. A continuous_monitor observes an external condition and acts only when a material change occurs. A user_gate asks a person or controller to resolve an authority question. A user_action makes a human task visible without necessarily blocking an Agent. A blocker records a known obstacle and its recovery path.
This distinction prevents a common failure mode. If every open item is treated as advancement work, a heartbeat can repeatedly wake an Agent to “check again” even though the only valid next step is to wait for CI, a reviewer, or a capacity change. If every user item is treated as a global stop, safe work that does not depend on the decision is starved. The task class tells the control plane what kind of lifecycle the item participates in; the status tells it where that lifecycle currently stands.
The frontier is the set of items that survives the current filters. Start with open work, then remove items whose dependencies or resume conditions are not satisfied. Apply decision scope and authority. Apply peer claims, exclusions, or leases. Check the capabilities actually available in this execution environment. Check the repository, worktree, and write scope. Finally, consider freshness and evidence. Only then does priority help order the remaining candidates.
The order matters because each filter can change the meaning of the next one. A P0 Todo to publish a change may be high priority, but a missing public-claim decision means it is not executable. A P1 test may be lower priority but runnable because it has no dependency on that decision. A Todo that requires a benchmark runner may be a perfectly valid work item while remaining blocked in the current host; the same item can become runnable in another session only after that capability is actually declared and verified. A matching repository name is necessary for a write, but it does not make an unsafe shared checkout acceptable. A claim can make one peer the preferred executor, but it cannot override a Gate or repair a stale workspace.
This filtering also prevents a work graph from becoming a hidden script. Dependencies express facts that must exist before work begins; they do not dictate every implementation step. A resume condition such as a completed predecessor, a merged change, or available capacity says when a decision should be revisited. It does not guarantee that the original route is still correct. Successors express the next accountable unit after a material outcome, while supersession expresses that new evidence has invalidated the old route. The graph preserves the relationship between these decisions without pretending that a single linear sequence can survive every external change.
For a reader inspecting a real Goal, the practical sequence is therefore: identify the outcome and acceptance gap, inspect the open task class, check what blocks or unlocks it, verify the intended peer and workspace, and then ask what evidence would move it to the next state. This is more informative than asking only which item has the highest priority. It reveals why a task is not runnable and whether the correct remedy is a user decision, a capability repair, a new worktree, a monitor, a successor, or a different route.
The diagram includes a resume candidate because satisfying a condition does not automatically reopen an old Todo. A deferred item may become eligible for review, but the work itself can be stale. The Agent may need to reopen it, supersede it with a current successor, or record that no follow-up is needed. Treating “the condition happened” as “repeat the old implementation” is one way long-running systems quietly redo obsolete work.
The same discipline applies to completion. A Todo marked done proves that one work item reached a validated lifecycle outcome; it does not prove that the Goal is complete. If acceptance remains open, completion should create a successor, a monitor, a blocker, or a Gate. If no later work is needed, the record should say why with structured no_followup. If new evidence invalidates the route, supersession preserves the old item and links the replacement rather than rewriting history to make the old plan appear correct.
Authority is layered, so peers can collaborate without a leader
The most useful way to understand LoopX's work graph is through a small conflict: a high-priority task is blocked, while a lower-priority task is independent and ready.
Suppose Todo A is a P0 change to a public API. It requires a decision about whether the interface may change, so a user Gate covers that exact action. Todo B is a P1 characterization test that does not change the API and needs only a local shell and filesystem. If the Gate is treated as global, the Goal stops unnecessarily. If the Gate is ignored, the system may perform the protected change without authority. The correct result keeps the Gate visible to the user while allowing an eligible peer to claim and execute Todo B.
This is not an exception to the safety model. It is what scoped safety looks like. A Gate should identify the decision kind, its granularity, the action or lane it covers, and the Agent or Todo it blocks. A user_action can remind someone to respond, but it cannot satisfy a required decision scope merely because its wording mentions the same subject. Only a compatible user_gate with matching scope and ownership can unlock the protected operation.
LoopX separates several forms of authority that are often collapsed into one word: “owner.”
- A claim says which peer currently intends to work on a Todo. It reduces duplicate selection and makes responsibility visible, but it is a soft routing signal. It does not grant repository-wide write permission, bypass a Gate, or prove that the peer is alive.
- A lease is an optional, time-bounded occupancy right for work that needs stronger concurrency control. It can include a time-to-live, renewal, transfer, version check, and idempotency identity. A lease does not replace the Todo lifecycle, and a valid lease does not override a user decision.
- Lifecycle authority says who may complete, supersede, reassign, or perform a narrowly delegated mutation. A Goal may delegate particular actions to a registered peer with a reason requirement. That is a revocable, Goal-local grant, not a permanent leadership role.
- A capability says what the current runtime can do: for example, whether it has shell access, filesystem write support, or a benchmark bridge. It is a precondition for execution, not permission to perform every action the tool makes possible.
- A workspace guard says whether the Agent is in the correct repository, worktree, branch, and write scope. A host can have the right tool and still be in the wrong place. A repository identity can match while the canonical shared checkout is still disallowed for peer delivery.
The distinctions become especially important at a handoff. Suppose a peer claims an implementation Todo, produces a patch, and then disappears before the review is complete. The next peer should not infer that the implementation is still running, nor should they erase the old claim and start editing the same checkout. They should read the Todo and its evidence, check whether a lease or claim is still valid, verify the repository and current revision, and then use the explicit continuation or handoff path. The old work remains part of the lineage; responsibility for the next bounded action is a new, inspectable fact.
These filters answer different questions, so they must remain independent. A peer may have a publication approval but no network capability. It may have network access but be in the wrong worktree. It may have a valid claim but lack the Gate required for a production action. Conversely, an Agent may be able to perform a safe local validation even while another lane waits for an owner decision.
LoopX's live runtime model is an equal-peer model. Registered Agents are work identities, not a permanent organizational hierarchy. There is no durable primary Agent that automatically owns review, merge, quota, or replanning authority. A deterministic helper may suggest which peer is a good route for unclaimed work, but that suggestion is not the durable claim. Ownership becomes real through the Todo lifecycle and its evidence.
This design has a practical benefit during handoff. A new Agent can read the same Goal and discover the current work graph without inheriting a previous Agent's private context. The handoff needs the Goal and stop condition, the relevant Todo lineage, current revision and workspace boundary, Gates and capabilities, evidence references with freshness, and the next validation condition. It does not need a transcript dump. The receiving Agent still reruns current guards; the previous Agent's receipt does not grant new source permission, and an old workspace observation does not prove that the environment stayed unchanged.
The work graph also supports parallelism, but only where the evidence permits it. Different repositories can have separate Todo scopes and independent worktrees. Disjoint write scopes in one repository may proceed in parallel when their validation is genuinely independent. A shared file, schema, or state machine normally calls for serial ownership or an explicitly divided seam. External effects, merge, publication, and production changes remain subject to their own Gates and repository policy.
A review is not a special identity in this model. It can be represented as an ordinary advancement Todo with an action kind such as review, an independent handoff policy, and an exclusion that prevents the author from reviewing their own change when that separation matters. This keeps review visible as work with evidence and ownership rather than treating “reviewer” as a hidden privilege attached to one permanent Agent.
The final test is whether a Todo can leave the active frontier honestly. There are three sound routes: validated completion, supersession with preserved lineage, or a blocked/deferred state with a concrete recovery condition. Deleting the item, leaving “continue later” in a prompt, or marking it done because the current session ended does not close the lifecycle.
That is the central value of the work graph. It does not make every task parallel or every decision automatic. It makes the boundary of legitimate work computable: open is not runnable, claimed is not authorized, capable is not permitted, and done is not the same as complete. The next problem is to turn that filtered frontier into one current turn—one that can explain what the user must decide, what the Agent must attempt, and what proof must exist before the system charges the work.