LoopX: A Local Control Plane for Long-Running AI Agents

Ask Codex to fix a bug: it runs for 20 minutes, modifies three files, then runs out of tokens. You restart the session and it starts from scratch—it doesn't remember what it changed, what todos remain, or why it made those changes.

This isn't a Codex problem; it's the common flaw 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 breaks down: goals change, decisions accumulate, evidence goes stale, agents must hand off to each other, and schedulers keep burning tokens without making valid transitions.

LoopX, which hit GitHub trending this week, addresses exactly this: it installs a local control plane for long-running agents. It is not an agent runtime and doesn't replace Codex or Claude Code—instead, it provides a "state kernel" for these runtimes.

Core abstraction: an agent-native Kanban

LoopX's mental model is a Kanban board—but not one designed for humans. It's for agents.

Traditional Kanban cards only have a title and description. LoopX cards carry five things:

• identity: whose card this is, which agent owns it
• authority: what permissions execution requires
• evidence: what has been done and where the artifacts are
• continuation: what to do next
• quota: how much budget remains

Moves on the board are verified operators: claim, gate, monitor, writeback. The board itself is just a projection—LoopX's state layer is the source of truth.

The key insight: the problem with long-running agents isn't insufficient capability—it's state loss. What an agent can finish in 5 minutes becomes unfinishable at 200 hours, not because it got dumber, but because intermediate state—goals, decisions, evidence, todos—is never reliably persisted.

200+ hours of real trajectories

The README offers a compelling data point: the OpenViking Issue-Fix and Auto ML trajectories each span 200+ hours of loop lifecycle.

Note this isn't 200 hours of continuous model execution—it's wall-clock time: the calendar time from project start to completion, involving many bounded agent turns, human decisions, and evidence updates. LoopX's value: after every turn ends, state is reliably saved; when the next turn starts, the agent sees full context.

This aligns with the "granularity isomorphism" principle behind Heddle and CodeRescue (discussed previously): the granularity of system optimization should match the granularity of the thing being optimized. Long-running agents work at the granularity of "multi-turn trajectories," not "single calls"—so state management must operate at the trajectory level, not the call level.

Four key mechanisms

LoopX's control state includes four core mechanisms:

1. Gates: Not everything can run automatically. Dangerous permissions, releases, production writes, final ownership—these stay in human hands. LoopX checks gates before each agent turn; if human judgment is needed, it poses a specific question and waits.

2. Quota-awareness: Agents can't burn tokens indefinitely. LoopX tracks per-turn budgets; when quota is exhausted, it pauses until the next wake-up. This solves the "scheduler burning tokens without valid transitions" problem.

3. Evidence logs: After every turn, the agent must write out evidence—what was done, where the output is, what's next. This isn't optional logging; it's part of the state.

4. Verifiable handoffs: When agents hand off work, it's not a simple "I'm done, your turn"—it follows a structured handoff protocol including current state, completed work, pending work, and required permissions.

Why "local control plane"

LoopX emphasizes being a local-first control plane, with two implications:

• Data local: State lives on your machine, not in the cloud. Enterprise-sensitive data, code, and internal docs never leave your computer.
• Control local: LoopX is not an autonomous production controller. Dangerous permissions, releases, production writes, and final ownership all remain with humans.

This positioning is smart. It avoids head-on competition with cloud orchestration tools like LangGraph and Temporal, instead providing a "local state layer"—you can use any agent runtime and any cloud orchestration tool, with LoopX as the state layer.

How it differs from other projects

Several recent projects manage agent loops, but from different angles:

• LangGraph: graph orchestration—how to define agent workflows
• Temporal: general-purpose workflow engine, not agent-specific
• obra/superpowers: skills framework—how to encode engineering experience for agents
• LoopX: state kernel—how to persist agent work state

LoopX's uniqueness: it doesn't try to replace any layer; it only does the state layer. This echoes cloudflare/computer, which also only does the state layer (a filesystem), not execution. But cloudflare/computer is cloud-based; LoopX is local.

A bigger trend

Place LoopX among recent trending projects and you see agent engineering rapidly stratifying:

• Runtime layer: Codex, Claude Code, Cursor
• State layer: LoopX (local), cloudflare/computer (cloud)
• Skills layer: addyosmani/agent-skills, obra/superpowers
• Evaluation layer: uber/ADR (safety observability)

Each layer is evolving independently but will ultimately assemble into a complete "agent operating system." LoopX chose the hardest layer: long-running state management. Short-task agents are easy for anyone to build—long-running agents are the real problem.

The LoopX README puts it well: "Keep the loop moving. Keep the judgment human." This may be the most concise design principle in agent engineering—automate everything automatable, but leave responsible decisions to humans.

---

*Project: huangruiteng/loopx · Python · 327 stars today · 200+ hour real trajectories*