Chapter 2 of 8
Automations & the /goal Primitive
The heartbeat of a loop — scheduled discovery and triage, plus the /goal primitive that runs until a verifiable condition is true.
Automations & the /goal Primitive
Automations are what make a loop an actual loop and not just one run you did once. There are two primitives worth knowing, and they do different things.
Primitive 1: the scheduled automation (discovery + triage)
A scheduled automation fires on a cadence, runs a prompt, and routes the findings to you. Runs that find something land in a triage inbox; runs that find nothing archive themselves.
In Claude Code, you reach the same place through scheduling and hooks:
# Re-run a prompt on an interval (e.g., poll a deploy every 5 minutes)
/loop 5m /check-deploy
# Or schedule a cron task, or fire shell commands at agent-lifecycle points via hooks,
# or push the whole thing to GitHub Actions so it survives your laptop closing.
In the Codex app, you create one in the Automations tab: pick the project, the prompt, the cadence, and whether it runs on your local checkout or a background worktree.
OpenAI uses these internally for the boring stuff: daily issue triage, summarizing CI failures, writing commit briefings, hunting bugs somebody added last week.
Automations should call skills, not paste walls of text
An automation can invoke a skill, so you keep the recurring thing maintainable — you fire $skill-name instead of pasting a giant wall of instructions into a schedule that nobody will ever update.
Primitive 2: /goal (run until a condition is true)
This is the one closer to the heart of loop engineering. /loop re-runs on a cadence. /goal keeps going until a condition you wrote is actually true.
The key design move: after every turn, a separate small model checks whether you are done — so the agent that wrote the code is not the one grading it.
# Give it a verifiable stopping condition and walk away
/goal all tests in test/auth pass and lint is clean
Codex has the same thing, also called /goal: it keeps working across turns until a verifiable stopping condition holds, with pause, resume, and clear. Same primitive, both tools.
Why the maker-checker split matters here
/goal is the maker-checker pattern applied to the stop condition itself. The model that did the work is too nice grading its own homework. A fresh model deciding "is the loop done?" is the only reason you can walk away from a /goal and trust the result.
This is the structural theme of the whole course: whenever a loop runs unattended, the verifier has to be something other than the thing that produced the output. We will see it again in sub-agents.
Automations cost tokens on a schedule
Every automation run consumes tokens whether or not it finds anything. A 5-minute /loop on a complex prompt can burn more tokens in a day than a week of manual prompting. Set a cadence matched to how fast the underlying state actually changes — a deploy check every 5 minutes is fine; re-summarizing a stable codebase every 5 minutes is waste.
What this block contributes to the loop
Automations are the part that surfaces the work. The rest of the loop is what acts on it — worktrees to act in parallel, skills to act competently, connectors to act in your real environment, sub-agents to act carefully, and state to remember what it did.
Next: Worktrees & Parallelism — so parallel doesn't turn into chaos.