§1The verdict
In a long-running agent system, the thing worth engineering is not the agent. It is the state the agent stands on: the goal, the todos, the evidence of what has been done, the quota, and the rules for handing off. The agent itself is the part you should be most willing to throw away and replace, because it will crash, hit a rate limit, or get swapped for a cheaper model halfway through a task. If any of that durable state lives inside the agent turn, it dies with the turn, and your "autonomous" system quietly resets to zero every time something twitches.
A new open-source project, loopx, spells this out cleanly. It calls itself a provider-neutral, stateful control plane for long-running agents, and it is explicit that it is not a runtime and not another framework. We have not benchmarked it. We are writing about it because it names, in one tidy spec, the architecture we arrived at the hard way and have been running across an eight-agent fleet for months. Seeing someone else draw the same line is the useful part, so this Note is what running that line has actually taught us.
§2The bet: the kernel is not the runtime
The single decision everything else follows from is to separate the control plane from the agent. loopx puts durable goals, todos, evidence and quota in a small local kernel, and lets any runtime, Codex, Claude Code, a custom worker, query the same state. No agent is the leader. Each turn is a bounded worker that reads the current goal, claims a piece of work, does it, writes back what it did, and exits. The state was there before it woke and is there after it dies.
That inversion is the whole game. Most agent demos put the plan in the model's context window and the memory in the chat history, which means the plan is exactly as durable as one session and one provider. Move goal, progress and evidence out of the agent and into a store the agent merely reads and writes, and suddenly a crash is a retry rather than a restart, and switching models is a config change rather than a rewrite. The agent becomes the commodity. The kernel is the asset.
§3What we actually run
Our version was not designed on a whiteboard, it grew because the alternative kept failing. Mapped onto loopx's five primitives, here is the shape of it, all of it in production today.
Durable goals and todos. Every unit of work is a card on a loop board with one hard contract: it exits as SHIPPED, BLOCKED or KILLED, never just abandoned. An agent picks one up, and picking up is a claim, not a copy. The board is the source of truth, not any agent's context. When a session ends mid-task, the card is still there in exactly the state it was left, and the next turn reads it cold.
Quota-aware waking. A long-running loop that polls in a tight foreground wait is a loop that burns money and pins itself. So waking is scheduled, not spun: work sleeps until a rule-correct time, and a deterministic gate refuses to launch a foreground poll loop at all, pushing it to a detached job that pings us when it finishes instead. The scheduler even reasons about the model's own cache window, because waking too eagerly throws away a warm cache and pays for a cold one. Spend follows validated work, not a timer.
Evidence logs. Decisions land in an append-only, hash-chained log: each record carries the previous record's hash, so editing any past verdict snaps the chain at that point. That is the difference between "the agent says it did the thing" and a record you can audit and cannot quietly rewrite. Alongside it, a plain changelog captures what shipped, so the history survives the conversation that produced it.
Verifiable handoffs. This is the one we respect most, and loopx is right to gate it hard. The kernel owns writeback; a worker can propose a transition but cannot bless its own. In our loop the same discipline shows up as a rule that the risky, outward-facing, irreversible step never belongs to the agent: the agent queues, the human publishes. A handoff a worker can approve for itself is not a handoff.
§4The two parts that are harder than the spec looks
Reading a clean spec, you would think the primitives are the work. They are not. Two of them are where the real hours go, and both are places we got it wrong first.
The first is who owns writeback. It is tempting to let a projection of the state, a nice dashboard, a synced board in some other tool, become a place work is also edited. loopx names this exact trap and forbids it: projections must not become the source of truth. We learned that the hard way. The moment two systems can both write the canonical state, you have two truths and a race, and the agent will faithfully act on whichever one it read last. One writer. Everything else is a read-only mirror, or it is a bug waiting for a quiet weekend.
The second is the wake schedule. "Auto-wake" sounds like a checkbox and is really a cost-and-freshness tuning problem with no universally right answer. Wake too often and you thrash, pay for cold caches, and generate noise. Wake too rarely and the loop is asleep when it should be moving, and a time-sensitive card goes stale. There is no setting that is correct for every task, only a rule you keep adjusting against what actually happened. A state kernel gives you the lever. It does not tell you where to put it.
§5Where it nets out, and the caveat
If you are building anything that runs longer than a single session, build the kernel before you polish the agent. Put the goal, the todos, the evidence and the quota in a store the agent only reads and writes, make one writer authoritative, and keep the irreversible steps on a layer the agent cannot approve for itself. Do that and the model you use becomes a decision you can change on a Tuesday, which is exactly where you want that decision to live given how fast models move.
The honest caveat: we have not run loopx, so this is not a review of its code, its recovery behaviour or its edge cases. It is an argument about the architecture it embodies, checked against the equivalent system we operate every day rather than against its test suite. Ours is homegrown and grew by accretion; loopx is a deliberate, provider-neutral take on the same idea, and it is refreshing to see it written down as a spec other people can adopt. If it saves one team from putting their plan in a context window and calling it autonomy, it will have earned its stars. Credit to its author for drawing the line in the right place: the durable part of an agent system is not the agent.