THE SIX PRIMITIVES OF A LOOP

The Six Primitives of a Loop

A well-designed agent loop has five working parts plus one place to remember state. These primitives are consistent across both Claude Code and OpenAI Codex.

1. Automations — The Heartbeat

Automations are what make a loop an actual loop and not just one run you did once. They surface work on a schedule without you asking — everything else in the loop reacts to what they find.

Automations run on a cadence and produce findings. Runs that find something land in a triage inbox or state file. Runs that find nothing archive themselves. The key in-session primitive is /goal: it keeps working across turns until a condition you wrote is actually true, with a separate model checking whether you are done after every turn — so the agent that wrote the code is never the one grading it.

2. Worktrees — Isolation for Parallel Work

The second you run more than one agent, file collisions become the dominant failure mode. Two agents writing the same file is precisely the same problem as two engineers committing to the same lines without coordination.

A Git worktree fixes it. It is a separate working directory on its own branch sharing the same repository history, so one agent’s edits cannot touch another’s checkout. Both Claude Code and Codex support worktrees natively — giving each agent its own isolated environment that cleans itself up after.

3. Skills — Codified Project Knowledge

A skill is how you stop re-explaining the same project context every session. Both tools use the same format: a folder with a SKILL.md inside holding instructions and metadata, plus optional scripts, references, and assets.

A skill encodes:

• Project conventions and build steps
• Decisions the team made and why
• The context the agent would otherwise guess at

Without skills, the loop re-derives your whole project from zero every cycle. With skills, the loop’s understanding compounds.

4. Plugins and Connectors — The Loop Touches Real Tools

A loop that can only see the filesystem is a tiny loop. Connectors, built on MCP (Model Context Protocol), let the agent read your issue tracker, query a database, hit a staging API, file a PR, or drop a message in Slack.

This is the difference between an agent that says “here is the fix” and a loop that opens the PR, links the Linear ticket, and pings the channel once CI is green — entirely on its own.

5. Subagents — Separate the Maker from the Checker

The most structurally important thing in a loop is splitting the agent that writes from the agent that checks. The model that wrote the code will grade its own homework too generously. A second agent with different instructions — and sometimes a different model — catches what the first one talked itself into.

The standard split in both tools:

• One agent explores and triages
• One agent implements a fix or feature
• One agent verifies the result against the spec and existing tests

6. State / Memory — The Spine of the Loop

The sixth primitive sounds too simple to matter: a Markdown file, a Linear board, anything that lives outside the single conversation and holds what has been done and what is next.

But it is the trick every long-running agent depends on. The model forgets everything between runs; the repo does not. The state file is the spine. It remembers what was tried, what passed, and what is still open — so tomorrow’s run picks up exactly where today’s stopped.