What Must Survive a Session: LoopX's State Substrate
In LoopX, the durable object is the Goal rather than the chat thread. The question here is how that Goal preserves enough identity, history, evidence, and policy for a new executor to make a sound decision after a session ends. Once the distinction is clear, a registry, a workbench, a run record, and a dashboard stop looking like competing versions of the truth: they become surfaces with different owners and different jobs.
The Goal outlives the session
A session is a temporary setting for reasoning. It may contain a model's current plan, recent tool output, and a partially understood problem. A Goal is the project boundary that must remain intelligible when that setting disappears. It gives long-running work a stable identity and a place to attach the things that a later decision depends on: the objective, its acceptance conditions, the authority that can change them, the current work frontier, and the evidence that supports a transition.
This does not mean that LoopX tries to preserve every thought. A full transcript is often the wrong recovery artifact. It may contain a useful insight beside an abandoned hypothesis, an expired observation, a private path, and a plan that was never executed. Replaying all of it would burden the next model while still failing to answer which facts are current. LoopX instead aims to externalize the minimum state needed to derive the next safe action.
That state has two parts. Some facts can be replayed: the Goal identity, Todo lineage, recorded decisions, prior receipts, and references to earlier evidence. Other facts must be inspected again: the current checkout and uncommitted changes, the latest CI or pull-request state, the host's available capabilities, the current time, and the state of an external job. An old receipt can prove that a particular effect was accepted for a particular input and revision; it cannot prove that the external world stayed unchanged afterward.
This is why recovery in LoopX is not “restore the previous conversation.” It is closer to:
next decision = replay durable project facts + inspect fresh environment
The formula is simple, but it has a demanding consequence. Durable state must be selective enough to survive context limits and precise enough to prevent the next executor from making a different assumption about what already happened. It must also identify what it cannot establish. If a run says that a test passed but does not bind that result to the relevant revision, the run remains historical evidence rather than current acceptance proof.
The same principle explains why Goal reuse and Agent reuse are separate. A new session can continue the same Goal while registering a fresh Agent identity. Reading a project's state does not grant the right to take over another executor's claim, and the presence of one registered Agent does not by itself prove that a new session should impersonate it. The Goal carries continuity; the Agent identity carries responsibility for a particular work lane.
Six surfaces, different jobs
LoopX's architecture describes six durable control-plane layers. They are best understood as answers to different questions, not as six copies of one project record.
The registry answers, “Which Goal is this, where is it connected, and which routes and guards apply?” It establishes identity, repository association, active-state location, registered peers, authority sources, and selected policy. It is the place to resolve an ambiguous Goal boundary. It is not a transcript and does not prove that a host successfully started or that an external action completed.
The active Goal state is the readable workbench. It gives a person or an Agent a compact view of the objective, current priorities, Next Action, User Todos, Agent Todos, progress, and operating lessons. Its value is readability: someone can open it and understand the current shape of the work without decoding an event stream. Its limit is equally important. A paragraph that says a Todo is complete, or a line that says “publish next,” is not automatically a lifecycle transition or a permission grant. Governed write paths must turn the intended change into canonical state and a recorded event.
The event ledger answers, “What durable transition was accepted?” Its append-only form preserves lineage instead of allowing a later rewrite to hide an earlier action. Ordered replay makes the sequence reconstructable. Idempotent event identity makes a retry distinguishable from a second business effect. Privacy partitions keep public-safe summaries separate from local or private material. These properties matter together: a history that cannot be replayed consistently is not a reliable recovery base, and a replay that exposes raw credentials or private traces is not a safe public projection.
The run history is a compact index of bounded turns. It can record which Goal, Agent, or Todo participated, whether a turn observed or delivered something, what validation or evidence references were attached, what outcome class was assigned, and what successor or wait condition followed. It is a timeline and evidence index, not the whole project memory. A historical row saying “tests passed this round” does not close the Goal's acceptance unless the corresponding lifecycle transition was written through the owning path.
The status and attention surface answers, “What should a person or an executor understand now?” loopx status aggregates registry health, compact history, attention items, quota state, and public-boundary checks. Its job is to make the current situation readable: a Goal may need a user decision, be ready for an Agent, wait for external evidence, or be blocked by a health problem. A dashboard can translate those signals into operator language, but it remains a consumer of the status contract.
The compute-quota layer answers, “Should this otherwise eligible Goal consume another automatic turn now?” It records policy and spend accounting, but it is not the same as the event ledger, an approval record, or a strategy engine. A Goal can have quota remaining and still be unable to run because a user Gate, a missing external result, an invalid workspace, or a stale projection has higher priority. Later decisions combine these surfaces rather than letting the quota number override them.
There is also a turn journal, but it belongs to a different scale. It records the phases of one transaction—such as host execution, validation, writeback, spend, and scheduler settlement—so an interrupted turn can resume from the correct phase. It is not Goal truth. A journal entry saying that a process reached a phase expresses transaction progress or recovery information; only an accepted writeback changes the project's durable lifecycle.
Consider what happens when an Agent creates a pull request and then loses its session. The registry still identifies the Goal and its repository boundary. The active state can tell a person that the work is now waiting for checks or review. The run index can point to the revision and the validation that occurred. The event ledger can preserve the accepted transition that created the monitor. The status projection can tell the next host to wait for external evidence rather than generate another patch. If the next check finds a changed review decision, that observation should create a new, typed transition or successor; it should not overwrite the earlier record to make the timeline look simpler.
The same pattern applies outside software delivery. An external experiment can be running while the Goal remains open, with a monitor holding the task identity and next observation time. A user can approve one action while an unrelated Todo stays executable. A provider can report that an effect is running without allowing the Goal to be marked complete. Each fact lands on the surface whose owner can interpret it, and the projections recombine those facts for the next decision. This is the architectural payoff of separation: failure in one surface becomes a diagnosable gap rather than an invitation to rewrite the whole project state.
The diagram's arrows are ownership and projection relationships, not invitations for every surface to write every other surface. The workbench helps a human understand the Goal. The ledger preserves accepted transitions. Status reorganizes those facts for a consumer. Git, CI, and external providers continue to own their own realities. A turn journal helps recover a transaction. Confusing these relationships is how a readable view gradually becomes an ungoverned second state machine.
Facts, views, and the local-first boundary
A useful test for any piece of information is to ask whether it is canonical state, a workbench, a projection, or an external fact.
Canonical state includes typed Todo transitions, Gate resolutions, accepted evidence references, and quota-spend events. It can authorize later lifecycle decisions because it was written through an owning contract. The workbench contains human-readable explanation and current orientation; it becomes authoritative only when a supported write path normalizes the intended change into governed state. A projection includes status, a dashboard card, a review packet, or a task graph. It may be rebuilt and rearranged, but it cannot authorize a transition merely because it displays one. External facts include a Git commit, a pull-request head, a CI result, or the state of a cloud job. LoopX can retain a bounded readback, but it should not treat an old copy as a substitute for fresh external inspection.
This source-versus-view discipline also makes projection failures diagnosable. Suppose the event stream says a Todo remains open while a dashboard says it is done. The correct response is not to edit both displays until they agree. First identify the authoritative source, determine whether the lifecycle write failed or the projection is stale, repair through the owning protocol, and then rebuild the view. Until the disagreement is resolved, a dependent action should not run on the assumption that the dashboard is right.
The local-first design makes this separation practical. Project state can live with the project, while run history and global visibility remain in local runtime storage that several hosts can read. A Codex App heartbeat, a visible Codex CLI Goal, or another host can therefore return to the same project boundary. The model need not carry the entire history between them, and the host does not need to become the long-term owner of project facts.
Local-first does not mean distributed. The repository describes staged file, PostgreSQL, and NoKV authority-store paths as development or qualification candidates rather than an automatically enabled online control plane. Installing a provider does not replace the Goal's source of truth. Putting a project directory in a synchronization drive does not create compare-and-swap semantics, lease safety, or conflict-free lifecycle writes. Those require an explicit authority contract, revision checks, idempotency, and a tested recovery path.
It also means that the shared registry and dashboard should be treated as local coordination surfaces, not as a hosted service. A project agent can update project-local state, while a global projection gives an operator a bounded view across projects. That projection deliberately omits raw private evidence and machine-specific details. If it becomes stale, the remedy is to identify the source registry and rebuild the projection; it is not to let the dashboard silently become a more convenient authority. The design favors a smaller and more inspectable system today, while making the missing distributed guarantees visible instead of hiding them behind a database label.
This is an important trade-off. Local state is comparatively simple to inspect, private by default, and available without a cloud coordinator. It also leaves concurrency and cross-device authority as explicit engineering problems. The current lightweight runtime can use registered peers, soft claims, optional task leases, and independent worktree guards, but those mechanisms should not be described as a fully distributed scheduler. A claim tells the system who is expected to work on an item; it does not prove that the peer is alive, that the worktree is correct, or that a protected effect is authorized.
Privacy is part of the state model, not a publishing afterthought. The project distinguishes public-safe schemas, generic CLI behavior, and sanitized examples from local paths, active objectives, raw logs, credentials, private links, and unredacted evidence. A handoff should transfer stable identities, bounded references, freshness, omission notes, and a legal route for reacquiring material—not a copied private transcript. The compact projection is useful precisely because it carries decision-relevant structure without carrying everything that happened.
The practical result is a controlled form of continuity. A fresh executor can recover the Goal, inspect the current frontier, find the latest accepted evidence, and learn which facts need rechecking. It can also see where the system is uncertain instead of treating missing data as zero or treating a display as permission. That is what the state substrate contributes to LoopX's larger theme: it turns continuity into a property of owned, replayable facts rather than a hope that the next model remembers the previous one.
The remaining question is how those facts become executable work. A durable Goal alone does not say which item may run, which human decision covers it, or whether two peers can safely act at once. Those decisions belong to the work graph built from Todos, Gates, claims, capabilities, workspaces, and successors.