What Is Loop Engineering? Building Better AI Agents
Martin Keen explains loop engineering as the next step beyond prompt engineering: designing systems where AI agents act, observe, adjust, and repeat toward verifiable goals. The discussion covers goal design, triggers, context and persistent state, tools via MCP and APIs, verifier subagents, and why humans must remain in the loop to manage comprehension debt, intent debt, and cognitive surrender.
Loop Engineering as the Successor to Prompt Engineering
The speaker opens by contrasting loop engineering with prompt engineering. Prompt engineering is about writing one perfect prompt, sending it to a large language model, reading the response, and then hand-writing the next perfect prompt. Loop engineering designs a system that does this prompting work automatically. It sends a prompt to an AI agent, checks the agent’s output, prompts again, and keeps going back and forth until the task is finished. The human no longer engineers every prompt, although the speaker signals that the word ‘minimal’ in ‘minimal human intervention’ will need unpacking later.
The Core Loop: Goal, Action, Observation, Adjustment
To make this concrete, the example is a checkout service with a set of failing unit tests, and the goal is to get them passing. The loop has four stages. The goal is the stopping criterion, evaluated on every pass. The agent then takes an action, such as opening a file or editing code. It observes the output, for instance test results. Finally it adjusts: if a test turns green, it moves on to the next failing one; if the test is still red, it tries a different fix. Then the loop returns to the question ‘are we done yet?’
The speaker places heavy emphasis on goal specification. A goal like ‘make the checkout faster’ is compared to a bad New Year’s resolution like ‘be happier’. Neither has a measurable test, so the agent could loop forever or stop after one pass and declare victory. A goal like ‘stop when every unit test in the checkout sweep passes’ is verifiable, so the agent knows exactly when it has succeeded. A good goal is specific and includes an explicit end or stopping condition.
What Surrounds the Loop
The speaker admits the loop itself is simple, which raises the question of why a whole engineering discipline is needed. The answer is that loop engineering is what gets built around the loop.
Triggers: something has to kick the loop off. A schedule, such as running the checkout loop every night, can be a plain cron job. A hook is event-driven and fires when something specific happens, like a file changing or a pull request opening. Developers largely use hooks for security and for enforcing policies.
Context: every pass through the loop generates context, such as test output or file contents. This piles up and makes it hard for the agent to focus on what matters, so context engineering means choosing what the loop actually gets to see. Techniques include compaction, and progressive disclosure through agent skills, which are instructions for how a recurring job is done.
Persistent state: the speaker calls this the ‘spine’. It might be markdown files where the agent records what it did and whether it worked. Future iterations read this record to learn what has worked, what hasn’t, and what to do next.
Tools: the action stage often requires calling external resources. This happens through standards like MCP (Model Context Protocol) or through direct API tool calling. Agents use tools to execute code, access file systems, run terminal commands, and query databases.
Subagents: rather than having the same agent that wrote the code check it, good loop engineering brings in a second agent as a checker and a coworker. It has its own instructions and context, may be powered by a different model, and sends its results back to the main agent.
Where Humans Still Belong
The speaker returns to ‘minimal’ human involvement. Even a well-built loop with a checker, subagents, and persistent state still needs people, and he names four pitfalls.
The first is unverified code. A checker subagent is still just an agent, and human developers remain responsible for all shipped code, so a real person has to read and verify it.
The second is comprehension debt, which is the gap between the total amount of code in a system and how much of it humans actually understand. As agents write more code and humans review less, this debt grows quickly, and it becomes a serious problem during urgent production failures or when someone must architect a migration.
The third is intent debt. An agent can read what a system does, but working out why it does it is harder unless that reasoning has been written down, perhaps in an AGENTS.md file (the transcript says ‘agent.md’). Without it, an agent can make a change that is technically sound but contrary to the project’s objectives. In the checkout example, the agent might make a failing test pass by relaxing validation on discount codes. That satisfies the tests and damages the business. The human’s job is to write intent down, keep it current, and keep it visible to the agent.
The fourth is cognitive surrender, which happens when a person blindly accepts whatever the loop produces with the reasoning ‘if the AI did it, it’s right’. This raises comprehension debt further, because nobody is trying to understand the output.
The human role therefore comes down to three concrete responsibilities: writing the goal with its stopping condition, writing the intent where the agent can find it, and reading the agent’s output. The speaker concludes that loop engineering works best with a human in the loop, and invites viewers to share whether they are engineering agentic loops in their own work.