When developing software with agents, I increasingly care about a short feedback loop that can keep running: from an idea to implementation and real feedback. As code generation gets faster, goals, validation, handoffs, and human attention shape how much useful work we can deliver.
Building LoopX has led me to frame this as adding goals, evidence, authority, and evolving plans to a recoverable execution system. This is a short introduction for software developers; the core architecture article develops the mechanisms.
Shorten the path from an idea to validation
For products shaped by outcomes and user experience, one person working with agents across design, implementation, use, and revision has two immediate advantages: fewer handoffs in the feedback path, and shared context for product and technical tradeoffs. A poor interaction can lead to coordinated changes in the interface, protocol, and tests, followed by another hands-on check.
This makes high-quality human reward valuable: people identify what matters and what remains inadequate; agents turn that judgment into the next piece of verifiable work. Reward here can mean a correction, acceptance criterion, or priority change. It need not be numeric and does not imply training model weights.
There are costs. Concentrated context makes independent review more important. Code output can grow faster than evaluation capacity and human review bandwidth. Specialization and independent judgment still make collaboration valuable. The engineering problem is preserving a short feedback loop while making validation, maintenance, and delivery sustainable.
A public case: carry a performance optimization upstream
Zheng Cai (@zigzagcai) described using LoopX as the workflow engine for an agent framework optimizing vLLM. The resulting change has been merged as vLLM PR #54951.
The optimization targets sparse-indexer prefill. Previously, each tensor-parallel rank repeated MQA scoring and top-k for the query rows. The change divides independent rows into cost-balanced contiguous slices. Each rank scores its slice against the full available key history, then all_gatherv restores the top-k indices in the original row order. It removes redundant computation without approximating attention.
The PR reports GLM-5.3-Flash on 4×H200, TP4, 1M input tokens, and C1 sequential requests: TTFT falls from 54.154 to 40.388 seconds, a 25.42% reduction; input-plus-output token throughput rises from 17,856.28 to 23,675.18 tok/s, a 32.59% increase.
The measurements use a 65,536-token batch budget, the legacy runner, an explicit FA3 backend, and four paired fresh-process A/B restarts. C1 total-token throughput is not saturated concurrent serving throughput. I have not independently reproduced the result, and this case does not isolate LoopX’s causal contribution. It shows an inspectable engineering delivery: the optimization, measurement conditions, validation scope, and upstream acceptance all have public artifacts.
Establish that the measurement exercises the change
The PR preserves an important constraint: the new path needs at least 16,384 × TP scheduled prefill query rows in the current batch. At TP4, an 8,192-token batch budget cannot activate it, even with a 1M-token accumulated context. Long context alone does not establish that the optimization ran.
The author reran the comparison with pinned baseline/candidate revisions and the same 65,536-token batch budget, and disclaimed attribution of the old tables to the current change. This gives agent development a stricter acceptance criterion: the artifact, active path, measurement configuration, and conclusion must agree. An attractive number cannot replace that evidence chain.
For long-horizon development, that is more informative than elapsed agent runtime. Profiling, comparing hypotheses, implementing a change, validating it, and responding to review must remain connected. Failure conditions and measurement definitions need to survive into the next round.
Add semantic properties to distributed execution
Queues, leases, event logs, revision checks, and retries make execution traceable and recoverable. They usually do not decide whether a recovered plan is still worthwhile, whether a test applies to the current revision, or whether finishing a local task satisfies the goal. Agent work brings these questions into the execution loop.
| Execution mechanism | Semantic property to make explicit |
|---|---|
| Persistence and recovery | Carry goals, acceptance, and negative evidence across sessions; reassess a recovered but outdated plan. |
| Claims, leases, and concurrency control | Check responsibility, execution occupancy, goal changes, and release authority separately. |
| Results and revision tracking | Bind evidence to artifacts, workloads, and revisions; successful execution supports only what it actually establishes. |
| Retries, waits, and scheduling | Distinguish no new facts, eligible independent work, an invalid route, and a decision that needs a person. |
Consider a constructed performance-development scenario: candidate rA passes an isolated microbenchmark, while mixed-load p95 remains unmeasured. A person adds: “Mixed-load latency is what matters; do not trade correctness for speed.” That feedback needs to become a revised acceptance contract, an evidence boundary, and successor work, rather than another preamble in the next prompt.
The model proposes acceptance v2 and a fixed-workload serving comparison. The appropriate authority accepts the revision; the kernel checks scope, identity, and version before persisting it. The old rA result remains valid for the isolated test, but cannot satisfy v2. Release remains gated; independent correctness and rollback analysis can continue. The diagram explains a control contract, not an actual vLLM PR trajectory.
LoopX’s Semantic Control Plane externalizes goals, work items, constraints, and accepted transitions. Models propose work from current facts; scope, authority, and budget are checked before execution; tools return observations; domain validators check results; the kernel checks identity, revision, and transition rules before committing durable state. Exhausting the task list means the current plan is exhausted, not necessarily that the goal is achieved.
The diagram describes responsibilities, not deterministic code for every semantic judgment. Models and people interpret evidence, form hypotheses, and make tradeoffs; deterministic rules protect expressible boundaries. Validators can be incomplete, so counterevidence, provenance, and human review remain necessary. See Effect Programs for execution and recovery, and native Kanban for the collaboration objects.
Semantic execution engines and agentic software
In Agents aren’t software, Runta’s Guanlan Dai moves the fault-tolerance unit toward semantic execution state and the judgments worth preserving. The question is whether unfinished work can continue meaningfully after process recovery.
A distributed-systems qualification matters: conventional software already has concurrency, randomness, dynamic scheduling, and external failures. Agents add solution paths, tool compositions, and intermediate evaluations proposed by models during execution. The search path is open-ended; execution, validation, and commit boundaries must remain explicit. Existing systems engineering becomes more necessary.
My framing is that models and harnesses own interpretation, hypotheses, and tool loops; domain capabilities define valuable outcomes and validation; execution environments constrain resources and external reach; LoopX preserves goals, responsibilities, evidence, and continuity between them. Latency, reliability, cost, and scale remain measurable requirements. We must also check whether changing sessions or executors loses the grounds for action.
The whole can be understood as a semantic execution engine: inputs include goals and feedback, while outputs include accepted state changes. The term describes responsibilities. LoopX specifically provides the semantic control plane alongside models, harnesses, and execution environments.
Local and cloud execution can share work identity, evidence, and acceptance contracts while adapting their environments separately. Migration checks should cover dependencies, revoked write rights of old executors, applicable authority, and the current acceptance revision. A shared protocol supports continuity; cloud delivery still needs independent verification.
A distributed-systems view: make judgments committable state
Adding semantics changes the state model, commit conditions, and recovery unit. Storing a natural-language goal in a database still leaves these engineering gaps.
Preserve authoritative facts; rebuild their views
Goal revisions, accepted decisions, evidence references, responsibility, and commit receipts need stable identities. Boards, summaries, and suggested actions are consumer-specific views. Irreplaceable results and negative evidence still need preservation; a recomputable display does not make its grounds disposable. The LoopX state/projection contract separates those responsibilities.
Use versions and causality to bound evidence
A passing test should identify candidate rA, workload W1, and acceptance v1; a decision should identify its action scope. With rB or v2, retain the historical fact and reassess its applicability. Ordering messages establishes sequence. Safe action also requires what the evidence addresses and who may accept a change.
Reconcile uncertain external effects before retrying
Suppose an agent loses connection after submitting a GPU experiment. The remote job may be running despite the missing response. AWS’s idempotent-API design explains the value of request identity for safe retries. Use a stable request or job ID for readback; retain uncertainty if the provider cannot resolve it. Settling the control-plane turn once cannot ensure one remote launch. The core article’s Effect Program develops that recovery chain.
Consistency protects commits; it cannot choose the best design
Leases, revision checks, and stale-writer isolation can reject an obsolete executor’s writes. They cannot choose between two designs that both pass local tests. Protocols protect execution boundaries; models, validators, and people compare routes. Shared state should align facts and expose disagreements, with decisions accepted by explicit authority. The last write is not necessarily the best judgment.
Long-horizon work therefore needs three lenses: safety, whether authority and acceptance boundaries are respected; liveness, whether eligible work is adopted and waits can resume; and value, whether further effort closes acceptance gaps or reduces uncertainty. A system can reliably execute a poor route. Outcome feedback must keep testing the third lens.
Build a foundation for sustained autonomous delivery
To sustain that short feedback loop, I would invest in three foundations:
- Composable atomic capabilities. Let agents perform real operations through CLIs, return identified results and errors, and read back external facts. Establish a complete small loop before expanding the capability surface.
- Evolving engineering constraints. Put architecture boundaries, RFCs, tests, independent review, and release gates in the repository. Continuously refactor duplicate authority and code decay instead of accumulating patches.
- Evaluation that keeps up with development. Preserve baselines, candidate revisions, workloads, budgets, and counterexamples. Separate cheap local checks from expensive comprehensive evaluations, and retain independent acceptance. More diffs do not automatically mean more useful output.
Turn experience feedback into cross-layer acceptance
LoopX has used its own long-horizon capabilities in development since its early days. The public Meta Goal of June 1, 2026 already defined operability, work continuation and validation as ongoing objectives. The June self-iteration case records parallel benchmark, control-plane, planning, interface and documentation work. Later came multiple agents and the Personal Workspace. Across these stages, development goals, ownership, human feedback and validation were retained so the improved system could participate in subsequent development. The bootstrapping and RSI essay covers the history; commit counts describe activity, not capability gains.
This is the value of end-to-end co-design. A product problem can change the interaction, state presentation and acceptance checks together, with intent and engineering context shared across layers. The current delivery process starts from an ordinary user task: what fails, what information is repeatedly requested, and how to walk the built page and read back the result. Human feedback changes subsequent work and acceptance; agents adapt design and implementation within the same chain.
The Goal workspace brings direction, acceptance conditions, the work map and owner decisions together, while separating task progress from Goal acceptance. Public first screens receive an owner preview, followed by desktop, narrow-screen and keyboard checks. The repository showcase below illustrates this organization with synthetic presentation data.
Compose atomic CLIs and thin skills into a complete loop
In local LoopX development, agents use CLIs to read work, invoke tools, submit results and reconcile state, following the current interaction_contract. The capability boundary is Agent → Capability → Provider; domain validation turns external observations into proposals for the Kernel lifecycle. Hosts execute tools, capabilities interpret domain results, and the Kernel retains task, authority and budget state. CLIs and thin skills connect these capabilities without each owning another set of work rules.
Optional Explore, for example, organizes questions, experiments, findings and counterevidence into an evidence graph. PR Review organizes a version-specific review plan, evidence and results. Their domain workflows differ, but reuse existing Todo, claim, gate and writeback boundaries. An Explore branch recommendation launches no worker and grants no budget. A research method or external tool can therefore reuse long-horizon infrastructure without creating another scheduler.
Make the next change easier: types, ownership and refactoring
Maintainability requires continuous behavior ownership. New enums and closed sets must identify their owner. The refactoring contract prioritizes removing duplicate authority, strengthening types and narrowing modules, treating code volume as a cost. These rules must shape subsequent changes, beyond the initial design.
A representative practice is the gradual control-plane migration that began in August 2026. It first characterizes behavior and authority, then consolidates complete transactions such as Turn settlement, quota and Todo completion—including internal durable effects—in TypeScript. Python retains required transport, legacy projections and external adapters. Translating individual helpers added bridges and duplicate code, so the migration adopted complete transaction cutover and deletion of replaced rules as its unit of progress. The aim is to make the next rule change easier to locate, test and revert. Delivered slices and remaining callers stay explicit; the overall migration is unfinished.
Automate checks, retain independent judgment and release authority
LoopX development follows a change loop from problem characterization to focused implementation, regression checks, risk-selected canary and review. loopx pr-review binds verdicts to a specific head; new commits cannot inherit an old pass. Tests, review, owner decisions and publication have separate boundaries. Passing checks grants no merge authority.
Collaboration can also be checked as a complete delivery chain. The public three-agent demo has a builder request an analyst model artifact, consume actual files to implement a solver, and obtain independent review. A revision adds reserve stock and a minimum regional allocation, prompting another implementation and review before results return to the original conversation. An exhaustive oracle never imports the candidate solver; each input version has exact expectations. A controller sets the inputs and phase schedule. The bounded demonstration covers same-host, same-Goal artifact adoption and continuation across fresh sessions, not unattended scheduling or full cross-host collaboration.
Keep evaluation abreast of development: layers, counterexamples and cost
LoopX separates evaluation layers: inexpensive deterministic contracts and real-entrypoint regressions support ordinary changes; canary checks cross-surface risk; real-model qualification and long-horizon outcome studies run separately. Tests must reject incorrect candidates, with expectations independent of the implementation. Runnable code, model adoption of a protocol and long-term task benefit require different evidence. Faster development creates no additional evaluation resources; layering preserves decisive checks under cost constraints.
Long-horizon development also changes the interfaces and rules that agents themselves use. LoopX makes output readability, vocabulary drift, decision-module growth and correct recovery executable checks. Semantic complexity is constrained by complementary guardrails rather than reduced to one aggregate score.
| Guardrail | What it checks | Evidence boundary |
|---|---|---|
| CLI output contracts | Measure actual stdout characters, UTF-8 bytes, lines and JSON shape. Compare base/head on identical fixtures, checking task/history growth, required fields and action semantics. Hot paths retain explicit detail routes. | Smaller output may omit essential guidance. Authority, stop conditions and evidence obligations also need review; size compliance does not establish model understanding. |
| Semantic vocabulary drift | Scan enums, Literal aliases, named closed sets and TypeScript as const carriers. Check definition owners, values, cross-runtime twins, projections and supported producer sites; undeclared values, duplicates and generated-binding drift enter the gate. | Evidence is bounded to recognized source forms and covered vocabulary domains. Unresolved dynamic paths and some consumer checks remain gaps, beyond any claim of general semantic equivalence. |
| Maintainability ratchet | Python AST checks control-plane decision-function statements and decision points, module size, Any occurrences, and forbidden dependency directions. Existing debt, module budgets and reviewed exceptions are explicit; exceptions carry reasons and retirement plans. | Unreviewed new debt, metric-bearing exceptions exceeding ceilings and stale exceptions fail. These metrics flag refactoring risk; shorter functions or lower counts alone do not establish better design. |
| State composition and recovery | Existing Turn checks inject interruption, unresolved readback and exact retry across writeback → quota spend → closeout. Independent expectations require each logical effect to commit once, with real-entrypoint and readback evidence. | Finite fault sequences use a real File journal and synthetic provider ledger. They do not prove power-loss durability, complete lease contention or general cross-domain liveness. Full composition qualification remains open. |
The gates themselves need counterexamples. Existing tests reject smaller output that removes required semantics, prevent narrowed scan scope from bypassing vocabulary checks, and reject growth concealed by an existing debt exception. Output budgets are regression baselines: useful new decision information can justify a reviewed adjustment with matched measurements, while compression must retain guidance obligations. Passing checks qualifies the tested contracts; model behavior and actual delivery still require observation.
The five-arm LHTB study checks whole-system outcomes across versions and execution modes. Its 46 matched tasks cover Plain Codex, Native Goal, SSH-Goal and two Heartbeat generations, with the same model and reasoning effort. LoopX 1.0.3 Heartbeat has mean reward 0.4948 versus Plain’s 0.4218, while both strictly solve 7/46 tasks. There is one effective trial per task and arm, replacement trials and unequal budgets, precluding an equal-budget efficiency or isolated causal claim. Retaining failures, regressions and limitations helps decide where to spend evaluation resources next.
Local to cloud: reuse semantics, qualify execution environments separately
LoopX separates control-plane contracts, domain capabilities and host/provider adapters. A local prototype can preserve work identity, acceptance and evidence while adapting remote tools. The current R6 roadmap distinguishes a single-authority, mixed-execution precursor from full cross-host collaboration. Cloning an independently writable Goal database cannot implement the precursor.
Full qualification still requires at least two real hosts, including a cloud worker, with tenant/actor authorization, revocation, disconnects, stale writers and ambiguous commits checked. Shared contracts reduce the work of restating intent; resources, dependencies and isolation need separate evidence. The decomposition is reusable today; complete local/cloud qualification remains an open objective.
Across rounds, sessions, and executors, these constraints need to become inheritable state. Long-horizon autonomous development aims to advance valuable work when no human decision is needed, let a correction change subsequent actions, and wait, change route, or close the work when evidence is insufficient or marginal returns decline.
When those improvements are used to improve the development system itself, a system-level self-improvement loop emerges. The bootstrapping and RSI article covers that history and its limits. Sustained commits and self-modifying code alone do not establish capability gains.
Start with a goal you can evaluate
You do not need a large agent team first. Choose your own experimental repository and specify the outcome, development scope, budget, and release authority. For example:
Fix the workload and baseline, then research and validate one performance optimization. Preserve failed experiments and counterexamples. Record the candidate revision, measurement conditions, remaining gap, and successor each round. Changes to the experimental branch are allowed; release and additional compute spending require my decision.
Connect through the Developer Book, then use loopx doctor and loopx status to inspect the environment and connected projects. Check a complete execute–validate–writeback–continue cycle. After changing sessions, can the agent recover the goal, evidence, wait conditions, and your correction?
For a small task that fits comfortably in one session, an additional control plane may not pay for itself. It is more promising where you repeatedly rebuild context, prompt continuation, and reconcile facts. I want more accepted deliveries and less human attention spent keeping work continuous.
Choose your next read
- Application scenarios: distinguish complex delivery, open exploration, and ongoing responsibilities.
- Core architecture: goals, the state kernel, Effect Programs, waits, and replanning in depth.
- Native Kanban: work items, claims, leases, gates, and shared authority state.
- Research findings and the freshness postmortem: examine feedback, experience, and freshness, including what remains unproven.
- Bootstrapping and RSI: the history and limits of carrying improvements into subsequent work.
Written by LoopX creator Ruiteng Huang. Technical descriptions refer to public implementation. The case and performance figures come from the contributor’s public PR; this article adds no experiments. Implementation references: Architecture, Goal / Vision / Replan, and Decision Scope. Historical essays provide context; use the current handbook for operations.