You typed one sentence, pressed Enter - and a stream of lines started scrolling in the terminal. It opened a file. Ran a command. Opened the same file again. From the outside it looks aimless: you asked for one simple thing, and something long and opaque is happening instead.
There's nothing aimless about it. The agent runs a repeating loop of three parts, and almost everything you see on screen is that same loop on different passes.
Why an agent does more than a chat assistant
A chat assistant prints an answer, and the rest is on you: copy, paste, save, run. An agent works inside your project on its own - it opens files, edits them, runs commands, looks at the result, and the changes really do land on your disk.
And that leads straight to the point of this article. Because the agent does the work instead of giving advice, one move is never enough. Between your sentence and the finished result there are several steps, and all of them are visible on screen.
What a single step is made of
After your request the agent enters this loop and goes through it as many times as it takes. Each pass consists of three parts.
Gather context. The agent fills in the gaps: opens the files it needs, looks at the project structure, reads the output of the previous command. The part that surprises people most often: it doesn't remember your project by heart; it reads it. Every time it needs a detail, it goes and looks.
Take an action. One specific thing: edit a file or run a command. Not the whole plan at once, just the next step.
Check the result. Look at what actually happened and compare it with what you asked for.
Then the loop branches. Goal reached - the agent stops and waits for your next request. Not reached - it goes back to gathering context and runs the loop once more.
The loop adapts to the request rather than running through a fixed routine. A simple question about code may end at gathering context: the agent reads, answers, changes nothing. Fixing a bug, on the other hand, takes all three parts several times over. And the boundaries between the parts aren't always sharp - the agent uses tools throughout the loop.
That explains everything that looked strange. The agent opened the same file twice - after the edit it had to look at it again. Several minutes passed between the request and the answer - there were four passes, not one. Going back to the start isn't a failure; it's how the loop is supposed to work.
Reasoning and tool calls
Not everything the agent does changes files in the project. The dividing line runs right through the middle of its work, and it's worth being able to see it.
Reasoning - the agent works out what to do next, which file to open, what the cause of the error might be. Zero changes on disk while that happens. However convincing the reasoning sounds, it's still only an intention.
A tool call - this is where something actually happens. Read or write a file, search the project, run a command, look something up in the documentation online. Every such action shows up in the terminal as its own line, and it's those lines that add up to what happened to the project.
The result of the call goes back to the agent and becomes part of what it knows on the next pass. It read a file - now it knows the contents. It ran a test - now it knows whether the test passed.
A command crashed, a file was missing, a test failed - the agent sees that and takes it into account on the next step. An error message in the output doesn't mean everything is broken and it's time to give up. Often it's exactly the information it was missing, and the next pass will be more accurate than the previous one.
The practical takeaway is simple. The lines about tool calls aren't filler noise to scroll past. They're where you can see what's happening to your files right now.
Why the agent asks questions
Partway through, the agent may stop and ask you something. That's a normal part of the loop, not a sign that it failed.
Questions come in two kinds, and it helps to tell them apart:
- it lacks information about the task - what exactly to change, which of two similar files you meant, what counts as finished. The agent ran into an ambiguity and doesn't want to guess;
- it needs permission for an action - the agent is about to do something significant and stops to ask if that's okay. How independent it is depends on your permission mode and settings.
The first kind of question is a good sign. Better to clarify now than to redo the work after three passes in the wrong direction.
You don't have to wait for questions; you can invite them. At the very start, before the first edits, ask it to restate the task in its own words and to ask about anything unclear:
Tell me what you understand the task to be and how you plan to solve it.
Ask questions if that helps you understand the task and the goal better.That way ambiguities surface before the first edit, not when half the work is already done. You can also step in at any point: add context, change direction, or stop the agent and rephrase the task.
Who decides it is done
The word "done" from an agent means exactly one thing: its loop has ended. It performed an action, checked the result against its own criteria and concluded that the goal was reached. The work itself, though, isn't finished.
A change counts as accepted not when the agent made it, but when you have looked at what actually changed and taken responsibility for it. From there it goes one of two ways: accepted - the work is finished; rework - you state what's wrong, and the loop starts over from your new request.
And what you look at isn't the report but the changes themselves: the agent shows which lines it removed and which it added. That's the precise answer to "what changed", and you won't find it in the agent's summary.
An agent can describe what it did so convincingly that there's nothing to argue with: "added error handling to three methods, checked, everything works". It sounds like a fact. But the text of the answer and the contents of the files are two different things, and they don't always match. The only way to know for sure is to look at the list of changes.
How this plays out with Claude Code
Here's what knowing the loop gets you in practice:
- the more precise the request, the fewer passes. The agent keeps going around the loop until the result matches what you asked for, and vague wording costs extra passes;
- the agent picks up your own edits the next time it opens the files: it doesn't remember the project; it reads it. If you changed something by hand, say so;
- the agent's loop ends with the word "done". The work ends with your review, and those are two different moments.
The whole picture looks like this: the agent's loop inside, your review outside.
GO TO FULL VERSION