Agentic Loops: What They Are and Why They're Changing the Way We Work with AI

The first (later discarded) version of this article was prepared by a team within an agentic system. I simply asked one of these Loops:

/deep-research ""Research Claude's agentic loops—of which this deep-research skill is an example—and explain them to a non-technical audience in a blog post that you'll write in projects/blog." Use Sonnet for subagents and Haiku for fetching."

A normal skill, some might say. But no, a loop isn't just a longer prompt, but a small system that discovers work, assigns it to agents, verifies the results, saves the state, and decides the next move. And it continues to do so until it reaches a goal.

Boris Cherny, at Anthropic, essentially says that his job now is to design loops, not write individual prompts. And this phrase is now everywhere... So, by popular demand, let's see what it means.

Agentic Loops

There are six important components of these loops.

1. The heartbeat. Something that wakes it up at intervals. Without it, it's a one-time session; with it, it's a system that checks and sorts itself, even if you don't open your computer. It's the difference between "I should look at that thing every morning" and something that looks at it for you. And it keeps going until it reaches a verifiable condition, with a second model deciding if it's truly "done," so the person working doesn't grade themselves.

   
   

2. Separate desks. Each agent has their own copy of the files. This way, they work in parallel without stepping on each other's toes or ruining each other's work.

   
   

3. The house rules. The conventions, the "how things are done here": written once, they remain from one round to the next. Without them, each time the AI restarts as if it were the first day.

   
   

4. Real tools. A loop that only knows how to read can only give you advice. Connect it to real tools (opening a request, updating a tab, writing a message, querying an archive) and it stops commenting: it starts doing.

   
   

5. Those who do and those who check. Those who write are terrible judges of themselves. It's not a flaw in the model, it's structural, and it applies to us too (if you have the patience to read my articles, you'll understand what I'm talking about). So one person does, and another (different instructions, sometimes a better model) checks. It's that second agent who lets you go undisturbed.

   
   

6. The logbook. None of this survives alone at the end of a session. The loop must rely on an external sheet that answers three questions:

   1. what are we working on now,

   2. what we tried last time and how it went,

   3. what awaits a human decision.

      
      

For loops that go on for days, that sheet is often the most important thing they produce. Because it's the only thing that allows us to arrive at a definition of 'done' (meaning "Task completed and correct!") that we also like, as we must apply taste and judgment to our invaluable phase of checking each AI's output. (RIGHT?!)

You need a team

Claude features an example loop, simulating Deep Research, with a team composed of a hundred (one hundred and one) sessions of different agents working together for about forty minutes. A Loop, indeed. One hundred and one sessions, to be clear, are one hundred and one separate work threads, the kind you see to the left of your AI agent like ChatGPT or Claude.

In an environment like Claude Code they are aesthetically uglier but clearer.

The first one broke the query down into five directions. And five agents searched the web in parallel.

Nineteen others opened the sources and extracted the key claims. Then came my favorite part: a group of "skeptics" attempted to debunk each claim, one by one. Out of twenty-five, they rejected thirteen. In the end, only one AI pieced together the surviving pieces, and I, as is my custom, basically rewrote the whole thing because I didn't like the way my AI agent writes. (I try again every now and then.)

Total approximately 1,777 messages and 19.4 million tokens.

I'll tell you in dollars: TWENTY-SEVEN !

For a search!

Do you understand that in some activities the costs are aligning with, and sometimes exceeding, the human costs?

Now, do you have a clearer idea of what "agentic loop" means? No? Next paragraph, then!

From answer to do

In the past, a chatbot would answer a question. If you didn't like the answer, you'd rephrase it and try again. It was useful. But it was fraught with problems, not least hallucinations.

An agentic system does something different: it operates in a cycle, in a loop. It tries a move, sees what happens, adjusts, tries again. It searches, reads, checks, corrects. It doesn't stop at the first answer: it works toward a goal until it reaches it. The difference between the two is the same as asking a colleague, "How do you think it's done?" and saying, "Do it for me, and let me know when it's ready."

The technical part that makes everything possible largely concerns the use of tools . This means that Claude, or the model you're using, alone decides when he needs a tool (a web search, opening a file, performing a calculation) and when he can answer from memory. No one tells him step by step: he's the one who, faced with something he doesn't know, chooses to go and get it. That small gesture is the engine of everything else.

But an engine, by itself, doesn't move anything, not even if it's Claude Mythos or Fable 5. Anyone who works with a machine knows this: power doesn't matter until there's a transmission that connects it to the work. The model is the engine. Everything around it (the tools it can use, the instructions it receives, the cycle that makes it retry when it fails, the barriers that prevent it from doing damage) is the transmission. In English, you could call it the "harness." It's the part you can't see, the part no one talks about, and where much of the engineering work is done. It's also where trust lies: a very powerful engine without a harness will spin in vain.

And here's the most surprising thing: the model, for us users, is the easy part. Just pay, and it's already very good as is. The difficult, and interesting, part is the harnessing, that is, how we connect it to the actual work. When this research began, the intelligence of the individual agents mattered less than how they were harnessed together. So much so that I deliberately used secondary engines like Haiku, which are more lightweight models.

Workflow or agent: who's in charge?

Here Anthropic makes a distinction worth stealing.

A workflow is a recipe. The steps are written beforehand by a person: first this, then that, then the other. AI executes each step, but the path has largely been decided by a human in advance. You always know which steps will be taken and how.

An agent is a chef. You give him the objective and the ingredients, and he improvises: he assesses the situation, decides what to do, tries a new approach, tastes it, and changes it if it doesn't work. He decides the path as he works.

It's not black or white. Between a rigid recipe and an improvised chef, there's a whole spectrum of nuances. The right question isn't "to have an agent or not?", but " how much agency should we give the machine for this task? "

Why trust more, not less

You might think that a hundred AIs combined would be more confusing than a single one that follows things from beginning to end. But the opposite happens, for three simple reasons:

• Division of labor. Those who seek seek, those who control control. No one does everything, so it's unlikely that things will turn out badly.

• Organized skepticism. Every statement, at least in this loop, goes through three independent verifiers , and two dissenting ones are enough to throw it out. It's like having someone double-check the accounts before handing them over.

• Sources in hand. What survives comes with the link it came from. You can go check. No unfounded claims.

There's also a fourth reason, which I'll say quietly: a system like this also tells you what it hasn't been able to confirm, finally . The 'usual models' that talk or think for themselves never alert you to their own doubts. A team that monitors each other does.

Prompt, context, harness... and now loop

I'll take a step back and show you the entire scale, because there's a word that's been making the rounds these past few weeks in every conversation among those who build these systems: loop engineering , the word of the month.

Working with AI has been like climbing steps, one at a time.

• Prompt Engineering. In the beginning, we learned to write each request well: objective, constraints, tone. A command, and the AI executes.

• Context Engineering. Then it was realized that the surrounding environment matters more: stable instructions, memory, the way you write. You prepare it once and the AI works within it every time.

• Harness Engineering. The harness step we were talking about: the tools for action (searching, reading your files, writing an email) plus a second agent that monitors the first.

• Loop Engineering. The final step, the new one: stop writing prompts. Design the system, the loop, which automatically discovers what needs to be done, assigns it, verifies the results, and only calls you when it needs a decision.

Let's go back to Boris Cherny and the one who says bluntly: "I don't write prompts to Claude anymore. I have loops that do it for me. My job is to design the loops." And he's not the only one: Peter Steinberger, creator of OpenClaw, who builds tools for agents by trade, repeats the same thing: your job is to design the loops that give orders to the agents, not to give them by hand one by one.

Put like that, it seems like AI is taking away a piece of your work at every step. It's the opposite: you're not delegating the thinking, you're moving it higher. First, you thought about the sentence, then the context, then the tools, now the entire system.

AI always executes. You're always the one designing (and containing).

So... what's left for us to do?

One fact, before we wrap up. Anthropic has measured, using its own tools, that people give AI less autonomy than it already knows how to handle. They call it "deployment overhang": a margin of capacity that remains unused not because the machine isn't ready, but because we don't yet trust it. In other words, we're the ones holding it back.

And so the right question becomes another: if we are the brake, what is left for us to do? You've seen how a loop works: it discovers, assigns, verifies, remembers. Almost everything you did by hand can now run on its own. Almost. Because the loop doesn't care about one thing, and it's the most important thing: the judgment on what is truly "done." The machine tells you it's finished. Deciding whether it's true, whether that result holds up, whether you'd put your face to it, remains yours. Indeed, it becomes the only work that matters.

There's also a hidden cost: the better the loop, the faster your debt of understanding grows , the gap between what came out and what you actually understood. A system can deliver a twenty-hour job in forty minutes. But if you sign without reading, you've simply automated the next blunder.

This is why being the brake isn't a flaw to be corrected : it's the job. The rule I give to the teams I work with doesn't change step by step: only sign what you understand. The machine goes around, you make the judgment. This article, which I rewrote from scratch because its loop didn't write the way I want it to, is there to prove it.

Massimiliano