Where does LoopX fit?
Complex tasks, open-ended exploration, and continuous delivery

Start with the work, then choose the abstraction

These categories can nest. An agent maintaining a repository over time may first explore a performance problem, then complete a fix with clear acceptance, and finally follow the pull request through review. The first two categories mainly describe how work is solved; the third adds an ongoing responsibility and a stream of newly arriving work.

What should persist is the work—and the reasoning behind its decisions.

01 / Finish a complex task

“Implement a decoder that conforms to the specification” sounds definite. Yet after the visible examples pass, edge inputs, memory safety, or compatibility may still be missing. Start a new session, and previously confirmed failure conditions may disappear from context.

LoopX keeps the goal and its acceptance gaps continuous across turns, then carries new evidence into the next decision. The model implements and judges; domain validators check the result; the control plane records which results were accepted and which work remains.

The best-fitting tasks usually span repeated validation, waiting, or handoffs. Existing agents may already be enough for small work that can be accepted in one session; an added control plane must justify its overhead.

Benchmarks: start with LHTB, then three supporting signals

Start with recovery and regression across long-horizon domains, then use three software-engineering studies to examine continuation, delivery, and validation. The four studies differ in tasks, model settings, and measurement rules. Each needs to be read on its own terms; the current evidence does not establish a universal LoopX gain.

Recover progress, preserve working results, and check whether continuation closes acceptance gaps.

The four studies offer local positive observations while exposing regressions, cost, and attribution problems. Matched budgets and repeated experiments should examine recovery, rollback, delivery, and counterexample-driven repair separately.

Withdrawn SSH Goal and Codex CLI scores and conclusions from SWE-Marathon and DeepSWE × Sol are not used in these comparisons.

02 / Find a path through open-ended exploration

“Find a better algorithm” does not come with a fully specified task chain. Real progress may validate a hypothesis—or eliminate a promising-looking route. If only successful conclusions survive, the next run can easily repeat ideas that were already disproved.

Explore provides an optional evidence graph and bounded branch planning: nodes represent questions and findings, while relationships express supports, refutes, and leads_to. Planning suggestions still pass through normal execution boundaries; the graph neither launches workers nor grants spending authority.

Auto Research organizes this pattern as research work: select a topic, propose hypotheses, run experiments, evaluate independently, and produce a report. Existing protocols and commands provide a foundation, while the public showcase still contains blueprints and items awaiting validation. Real effectiveness must be demonstrated on specific tasks.

Place RSI here, but keep the claim precise

When the object of improvement is the agent’s own tools, strategies, or harness, the work becomes self-improvement research. Changing its own code only creates a candidate; sustained improvement still requires independent evaluation, cross-task generalization, regression checks, and rollback.

Applying past experience to a later decision, automatically generating experiments, and modifying the harness are different levels. We can discuss an experimental path toward recursive self-improvement (RSI) here; we cannot equate “automatic iteration” with open-ended self-improvement already achieved.

03 / Own continuous delivery

For a pull-request or issue-fix digital worker, the job begins by deciding whether the issue is worth fixing. After delivery, CI, review feedback, branch changes, and the merge result still remain. New tasks keep arriving, and external facts keep changing.

Responsibility does not end when the patch is generated.

This synthetic scenario starts after a fix has been submitted while CI and review are still running. Choose an external state to see how the next step changes.

This interactive diagram is a design explanation. It is not connected to a real repository and performs no GitHub operations.

Here, a “digital worker” means continuing responsibility, boundaries, memory, and a feedback loop. Its value should be judged by accepted fixes, reopenings and regressions, handling latency, delivery cost, and how often a person must repeatedly supervise it. Pull-request count and uptime are only process signals.

The richer the domain, the clearer the division of responsibility must be

For checks failing, a domain capability can propose a successor task to repair CI. The fact that a repair is needed does not itself grant repository write or merge authority. In an experiment, check state becomes metrics and held-out conclusions; the common claim, authority, and recovery rules should remain consistent.

That is the value of a capability: it captures recurring judgments and outcome contracts for a scenario without forcing every business stage into the Kernel.

Evolution: add one verifiable capability at a time

1. One-shot execution → recoverable long-running taskRecover the goal, evidence, and next step across sessions and process interruptions. First prove one thing can be finished reliably.
2. Generic task → domain delivery and explorationUse issue-fix and research work for real outcomes, preserve domain state, and define what makes a result valuable.
3. One agent → small-team collaborationFirst have two or three workers complete two rounds of dependent delivery: receive artifacts, accept independently, absorb corrections, and return results.
4. Local collaboration → continuous work across hostsValidate shared state, authority revocation, stale-worker isolation, network failure, and shared budgets. Successful registration is not proof of collaboration.
5. Sustainable operation → measurable improvementUse outcome feedback to improve selection, memory, and strategy; prove gains through controlled experiments, held-out validation, and rollback. Qualify scaling separately.

These are a build order and validation targets, not a completion checklist. Foundations, partial implementations, blueprints, and end-to-end qualification should be read separately.

I want what we hand to an agent to evolve from a single instruction into a work agreement it can keep fulfilling.

That agreement should remain legible and editable to people, actionable to agents, and auditable through evidence after failure.

Public sources and further reading

The technical content is derived only from public repository material. Source and data links are pinned to the revisions read for this article; historical experiments retain their own versions. This page introduces no new experimental results.

1. LHTB: compared with Plain and native Goal; public aggregates for 46 tasks; setup and evidence boundary; mechanisms and cases reported in the brief; official benchmark. See the study for contributor attribution.
2. SWE-Marathon: continuous self-verification; setup, positive and negative cases, and limitations; public aggregate data. See the study for contributors and case provenance.
3. DeepSWE × Sol: from continued execution to valid delivery (Chinese). The standalone brief covers historical results over 113 tasks, mechanism diagrams, and pinned primary sources; research archive contribution: @gwh6669999, #4502.
4. DeepSWE × V4 Flash max: from hints to behavior; disclosure boundary; charts, cases, and metrics at the pinned revision.
5. Explore: evidence graphs, planning, and authority boundaries.
6. Auto Research: public blueprint and command path.
7. PR / Issue Fix: how State Kernel and domain state work together (Chinese).
8. Overall roadmap: product goals and independent acceptance milestones.
9. From one-shot agents to long-horizon control; LoopX: Native Kanban for long-running agents.