Loops and goals

Long-running objectives, subagent swarms, and the 24-hour employee.

Plan mode executes a plan once. The next gear up is a goal: a single objective the agent keeps working toward on its own, planning, building, checking its result, and going again, until the thing is actually done. People call the craft of setting these up well loop engineering, and it's where the biggest results (and the biggest token bills) live.

The economics behind it come straight from our engineering meetups. One builder framed a monthly subscription as a 24-hour employee: if you stop giving it work at 5pm, you're wasting most of what you pay for. So the move is to hand agents long, well-scoped jobs and let them run, often overnight, often several in parallel.

Where this actually happens today:

• –Codex's cloud. Long tasks run on OpenAI's servers, self-managing their own context, surviving your laptop closing. Its automations can even trigger on events like a new commit, so the loop runs without you starting it.
• –Subagent swarms. Both Codex and Claude Code can fan a big goal out across specialist helpers working in parallel, then gather the results, which is what turns “refactor the whole app” from a week into an afternoon.
• –Parallel worktrees. Multiple full agent sessions on separate copies of the same project, each chasing a different feature, merged when they land. This is the mechanic behind people who say they “manage a team of agents.”

Loop engineering is mostly about guardrails, because an unsupervised agent chasing a fuzzy goal will happily run in circles and burn tokens. Three that matter: give it a crisp definition of done it can test against, wire in checkpoints so a bad hour is one rollback away, and set a spending limit so an infinite loop hits a wall instead of a bill. Get those right and the agent's productivity while you sleep stops being a party trick.

AI Clubhouse · Vibe Coding Guide