> SEFA_EKICI
AI Lab 8 min read

Loop engineering: agents now build their own loop

What it means for an agent to run its own task loop without waiting for approval, the five components that make the loop work, and the checks to put in place before you ship one.

The agent that starts work at eight in the morning

Picture a coding agent. At eight in the morning, with nobody telling it anything, it gets to work. It scans yesterday's failures, writes the fix, and assigns a second agent to check its own work.

Anthropic ran this setup inside its own engineering team over the past months. The share of pull requests receiving a meaningful review comment went from 16 percent to 54 percent, and engineers disputed less than 1 percent of the findings. The part that interests me isn't the percentages: a human no longer stands at every link in the chain.

This arrangement has a name, loop engineering. The idea is simple enough. Once the agent has its task, it doesn't wait for approval at each step. It steers itself and carries the work through.

The classic flow first

What does an agent actually do? It takes the task it was given, picks the tools it can use, plans the steps and produces a result. Familiar so far.

The flow we're used to goes like this: a human starts the agent, hands over the task, the agent works, the agent presents a result. The human reviews it, approves it, maybe hands over a new task. There's a human intervention at every link.

That flow is reassuring, no argument there. What it costs you is speed and autonomy. Loop engineering changes the question at exactly this point: do some jobs really need a human at every step?

Why "loop" is the right word

The power of the word is in this: tasks trigger each other. When one task finishes, the agent decides on the next one itself and starts it.

Observation, reasoning, execution and evaluation come round one after another. The agent sees the result, re-prompts itself, and keeps turning the same circle until it reaches the goal. Manual prompting gets replaced by goal-bound automation.

There's a subtlety that gets missed here. The human doesn't leave entirely. The human starts the loop and sets the general direction. After that, the agent keeps the flow going.

Scope shifts from human to agent

The best frame for this topic is scope drift. The more work you ask agents to do, the more the initiative to start that work moves from the human to the agent.

At first a human defined every task. Then agents began doing a whole task end to end. Loop engineering goes one step further, because the agent decides for itself what the next task is.

This is momentum, not a one-time jump. As the initiative moves to the agent you step back from the basic work, but responsibility moves with it. That's exactly why the section on oversight is at the end of this post.

The five components that hold the loop up

Loop engineering isn't built with a single tool. It comes out of five components working together, and each one covers a different weakness of the loop.

Automation: what actually starts the loop

The idea is familiar. Just as cron jobs on your system run a command at a set hour, here a time or an interval signals the agent to go to work.

A coding agent gets prompted at eight to look at GitHub and check yesterday's CI failures. Another schedule asks it to triage newly opened issues, another sends it hunting for bugs quietly growing in the project.

The trigger doesn't have to be tied to the clock. A short pulse measured in seconds, an event arriving from a webhook, or a goal on its own can all start the loop. What they have in common: none of them waits for a human to say "do this now".

Work tree: every agent on its own island

Think of the worktree in git. The agent gets a separate working directory on its own branch, and the changes it makes don't touch the environment of the other agents.

Why does this matter? We've all seen how a tiny change in a web project affects other components. Now multiply that, because several agents may be running several tasks at the same time. Without isolation, one agent's change breaks another one's runtime.

The real guarantee is this: when the agent breaks something, it breaks a copy and not your main branch. The good news is that most coding agents today already ship with this support.

Skills: the knowledge of the job, within reach

A skill is a file written in markdown. Inside it are the methods for doing a particular job and the boundaries it has to stay within. Think of it as the alternative to pasting a wall of instructions every time: you put the knowledge in a file once, and the agent calls it when it needs it.

The elegant part is how it loads. At startup the agent sees only the name and the short description of each skill, a few dozen tokens. The body of the file waits on disk until that skill is triggered. So you can carry hundreds of skills around without filling your context window.

Plugins and connectors: the door to the outside world

Separating this from skills matters. Skills give knowledge, plugins give access.

A coding agent can reach documents in Notion, payment data in Stripe, or the company database. These connections are usually set up over a standard protocol like MCP, and which systems you open up is a per-project choice.

With loop engineering this component carries more weight. A fully autonomous agent can't get its work done with local files alone. It needs to reach the external systems the job depends on. As access widens, so does the agent's blast radius.

Sub agents: split the work, then have it audited

The main agent breaks the task into pieces, assigns sub agents, and they work and report back. In the context of a loop this structure does two jobs.

The first is speed. When a large task is split up the sub agents work in parallel, and since each one opens with a clean context window, the main loop's memory doesn't fill up.

The second, and to me the more valuable one, is independent review. In Anthropic's own measurements, 84 percent of changes larger than a thousand lines produced findings, at an average of 7.5 issues per change. For changes under fifty lines the rate dropped to 31 percent and the issue count to 0.5. Average review time was around 20 minutes. So as the work gets bigger, the need for an outside pair of eyes grows too, and not at a linear rate.

There is no one correct structure

Let's be clear about this: there's no official body or strict standard defining what exactly makes up loop engineering. It's a field developing in real time and it takes different shapes in different projects.

Here's a good example. Some setups add a memory layer on top of the five components. At the end of each turn the agent writes down what it did, into a markdown file or a task board, and picks up from there on the next turn. The real function of this layer isn't remembering the past. It's stopping the agent from making the same mistake twice.

The structures vary, but the core stays the same: scope keeps growing from human initiative toward agent initiative.

As scope grows, so do the errors nobody caught

This is the most important part of the post. The more work the agent does on its own, the higher the risk of unnoticed errors piling up. As the human moves away from the loop, there are fewer eyes to catch a mistake.

The real danger is errors compounding. A small wrong decision grows unnoticed in the next step, and a few turns later you're holding a result you can't trace back to anything. That's why you build checks and balances together with the loop. Oversight added afterwards doesn't undo the errors that already accumulated.

In practice this comes down to three things:

  • Put a turn ceiling on the loop. Around fifty turns is a reasonable starting value, not a research finding.
  • Tie the exit condition to a hard measure rather than the agent's own judgement. Zero failing tests, for example.
  • Add an independent verification step that checks the whole codebase, not just the code that was produced.

Wrapping up

Loop engineering is the name for task loops where agents steer themselves without human approval. Automation ties the loop to a time or an event, work tree prevents collisions, skills make the knowledge persistent, plugins open the door to external systems, and sub agents both split the work and audit the main agent. If you want, add a memory layer on top and give the loop recall between turns.

But before any of that: don't ship the loop without checks and balances. With them in place, the agent adds power to your workflow. Without them, it becomes a new pile of cleanup work.

Sources

  • #AI
  • #agents
  • #automation
  • #loop engineering
  • #MCP

Related posts