A long-running loop is not a magic “work for a long time” button. Long work is useful only when the agent has a checkable end condition, intermediate artifacts, and an independent way to verify the result.
Goal and loop are different modes
Claude Code documentation separates two modes.
/goal keeps the session working toward a condition. After each turn, a smaller model checks whether the goal criterion is satisfied and either closes the goal or sends Claude into another turn.
/loop solves a different problem: repeating a prompt on a schedule or self-paced interval, such as checking a deploy, PR, or CI job while the session is open.
What a governed loop needs
Minimum set:
- Planning: remove unknowns first: files, checks, constraints, and risks.
- Checkpoints: save progress, decisions, and next steps so the session can be recovered.
- Terminal condition: “tests pass”, “queue is empty”, “Lighthouse >= 90”, not “make it good”.
- Recovery: if the same failure repeats, change the rule or input instead of asking the agent to continue blindly.
Subagents are useful here not as parallelism theater, but as noise isolation. One agent can inspect logs, another can review a diff, a third can gather sources, and the main context receives a short result.
New Runtime Read
A governed loop differs from endless prompting because it has a budget and permission to stop.
For an editorial pipeline the principle is the same. Ingest, source resolution, and drafting should be separate states, not one long “make a post” request. Without an explicit human signal, the loop ends in a verified draft, not an external action.