Loop Engineering: From Prompting AI to Designing Systems That Prompt Themselves

Consider a familiar bottleneck. A model is stuck at 0.81 accuracy, and the target is 0.83. The analyst asks the AI assistant to try a new feature: 0.815. Then a different algorithm: 0.822. Then a higher learning rate: 0.819, so the analyst asks it to undo that. The assistant does the work. The analyst does everything around it: deciding when to run, reading each result, remembering what has already been tried, and choosing the next move. The problem is not simply that AI needs supervision. It is that skilled people are still operating the AI between every attempt, creating a hidden labor cost and a scaling constraint.

Build a small system that does what the analyst was doing: propose a change, score it, record the score, choose the next move, and repeat until the target is met or a budget runs out. Then let it run. That practice is loop engineering, and it is becoming an increasingly practical way for experienced teams to work with AI agents.

“I don’t prompt Claude anymore. I have loops running that prompt Claude. My job is to write loops.”
Boris Cherny, Head of Claude Code

The point generalizes well beyond coding. The leverage has moved from writing the individual prompt to designing the system that issues prompts. This was the subject of a live session at DataHack Summit 2026 by Sudalai Rajkumar, co-founder of CobuildX AI, who built such a system on stage and ran it live. The framework below comes from that session.

What is loop engineering?

Loop engineering is the practice of designing AI systems that run, receive feedback, self-correct, and repeat until a defined condition is met. A well-designed loop does more than automate a sequence of prompts. It gives an AI agent a measurable goal, a way to observe results, a mechanism for adjusting its next action, and a defined stopping condition. Miss one and the result is a script with a language model attached, which is useful but is not a loop. The discipline is writing the stopping condition first. “Make the site faster” never terminates. “Stop when the tests pass and the page loads under 800 milliseconds” does.

Loop engineering vs. prompting and automation

What every loop is made of

Eight parts make up a well-formed loop. When a loop misbehaves, it is usually missing one of them.

• Automation: Something starts the run, whether a schedule, a webhook, or a new record in a table.
• Hooks: Checks that fire on an event, such as before a commit or after an edit. They run outside the model and cannot be argued with, which makes them the right place for policy and security scanning.
• Isolation: Separate working copies, so parallel agents do not overwrite each other.
• Context engineering: Each cycle receives only what it needs, which keeps the loop faster, cheaper, and more accurate.
• Skills: The conventions, rubrics, and house style the agent should have without being told each time, written once and read every run.
• Connectors: The link to your real repositories, databases, and tools so that the loop can act rather than only produce text.
• Sub-agents: A separate maker and checker, kept apart. This is the most consequential design choice in the framework.
• State and memory: The agent’s context resets each run, but the record does not. Each run reads the durable log and writes back to it, which is what stops one cycle from repeating the last one’s mistake.

Four kinds of loops, and when each fits

Not every loop is the autonomous kind. There are four shapes, and the discipline is choosing the one that fits the task rather than the most autonomous one available.

• Turn-based: you prompt, it acts, you review. Best while requirements are still forming.
• Goal-based: runs until a checked condition holds. Best when the outcome is measurable but the path is not. This is the shape most people mean by agentic, most associated with work across the software development lifecycle, and the one that carries the strictest preconditions.
• Time-based: a schedule fires recurring work. Best for recurring duties.
• Proactive: watches, triages, and closes without a person present. Best for standing duties.

Should you build an AI loop? Ask these four questions

All four need a yes. If any answer is no, a single well-written prompt is the better tool.

• Does the task repeat? A loop pays back its setup over many runs.
• Can verification be automated? A test, a score, or a rule that can fail the work without a person present. If the only judge is human intuition, you have a review queue, not a loop.
• Can the budget absorb waste? Loops retry and explore, and that costs tokens.
• Does the agent have adequate tools? Logs, a way to reproduce results, the ability to run code. An agent that cannot observe its consequences cannot correct them.

The test works beyond engineering. Screening resumes across multiple open roles can meet all four conditions when the rubric, fairness checks, data, and tooling are defined. Drafting one executive’s severance agreement does not: it is infrequent, requires legal judgment, and has little tolerance for iteration.

Separate the maker from the checker

An agent that produces work is not a reliable judge of its own work. After reading the goal and doing the work, it tends to be optimistic about the result. A single context that both proposes and evaluates will talk itself into things. People do the same, which is why code review exists.

So the job is split. The maker reads the goal and the memory, proposes one change, and implements it. The checker grades that change in a fresh context, with different instructions and no access to the maker’s reasoning, and catches what the maker overlooked. The stop condition stays an objective gate, a test or a score or a threshold, never an opinion. That separation is what makes it reasonable to step away.

The principle applies beyond code. In software testing, the checker runs the tests; in HR, the agent drafting performance-review language should not evaluate it for rating inflation or biased phrasing. A separate fairness check gives legal and compliance teams a clear control point before unattended execution.

What a working loop looks like

On stage, the goal was precise: cross-validated accuracy of at least 83 percent, no data leakage, and a valid submission, judged by a grader the agent could not modify. Six steps ran in a cycle:

1. Propose: the maker edits the model.
2. Evaluate: the driver, not the agent, runs the grader.
3. Record: the score is written to the shared log, the loop’s memory.
4. Review: a checker reads the change in a separate context.
5. Reflect: the loop notes what helped to inform the next proposal.
6. Check: goal met? Stop. Otherwise, repeat.

Three limits sit above the cycle: a maximum number of iterations, a patience limit that stops the loop after a set number of rounds without improvement, and a hard budget cap. Reach any one and the loop stops, leaving either a model that cleared the bar or an honest record of every attempt that did not. Both are useful.

Where leaders stay involved

Loops rarely fail outright. The more common problem is that they work well enough that people stop paying attention. A checker agent is still an agent. It makes the loop safer, but it does not transfer responsibility for what ships. The person who designed the loop owns its output: correctness, data handling, and compliance.

Four risks increase as loops become more autonomous: comprehension debt, intent debt, cognitive surrender, and security exposure. Teams can lose sight of what the system contains, why a decision was made, whether outputs are being accepted without independent judgment, and what credentials or systems an unattended loop can reach.

This is also what separates a pilot from production. Moving from isolated pilots to production is less about the model and more about the checks, the memory, and the accountability around it. Designing a loop is a way to apply judgment more efficiently, not a way to avoid it.