LoopX: A Control Plane for Long-Running AI Agent Work

Most agent tooling optimizes the ten minutes a model spends thinking. LoopX is built for the two hundred hours a real project takes — and the gaps in between where nobody's watching.

LoopX is an open-source, local-first control plane for long-running AI agent work — currently at v0.4.1, with 1.7k GitHub stars and 14 contributors. Its pitch isn't a better agent loop; it's the layer above the loop: durable state — objectives, human-approval gates, todo ownership, evidence, and quota — that survives across sessions, tool switches, and handoffs between different agents, regardless of whether the actual work is running in Codex, Claude Code, Cursor, or a custom runtime.

TL;DR

The problem: single-session agents don't survive multi-day work

A coding agent can reliably finish a task inside one session — that's a solved problem across most modern harnesses. What breaks down is work that spans days: objectives shift as new information arrives, a decision that needed a human's judgment gets buried in scrollback, evidence of what's already been tried goes stale, one agent hands a task to a peer agent without clear ownership boundaries, and a scheduler can keep burning compute on a cron timer long after there's nothing useful left to do. Chat memory plus a cron job isn't a control system — it has no concept of "wait for approval," "who owns this next," or "stop spending, nothing changed."

LoopX's answer is to externalize that control state into a compact layer independent of any single agent session: objective, gates, todos, scope, evidence, and quota live in .loopx/ state on disk, not inside a model's context window. Each agent turn becomes a bounded slice: check quota, claim a todo, do the work, write evidence, hand off — rather than an open-ended session that runs until it drifts or someone remembers to check on it.

How the "tick" works

LoopX's core interaction loop is deliberately small — five commands that together decide whether an agent should act, what it owns, and what happens after:

loopx quota should-run      # should this registered agent act now?
loopx todo claim            # who owns this slice?
loopx todo update           # what changed?
loopx refresh-state         # what should the next turn see?
loopx quota spend-slot      # account for a completed, validated slice

The ordering matters for the project's stated safety model: quota is checked before a turn spends anything, and a spend is only recorded after validated writeback — so a quiet skip, a failed preflight check, or a dry-run preview costs nothing against the budget. That's the mechanism preventing runaway scheduler spend, one of the specific failure modes LoopX calls out as unsolved by "chat memory and a timer."

Gates: concrete, not vague

LoopX's framing of "gates" is a specific design choice worth calling out. Instead of an agent reporting a nonspecific "waiting for owner" status, a gate is a concrete, answerable question the loop is blocked on — the kind of thing a human can actually resolve in one exchange rather than having to reconstruct context from a long transcript to figure out what's even being asked. Dangerous permissions, publishing actions, and production writes are explicitly gated to stay with a human regardless of how capable the underlying agent is — a hard boundary rather than a configurable default.

Runtime support: agent-agnostic by design

LoopX doesn't compete with agent harnesses — it sits above them, with different integration paths per runtime:

That "no hidden headless execution by default" detail for Codex CLI is a deliberate transparency choice — the project's broader positioning leans hard on legibility: a non-engineering operator should be able to look at LoopX's state and understand what's happening, not just an engineer reading raw agent transcripts.

The evidence: three 200+ hour trajectories

Rather than a synthetic benchmark, LoopX's public evidence is three real trajectories, each spanning 200+ elapsed hours (wall-clock project time, explicitly not continuous model execution) with redacted, public-safe decision graphs: an open-source issue-fix arc where the maintainer used LoopX as a contributor to another project, an Auto ML experiment arc tracking hypotheses, evidence, invalid lineages, and promote/stop gates in one graph, and an Auto Research setup where proposer, executor, and evaluator/promoter agents iterate in parallel with visible quota and evidence state.

The project is careful about what this evidence does and doesn't claim — it's explicitly framed as "trajectory evidence, not a claim of continuous compute, independent reproduction, or a production result." That kind of hedging is worth noting given how much of the current AI-agent-tooling space tends toward overclaiming; LoopX's own README repeatedly draws the line between what's demonstrated and what's aspirational.

Where LoopX fits next to Pi and loop engineering

LoopX's "control plane above the harness" framing lines up closely with concepts explainx.ai has covered under loop engineering — the discipline of designing the surrounding scaffolding (verification, gating, iteration control) rather than just the model call itself. It's a genuinely different layer than Pi, the minimal terminal harness explainx.ai has covered separately: Pi owns a single agent's loop (tool dispatch, context, session state); LoopX owns the state that outlives any one harness session and coordinates across multiple sessions, tools, or peer agents. In principle you could run Pi as the executor underneath a LoopX-managed objective — they solve adjacent, not competing, problems. The agent harness guide's six-component model (task definition, context manager, tool execution, loop controller, verification, failure handler) maps mostly onto what a single harness session does; LoopX is closer to a seventh layer sitting above all of them — durable objective and handoff state that no single harness component tracks.

What people are asking

Is this a new agent runtime I have to switch to? No — that's the explicit non-goal. LoopX states directly that it "does not replace your agent runtime." You keep using Codex, Claude Code, or Cursor exactly as you do today; LoopX adds a state layer that those tools check in with.

Does it require cloud infrastructure or an account? No — it's local-first. The Python package has no runtime dependencies outside the standard library, and state lives in a local .loopx/ directory, not a hosted service. Optional projections (a dashboard, a Feishu/Lark Kanban adapter) exist for visibility, but the project is explicit that these are views, not the source of truth.

How mature is this, really? LoopX self-describes as v0.4.x — "early but usable" — with the state and CLI contracts positioned as the stable center, while several host integrations and advanced paths (Reward Memory, Explore) are marked optional, default-off, or experimental. That's a reasonably honest maturity signal for a project with 1.7k stars but a young version number.

Why would peer-agent handoff need a control plane at all? Because without one, "which agent owns this task right now" and "what did the last agent already try" both live only in whatever context that agent happened to have — lost the moment a session ends or a different agent picks up the work. LoopX's claim/lease model and evidence log exist specifically so that handoff between agents doesn't silently drop context or duplicate work.

The takeaway

LoopX is a bet that the next bottleneck in agentic coding isn't model capability or even harness design — it's the boring, unglamorous problem of keeping multi-day, multi-agent work legible and safely bounded over time. The project's own honesty about its limits (not a production controller, not a replacement for human judgment on dangerous actions, evidence framed carefully rather than oversold) is arguably as notable as the technical design. Whether a dedicated control-plane layer becomes a standard part of the agent stack, or gets absorbed into individual harnesses over time, is the open question — but the specific failure modes it targets (drifting objectives, lost gates, stale evidence, runaway scheduler spend) are real and currently under-addressed by "chat plus a cron job."

Related on explainx.ai:

• From ReAct to production harness — DAG, Planner/Worker/Critic, budget pressure
• Pi Agent Harness: Mario Zechner's Minimal Coding Agent
• What Is an Agent Harness? Complete Guide
• What Is Loop Engineering?
• Loop Engineering for Coding Agents: Claude Code Guide
• Cloudflare Wallets: AI Agent Payments

Official: LoopX on GitHub · Getting Started docs

Feature set, version number, and star count reflect LoopX's state as of early August 2026 and will change as the project evolves.