Loop engineering na wetin? Simple definition

Wetin loop engineering mean

Loop engineering na the practice of designing the repeating cycle wey an AI agent dey run: wetin go 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 the prompt go the 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 component inside a cycle wey dey run on a schedule, dey work for an isolated copy of your code, dey prove its result with a test, and dey stop when budget don finish.

Why dem use di term for 2026

Dem dey settle the name for public 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 dem keep outside the conversation.

E quote Boris Cherny, wey dey lead Claude Code for Anthropic:

I no dey prompt Claude again. I get loops wey dey 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 dey make repository safe for agent to run tests and deploys inside am, and a "loop engineer" wey dey build workflows wey wake up when trigger happen, do the work, and write wetin dem learn into shared file so the next loop fit read am.

None of the two repositories invent this practice. Anybody wey don run nightly build, linter for continuous integration, or cron job wey dey 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.

Parts wey make loop

Every loop wey dey work get these four parts. If loop miss one, e fit wake you for 3am.

• Trigger. Na event wey start one run: timer, webhook, new pull request, or alert.
• Boundary. Na files, credentials, and network wey agent fit reach during that run.
• Verification. Na check wey get exit code. E decide whether to keep or throw away the output from the run.
• Budget. Na limit for token, time, and money wey go end the run, whether e succeed or not.

If you turn these four points into questions, you get design review for any agent wey you wan leave running.

Trigger: wetin dey wake the agent

Timer na the simplest trigger. For Linux server, systemd timer better pass cron for this work because e dey log, e dey retry based on how you set am, and e no go start another copy of unit wey still dey run. This last property removes 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=1800

And 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.target

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

systemctl list-timers suppose show NEXT column wey get future time, and LEFT column wey dey count down. Empty result mean say timer no dey enabled, because enable without --now go schedule am for next boot only. TimeoutStartSec=1800 important pass as e look: agent wey hang dey wait for input go otherwise keep the unit active forever, and timer no go fire again. Read one run with journalctl -u agent-loop.service -n 50.

If you use cron to drive the loop instead, add your own overlap guard, because cron fit start another copy without problem:

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

flock -n go exit immediately with status 1 when lock dey held. So the second run go 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: give every run e own copy

An agent wey dey edit your working tree fit lose work wey you never commit. Git worktrees solve this cheaply: every run get e own directory and e 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 list

git worktree list dey print one line for every tree with e path, commit and branch. When the run finish, git worktree remove /srv/agent/work/triage-01 dey delete the directory, and git worktree prune dey 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.

The boundary concern credentials too. A loop wey dey run unattended dey hold tokens wey fit last long, 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 comot from the environment wey the agent own shell dey see. Read how to keep secrets away from AI agents before you give loop production access. If you need stronger separation, put the whole loop for a disposable VM wey you fit destroy after every run.

Verification: gate wey dey make the loop safe

Na this part dey separate a loop from cron job wey dey type. The agent output na proposal. The 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, failed git fetch go dey ignored and the run go continue against stale origin/main. Without -u, typo for variable name go expand to empty string, and the cleanup go then run against wrong path instead of failing clearly.

The if ! npm test block na the main idea. The exit code from check wey you already trust, your test suite or your type checker, dey decide whether to push or destroy the branch. Loop wey no get gate dey produce work wey nobody get time to review, and that one worse pass no work. Loop wey get gate dey produce branch wey don already pass the same standard wey human contributor branch must pass.

Choose gate wey go fail honestly. Test suite wey dey pass with empty diff dey 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".

Budget: wetin dey stop one run

Agent wey dey retry forever na agent wey get bill wey no get limit. Give every loop one wall-clock ceiling, make TimeoutStartSec above enforce am; put retry count inside your script; and make provider account enforce one spend cap. Then log wetin each run cost, so you fit see when loop dey drift before invoice show am. Cost control for agent VPS wey dey always on cover the accounting side, and how to manage the context wey agent carry between turns cover the biggest single way to reduce cost per 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 and exit dey keep im context small. Session wey remain open for eight hours carry every earlier mistake for im history, and pay for the whole transcript on every turn.

The patterns wey trending repositories dey codify

The loop-engineering repository list seven production patterns, and e better make you read dem like menu instead of manifesto. Daily triage. One pull-request babysitter wey dey monitor review comments and answer dem. One continuous-integration sweeper wey dey pick red builds. One dependency sweeper. One changelog drafter. Cleanup after merge. Issue triage.

The thing wey dem get for common na one narrow job with one clear gate. “Fix the failing build” get pass condition wey machine fit read. “Improve the codebase” no get am, so e never turn to loop. E go turn to mess with schedule.

Dem still get written record for common. Both repositories dey move state comot from conversation enter files inside the repository: wetin run, wetin e find, and wetin e decide. That file na the loop memory, and na wetin make second loop fit continue the first loop work instead of finding the same thing again. E still be how you fit audit agent later, because model context don disappear immediately the run comot.

Wey loops dey fail

The failures no dey interesting, and dem dey repeat for different teams.

• No gate. Output dey pile up, nobody dey review am, trust dey disappear, and dem dey switch off the loop.
• Overlap. Two runs dey happen for one branch, or two agents dey work for one working tree, and dem dey create conflicts wey the agent later tries to resolve.
• Silent drift. The loop dey continue to pass because the check no strong enough to fail.
• Unbounded scope. Trigger wey fires for every commit inside busy repository fit turn to spending problem within one day.

Each 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 never ready for automation.

Getting started without the vocabulary

You no need framework. One small Linux server wey dey always on, one git repository wey im test suite dey fail when e suppose fail, one systemd timer, and one shell script wey get if inside am fit make complete loop. Na so most people suppose start, because you go answer the design questions by running the thing, instead of choosing tool first. Once one loop 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 current self-hosted AI agent options 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: the wording, examples, and output format. Loop engineering dey optimise the cycle around the message: the trigger wey starts a run, the sandbox wey e runs inside, the check wey accepts or rejects the output, and the budget wey ends am. You still need a good prompt inside the loop. But prompt no longer be the main thing you tune every day, because the gate and trigger dey affect the result more.

I need framework to build an agent loop?

No. A systemd timer, one git worktree for each run, a shell script wey ends with a test command, and a spend cap for the provider account cover every part of the definition. Frameworks add scheduling interfaces, shared memory formats, and multi-agent routing. These things dey useful when you run several loops. But framework no be requirement to start the first one.

Wetin be codebase harness?

Na the set of things wey let an agent work inside a repository without human presence: setup with one command, tests wey run non-interactively and fail loudly, a linter, and a way to deploy or preview a change. The term come from the same 2026 wave of repositories as loop engineering. The practical test simple: if new human contributor no fit move from clone to green tests with one command, agent no fit do am too.

How I fit stop an agent loop from running up big bill?

Put limit for three places. Set TimeoutStartSec for the systemd unit so e go kill any run wey hang. Limit 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 past. Then log the cost for each run, because when loop cost doubles, e usually mean say the scope quietly become wider.

Which jobs dey 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 no get anything to check. Loop without gate na expensive way to generate review debt.