From one-shot agents to long-horizon control

1. More useful work, less human attention

I started LoopX with a practical goal: let agents take on more work, especially the work that otherwise keeps pulling a person back to the keyboard. As projects grew longer, the bottleneck shifted. A capable model could solve the next problem, but someone still had to remember the objective, route work, check evidence, resolve permissions, and tell it when to continue.

LoopX optimizes two things together: useful agent output and the human attention required to obtain it. Output depends on model capability, useful parallelism, time utilization, and alignment with the goal. LoopX concentrates on the latter three, while the underlying harness and model execute the work.

The engineering target is straightforward: keep working reliably when no human decision is needed, and improve the direction of the work when a person intervenes. That includes quiet waiting when facts have not changed, replanning when a route stops working, repairing contradictory control state, and stopping when acceptance is satisfied.

This is a throughput problem. A fast reply matters, but a project also benefits when several independent tasks make progress while its owner is elsewhere. The useful measure is validated output per unit of compute and human attention.

Deliver a faster long-context inference backend

Imagine giving an agent team this goal: deliver a long-context attention acceleration backend for an open-source inference engine. The work spans a kernel repository and a serving repository. It needs a reproducible baseline, competing optimization hypotheses, remote GPU experiments, numerical checks, integration under concurrent traffic, and a release candidate with a rollback path. This constructed scenario illustrates the control contracts; the chosen host and providers supply the experiment tools.

A kernel specialist can investigate memory movement while a serving specialist builds a realistic workload replay. A verification peer can challenge numerical tolerances and boundary cases. The owner authorizes development and a bounded experiment budget, and retains the decision to publish the release. Some work can proceed in parallel; other work must wait for a scarce GPU slot, a compatible kernel revision, or a result that invalidates the current hypothesis.

Several days later, “the benchmark is green” tells us very little. Which model, hardware, input lengths, concurrency, and revision were measured? Did throughput improve at the expense of tail latency? Was an apparent gain caused by a changed workload? Did the remote experiment start before the submitting session lost its connection? The next worker must recover these distinctions.

2. What a semantic control plane preserves

A model has a finite working context. Summarization and subagents can help manage it, but a summary alone cannot reliably enforce ownership, concurrency, permissions, or idempotency. A project that crosses sessions needs durable answers to a different set of questions:

• What is the current objective, and what would count as acceptance?
• Which facts and decisions are still current?
• Who is responsible for each piece of work, and which actions are authorized?
• Did an external operation actually happen?
• Is another turn worth its cost, and what should happen after it?

These questions define the semantic control plane. A useful way to locate it in the agent stack is to separate four kinds of recovery.

A runtime restores the execution environment. LoopX preserves what the agent is doing, why it is doing it, what has been proved, and whether the next step is permitted. Codex threads, Claude Code sessions, and CLI runners can act as replaceable workers around that shared state.

Four terms keep the accounting precise:

Turn       = a bounded execution window
Result     = an artifact or observation returned by a turn
Transition = a validated, permitted state change
Progress   = a durable transition relevant to acceptance

A convincing answer is a result. It becomes project progress when the relevant validation and state transition have been accepted. See the architecture and vocabulary.

How this relates to workflow engines and memory

Existing systems already solve important parts of durability. LangGraph checkpoints preserve graph state for recovery, human intervention, and time travel. Temporal Activities isolate external work and need application-specific idempotency for safe retries. LoopX adds a project-level interpretation: which evidence satisfies acceptance, which actor may commit a change, and whether the current route should continue.

Memory helps retrieve a useful fact. Authority decides whether that fact can justify an action now. Remembering that an owner once approved a release is useful context; treating it as permission for every future release would be a bug. Likewise, faithfully resuming an obsolete plan can be operationally durable and still waste the entire remaining budget. Recovery needs to preserve the goal and re-evaluate the route.

3. External state, reconstructible views

LoopX separates canonical state from projections. The registry identifies goals, project connections, policy, and authority sources. An append-only ledger records identified events. Run history and evidence connect execution to artifacts, validation, failures, and resource use. An active-state workbench provides a human-readable compatibility surface.

Status, task graphs, review packets, and dashboards are projections of those facts. They can be rebuilt; their appearance does not independently authorize a transition. The event-sourced state contract defines replay and identity: replaying the same event is idempotent, while a conflicting event with the same identity must fail closed.

An open Todo illustrates why this matters. It might be waiting for approval, for a pull request to merge, or for a monitor to observe a change. Another agent might have claimed it. Its host might lack a capability, its workspace might be wrong, or a later route might have superseded it. “Open” is insufficient to decide whether to execute it.

Open work
  → dependencies and resume conditions
  → scoped authority
  → claim and lifecycle ownership
  → host capability and workspace
  → freshness and evidence
  → quota and the current runnable frontier

Human decisions belong in the same durable model. “Wait for my review” or “This route may continue” has a particular scope. The Decision Scope contract binds that authority to an action, lane, goal, or project. An independent authorized task can continue while one path waits.

Completion also needs an explicit boundary. Closing a Todo supplies evidence about one piece of work; it does not automatically satisfy the goal. If the runnable frontier is exhausted while acceptance remains open, the control plane needs a new route or an evidence-backed explanation of why no follow-up is appropriate.

In the inference example, “wait before publishing” applies to the release. It does not erase the authorization to analyze profiles or validate compatibility. A useful projection can show three facts together: a kernel candidate meets its local checks, the service-level latency target remains unproved, and publication awaits a decision. A single “blocked” label would hide runnable analysis; “done” would hide the unclosed acceptance gap.

4. A CLI that helps agents make the next decision

An executable Kanban is a useful picture of LoopX. Its cards have stable identities, dependencies, claims, scope, evidence, and successors. Moving a card means requesting a validated state transition. The board is a view of the contract.

The CLI makes continuity part of the interaction. Completing work can create a successor, link an existing successor, or record a structured no-follow-up rationale when acceptance is satisfied. This keeps a locally successful action from leaving the larger task disconnected. The details live in the Todo contract.

The interaction contract separates what the person needs to hear from what the agent must do. A quiet notification channel can coexist with an obligation to execute a bounded piece of work. Conversely, a scheduled wake may legitimately produce no work when the state calls for waiting.

This protects both sides from overload. The human-facing view highlights decisions that deserve attention. The agent-facing view gives the current authority, next action, validation, and stop conditions. Neither should require reading every old conversation to reconstruct the present.

A host scheduler supplies wakeups; the LoopX CLI and lightweight skills supply the governed work contract. A scheduler prompt should preserve this lifecycle and obtain current decisions from state, rather than accumulate a second project plan in prose.

A handoff that contains a decision

The useful writeback for a kernel experiment names the exact candidate, comparison conditions, measured boundary, remaining gap, and successor. The following is an explanatory record, not a CLI payload or a claim about a real run:

Completed slice: evaluate attention kernel candidate A
Evidence: pinned candidate + baseline + workload + result manifest
Established: numerical checks pass; isolated kernel is faster
Remaining gap: service p95 under concurrent traffic is unproved
Successor: replay the fixed workload against both serving builds
Authority: bounded experiments allowed; publication remains gated

Compare that with “attention optimization complete, benchmarks pass.” The explicit record prevents a local microbenchmark win from becoming an unsupported service-level claim. A result manifest should identify the code, environment, workload, and measurement method so a later peer can reproduce or challenge it.

The actual todo complete interface supports --next-agent-todo for a successor and --no-follow-up with a rationale when appropriate. These are lifecycle operations: quota-bound repository advancement must first satisfy the matching writeback and spend receipts. Copying a completion command without its current interaction contract can violate that order. Let the host obtain the current contract, then execute the actions it specifies.

5. Effect Programs: recovering what actually happened

For the functional-programming perspective in this section, see 齐梦星空’s series on Agent Loop, Kleisli arrows, and function composition.

A pure function is often described as A → B. An agent action looks more like A → F[B]: it can involve permissions, persistence, time, budget, external calls, and failure. The model's proposal and the world's resulting state are distinct facts.

Goal state → effect request → authority / quota interpretation
  → external operation → observation / readback → receipt
  → durable transition → next goal state

An Effect Program gives those steps identity, order, receipts, and failure semantics. Without them, a crash after a successful external operation can lead to a duplicate retry. A delayed acknowledgment can settle the wrong turn. Different modules can gradually invent incompatible orders for writing state, recording spend, and closing work.

The public EffectTurn implementation describes an interaction through four serializable slots:

interface EffectTurn<Context, Decision extends string> {
  request: EffectRequest<Context>;
  interpretation: EffectInterpretation;
  observation: EffectObservation<Decision>;
  next_effect: EffectNext;
}

Settlement has three mutually exclusive next actions: failed, execute, or complete. A selected turn follows a fixed order:

Settlement identity binds the goal, agent, and turn instance, plus the selected Todo or replan obligation. Matching receipts identify committed steps. Recovery checks that identity and continues from the uncommitted suffix. The effect-program tests cover order, replay, failure, and committed prefixes.

A remote GPU experiment submitted just before a disconnect

An authorized experiment submission reaches the remote scheduler, but the agent’s connection drops before it records the response. Retrying blindly might launch a duplicate job and consume the budget twice. Recovery first uses the provider’s request identity or job identifier to read back whether the submission was accepted. If the provider cannot establish the outcome, that branch remains unresolved until it can be reconciled.

A confirmed submission proves only that a job was accepted. It does not prove that the job finished or that the candidate met acceptance. The submission turn can settle its bounded outcome and create a monitor; a later validation turn evaluates the result manifest. Both turns need their own identities and receipts.

This is a recovery contract for governed settlement. Exactly-once accounting inside the control plane does not make every arbitrary external API operation exactly-once; external operations still need provider-specific idempotency or readback. Effect Programs also preserve domain ownership: the settlement algebra does not replace goal planning with a universal executor.

There are two budgets to reconcile here: the external experiment budget and the control plane’s turn accounting. A LoopX spend receipt does not cancel a duplicate GPU job or prove that a remote charge was correct. The provider must establish the external outcome; the kernel must settle the matching turn. Keeping those responsibilities separate makes an expensive ambiguity diagnosable.

6. Knowing when to work, wait, and replan

Quota compiles a decision

quota should-run considers health and safety, operator gates, evidence waits, and focus waits before compute budget. It combines the selected work, capabilities, workspace, and scheduler state into an interaction contract. The result can authorize bounded work, identify a decision gate, preserve a wait, throttle delivery, or request repair. See quota allocation.

Validated durable writeback precedes quota spend. Quiet skips, preflight failures, and dry runs do not count as delivery spend. A spend record must remain attributable to the work just completed, even if a refresh has already selected a different next action.

A small planning horizon around the current task

A typed planning inventory supports several views. The action portfolio offers a few current candidates. The planning horizon shows nearby successors, dependencies, resume links, and acceptance gaps. On-demand Todo detail expands the cold path, while a task graph supports diagnosis.

Visibility does not grant execution rights. A relevant task claimed by another agent is coordination context. A runnable unclaimed task still requires a claim and the normal checks. The planning-horizon protocol keeps the read model separate from selection authority.

For open-ended research, the Explore capability adds an evidence graph of questions, hypotheses, experiments, and findings. Its planning layer can organize branches; execution still follows the normal LoopX lifecycle. This preserves failed routes and reasons to try combinations without putting every exploration detail into the next prompt.

Wait for a new fact

A monitor-based resume condition needs a material change after waiting began. A generation fence compares the current monitor generation with the saved baseline. Old results, unchanged polls, and duplicate replay cannot count as a fresh signal. See the resume-condition implementation.

Independent fallback work can keep moving while a main path waits. Polling without new facts should back off; repeated lack of progress needs an explicit blocker, expiry, successor, or replanning decision.

Replanning has an identity and an outcome

Replanning becomes a machine-enforced obligation when the current route no longer supports acceptance. Its obligation_id identifies that generation of the problem. A late acknowledgment of an older obligation cannot close a newer one.

Triggers include repeated semantic stagnation, broken Todo continuity, acceptance gaps, overly long task chains, periodic review, and an exhausted frontier. Legal waits and ordinary scheduler wakeups have their own semantics; they do not automatically imply replanning.

Settlement requires the exact current obligation and an accepted semantic change: for example, a runnable successor, a concrete blocker, a new evidence-backed route, or a supported no-follow-up outcome. Rewording the plan or sending an acknowledgment alone does not satisfy it. The Goal / Vision / Replan contract defines the boundary.

What a real replan changes

Suppose the new kernel improves isolated throughput, yet two serving experiments still miss the p95 target. Another kernel tuning pass may be the wrong next step. A useful replan records that the local speedup did not establish end-to-end value, proposes a competing hypothesis about scheduling or memory contention, and creates a controlled experiment that changes one factor. The integration route then depends on that result. These are illustrative observations, not measurements from a real run.

The control plane can require a meaningful transition and reject a stale acknowledgment. The quality of the new hypothesis still depends on the model, tools, evidence, and human judgment. Typed obligations make a failure visible and recoverable; they do not manufacture insight.

7. An interface for judgment

As agents work across code, documents, research, and communication, an operator needs a concise view of the decisions ahead. Which project needs judgment? Which high-priority route is blocked? What can proceed independently? Has a monitor observed a meaningful change? Is recent activity producing useful progress?

The intended loop is signal inbox → anchor selection → performance review. External signals enter a bounded inbox. People and agents choose a few valuable anchors. Results are reviewed for value, quality, control, cost, and learning, and that feedback informs the next round.

Reports are an attention boundary. A meaningful delivery, stage closeout, route decision, or major blockage can justify an update. Ordinary refreshes and unchanged monitors should not repeatedly interrupt the owner. Related events can be grouped and deduplicated. The periodic-report capability and presentation RFC separate existing mechanisms from the broader product direction.

The owner supplies direction and a standard of quality

My experience with longer agent work changed where I spend time. Early on, I managed cards and repeatedly restarted sessions. As continuity improved, it became more valuable to inspect the artifact, sharpen the objective, and explain why an apparently acceptable result was still weak. “This diagram does not explain the failure boundary” is a better signal than another generic instruction to continue.

For the inference project, the decisive intervention may be: “Our users care about interactive latency under mixed traffic; a higher offline throughput score is insufficient.” That judgment changes the workload, acceptance, and next experiment. It should survive the current conversation. Repeatedly pasting it into new sessions is a sign that the system is losing an important part of the project.

I want the operator surface to make this kind of feedback cheap: show the artifact, the evidence, the unresolved choice, and the expected value of another turn. More parallel agents create value only when review and coordination do not grow at the same rate. Human attention is part of the operating budget.

8. Digital teams need explicit authority

Parallel workers need a common goal, distinct work boundaries, and a reliable handoff. LoopX models equal peers: an agent identity describes a working role, not a permanent hierarchy. A temporary coordinator can route work without automatically gaining authority to complete or reassign another peer's tasks.

These distinctions become more important across hosts. Shared Goal Authority separates semantic transition rules from storage. The authority layer owns revisions, lease epochs, receipts, and conflict decisions. A storage provider supplies loading, compare-and-put, and durability. Storage generation, authority revision, and lease epoch describe different things and need separate identities.

The Shared Goal Authority RFC and authority-store implementation document this work. Cross-host productization remains an evolving validation area. The existence of an interface should not be read as a claim that arbitrary distributed teams are already a turnkey product.

A good handoff is an interface between work boundaries. In a cross-repository change, that may mean an API contract and a pinned revision, followed by a consumer compatibility check. It rarely means sending another agent the whole conversation and hoping it infers which decisions are current. Start parallelism where the acceptance boundaries can be separated; tightly coupled edits may be cheaper to keep with one worker.

9. Let capabilities evolve around a stable kernel

LoopX keeps goal, Todo, gate, quota, evidence, recovery, and scheduling semantics in the kernel. Domain behavior evolves through three independent boundaries:

• Capability: the outcome promised to the caller, including domain policy and validation.
• Provider: the bounded local or external implementation, returning observations and readback.
• Extension: optional delivery and lifecycle, including installation, checks, enablement, upgrades, and rollback.

Agent → Capability → Provider → external or local system
Readback → Capability validation → Kernel transition

Installing an extension does not itself grant goal authority or external write permission. A provider does not decide whether the kernel accepts a transition. This distinction lets optional integrations coexist with a provider-neutral core. See Extensions and Capabilities.

Hooks add bounded behavior at specific phases. A turn-start hook can obtain a scoped observation. An interaction-projection hook contributes a read-only view. A post-writeback hook can record an effect-free intent after the primary state has committed. That intent still needs its own authorized lifecycle before any external delivery.

The practical route to code evolution begins with evidence from real work. Capture a small implementation seam, make its observations and failure boundary explicit, give it a separate lifecycle when needed, and stabilize a capability when the caller outcome is clear. Only recurring cross-domain invariants belong in the kernel. This gives experimentation room without duplicating the authority model.

In the inference scenario, a domain capability would own the experiment’s comparison contract and result validation. A GPU scheduler provider would own job submission, status readback, and cancellation within the authorized scope. Swapping a cluster provider should not change what counts as a valid comparison. This is a placement example, not a claim that a particular GPU integration ships with LoopX. An integration that only transports a result may need a provider and lifecycle without a new capability.

10. What the evidence can tell us

A long-running project and a stronger benchmark result establish different things. A showcase can demonstrate continuity across turns, waits, reviews, and recovery. Its elapsed time is not uninterrupted model reasoning time. A benchmark asks what a particular system completes under specified conditions.

The wider research makes the setup worth taking seriously. OpenAI reports that UK AISI’s cyber-range evaluation improved performance by up to 59% when token budgets increased from 10M to 100M. This concerns that tested setting; it is not a LoopX result or a promise that longer runs always help. It motivates measuring harness and budget together. See OpenAI’s evaluation methodology discussion.

SWE-Marathon: gains, cost, and a failed integration mode

The public LoopX study, contributed by BouwenZhou, compared five modes on 15 matched SWE-Marathon v1.1 tasks: 75 trials, one per task and mode. It used GPT-5.6 Sol at high reasoning effort, Codex 0.151.0, LoopX 0.5.3, Harbor 0.20.0, and a timeout multiplier of 0.3. These are historical experiment versions, separate from the implementation revision discussed elsewhere in this article.

The heartbeat arm completed one more task than the native goal baseline, with a 0.011 higher mean partial score and about 56% higher total cost. The codex-cli arm performed worse and included one build failure. That failure remains in the common denominator. The study describes a mismatch between an attended host mode and unattended continuation as a possible explanation; this is a hypothesis, not an isolated causal result. Settings and limitations · Pinned aggregate data.

This is an exploratory comparison with multiple mechanisms changing together. There are no repeated trials in each cell from which to estimate variability. Much of the observed improvement over plain Codex was already present in the native goal baseline. The table supports investigating continuation and integration quality; it does not establish a universal LoopX uplift or the efficiency of every kernel mechanism.

A case where further verification mattered

The public case analysis, contributed through Wanli-Lee’s case-insight projections, offers a concrete example. On the zstd-decoder task, plain Codex stopped after 52 steps and six visible fixtures; its final evaluation passed 25 of 37 hidden checks. The SSH LoopX arm used 135 steps and passed 37 of 37. The heartbeat arm used 453 steps, developed a 156-check acceptance suite, and also passed 37 of 37. These counts come from the published aggregate case analysis; they are observations of those runs.

The useful hypothesis is that extra turns help when they produce new evidence and repairs. Continuing to reread the same plan can consume more budget without improving the result. The engineering target is a stopping rule sensitive to acceptance gaps, failed hypotheses, and diminishing returns.

The next experiments should repeat matched trials, report variance and cost per success, and separately vary continuation policy, evidence retention, and recovery. Interrupted effects and peer handoffs need dedicated tests too. The research program outlines that wider space. A promising case is a reason to test a mechanism more carefully.

11. Start with one real project

Begin with the Developer Book and the Quick Start. Connect one project through your existing agent, inspect its goal and next safe action, and give it a bounded task with a visible acceptance condition. Add parallel peers and optional integrations as the work requires them.

After installation, these commands inspect the setup and connected project:

loopx doctor
loopx status

Make the first loop small enough to judge

1. Choose an observable outcome. For the inference project, pin the workload, quality envelope, latency target, and baseline before delegating.
2. State the authority boundary. Separate development, experiment spending, and publication authority. Give enough scope for useful independent work.
3. Inspect one complete cycle. Follow selection, execution, validation, writeback, and the successor. Confirm that a fresh session can recover the current facts.
4. Test a wait and a correction. Wait for a remote result, allow independent analysis, and correct an insufficient performance claim. Check that the next turn inherits both the wait and the feedback.
5. Expand where the evidence supports it. Add peers for separable work. Watch coordination cost, repeat failures, and the amount of attention required.

A short, well-specified task that fits comfortably in one session may be best served by the agent you already use. LoopX becomes interesting when continuity, scoped decisions, evidence, and coordination become recurring work of their own. Its overhead should earn its place in the project.

My ambition is a digital team that can carry useful work across projects and hosts while remaining understandable to the people directing it. That is a direction to build and test, not a claim that all the pieces are finished. Opening the project also changes the work: other developers bring different tasks, failure modes, and standards. The strongest version of LoopX will come from those concrete demands.

References and further reading

Original essay

• Original Chinese essay on Feishu: From one-shot agents to long-horizon control. The longer original and this edited bilingual edition are maintained separately.

LoopX implementation and experimental evidence

• LoopX architecture: the design of goals, state, and execution boundaries. For operating instructions, start with the Developer Book.
• Effect Program implementation and its tests: settlement order, receipts, replay, and recovery from interruptions.
• Bilingual SWE-Marathon research brief and pinned aggregate data: settings, results, costs, and limitations across five execution modes.

Agent Loop and functional programming

A Chinese-language Xiaohongshu series by 齐梦星空 (May 2026), exploring effectful computation, tool calling, and composition:

• Agent Loop as an effectful program (1)
  2026-05-11
• Tool Calling as a Kleisli arrow (2)
  2026-05-12
• Function composition in the Agent Loop (3)
  2026-05-14

Related public materials

• OpenAI: A shared playbook for trustworthy third party evaluations: how harness and budget choices shape evaluation claims.
• LangGraph: Persistence: checkpointing, recovery, and human intervention.
• Temporal: Activities: external work, retries, and application-level idempotency.