Loop Engineering for the Enterprise

For three years the marquee skill in applied AI was prompt engineering — phrasing a single request so a model would do the right thing on the first try. In the second week of June 2026 that framing quietly stopped being the interesting problem. Peter Steinberger, working on the OpenClaw agent project, argued that the skill that now matters is designing the loops that drive agents, not the prompts inside them. The next day Addy Osmani at Google published an essay that gave the practice a name: loop engineering.

The distinction is not cosmetic. A prompt is a single turn. A loop is a control structure — the agent acts, observes the result, decides the next step, and repeats, ideally until a goal is actually met rather than until the operator runs out of patience. The unit of design moves from the wording of one request to the shape of the process around it: what the agent steers toward, what signals it steers against, and when it is allowed to stop.

This reframing matters most in the enterprise, where agents now run unattended for minutes or hours against production systems. In our deployment work the pattern is consistent: most agent failures are loop-design failures, not model failures. A capable model in a loop with no testable stop condition will spin, drift, or burn budget. A modest model in a well-designed loop will converge on a verifiable result and stop. Teams keep upgrading the model when they should be fixing the loop.

This whitepaper treats loop engineering as a production discipline. It covers the two ingredients that separate a reliable loop from a runaway one, the anti-patterns we see most often, the design patterns that contain them, where loops belong beyond coding, and how to govern loops that run without a human watching. It closes with a checklist for a loop you would be willing to leave running overnight.