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

Ask two questions: what counts as done, and how do we get there?

For work handed to an agent, I first separate two uncertainties: clarity of the goal and clarity of the process. Knowing what you want and knowing how to achieve it are different things.

A clear goal names the outcome, constraints, and acceptance criteria. A clear process has a reusable method. A workflow with many steps can be well understood; “make the system better” may leave both the outcome and the route unresolved.

Top right: clear goal, known process. Convert data to a specified format or run a validated release workflow. Reliable execution matters here. A script or workflow can be enough for short work; waiting across days, recovering from interruption, or owning downstream results creates an additional continuity need.

Top left: known process, unclear goal. A team may know how to produce a weekly report without having agreed whose decisions it should inform. Clarify the audience, value criteria, and tradeoffs first. Speeding up a familiar process does not automatically make its output useful.

Bottom right maps to 01; bottom left maps to 02. The former knows the destination and must find a route. The latter also uses exploration to discover what is worth pursuing. An exploratory round can still define its question, evidence requirements, and stopping conditions; an unclear goal is not a mandate to run indefinitely.

03 is a continuing responsibility across quadrants. An agent maintaining a repository may clarify performance needs, investigate a bottleneck, complete a fix, and follow its pull request. It takes on both complex tasks and exploration, while remaining responsible when new feedback arrives.

Uncertainty determines what must persist.
Continuing responsibility determines for how long.

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.

Preserve more than completed steps: the current acceptance version, unresolved gaps, attempted repairs, and the artifact version each check evaluated. If the task list is exhausted but acceptance is unmet, replan. If a person changes compatibility requirements, a pass on the old version cannot establish acceptance under the new criteria.

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.

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.

Exploration can be accepted by the uncertainty it removes: compare candidate routes, produce a reproducible experiment, rule out a hypothesis, or identify the evidence still missing. A well-supported negative conclusion can complete a bounded research round. A finite research deliverable can close out while a longer-term direction continues in another round.

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.

A continuing responsibility also needs rules for when to wake, when to stay quiet, and when to involve a person. New review feedback can become work input; unchanged pending CI does not need repeated interruptions. Missing authority, goal tradeoffs, or exhausted budgets need explicit stopping points. One repair can finish while the maintenance role continues; that role must also be pausable, revocable, and transferable.

Work moves between quadrants. State must follow.

Consider maintaining a service’s performance. “Make it faster” first requires agreement on workload, metrics, and compatibility constraints. Once the outcome is clear, the bottleneck still needs investigation. Finding a repair route turns the work into implementation and acceptance; submission brings review, feedback, and regression follow-up.

This is not a one-way progression. Feedback can change the goal; a counterexample can invalidate the route. A stable method discovered through exploration can become a routine workflow, while new conditions can send a workflow back into exploration. An agent must recognize whether the remaining issue is disagreement about the goal, uncertainty about the route, or simply waiting.

A task’s name does not determine its position; the information currently available does. Research with an agreed question, deliverable, and scoring rule can be managed as a task with clear acceptance. A refactor with a mature method can rely more on an established workflow. Both axes are continuous; the quadrants mark common work patterns.

Useful handoff state includes the current goal and constraints, why this route was chosen, rejected approaches, artifact and acceptance versions, and conditions for continuing or stopping. A chat summary or “step three completed” alone cannot carry these changes.

The same work may change models, sessions, or executors. Revisions to its goal, evidence of failure, and outstanding responsibilities should remain continuous. This is the shared place of a long-horizon control plane in all three scenarios.

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.

When does a long-horizon control plane help?

The quadrants describe uncertainty. The need for continuity across turns determines whether additional state management helps. Exploration that can be accepted within an hour may not need a long-horizon system. A fully understood release process may need one because it spans days, handoffs, and external feedback.

• Complex tasks: changing sessions means explaining acceptance again, recovering repair progress, or rediscovering known gaps.
• Open exploration: several routes run in parallel, negative results disappear, and the next round needs evidence-based allocation rather than recollection.
• Continuing responsibility: tasks, reviews, or external outcomes keep arriving, leaving a person to act as dispatcher and follow-up manager.

These are concrete reasons to externalize state. After adding LoopX, check whether verified output increases, regressions and duplicated work decrease, and people spend less attention managing it. Count the additional execution and maintenance costs too.

My goal remains to have agents do more work while people spend less attention managing them. Separating exploration, execution, and continuing responsibility helps give each kind of work the right management—and reserve human judgment for decisions worth making.

Benchmarks: start with LHTB, then three supporting signals

Most benchmarks provide acceptance criteria, testing problem solving with a clear goal and an unknown route. Even a task that requires algorithm exploration has a specified deliverable and scoring rule. Choosing an open-ended research direction or maintaining an ongoing responsibility is a different level of work.

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.

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.