LoopX puts a durable state kernel between your agents and their drift

The most honest sentence in the LoopX README is the disclaimer buried under the architecture diagram: “It does not replace your agent runtime.” That restraint is the whole point. LoopX, a lightweight Python package from developer huangruiteng, is a state kernel for long-running AI agent work. It sits between your objective and your agent runtime, keeping goals, gates, todos, evidence, quota, and handoffs stable while Codex, Claude Code, Cursor, or a custom runner executes bounded turns.

The category it targets is real and increasingly painful. An agent can finish a task in one session. Multi-day engineering, research, or benchmark objectives are a different beast entirely. The README names the failure modes precisely: objectives change, owner decisions appear, evidence goes stale, agents hand work to peers, and a scheduler can keep spending after no useful transition remains. Chat memory and a timer, LoopX argues, are not enough to govern that.

What LoopX actually ships is a compact control-plane layer. The state model holds the objective, explicit scope, current authority, ordered todos, ownership claims and leases, concrete user gates, compact run history, validation, blockers, and accepted writeback. The core tick is deliberately small: loopx quota should-run, loopx todo claim, loopx todo update, loopx refresh-state, and loopx quota spend-slot. That is the entire loop. Five commands, one bounded agent slice per turn, evidence written back, quota deciding the next tick.

The interesting design choice is that LoopX treats registered agents as peers. Claims, leases, task boundaries, capabilities, and typed continuation decide who acts next. No durable leader identity is required. That is a meaningful departure from the orchestration-heavy patterns most agent frameworks push, where a central controller dictates every step. LoopX’s mental model is an agent-native Kanban: cards carry identity, authority, evidence, and continuation, and moves are validated operators such as claim, gate, monitor, and writeback. The board is a projection; LoopX state remains the source of truth.

The quota mechanism deserves attention. loopx quota should-run decides whether a turn should deliver, ask, wait, self-repair, or stay quiet. That is a governance function disguised as a scheduling function. Most agent tooling spends its effort on making agents do more; LoopX spends its effort on making agents do less, more deliberately. The README is explicit that LoopX is not an autonomous production controller. Dangerous permissions, publishing, production writes, and final ownership stay with the human. Human judgment is encoded as a first-class state transition: when the loop hits a “human judgment needed?” branch, it asks a concrete question and waits, rather than emitting a vague “waiting for owner” status.

The evidence claims are scoped carefully. The OpenViking Issue-Fix and Auto ML trajectories each span 200+ hours of elapsed loop lifetime across many bounded turns, decisions, and evidence updates. The README is careful to define elapsed lifetime as wall-clock project time, not 200 hours of continuous model execution or a claim of unattended production autonomy. That distinction matters because it is the difference between a demo and a workload. The trajectories are public-safe graphs preserving decision lineage, evidence branches, and decisions across turns. They are trajectory evidence, not a claim of continuous compute, independent reproduction, or a production result.

What is genuinely new here is not the individual primitives. Durable goals exist in other tools. Evidence logs exist. Handoffs exist. The novelty is the packaging: a state kernel that is agent-agnostic, runtime-agnostic, and dependency-free. The Python package has no runtime dependencies outside the standard library. Requirements are Python 3.11+, curl, tar, and a macOS or Linux shell. Git is only needed for contributor clone and canary workflows. That is a deliberate bet that the control plane should be boring, stable, and portable while the agent runtimes underneath churn through releases.

The integration surface is broad. Codex App, Codex CLI, Claude Code, OpenCode, Cursor, shell, and custom runners all have documented paths. Claude Code gets an opt-in adapter with a native /loop gated by LoopX. Codex CLI gets a visible /goal with no hidden headless execution by default. Codex App gets heartbeat automation refreshed from quota scheduler hints. Custom runners get a worker bridge install contract. The README even includes copy-ready setup messages and host recovery paths, which is the kind of operational detail that suggests real usage rather than a demo.

The domain capabilities are where LoopX starts to look like a platform rather than a utility. loopx issue-fix, loopx content-ops, loopx value-connectors, loopx ml-experiment, loopx benchmark, and Explore package repeatable work lanes. There are presets for daily triage, changelog drafts, and PR watching. An Auto Research path coordinates proposer, executor, and evaluator/promoter roles while keeping quota and evidence visible. A Lark Kanban adapter projects todos and gates into collaboration surfaces while LoopX remains authoritative. An experimental Reward Memory feature lets named registered agents trial provider-neutral context learning through ignored, default-off project configuration.

The opinionated take: LoopX is correct about the hard problem, and the hard problem is not agent capability. It is agent continuity. The industry has spent two years making agents smarter, faster, and more tool-capable. The gap that remains is operational: how do you keep a multi-day agent effort reviewable, restartable, and handoff-able without a human babysitting every turn? LoopX’s answer is to make the state explicit, durable, and human-gated, and to make the loop itself the unit of management rather than the individual turn.

There are limits worth naming. LoopX is a single-developer open-source project, which raises the same sustainability questions that hang over most indie agent tooling. The evidence base is two trajectories from the creator’s own usage, one of them on OpenViking, which the README discloses. The quota mechanism is provider-neutral but the tuning of “should-run” heuristics is the kind of thing that only gets refined through real production load. And the claim that LoopX is agent-agnostic is true at the state layer but the quality of the integration varies by host, with Codex and Claude Code getting first-class treatment and the rest getting documented paths.

The deeper significance is for AI builders. The industry is moving from single-turn tool use to long-running agent teams, and the missing piece is not another agent framework. It is a governance layer that keeps human judgment in the loop without requiring a human in every loop. LoopX’s five-question model, what is the objective, what happens next, what needs human judgment, what evidence changed, may the loop continue, is a reasonable specification for that layer. Whether LoopX wins or not, the problem it names is the one that will decide whether agent teams become real infrastructure or remain demos. The state kernel is the unglamorous part, and it is the part that matters.