What is loop engineering? A definition

What loop engineering means

Loop engineering is the practice of designing the repeating cycle an AI agent runs in: what wakes it, what it may touch, how its output is checked, and what stops it. Prompt engineering shapes one message to a model. Loop engineering shapes the process that sends thousands of messages while you are asleep. The unit of work moves from the prompt to the loop.

The short version: you stop writing instructions and start writing a control system. The agent still needs good instructions, but they become one component inside a cycle that runs on a schedule, works in an isolated copy of your code, proves its own result with a test, and gives up when a budget runs out.

Why the term appeared in 2026

The name is being fixed in public right now. The GitHub repository cobusgreyling/loop-engineering passed 9,600 stars inside two months of first appearing (as of July 2026), under the line "Stop prompting. Design the loop. Get a score." It collects the shift into six building blocks: scheduling, worktrees, skills, plugins and connectors, sub-agents, and durable memory kept outside the conversation.

It quotes Boris Cherny, who leads Claude Code at Anthropic:

I don't prompt Claude anymore. I have loops running that prompt Claude.

A second repository, AI-Builder-Club/skills, sits near 1,100 stars (as of July 2026) and names the two roles directly: a "codebase harness" that makes a repository safe for an agent to run tests and deploys in, and a "loop engineer" who builds workflows that wake on a trigger, do the work, and write what they learned into a shared file so the next loop can read it.

Neither repository invented the practice. Anyone who has run a nightly build, a linter in continuous integration, or a cron job that opens a ticket already knows the shape. What is new is that the worker inside the loop is now non-deterministic, which changes what the surrounding machinery has to do.

The four parts of a loop

Every working loop has these four parts, and a loop that skips one of them is the loop that wakes you at 3am.

• Trigger. The event that starts a run: a timer, a webhook, a new pull request, an alert.
• Boundary. The files, credentials and network the agent may reach during that run.
• Verification. A check with an exit code that decides whether the run's output is kept or thrown away.
• Budget. The token, time and money limit that ends a run whether or not it succeeded.

Read those four back as questions and you have a design review for any agent you are about to leave running.

Trigger: what wakes the agent

A timer is the plainest trigger, and on a Linux server a systemd timer beats cron for this because it logs, it retries on your terms, and it will not start a second copy of a unit that is still running. That last property removes the most common overlap bug in agent loops: two runs editing the same branch.

Write the unit at /etc/systemd/system/agent-loop.service:

[Unit]
Description=Agent loop: triage open issues
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
User=agent
WorkingDirectory=/srv/agent/repo
ExecStart=/srv/agent/bin/loop.sh
TimeoutStartSec=1800

And the timer at /etc/systemd/system/agent-loop.timer:

[Unit]
Description=Run the triage loop every 30 minutes

[Timer]
OnBootSec=5min
OnUnitActiveSec=30min
Unit=agent-loop.service

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now agent-loop.timer
systemctl list-timers agent-loop.timer

systemctl list-timers should show a NEXT column with a time in the future and a LEFT column counting down. An empty result means the timer is not enabled, because enable without --now schedules it for the next boot only. TimeoutStartSec=1800 matters more than it looks: an agent that hangs waiting for input will otherwise hold the unit active forever, and the timer will never fire again. Read a run with journalctl -u agent-loop.service -n 50.

If you drive the loop from cron instead, add your own overlap guard, because cron will happily start a second copy:

*/30 * * * * /usr/bin/flock -n /tmp/agent-loop.lock /srv/agent/bin/loop.sh

flock -n exits immediately with status 1 when the lock is held, so the second run disappears quietly instead of racing the first. The same systemd service and timer setup applies to any long-running job on the box, agent or not.

Boundary: give each run its own copy

An agent editing your working tree is an agent that can lose your uncommitted work. Git worktrees solve this cheaply: each run gets its own directory and its own branch, sharing one object store.

cd /srv/agent/repo
git worktree add -b loop/triage-01 /srv/agent/work/triage-01 origin/main
git worktree list

git worktree list prints one line per tree with its path, commit and branch. When the run ends, git worktree remove /srv/agent/work/triage-01 deletes the directory, and git worktree prune clears entries whose directory has vanished. Parallel loops become safe at this point, because two agents on two branches in two directories cannot overwrite each other.

The boundary is also about credentials. A loop that runs unattended holds long-lived tokens, and every run is a chance to leak one into a log, a commit or a model context. Scope the token to the one repository the loop touches, keep it out of the environment the agent's own shell sees where you can, and read how to keep secrets out of AI agents before you hand a loop production access. For a harder wall, put the whole loop on a disposable VM you can destroy after each run.

Verification: the gate that makes the loop safe

This is the part that separates a loop from a cron job that types. The agent's output is a proposal. The gate decides.

#!/usr/bin/env bash
set -euo pipefail

repo=/srv/agent/repo
branch="loop/$(date -u +%Y%m%dT%H%M%SZ)"
tree="/srv/agent/work/$(basename "$branch")"

cd "$repo"
git fetch --quiet origin
git worktree add -b "$branch" "$tree" origin/main
cd "$tree"

# the agent's own command runs here, in non-interactive mode

if ! npm test; then
  echo "gate failed: discarding $branch" >&2
  cd "$repo"
  git worktree remove --force "$tree"
  exit 1
fi

git push origin "$branch"
cd "$repo"
git worktree remove "$tree"

set -euo pipefail is doing real work in that script. Without -e, a failed git fetch is ignored and the run continues against a stale origin/main. Without -u, a typo in a variable name expands to an empty string, and the cleanup then runs against the wrong path instead of failing loudly.

The if ! npm test block is the whole idea. The exit code of a check you already trust, your test suite or your type checker, decides whether the branch is pushed or destroyed. A loop with no gate produces work nobody has time to review, which is worse than no work. A loop with a gate produces a branch that already passed the same bar a human contributor's branch has to pass.

Pick a gate that fails honestly. A test suite that passes on an empty diff teaches the loop that doing nothing is a success. Repositories with weak tests get weak loops, which is why the trending repositories put "make the codebase agent-ready" before "write the loop".

Budget: what stops a run

An agent that retries forever is an agent with an unbounded bill. Give every loop a wall-clock ceiling, enforced by TimeoutStartSec above; a retry count inside your script; and a spend cap enforced by the provider account. Then log what each run cost, so you can see a loop drift before the invoice does. Cost control for an always-on agent VPS covers the accounting side, and managing the context an agent carries between turns covers the largest single lever on per-run cost, because a loop that re-reads the same repository every 30 minutes pays for it every 30 minutes.

Cost is why loops usually beat one long session. A run that starts fresh, does one narrow job and exits keeps its context small. A session left open for eight hours carries every earlier mistake in its history, and pays for the whole transcript on every turn.

The patterns the trending repositories codify

The loop-engineering repository lists seven production patterns, and they are worth reading as a menu rather than a manifesto. Daily triage. A pull-request babysitter that watches for review comments and answers them. A continuous-integration sweeper that picks up red builds. A dependency sweeper. A changelog drafter. Post-merge cleanup. Issue triage.

What they share is a narrow job with an obvious gate. "Fix the failing build" has a pass condition the machine can read. "Improve the codebase" does not, so it never becomes a loop. It becomes a mess with a schedule.

They also share a written record. Both repositories push state out of the conversation and into files in the repository: what ran, what it found, what it decided. That file is the loop's memory, and it is the reason a second loop can build on the first one's work instead of rediscovering it. It is also how you audit an agent after the fact, since the model's context is gone the moment the run exits.

Where loops fail

The failures are boring, and they repeat across teams.

• No gate. Output accumulates, nobody reviews it, trust collapses, and the loop is switched off.
• Overlap. Two runs on one branch, or two agents in one working tree, producing conflicts the agent then tries to resolve.
• Silent drift. The loop keeps passing because the check is too weak to fail.
• Unbounded scope. A trigger that fires on every commit in a busy repository turns into a spend problem within a day.

Each has the same fix: shrink the job, sharpen the check, and log the run. If you cannot describe the pass condition in one sentence, the job is not ready to be automated.

Getting started without the vocabulary

You do not need a framework. A small always-on Linux server, a git repository whose test suite fails when it should, one systemd timer and one shell script with an if in it make a complete loop. That is genuinely where most people should start, because the design questions get answered by running the thing rather than by picking a tool. Once one loop is stable, running a second is mostly a matter of another timer and another worktree. See how to run a coding AI agent on a VPS for the base setup, and the current self-hosted AI agent options if you want the agent itself running on hardware you control.

FAQ

Is loop engineering different from prompt engineering?

Prompt engineering optimises one message: wording, examples, output format. Loop engineering optimises the cycle around the message: the trigger that starts a run, the sandbox it runs in, the check that accepts or rejects its output, and the budget that ends it. You still need a good prompt inside the loop. The prompt stops being the thing you tune day to day, because the gate and the trigger have more effect on the result.

Do I need a framework to build an agent loop?

No. A systemd timer, a git worktree per run, a shell script that ends in a test command, and a spend cap on the provider account cover every part of the definition. Frameworks add scheduling interfaces, shared memory formats and multi-agent routing, which are useful once you run several loops. They are not the entry price for the first one.

What is a codebase harness?

It is the set of things that let an agent work in a repository without a human present: a one-command setup, tests that run non-interactively and fail loudly, a linter, and a way to deploy or preview a change. The term comes out of the same 2026 wave of repositories as loop engineering. The practical test is simple: if a new human contributor cannot get from clone to green tests with one command, an agent cannot either.

How do I stop an agent loop from running up a large bill?

Cap it in three places. Set TimeoutStartSec on the systemd unit so a hung run is killed. Cap retries inside the script rather than looping until success. Set a hard spend limit on the API account, since that is the only ceiling the agent cannot talk its way past. Then log per-run cost, because a loop whose cost doubles is usually a loop whose scope quietly widened.

Which jobs are worth turning into a loop first?

Pick a job with a machine-readable pass condition and a small blast radius. Fixing a red build, updating a dependency and regenerating a changelog all qualify, because a test suite or a diff can prove the result. Open-ended work like refactoring or design does not qualify yet, since there is nothing for the gate to check, and a loop without a gate is an expensive way to generate review debt.