Loop engineering na wetin? Simple definition
Loop engineering na how you design the trigger, boundary, checks and budget wey AI agent dey repeat, instead of relying on one clever prompt.
Loop engineering mean wetin
Loop engineering na the practice of designing the repeating cycle wey an AI agent dey run: wetin dey wake am, wetin e fit touch, how dem go check the output, and wetin go stop am. Prompt engineering dey shape one message for a model. Loop engineering dey shape the process wey dey send thousands of messages while you dey sleep. The unit of work dey move from prompt go loop.
The short version be say: you stop writing instructions and start writing a control system. The agent still need good instructions, but dem become one part inside a cycle wey run on schedule, work inside an isolated copy of your code, prove the result with a test, and stop when budget finish.
Why di term show for 2026
People dey settle the name publicly now. The GitHub repository cobusgreyling/loop-engineering pass 9,600 stars within two months after e first show (as of July 2026), under the line "Stop prompting. Design the loop. Get a score." E gather the change into six building blocks: scheduling, worktrees, skills, plugins and connectors, sub-agents, and durable memory wey dey outside the conversation.
E quote Boris Cherny, wey dey lead Claude Code for Anthropic:
I don't prompt Claude anymore. I have loops running that prompt Claude.
Another repository, AI-Builder-Club/skills, dey near 1,100 stars (as of July 2026) and e name the two roles directly: a "codebase harness" wey make repository safe for agent to run tests and deploys inside, and a "loop engineer" wey dey build workflows wey wake up when trigger happen, do the work, then write wetin dem learn into shared file so the next loop fit read am.
Neither repository invent this practice. Anybody wey don run nightly build, linter for continuous integration, or cron job wey open ticket already know the pattern. The new thing be say the worker inside the loop now dey non-deterministic, and this change wetin the surrounding machinery need to do.
Loop get four parts
Every loop wey dey work get these four parts. If loop miss one, e fit keep waking you for 3am.
- Trigger. Event wey dey start one run: timer, webhook, new pull request, or alert.
- Boundary. Files, credentials, and network wey agent fit reach during that run.
- Verification. Check wey get exit code. E decide whether to keep or throw away the run output.
- Budget. Token, time, and money limit wey go end the run, whether e succeed or not.
Read these four parts again as questions. You go get design review for any agent wey you wan leave running.
Trigger: wetin dey wake agent
Timer na the simplest trigger. For Linux server, systemd timer better pass cron for this work because e dey log, e fit retry based on how you set am, and e no go start another copy of unit wey still dey run. This last behaviour remove the commonest overlap bug for agent loops: two runs dey edit the same branch.
Write the unit for /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=1800And the timer for /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.targetsudo systemctl daemon-reload
sudo systemctl enable --now agent-loop.timer
systemctl list-timers agent-loop.timersystemctl list-timers suppose show NEXT column wey get future time, and LEFT column wey dey count down. If result empty, e mean say timer no dey enabled, because enable without --now go schedule am for next boot only. TimeoutStartSec=1800 important pass as e first look: if agent hang while e dey wait for input, e go hold unit active forever, and timer no go fire again. Use journalctl -u agent-loop.service -n 50 to read one run.
If you use cron to drive the loop instead, add your own overlap guard, because cron go start second copy without problem:
*/30 * * * * /usr/bin/flock -n /tmp/agent-loop.lock /srv/agent/bin/loop.shflock -n go exit immediately with status 1 when lock dey held. This make second run disappear quietly instead of racing the first one. The same systemd service and timer setup dey apply to any long-running job for the box, whether na agent or not.
Boundary: make every run get im own copy
Agent wey dey edit your working tree fit lose work wey you never commit. Git worktrees solve this problem cheaply: every run get im own directory and im own branch, while dem share one object store.
cd /srv/agent/repo
git worktree add -b loop/triage-01 /srv/agent/work/triage-01 origin/main
git worktree listgit worktree list go print one line for each tree with im path, commit, and branch. When the run finish, git worktree remove /srv/agent/work/triage-01 go delete the directory, while git worktree prune go clear entries wey directory don disappear. Parallel loops become safe for this point, because two agents for two branches and two directories no fit overwrite each other.
This boundary still cover credentials. Loop wey dey run unattended dey hold tokens for long time, and every run fit leak one enter log, commit, or model context. Limit the token to the one repository wey the loop dey touch. Where you fit, keep am out of the environment wey the agent own shell dey see. Read how to keep secrets out of AI agents before you give loop production access. If you need stronger isolation, put the whole loop inside a disposable VM wey you fit destroy after every run. The tool wey you run also define part of the boundary before you write anything, so e make sense to read how Cowork managed sandbox compare with Claude Code for your own machine before you decide how much isolation you need to build yourself.
Verification: the gate wey make the loop safe
Na this part dey separate loop from cron job wey dey type. Agent output na proposal. Gate na im dey decide.
#!/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 dey do real work for that script. Without -e, if git fetch fail, dem go ignore am and the run go continue with stale origin/main. Without -u, typo for variable name go expand to empty string, then cleanup go run against wrong path instead of failing clearly.
The if ! npm test block na the main idea. Exit code from check wey you already trust, like your test suite or type checker, go decide whether to push or destroy the branch. Loop wey no get gate go produce work wey nobody get time to review, and that one worse pass no work. Loop wey get gate go produce branch wey don already pass the same standard wey human contributor branch must pass. Green gate no tell you how much code agent touch to reach there, so e make sense to pair the check with standing instruction like the rule wey make agent take the smallest change wey work. This one keep the diff small enough to make review cheap.
Choose gate wey go fail honestly. Test suite wey pass for empty diff go teach the loop say doing nothing na success. Repositories wey get weak tests go get weak loops. Na why trending repositories dey put "make the codebase agent-ready" before "write the loop". If you want know whether your suite go really catch regression instead of only executing the lines, mutation testing na the check wey answer am. Agent wey dey return evidence report wey you fit run again instead of asking you to read its diff go turn that answer into something wey you fit confirm by yourself.
Budget: wetin dey stop one run
Agent wey dey retry forever fit pile up bill without limit. Give every loop a wall-clock limit, enforce am with TimeoutStartSec wey dey above; put retry count inside your script; and use provider account take enforce spending limit. Then log how much each run cost, so you fit notice when loop dey drift before invoice show am. Cost control for VPS agent wey dey always on explain the accounting side, while how to manage context wey agent dey carry between turns cover the biggest single way to reduce cost for each run, because loop wey dey read the same repository again every 30 minutes go pay for am every 30 minutes.
Cost na why loops usually better pass one long session. Run wey start fresh, do one small specific job, then stop go keep im context small. Session wey remain open for eight hours go carry every earlier mistake for im history, and go pay for the complete transcript on every turn.
Patterns wey trending repositories don put into practice
The loop-engineering repository list seven production patterns, and e good make you read dem as menu instead of manifesto. Daily triage. A pull-request babysitter wey dey watch for review comments and answer dem. A continuous-integration sweeper wey dey pick red builds. A dependency sweeper. A changelog drafter. Post-merge cleanup. Issue triage.
Wetin dem get in common na narrow job with clear gate. “Fix the failing build” get pass condition wey machine fit read. “Improve the codebase” no get one, so e never become loop. E go become disorganized work with schedule.
Dem also get written record in common. Both repositories dey move state comot from conversation put am inside files for repository: wetin run, wetin e find, and wetin e decide. That file na the loop memory, and na why second loop fit build on the first loop work instead of finding the same thing again. Na also how you fit audit an agent later, because model context dey disappear immediately the run finish. Live coordination na separate channel, and one Claude Code session fit hand work give another for the same box while both still dey run, but nothing for that exchange go survive after either session finish, so na the file remain the part wey you go read later.
Wetin make loops fail
The failure dem boring, and teams dey see dem again and again.
- No gate. Output dey pile up, nobody dey review am, trust dey disappear, and dem go switch off the loop.
- Overlap. Two runs dey happen for one branch, or two agents dey work inside one working tree, and dem dey create conflicts wey the agent later try resolve.
- Silent drift. The loop dey continue to pass because the check no strong enough to fail.
- Unbounded scope. Trigger wey dey fire for every commit inside busy repository go turn to spending problem within one day.
Every one get the same fix: make the job smaller, make the check sharper, and log the run. If you no fit describe the pass condition with one sentence, the job no ready for automation.
Start without the big-big technical terms
You no need framework. Small always-on Linux server, one git repository wey test suite dey fail when e suppose fail, one systemd timer, and one shell script wey get if inside fit complete the whole loop. Na here most people suppose start, because you go answer the design questions by running the setup, instead of choosing tool first. Once one loop don stable, to run another one mostly na to add another timer and another worktree. See how to run coding AI agent for VPS for the basic setup, and the self-hosted AI agent options wey dey available now if you want make the agent itself run for hardware wey you control.
FAQ
Loop engineering dey different from prompt engineering?
Prompt engineering dey optimise one message: wording, examples, and output format. Loop engineering dey optimise the cycle around the message: the trigger wey start one run, the sandbox wey e run inside, the check wey accept or reject the output, and the budget wey end am. You still need good prompt inside the loop. But prompt no be the main thing you go tune every day again, because gate and trigger get bigger effect for the result.
I need framework to build agent loop?
No. One systemd timer, one git worktree for each run, one shell script wey end with test command, and one spend cap for the provider account fit cover every part of the definition. Frameworks add scheduling interfaces, shared memory formats, and multi-agent routing. Dem useful when you dey run several loops. But you no need framework to start the first one.
Wetin be codebase harness?
Na the set of things wey allow agent work for repository without human present: one-command setup, tests wey run non-interactively and fail loudly, a linter, and one way to deploy or preview change. The term come from the same 2026 wave of repositories as loop engineering. The practical test simple: if new human contributor no fit go from clone to green tests with one command, agent no fit do am too.
How I fit stop agent loop from running up big bill?
Put cap for 3 places. Set TimeoutStartSec for the systemd unit so hung run go die. Cap retries inside the script instead of looping until success. Set hard spend limit for the API account, because na the only ceiling wey agent no fit talk its way past. Then log cost for each run, because when loop cost double, e usually mean say the scope don quietly widen.
Which jobs worth turning into loop first?
Choose job wey get machine-readable pass condition and small blast radius. Fixing red build, updating dependency, and regenerating changelog all qualify, because test suite or diff fit prove the result. Open-ended work like refactoring or design no qualify yet, because gate get nothing to check. Loop without gate na expensive way to generate review debt.