Loop Engineering, Chapter 2: The Six Primitives of Loop Engineering

This is Part 2 of a series walking through my book Loop Engineering: Scaling and Governing Agentic AI. In the previous chapter, we took apart the loop itself. This one asks what a durable loop is built from.

Chapter 1 described the loop as an engine. An engine alone does not make a car. The gap between a loop that works once on your machine and a system that runs unattended for someone else is filled by a small number of building blocks that recur across every serious agentic system I have seen. The book names six. None is exotic; what matters is seeing them as primitives — parts you compose deliberately rather than reinvent each time.

The first is automations, the heartbeat. A scheduled trigger that wakes the system up, discovers work, and triages it without a human in the loop is what turns an agent you run by hand into a system that runs on its own. The second is worktrees, for parallelism and isolation. Git worktrees let several agents work simultaneously on the same repository without overwriting each other's files, which is what makes branch-per-agent safe instead of a recipe for collisions.

The third is skills — codified knowledge. A SKILL.md file captures a project's conventions once, so an agent stops relearning them every session and stops guessing at the things your team already decided. The fourth is plugins and connectors: tool access through a standard interface like the Model Context Protocol, so an agent can read a database, pull an issue, or post to Slack through one adapter instead of a dozen bespoke integrations.

The two primitives people skip

The fifth and sixth are the ones teams most often leave out, and they are the ones that separate a clever demo from a system you can trust. The fifth is sub-agents — the maker/checker split. The principle is simple and strict: the agent that generates work should not be the agent that grades it. A separate checker, with its own instructions and no stake in the answer, catches a class of errors that a self-reviewing agent is structurally blind to. The sixth is memory and state, the glue. A model forgets everything between sessions; the repository should not. Keeping state outside the context window — in Markdown, in a project board, in files the next run can read — is what lets the system remember what the model cannot.

Each primitive in the chapter comes with the economics behind it: when a Git worktree beats a full clone, when a standard connector beats a bespoke one, when a separate checker is worth the extra tokens and when it is not. The point is not to use all six everywhere, but to recognize which one a given failure is asking for.

Tomorrow: once you have more than one agent and more than one step, something has to coordinate them. Chapter 3 is a working guide to choosing an orchestration framework.