LoopX: A Local Control Plane for Long-Running Agents
When you ask Codex to fix a bug, it runs for 20 minutes, edits three files, then runs out of tokens. You restart the session and it begins from scratch—it does not remember what was changed, does not know the remaining todos, and has even forgotten why it took that approach.
This is not Codex's fault; it is a common weakness of all agent loops. Short-task agents are easy to build; long-task agents are hard. Once work spans hours, days, and multiple sessions, the "chat memory + timer" approach collapses: goals drift, decisions accumulate, evidence expires, agents need to hand off work, and schedulers keep burning tokens when there is no valid transition.
LoopX hit GitHub trending this week and addresses exactly this problem: it gives long-running agents a local control plane. It is not an agent runtime, does not replace Codex or Claude Code, but provides these runtimes with a "state kernel."
Core Abstraction: Agent-Native Kanban
LoopX's mental model is Kanban, but not for humans—for agents.
Traditional Kanban cards have only a title and description. LoopX cards carry five things:
- identity: who owns the card, which agent manages it
- authority: what permissions execution requires
- evidence: what has been done, where outputs are
- continuation: what to do next
- quota: how much budget remains
- Local data: State stays on the local machine. Enterprise-sensitive data, code, and internal documents never leave your machine.
- Local control: LoopX is not an autonomous production controller. Dangerous permissions, releases, production writes, and final ownership stay with humans.
- LangGraph: Graph orchestration tool, focused on "how to define agent workflows"
- Temporal: General-purpose workflow engine, not agent-specific
- obra/superpowers: Skills framework, focused on "how to encode engineering experience for agents"
- LoopX: State kernel, focused on "how to persist agent work state"
- Runtime layer: Codex, Claude Code, Cursor
- State layer: LoopX (local), cloudflare/computer (cloud)
- Skill layer: addyosmani/agent-skills, obra/superpowers
- Evaluation layer: uber/ADR (safety observation)
Card moves are verified operators: claim, gate, monitor, writeback. The Kanban board is only a projection; LoopX's state layer is the source of truth.
The key insight: the problem with long-running agents is not "insufficient capability" but "state loss." What an agent can finish in 5 minutes cannot be completed in 200 hours, not because it became dumber, but because the intermediate state—goals, decisions, evidence, todos—was not reliably persisted.
Real Trajectories Exceeding 200 Hours
The README provides a convincing data point: OpenViking Issue-Fix and Auto ML trajectories, each spanning 200+ hours of loop lifecycle.
Note that this is not 200 hours of continuous model execution; it is wall-clock time—the calendar time a project takes from start to finish, with many bounded agent turns, human decisions, and evidence updates in between. LoopX's value is that after each turn, state is reliably saved; at the next turn, the agent sees the full context.
This aligns with the "granularity isomorphism" principle (discussed in Heddle and CodeRescue on zhichai.net): system optimization granularity should match the granularity of the optimized object. The work granularity of a long-running agent is "multi-turn trajectory," not "single call"—so state management must also happen at the trajectory level, not the call level.
Four Key Mechanisms
LoopX's control state includes four core mechanisms:
1. Gates: Not all operations can run automatically. Dangerous permissions, releases, production writes, final ownership—these stay with humans. LoopX checks gates before each agent turn; if human judgment is needed, it raises a specific question and waits.
2. Quota-aware: Agents cannot burn tokens indefinitely. LoopX tracks each turn's budget; when quota is exhausted, it pauses until the next wakeup. This solves the problem of "schedulers continuing to burn tokens when there is no valid transition."
3. Evidence logs: After each turn, the agent must write evidence—what was done, where the output is, what comes next. This is not an optional log; it is part of the state.
4. Verifiable handoffs: When agents hand off work to each other, it is not a simple "I'm done, you continue"—it is a structured handoff protocol containing current state, completed work, pending work, and required permissions.
Why a "Local Control Plane"
LoopX emphasizes being a local-first control plane. This has two meanings:
This positioning is clever. It does not compete head-on with cloud-based orchestration tools like LangGraph or Temporal; instead, it provides a "local state layer." You can use any agent runtime, any cloud orchestrator, but the state layer is LoopX.
Differences from Other Projects
Recently, several agent loop management projects have emerged with different angles:
LoopX's uniqueness: it does not try to replace any layer, it only provides the state layer. This is similar to the thinking behind cloudflare/computer—cloudflare/computer also only provides the state layer (file system), not the execution layer. But cloudflare/computer is cloud-based, while LoopX is local.
A Bigger Trend
Placing LoopX alongside recent trending projects reveals that agent engineering is rapidly becoming layered:
LoopX's README states it well: "Keep the loop moving. Keep the judgment human." This may be the most concise design principle in agent engineering—automate everything that can be automated, but leave decisions that require accountability to humans.
---
*Project: huangruiteng/loopx · Python · 327 stars today · 200+ hours of real trajectories*