In June 2026, loop engineering started circulating as a name for a way of working with coding agents.
Addy Osmani described it as replacing yourself as the person prompting the agent by designing the system that performs the prompting instead. A goal is defined, the system finds work, assigns it, checks the result, records progress and selects the next action. (addyo.substack.com)
The automation has advanced.
The loop has not suddenly appeared.
Developers have always worked through repeated cycles of inspection, change and verification:
Inspect -> change -> build -> test -> interpret -> repeat
CI automated parts of that sequence. Continuous delivery connected it to release and deployment. Operations, monitoring and incident feedback closed the outer loop.
Coding agents automate more of the interpretation and decision-making that previously happened between executions.
I was already wondering why this was being discussed as a new loop rather than an extension of the delivery loop we already operate.
Later, I watched Benedikt Sanftl present The Agentic AI Engineer at AI Engineer World's Fair.
I liked the presentation.
The system moved through specification, build, evaluation, release, deployment, monitoring, diagnosis and optimisation. Production traces became new evaluation cases. Failed variants returned for another attempt. Successful variants progressed through a gate.
The agent-specific engineering was useful. The presentation covered trajectory and tool-call evaluation, harness behaviour, measurable evaluation criteria, production-failure clustering and comparisons between candidate versions and the live system.
It gave a concrete shape to the concern I already had.
I could not shake the feeling that we were rebuilding a delivery pipeline from first principles.
Define the intent. Build the change. Test it. Release it. Deploy it. Monitor it. Diagnose failures. Feed what we learn into the next iteration.
That is the DevOps loop.
The agent-specific mechanisms were useful additions. The lifecycle carrying them was familiar delivery engineering.
The concern is where the engineering starts.
Delivery systems already contain mature designs for isolated execution, independent verification, identity, provenance, policy enforcement, controlled promotion, rollback, observation and feedback.
Agentic execution should build on that foundation.
The Shape Is Familiar
Andrew Ng describes three loops: an agentic coding loop, a developer feedback loop and an external feedback loop that incorporates production and user feedback. (DeepLearning.ai)
The mapping to delivery terminology is approximate, but the shape is familiar.
The inner development loop. Review and integration. Production observation and product feedback.
The loops already have a logo. It is shaped like an infinity symbol.
The lifecycle shown in The Agentic AI Engineer also maps closely to that established delivery loop.
| Agent lifecycle | Existing delivery discipline |
|---|---|
| Define and design | Plan |
| Build | Code and Build |
| Evaluate | Test and Verify |
| Ship | Release and Deploy |
| Monitor | Operate and Monitor |
| Diagnose | Incident analysis |
| Optimise | Feedback and Plan |
The mapping does not make the agent-specific work redundant.
Trajectory evaluation is not a unit test. Harness behaviour introduces failure modes that a compiler cannot detect. Production traces can expose missing context, incorrect tool selection and behavioural drift. Model-based evaluation introduces variance and calibration concerns that deterministic tests do not have.
Those are real additions.
They belong inside a delivery structure whose purpose is already understood: move a candidate change through independent verification, controlled promotion, production observation and feedback.
The DevOps loop appears whenever changes must move through an unreliable process into systems that matter.
The actors change. The implementation inside each stage changes. The control structure remains recognisable.
The interesting part of loop engineering is the increased automation inside the loop.
The surrounding loop already exists.
A Demonstration Is Not a Delivery Architecture
The loop-engineering material that prompted this post begins with the recursive mechanism.
A scheduler starts an agent. A worktree isolates it. The agent discovers work, modifies files and runs a verifier. State records progress. A retry policy handles failure. A stopping condition determines whether the system should continue.
That is a valid way to demonstrate the inner loop.
It is not a sufficient starting architecture for production delivery.
The surrounding controls already exist elsewhere:
Identity boundaries. Protected branches and paths. Independent required checks. Artifact provenance. Promotion between environments. Rollback. Production observation. Incident feedback.
A conference presentation or short tutorial cannot cover an entire delivery platform. The omission itself is not the problem.
The problem appears when the demonstrated loop is copied as the system design and the missing delivery controls are added later from first principles.
Those controls carry operational history. They were shaped by failed deployments, skipped checks, compromised credentials, incomplete audit records and rollback paths that did not work when needed.
Public technical guidance becomes implementation material. Developers copy it into repositories. Other articles and videos repeat it. Search, retrieval and generated content reinforce the patterns that are already most visible.
Repetition can make an incomplete design look established before it has been exercised under production conditions.
This is not an argument that organisations are deliberately operating two delivery pipelines. I found no evidence to support that claim.
The concern is architectural amnesia.
Agentic delivery is being described from the agent outward, while the delivery system shaped by years of production failures appears as an integration around the edge.
The existing delivery system should be the starting architecture. The recursive agent loop belongs inside it.
Start With the Pipeline You Already Have
An agent loop can discover work, create an isolated branch or worktree, make bounded changes and run fast checks.
That is the inner development loop:
Intent -> generate -> run fast checks -> revise
When it produces a branch, diff or pull request, it has produced a candidate change.
The established pipeline can then build, independently verify, package, apply policy, promote, deploy and observe that change:
Build -> independent verification -> policy -> promotion
-> deployment -> observation -> feedback
The complete delivery pipeline does not need to run after every agent edit.
That would often be slow and expensive. The inner loop needs fast feedback so compilation errors, unit-test regressions and obvious implementation failures can be corrected without waiting for the full delivery process.
The delivery pipeline has a different responsibility. It provides independent evidence and determines whether the candidate may progress.
That distinction is particularly important around evaluation.
A stopping condition answers whether the agent should continue working.
A delivery gate answers whether the candidate is allowed to progress.
The two decisions may use overlapping evidence. They do not carry the same authority.
The model can select the next attempted action. Deterministic tools can evaluate executable conditions such as compilation, tests, type checking, dependency constraints, policy rules and interface compatibility.
Model-based evaluators can contribute evidence where semantic requirements cannot be expressed cleanly as deterministic assertions.
Their output remains evidence.
The evaluator, its prompt, thresholds and test dataset require calibration and regression testing. The system being evaluated should not hold sole authority over whether its output is acceptable.
Any required gate can stop a change.
No single gate can ship one.
This is already how mature delivery systems handle human-produced changes. Human approval may be required, but it is not sufficient. A red required check still stops the change.
The same principle applies when an agent produced the candidate.
Developers and agents produce candidate changes.
The delivery system verifies and promotes them.
Harden the Existing Design
I argued previously that intent-driven development changes the shape of risk. Implementation throughput increases faster than verification throughput, while most delivery systems were calibrated around human-rate change.
Human implementation speed acted as an implicit throttle. Broad changes required time and coordination. Agentic execution removes part of that throttle.
The response is to recalibrate the delivery system.
Extend provenance.
A commit hash records the resulting change. It does not record the complete environment that produced it.
Useful provenance for agent-generated work may include the model, harness, tool definitions, prompt or skill versions, source intent, granted permissions and evaluation configuration.
These are components of the change-production system. Modifying them can change outcomes without directly modifying application source.
Narrow permissions.
An agent changing documentation does not need access to deployment configuration, authentication code or production secrets.
Permissions should follow the task and change class. They should not default to the maximum capability supported by the agent product.
Existing identity and policy systems provide the base. Task-scoped identities and short-lived credentials extend them.
Protect sensitive paths.
A documentation correction, dependency update and authentication change do not carry the same blast radius.
They require different verification depth and different levels of autonomy.
Protected paths, ownership rules and policy checks already provide mechanisms for expressing those boundaries.
Limit throughput.
A system capable of producing hundreds of candidate changes can saturate reviewers, CI runners and deployment queues.
Diff budgets, concurrency limits and change-rate controls become containment mechanisms.
Increasing generation throughput provides little value when verification becomes the bottleneck.
Calibrate probabilistic evaluation.
Model-based evaluation can cover requirements that are difficult to reduce to deterministic checks. Its variance does not disappear because the result is expressed as a score.
Evaluation datasets need representative cases. Thresholds need calibration. Repeated runs may be required to distinguish a real improvement from normal variation.
A model-based gate should add evidence to the delivery decision. It should not quietly replace the other evidence already required.
Test the agent system.
Prompts, skills, harnesses, tool definitions and evaluators are software components.
A change can improve one task while degrading another. A new model can alter tool selection, token use, failure handling or compliance with repository constraints.
These components need versioning and regression testing.
Agent evaluation fits naturally inside the existing loop. It extends verification and observation. It does not replace them.
Build remains Build.
Deploy remains Deploy.
The evidence and controls inside those stages become richer.
The Loop Already Exists
The presentation that prompted this article was technically thoughtful.
It showed useful ways to evaluate, observe and improve agents. My reaction was not that its loop was wrong.
It was that the loop looked familiar.
Software delivery already has mature designs for isolated execution, independent verification, identity, provenance, policy enforcement, controlled promotion, rollback, observation and feedback.
Agentic execution automates more of that lifecycle. It introduces additional evidence, new failure modes and a higher potential change rate.
Those changes require engineering work.
They do not require forgetting the engineering already done.
Start with the pipeline that has survived production.
Add model and harness provenance. Narrow permissions. Protect sensitive paths. Limit throughput. Calibrate probabilistic evaluators. Regression-test the agent configuration.
The loop already existed.
More of it is automated now.
Build on the pipeline you already have.
Top comments (0)