4 min read
Loop Engineering is appearing in conversations about coding agents because prompting is no longer the only useful unit
of work.
Instead of telling an agent what to do one turn at a time, a team can design a system that finds work, gives it to an
agent, evaluates the result, records state, and decides whether to continue.
The term is still emerging. It is practitioner language, not a settled engineering standard.
Its most useful idea is the boundary between the inner and outer loop.
What happens inside the loop
The inner loop is where repeated execution lives:
- Inspect the task and repository.
- Choose or follow a plan.
- Implement a scoped change.
- Run checks.
- Read the result.
- Adjust and try again.
Agents are well suited to this cycle because they can work through files, commands, failures, and revisions without a
person controlling every turn.
The inner loop can remove tedious coordination. It can also repeat a mistake at machine speed.
What the outer loop owns
The outer loop defines the conditions under which inner-loop activity is useful.
It owns:
- the product goal;
- the approved specification;
- important invariants;
- the risk classification;
- the allowed scope and permissions;
- the evidence standard;
- time, token, and retry budgets;
- escalation and recovery;
- the accountable production verdict.
Addy Osmani’s “outer loop” framing connects quality controls to evidence and evidence to a verdict. IBM’s explanation
of Loop Engineering similarly includes explicit goals, observation, adjustment, and stopping criteria while keeping
humans responsible for quality, security, and business outcomes.
These sources explain an emerging practice. They do not prove that one loop design fits every team.
Why the core matters more than the cycle
A loop multiplies the quality of the system it repeats.
If the goal is unclear, repeated investigation does not discover what the product owner never decided.
If the specification is weak, the agent can optimise the wrong behaviour until every test passes.
If context is stale, memory makes the old mistake more consistent.
If the evaluator shares the maker’s assumptions, each iteration can increase confidence without increasing proof.
If the stop rule is “looks complete,” the loop ends on plausibility.
This is why Loop Engineering cannot be copied as a scheduler around a prompt. The visible recurrence is the easy part.
The core is the engineering.
Design an accountable outer loop
Give every loop one owned goal
The goal should name the user or system outcome, not only the implementation activity.
“Add an index” is work. “Keep product search below the approved latency threshold at the expected data size” is closer
to an outcome.
Define proof before execution
Write acceptance criteria with proof methods. Decide which facts need deterministic checks, which questions require
specialist judgement, and which decisions belong to a human.
Route by sensitivity
Use lighter loops for small, reversible work. Sensitive changes involving access, personal data, money, public
contracts, or security need a stronger floor even when the diff is small.
Separate maker and evaluator
The evaluator should receive an independent target and be able to return pass, fail, inconclusive, or decision required.
It should not use the maker’s summary as the answer key.
Preserve durable state
Store the active step, artifacts, results, decisions, and next action outside one conversation. A loop that cannot pause
and resume safely is only a long session.
Set stop and escalation rules
Define success, failure, uncertainty, decision, budget, and safety stops. State what happens next for each one.
Keep the verdict human-owned
The human does not need to approve every file write. They do need evidence, authority, and timing at consequential
boundaries.
A practical outer-loop receipt
Before a loop can propose a production verdict, require a compact receipt:
- Goal and specification version.
- Risk lane.
- Changed scope.
- Deterministic check results.
- Model-judged findings and limitations.
- Open uncertainty.
- Human decisions and reasons.
- Documentation status.
- Rollback or recovery path.
The receipt lets the accountable owner decide without reading the entire transcript.
paqad-ai as lifecycle orchestration
paqad-ai fits this model because it is designed around the full feature-development orchestration, not one agent turn.
It routes work, creates planning and specification artifacts, coordinates specialist roles, runs checks, pauses for
human decisions, syncs documentation, and records evidence.
The agent runs inside the workflow.
The team owns the workflow.
That ownership is the practical meaning of the outer loop.
Loop Engineering can remove repetitive prompting. It cannot remove accountability. If anything, a faster inner loop
makes ownership of the outer loop more important.
Install paqad-ai: https://github.com/Eliyce/paqad-ai/
Source notes
- Addy Osmani, Loop Engineering.
- Addy Osmani, Own the Outer Loop.
- IBM, Loop Engineering.
- NIST AI RMF Core, voluntary governance guidance.
