Using coding agents interactively in one conversation is how I started. But I hit a wall everytime I want a goal to run unattended for hours — i.e. burn tokens against a target goal until it’s actually met, and not until the session ends.

And I have no persistent record of what ran, what changed, and what happened when it fails halfway through.

I still conflate transcript and supporting .md with the actual state of the work, so a crash mid-run leaves me unable to tell “this already happened” from “this still needs to happen.”. A TODO.md and a DONE.md alone provide such information at a very high level. But what actually happened is still opaque.

At a team level this may also be the gap that makes agentic pilots stop past the demo stage. I cannot answer the question “what did my agents do today or this week?” without reading raw logs.

And I don’t want to hand an agent an unattended, multi-hour goal when a dropped run means silently redoing (or double-doing) expensive work.

It’s a control plane (not another agent framework) to which I give a goal: it runs a loop — plan, act, check against completion criteria, repeat — until the goal is met or it escalates back to you. Every run gets written to Postgres, so instead of a terminal scrollback that vanishes when you close the window, you get a durable, queryable history: what ran, what changed, what failed, when it retried. The React dashboard sits on top of that history — it’s the answer to “what did my agents do” as opposed to a live status ticker that only shows “what is my agent doing right now.”

The part that matters most: it drives Pi, a provider-independent coding agent, instead of calling any one vendor’s API directly. That means the same loop definition runs unmodified against Claude, GPT, Gemini, Kimi, or a local model — you’re not rewriting your orchestration layer every time you want to try a different model or a client insists on their own vendor. For a team, that’s the difference between betting your automation stack on one provider’s roadmap and being able to swap the engine under a loop that already works.

Building this made concrete something I’d only understood abstractly from watching how other agent-loop projects fail: conversation state and workflow state are not the same problem, and treating them as one is why so many long-running agent setups quietly break on restart. A transcript answers “what did we say” — it says nothing about what step you’re on, what side effects already fired, or whether a given action is safe to retry. Building the run history as its own durable, structured record, not a log tail of the conversation, forced me to actually model the loop as named states with real persistence, instead of assuming the agent’s own narration was the source of truth.

The natural next step is closing the loop further: right now a run stops when the goal is met or it escalates to a human, but the richer version is a run that feeds its own outcome back into how the next run behaves, the way a scheduled retraining job or a self-healing CI pipeline does. The other direction is depth on the control side: today’s escalation is coarse; a team running this on anything that touches production, spends money, or sends external messages needs graduated approval gates — reversible reads run free, irreversible or costly actions pause for a human — rather than one blanket “ask before continuing” switch. That’s the version of this that scales past a solo builder’s overnight runs into something a platform team could put in front of multiple agents and multiple engineers without losing track of who authorized what.