AI Agent Running for 200+ Hours: How LoopX Keeps Long-Horizon Execution from Losing Memory or Drifting

I’ve open-sourced LoopX, a control plane designed for ultra-long-horizon agents.

Right now, two real agent trajectories have been running continuously for 220.7 and 272.9 hours. They keep generating, validating, and delivering results around the same goal; through waits, human feedback, writebacks, model switches, and resumes, the execution chain remains unbroken. For long-running agents, that’s continuous execution for 200+ hours.

These two trajectories push agent systems to a new engineering scale: a single model call can take just minutes, but one goal has to keep working for ten days; models, sessions, and hosts can all be swapped, while the causal chain between goals, evidence, permissions, and next steps must stay stable.

LoopX’s technical claim is this: model context is finite, so long-horizon agents need externalized structured state. Each model call completes only a bounded Turn; the control plane is responsible for organizing these bounded calls into an execution system that can keep advancing, validating, waiting, and recovering.

That is also LoopX’s goal: long-horizon tasks should run steadily when no human intervenes, and run well when a human does intervene.

What 200+ Hours Changes

In short tasks, the chat context is almost the entire work site. The model reads code, modifies files, runs tests, and returns results.

Once a task spans days, the work site disperses across code repositories, PRs, CI, experiment platforms, documentation, user feedback, and permission relationships. The external world also keeps changing: reviewers raise new comments, tests move from pending to failed, upstream commits create conflicts, experiments end but their results are invalid, and users modify acceptance criteria again.

At this point, a long context can only help the model see more history; it cannot automatically answer five control questions:

1. Which system owns the current facts?

2. Which agent is authorized to advance which part of the work?

3. Did this tool call produce an acceptable result?

4. Should the current state continue, wait, ask a human, replan, or terminate?

5. After a process interruption, where does the next round resume from?

Codex’s /goal already externalizes the objective and goal lifecycle, and at the end determines whether something is complete or blocked. LoopX builds on this by externalizing process state further: todo, authority, evidence, gate, quota, cadence, handoff, and recovery.

The relationship between the two can be compressed into two lines:

Native Goal = objective + goal lifecycle + completion audit

LoopX State = goal boundary + work graph + authority + evidence + cadence + recovery

The former prevents agents from stopping too early; the latter turns “how to continue in the next round” into a structured protocol.

An Executable Kanban for Agents

If I had to introduce LoopX using just one product concept, I’d say it’s an executable Kanban for long-horizon agents.

An ordinary Kanban board shows “who is doing what.” Why something can’t start right now, what evidence counts as done, when to check again if external conditions haven’t changed, and who has the authority to approve high-risk actions—those states are still usually kept in human heads.

Agents cannot rely on that layer of implicit memory for the long term. So a LoopX card contains not just text and completion state, but also stable identity and routing semantics:

todo identity + role + priority + task class + action kind

• claim / lease

• required capability

• repository / write scope

• decision scope / gate

• successor / supersede / resume condition

• evidence / completion rationale

Among these, advancement_task represents work that can advance the goal; user_gate represents a need for the user to provide direction, permission, or risk judgment; continuous_monitor represents observing an external state once when it comes due; blocker holds blocking facts and resume conditions.

Runnable, Waiting, Review, and Done are projections of these facts. Changing the display column doesn’t directly alter the long-term facts; a legal “card move” requires completing a controlled transition:

observe facts

-> domain judgment

-> Kernel decision

-> bounded execution

-> independent validation

-> durable writeback

-> committed-state readback

-> successor / wait / ask / replan / terminal

The Kanban provides a visible work surface; the control plane defines how cards may legally move.

Six-Layer Architecture: Facts, Judgment, Execution, and Display Each Have an Owner

The most common architectural problem in long-horizon systems is having multiple components each maintain their own “current state.” The dashboard maintains one set of statuses, agent memory maintains another set of progress, and the workflow maintains yet another set of retries—until no layer can explain which state is authorized to drive the next step.

LoopX splits responsibilities across six layers.

External Truth

GitHub decides whether a PR is merged, CI decides whether a check passes, the experiment platform decides whether a job has finished, and the file system decides whether an artifact exists. The control plane cannot rewrite these facts based on old chat content.

Domain State

Domain State stores compact domain facts that still have decision value across turns, such as PR revision, check fingerprint, experiment lineage, metric results, and artifact identity. Raw logs, full transcripts, and large verifier outputs remain in external systems or private runtime artifacts.

Capability Pack

Capability Pack understands domain semantics and translates observations into a limited set of typed proposals. For example:

checks_pending -> monitor_continuation

checks_failed -> runnable_successor

changes_requested -> runnable_successor

merged -> terminal_candidate

dev_lift_only -> holdout_successor

holdout_clean -> promotion_candidate

negative_evidence -> retirement_candidate

A capability can propose next steps, but it cannot grant itself authority, nor can it directly write proposals as Kernel truth.

State Kernel

The State Kernel owns cross-domain lifecycles: goal, vision, todo, claim, gate, quota, scheduler, evidence lineage, handoff, and terminal closure. It continues to check agent identity, authority, capability, workspace, decision scope, and continuation policy.

Host / Runtime

Codex App, Codex CLI, Claude Code, or another managed runtime is responsible for creating sessions, invoking models, executing tools, and applying external effects. The runtime is a transient worker; each time it receives only one bounded action.

Projection

Status, Kanban, evidence graphs, and reports are read models. They are rebuilt from source state and serve observation, filtering, and routing for humans and hosts—they do not become another source of truth in reverse.

This layered design maintains two core constraints: domain capabilities can add specialized judgment, but they don’t replicate todo, quota, gate, or authority; Domain State can preserve domain continuity, but observations must pass through the Kernel to become executable transitions.

Stable Goal Identity and Layered State

LoopX uses the goal as the durable identity for a long-horizon task. Codex threads, Claude sessions, models, and hosts are all executors for a given round; they can be interrupted, replaced, or advanced in parallel.

When a new peer takes over, what needs to be restored is the same objective, authority boundary, open frontier, gate, next probe, and stop condition. It doesn’t need to reproduce the old session’s reasoning verbatim.

To achieve this, LoopX classifies state into several types.

The Registry stores goal identity, repository, registered peers, authority source, spawn policy, quota policy, and capability configuration that is disabled by default.

The event ledger stores already committed transitions as append-only events, such as todo_added, todo_claimed, operator_gate_recorded, evidence_recorded, run_refreshed, and quota_spent. Events carry stable event IDs and support idempotent replay, deterministic ordering, and public/private payload partitioning.

Active state provides a human-readable objective, boundaries, next actions, user todos, agent todos, and a progress workbench. It is an important compatibility surface and projection source, but structured state is still written through controlled commands.

Domain State stores compact continuity for domain-specific areas like Issue-Fix, Auto Research, and ML Experiment; it does not own quota, gate, claim, or external write permissions.

Run history and the evidence index store per-round classification, delivery outcome, artifact ref, validation, agent identity, successor, and spend lineage.

Status / Dashboard compresses these facts into an operator read model: which goal needs a decision, which todo is runnable, which monitor is waiting, and which projection needs repair.

These state layers are not several overlapping backups. The Registry owns long-term identity and policy; the event ledger owns committed lifecycle facts; Domain State owns domain observations; the Turn Journal owns only the recovery cursor for a single execution transaction; and Status/Dashboard are read-only. Writes must go back to the corresponding owner’s controlled API:

external observation

-> capability normalization

-> transition validation

-> durable event / state write

-> projection rebuild

-> source-state readback

For example, a Dashboard showing a card as Done won’t automatically complete the todo; an external provider returning success won’t automatically release a gate. Only after a canonical transition is written and appears in readback will the next Kernel round treat it as fact. This avoids Markdown, UI, memory, and workflow each maintaining its own “current state.”

Therefore, a recovery can be written as:

next decision

= replay(committed project state)

• inspect(fresh environment)

Old transcripts can still be used for explanation, but the next step is determined jointly by committed state and current external facts.

The Full Transaction of a Turn

Long-horizon stability ultimately rests on the transaction boundary of each turn. LoopX organizes one Turn into eight phases.

1. Read the current snapshot

Each round begins by reading the registry, todo, gate, monitor, vision, evidence, workspace, and host capabilities. The snapshot binds goal_id, agent_id, selected work, and revision, preventing later results from being written back to the wrong lane.

2. Compile the interaction contract

quota should-run keeps the quota name but actually serves as the decision compiler. It processes, in stable order:

identity

-> goal authority / boundary

-> user decision scope

-> self-repair obligation

-> capability eligibility

-> workspace guard

-> frontier / continuation

-> interaction contract

-> scheduler hint

The order itself is safety semantics. Selecting a todo first and checking workspace later may let a host start writing in the wrong repository; looking only at priority while ignoring decision scope may let an agent cross a user gate.

3. Separate the three interaction channels

The interaction contract simultaneously outputs three types of responsibilities:

• user_channel: whether the user needs to be notified, and what the specific question is;

• agent_channel: whether the current peer must attempt, whether delivery is allowed, and what the primary action is;

• cli_channel: the writeback order for validation, refresh, and spend.

This lets the control plane express composite states. For example, while a P0 is waiting on a user decision, a fully independent P1 can still proceed; the user receives a concrete question while the agent simultaneously advances safe work that doesn’t depend on that gate.

4. Generate the fresh packet for this round

The Codex App’s heartbeat task body can stay stable, responsible only for asking the executor to re-read LoopX CLI truth. The packet for each Turn is generated from the latest state, including the current selected work, scope, gate, evidence requirements, stop conditions, and correct CLI commands.

What stays stable is the host entry point; what changes is the process protocol returned by the CLI.

5. Execute one bounded action

The runtime only executes the action authorized in this round—for example, modifying one focused patch, reading PR status once, running an experiment, or generating a validation report. Large goals advance through a successor graph, rather than letting a single session hold an infinite loop.

6. Independently validate the result

A command returning 0 only proves the process exited successfully. Implementation work still needs diffs, tests, and target behavior; research work still needs metrics, lineage, holdout, and guardrails; external effects need readback proving they applied to the correct object.

7. Persist writeback and re-read

Results, evidence, effect receipts, todo transitions, and vision checkpoints are written back to canonical state. Then the committed state is re-read to confirm that the projection and sink postconditions hold.

8. Record spend and the next wake-up

A quota slot represents one effective advancement, not one model call. It is spent only after validated writeback forms material progress; guided previews, read-only status, scheduler ACKs, monitor no-changes, and quiet no-ops do not spend.

This transaction can be compressed into four invariants:

observation != transition

proposal != authority

tool success != accepted progress

accepted progress = validation + durable writeback + committed readback

The Turn Journal records only whether this round’s transaction reached host result, validation, writeback, spend, or scheduler ACK. After a process interruption, it resumes from the stage that wasn’t completed; external effects already done are not re-executed. It handles transaction recovery, while goal/event state continues to handle long-term facts.

Running Steadily and Running Well Are Two Different Mechanisms

A long-horizon system must first run steadily: it recovers after session restarts, doesn’t spin when external state hasn’t changed, doesn’t repeat effects already executed, and fails closed on actions that cross authority boundaries.

On top of that, it must run well: local actions continuously serve the long-term goal, routes can be adjusted when evidence changes, plans aren’t executed mechanically when they’ve been falsified, and an exhausted work frontier isn’t mistakenly treated as completion.

Running steadily: durable identity + bounded Turn + receipt + replay

• monitor/backoff + gate/workspace boundary

Running well: vision + acceptance + evidence + outcome floor

• replan + self-repair + independent quality gate

The first set of mechanisms keeps the execution chain unbroken; the second keeps it converging in the right direction. Replan is the key transition connecting the two sets: it reads committed evidence, judges whether the current frontier is still valid, and writes the new long-term judgment back into a work graph that the next round can execute.

Work Graph, Peers, and Authority Boundaries

A long-horizon task is usually a dynamic work graph. Todos are connected through successor, supersede, dependency, resume condition, and no-followup links; the current runnable frontier is computed from multiple constraints together:

priority

• task class

• decision scope

• claim / lease

• capability availability

• repository / write scope

• dependency / resume condition

= current runnable frontier

Claim, lease, capability, workspace, and gate each solve a different problem.

• Claim indicates that a particular peer is currently responsible for a piece of work, reducing duplicate effort;

• Lease provides TTL-bound execution occupancy in true concurrency or exclusive-resource scenarios;

• Capability states whether the current runtime has the ability to execute;

• Workspace guard constrains which repository, worktree, and write scope operations are allowed;

• Gate stores direction, permission, and risk decisions owned by the user.

LoopX currently uses an equal-peer runtime. Registered agents have no permanent primary/side hierarchy; current ownership comes from todo claims, continuation policy, or explicit goal-local lifecycle authority. A task-scoped collaboration does not automatically earn long-term permissions.

Handoff follows the same boundaries. It transfers a recoverable frontier and lineage, not a copy of the full transcript. A new peer, after reading durable state and the fresh environment, should reconstruct an equivalent objective, authority, validation surface, next action, and stop condition; it must also pass quota, gate, capability, and workspace guard again before further business execution.

Waiting, Monitors, and Stateful Backoff

A ten-day long-horizon task won’t stay runnable the whole time. CI, review, experiments, user judgment, and external dependencies all create waiting windows.

LoopX expresses such states with continuous_monitor. A monitor carries at least target identity, next due time, the last result fingerprint, a consecutive no-change counter, and successor rules.

A due poll has only three primary outcomes:

1. External facts changed: write new evidence and create a successor, gate, or terminal candidate;

2. External facts unchanged: update the result hash, no-change counter, and next due time; quiet no-op;

3. Observation cannot form a trustworthy conclusion: record a blocker or repair obligation, without fabricating progress.

Monitors that aren’t due don’t invoke strong models. Polls that are due but show no change don’t spend, and don’t repeatedly output “still waiting.” Stateful backoff saves consecutive waits under the following identity:

goal + agent + lifecycle reason + monitor target / selected work

For the same identity, backoff can progress from 15 minutes to 30 or 60 minutes; after todo, gate, evidence, or target changes, cadence returns to the initial value for the new state.

The scheduler still remains a derived protocol. LoopX produces cadence proposals; the host actually modifies the RRULE or next trigger time, then writes back an ACK with the proposal identity, reset token, and actual readback:

proposal

-> host effect

-> host readback

-> durable scheduler ACK

The ACK proves the host applied this proposal, but it doesn’t constitute business delivery and doesn’t spend.

This quiet contract keeps the system alive while waiting, without burning tokens, logs, and user attention on high-frequency idle churn.

How Long-Horizon Tasks Keep Converging: Evidence, Acceptance, and Replan

Stable recovery answers “can we still continue”; long-term convergence answers “is the current route still worth continuing.” A todo set ten days ago may already be falsified by new evidence; a phase may finish with no successor; an agent may produce locally correct but globally ineffective actions.

LoopX forms a second feedback loop with Vision, Acceptance, Evidence, Outcome Floor, Replan, and Self-Repair.

Vision Provides a Cross-Turn Direction Baseline

The Goal describes what the current phase must deliver; the bounded Agent Vision further stores that peer’s role scope, acceptance summary, advancement policy, and replan triggers. It doesn’t choose the todo for this round on behalf of the Kernel, nor does it grant authority; it provides a reviewable long-term direction for every local execution.

Vision

-> Goal boundary / acceptance

-> Todo frontier

-> bounded delivery + evidence

-> acceptance audit

-> continue / replan / vision patch / terminal

Every material refresh must leave a vision checkpoint, with only three kinds of outcomes:

1. New evidence changes direction: write a bounded vision patch;

2. The long-term judgment still holds: state an unchanged reason aligned with the current evidence;

3. Acceptance is satisfied or the old route is invalid: close, retire, or supersede the current frontier with evidence.

A missing checkpoint creates a vision_checkpoint_missing acceptance gap. This gap doesn’t crudely freeze all safe work, but it does prevent the system from going terminal immediately after local todos are done. It turns “has the user’s goal quietly changed” and “does the current route still serve acceptance” into checkable questions every round.

Evidence Determines Whether a Route Still Holds

Implementation deliveries need artifacts, focused validation, diff/commit lineage, and external readback; experiments need code/data revision, metric receipts, holdout, and guardrails; monitors need stable targets, fingerprints, and changed/no-change receipts.

A credible refresh forms a proof pipeline:

work effect

-> machine-visible delta

-> refresh-state run record

-> projection / external readback

-> focused validation

-> spend-slot binds latest unconsumed delivery run

LoopX also records delivery scale and delivery outcome. A multi-file diff can still be surface_only, while a very small transition that unlocks a key blocker is outcome_progress. The Outcome Floor identifies consecutive surface-only changes, repeated observations, or no-progress states, and requires the next round to advance the primary result or enter self-repair.

This makes replan inputs come from factual changes, not from a model suddenly “changing its mind.” PR checks, reviews, merge state, dev/holdout results from experiments, user-modified acceptance criteria, and even monitors with no change across consecutive runs can all form replan evidence with identity.

When Replan Triggers

LoopX looks for several kinds of structured signals in the work graph and run history:

• Succession gap: an advancement todo is complete, but there is no successor and no evidenced no_followup;

• Vision acceptance gap: the current acceptance is still unmet, and there is no runnable frontier that can close the gap;

• Long todo chain: consecutive local todos exceed the bounded review threshold, requiring a check for local-optimum traps;

• Monitor no-change streak: the same monitor target has repeatedly shown no change, and continued polling has no information gain;

• Monitor frontier exhausted: advancement work has run out, leaving only the watch lane; the system must decide whether to keep observing, set an expiry, create a successor, or declare a blocker;

• Periodic review / no-progress: a review cadence is reached, or consecutive run records show repeated actions, backlog mismatch, phase transitions, stale evidence, or evidence contradictions;

• External direction change: a user, reviewer, or authoritative external system changes boundaries, acceptance, or executable conditions.

These signals only generate a replan obligation; they don’t directly authorize arbitrary new actions. Replan remains constrained by the original goal boundary, user gate, capability, workspace, and agent scope.

Replan Has an Explicit Decision Precedence

A long-horizon system cannot overturn a plan at the sight of any new information. The Kernel first protects existing authority and the executable frontier:

existing scoped obligation / blocking handoff gate

-> ready deferred successor / blocking user work

-> succession or acceptance gap

-> bounded long-chain review

-> stalled monitor / exhausted watch frontier

If an existing deferred successor meets its resume condition, the system resumes it directly; if a user gate owns the next decision, replan cannot bypass it; if the current agent still has a legitimate runnable advancement, the system generally prioritizes real work over letting a monitor-derived replan seize the frontier.

Conversely, monitor quiet is only a candidate decision. When a lane has reached its no-change threshold and the current advancement is empty, replan precedence overrides quiet, forcing the system to address “why has there been no new information” rather than scheduling the same poll for the next round.

When a P0 is waiting on a user decision while an independent P1 can still run, the interaction contract simultaneously outputs the specific user question and the P1 delivery. Replan only reorganizes the affected decision scope; it doesn’t turn a local gate into a pause button for the entire goal.

Replan Must Write Out a New Work Frontier

An effective replan must produce at least one machine-visible delta:

• keep the current route, while declaring a new checkpoint or watch expiry;

• split todos that are too long or too coupled;

• add successors that can close an acceptance gap;

• retire / supersede branches that have been falsified, duplicated, or expired;

• convert work waiting on external facts into monitors, with explicit resume conditions;

• establish concrete user gates, with decision scope and a safe fallback;

• patch Vision, acceptance, or priority;

• repair capability / workspace routes so existing work becomes executable again.

replan evidence

-> bounded frontier delta

-> durable writeback + readback

-> fresh interaction contract

-> new selected work / wait target

-> new scheduler identity

Merely recording “replanned” doesn’t clear the obligation; a result without successor, resume condition, Next Action, gate, or vision patch is identified as replan_noop. This rule turns replan from model reflection into an executable state transition.

Replan, Self-Repair, and Dreaming Each Handle One Layer

Replan adjusts the current goal’s work graph. Self-Repair handles stalls caused by the control plane itself—for example, projections losing fields, claim/lease drift, wrong workspace routes, host effects without receipts, or a scheduler repeatedly repeating the same invalid cadence. Dreaming can explore future directions and produce proposals, but it doesn’t override the current runnable frontier.

When two consecutive rounds show no material progress, Self-Repair systematically audits:

exact interaction contract

-> agent-scoped evidence and latest run

-> selected todo / claim / lease

-> capability / workspace / gate

-> projection / host / scheduler effect

-> lowest-layer repair delta

-> focused validation + readback

Repair does not recover by lowering gates, guessing missing state, or renaming no-progress as success. If the error comes from a projection, fix the projection and add regression tests; if it comes from a host receipt, complete the effect/readback contract; only if the route itself is invalid do we return to replan.

Terminal Is Also an Acceptance Decision

open todo count == 0 only says the current list is temporarily empty. Terminal closure also checks user gates/actions, active monitors, successor/handoff, replan obligations, acceptance gaps, retryable projection postconditions, blocker/resume routes, and evidenced no_followup.

This closed loop allows models to make mistakes, plans to expire, the external world to change, and users to change direction mid-way. The system doesn’t require a fully correct ten-day plan written up front; it requires each phase to leave enough evidence to decide whether to continue, wait, pivot, repair, or end, and then write that decision into executable state for the next round.

Layered Quality Gates

Errors in long-horizon agents often don’t manifest as function failures. An agent may select the wrong todo, misunderstand a gate, repeatedly spend on a monitor with no changes, lose a scheduler ACK, or use test results from an old revision to validate a new artifact.

Therefore, a quality gate first needs an independent semantic oracle: given source facts, specify the correct decision, prohibited outcomes, authority owner, and fail-closed conditions, then test the implementation against it. We cannot infer “expected values” backwards from current program outputs.

LoopX’s quality surface is layered from near to far:

1. unit / contract: validates schemas, pure transitions, and rejection of illegal states;

2. focused deterministic smoke: validates one delivered CLI path or cross-module path;

3. public-safe decision replay: replays final decisions from independent source facts;

4. risk-based canary: selects the minimal cross-surface combination based on Git diff;

5. actual-default model qualification: verifies that a real model can understand the current default packet;

6. exact-commit release qualification: confirms that all receipts belong to the same clean commit, tree, and version;

7. matched outcome baseline: requires corresponding evidence only when claiming benchmarks or long-horizon benefits.

Model behavior passing cannot override deterministic contract failures; full test passes also cannot replace focused regressions for known failures. Each layer proves the semantics it owns, and the acceptance audit ultimately merges them into a delivery decision.

PR Issue Fix: An Execution Chain Across Multiple Days

Take an open-source repository PR issue fix as an example; the full chain passes through the following states.

1. GitHub provides authoritative facts such as issue, repository, checks, review, and merge state;

2. The Issue-Fix Capability reads the issue and generates feasibility and a stable domain key;

3. The Kernel creates a fix_pr advancement todo and checks scope, claim, capability, and an independent worktree;

4. The Runti