AgentLoop - Starts a fresh Codex worker and critic every cycle
by•
Unlike long-running agent chats, AgentLoop starts a fresh Codex worker and critic every cycle. Set the goal and GUIDELINES.md rubric once; workers build, critics test, and failures become concrete fix notes for the next clean context. Project files carry the memory. Runs stay local, sandboxed, observable, and cancellable from a live dashboard, with ChatGPT control through MCP. Polish mode can continue beyond PASS until the critic says SHIP. Open source and zero-dependency Node.js.
Replies
AgentLoop
AgentLoop
Fresh worker and critic each cycle is the right instinct, and the file-as-memory part is where I'd expect trouble. We ran a loop like this and hit critic flip-flop: the same code passed one cycle and failed the next, because nothing in the carried notes told the new critic what had already been tried and accepted. We ended up requiring two consecutive passes before calling it done. Do the fix notes accumulate across cycles, and does polish mode have a hard cycle cap?
AgentLoop
@dipankar_sarkar Yeah, you're poking at the right spot.
They don't accumulate. Only the last critic's fix line gets injected into the next worker prompt. STATE.md is the thing that carries, and the worker rewrites it every cycle. The critic doesn't even read STATE.md, it only sees PLAN.md, GUIDELINES.md and the actual files.
That's on purpose, and it's why I haven't hit the flip-flop. PASS ends the loop, so finished code never gets voted on twice. With polish mode on, the polish critic can only return IMPROVE or SHIP, there's literally no FAIL in the grammar, so it can't take a PASS back. If something regressed it comes back as IMPROVE, restore whatever broke.
Cap is hard. maxCycles 1 to 10, default 3. Polish doesn't get its own budget, it just spends whatever cycles are left after the PASS.
Your point still lands though. Stateless critic means nothing stops it asking for X in cycle 1 and not-X in cycle 3. Objective GUIDELINES items are the only thing holding that line, and if the rubric is loose your two-pass rule is probably the right call.
Was yours free-form or a fixed checklist? I suspect that's the actual variable.
Nice one, congrats on the launch. The relay between ChatGPT and Codex is painfully familiar. You start out supervising the work, then somehow end up doing project management for two AI tools. The fresh critic idea is the part that stands out for me. I’d be interested to see how it behaves on a larger codebase where the tests are incomplete or the problem is architectural rather than a clean bug fix. Also, can you cap how much of the codebase it is allowed to touch in each loop? That would probably be the difference between me trusting it and hovering over the dashboard anyway.
AgentLoop
@os_ishmael Thanks! And yeah, project managing two AI tools is exactly what pushed me to build this.
Scope is directory-level right now, not file-level. The project path gets realpath'd before a loop starts and has to sit inside the daemon's root, so symlinks can't sneak out. Then every worker and critic runs with cwd pinned to that project, workspace-write sandbox, network off inside it. One folder is the whole blast radius.
Inside that folder it's wide open though. No per-cycle file budget, no allowlist. PLAN.md keeps it narrow in practice since the worker only takes the next incomplete increment, but that's just the prompt, nothing actually enforces it.
Git is the real seatbelt. Learned that when a loop overwrote work I hadn't committed yet.
A proper per-loop scope cap is next on my list.
On the architectural stuff, it really comes down to whether you can write the goal as rubric items the critic can check. If you can, size doesn't matter much. Bug fix in a huge repo works fine. Architectural change with no tests, the critic has nothing to check against and it just thrashes. If you point it at something bigger I'd want to hear where it breaks.