AgentLoop

AgentLoop starts a new engine process for every worker and every critic session, so no prior chat history follows them. This avoids context rot, the buildup of stale assumptions that makes long-running chats unreliable. The durable memory is the project itself plus the concrete fixes the critic writes, which keeps tokens from being burned re-reading an ever-growing conversation.

You put your definition of done in GUIDELINES.md. A fresh critic reads that file every cycle alongside the worker's output and the project files. The critic's final line is a strict contract: it must land on PASS, FAIL with fix notes, or CONTINUE. FAIL becomes injected instructions for the next worker, so feedback turns into action rather than a comment you have to relay by hand. In the project's own evaluation, a fresh critic found a mixed percent-decoding defect after all nine tests had passed.

Progress lives in PLAN.md and STATE.md, not in a conversation. A worker reads the plan and state, makes one increment, updates state, and exits. Because the memory is in files, a loop stays bounded and easier to leave unattended. It also means you can read the same artifacts the agents work from and see exactly what changed in each step.

Every cycle, verdict, transcript, cost, and file handoff shows up on a local dashboard. You can cancel a run from there instead of hunting down a process, and you can ask ChatGPT for status through an MCP bridge. No guesswork. For anyone who's tried to debug an unattended agent run after the fact, having the timeline recorded is the difference between fixing a problem and guessing at it.

AgentLoop runs Codex CLI and Claude Code as interchangeable engines. You pick one per loop from the dashboard, or per task through the bridge. The project keeps planning separate from local execution, and the roadmap points toward two-way agent questions and research loops next.

For projects inside a git work tree, auto-checkpointing is on by default, so the daemon can commit progress as cycles complete. Sudden failures, like a stuck task that hits its retry cap, don't wipe out the work already done. Recovery is a git command away, not a lost afternoon. That matters on overnight runs.

A loop is intentionally sequential. Independent queued tasks can run up to a concurrency limit, but one loop never spins into a parallel swarm racing across the same project. That's deliberate. Budgets are capped too. maxCycles runs from 1 to 50 and defaults to 3, and taskRetries caps consecutive failures before a task is marked blocked and skipped.