The Loop You Supervise
An agent is a model in a loop: it reads, acts, looks at what happened and goes again until it decides it is done. One paragraph of that mechanism explains most of what you will watch an agent do, including most of what it gets wrong. Building the loop is a different book, Agentic AI from Scratch. This page names the parts you supervise: the tool call, the turn, the transcript and the point where it stops.
Supervising does not mean watching every step. It means setting the conditions before a run and checking the evidence after it, and both depend on knowing what happens in between.
The Mechanism in One Paragraph
The harness, the program around the model, sends the model its context: the tool's own instructions, your project instructions file, your message and everything that has happened since. The model replies in one of two ways. Either it writes text for you, or it asks to use a tool: read refunds, search for "refund window", run the test runner. The harness runs that tool, appends the result to the context and calls the model again. This repeats until the model answers without asking for a tool, a limit stops the run, or a permission rule makes the harness wait for your yes.
Vocabulary for the Rest of the Book
A tool call is one request to act: read a file, edit one, run a command. A turn is one reply from the model, which may contain a tool call. A session is the whole conversation until you reset it, and a new session starts without any of it. The transcript is the visible record of every tool call and its result. The agent loop is the cycle above.
A turn is the unit that matters for cost and for drift. Every turn sends the whole context so far, so the fortieth turn of a session carries the thirty-nine before it. A session is the unit that matters for memory: start a new one and the agent begins again with nothing but its instructions, which the next page takes up.
Keep that last term separate from the loop this book teaches in Chapter 2: specify, context, generate, read, test, then commit or discard. The agent loop runs entirely inside one of those stages, "generate". The stages before and after it are yours.
Every Step Leaves a Trace
The transcript shows which files the agent read, which commands it ran and what they printed. When a change surprises you, it tells you whether the agent read booking before editing refunds or never opened it. That is how you learn what the agent knew when it made the change, and the polished summary at the end of the run does not tell you. The summary is written by the same model, after the fact, about its own work.
you On the refund receipt, change the label "Refund" to "Refund issued".
search "Refund" in the source 4 matches in 2 files
read refunds 142 lines
edit refunds 1 line changed
run the test runner, refunds tests 151 passed
agent Done. The receipt label now reads "Refund issued" and all refunds
tests pass.
Read the transcript above for what it does not show. The search found four matches in two files, and the agent read only one of them. Whether the second file was the email template that also prints the label, or something unrelated, the summary does not say. The run of 151 tests is real, and it covers only refunds. None of that makes the change wrong. It tells you exactly what to check before you believe it.
Three things are worth looking for in any transcript. The files read, because a change built without reading a file cannot account for what is in it. The commands run and what they printed, because a test run that printed failures and was followed by "all tests pass" is a summary you can no longer trust. And edits outside the files you expected, because they are the changes you will not think to look for in the diff.
"Done" Is the Model's Judgement
The loop ends when the model stops asking for tools. Nothing in the mechanism checks the work. An agent that never ran the tests can report success in the same confident sentence as one that ran all 900 of Cragmoor's, and the sentence carries no information about which of the two happened. The transcript does.
That is why "done" has to be something a command can check. A task that says "the refunds tests and the full suite pass" gives the agent a stopping point that is evidence, and gives you a line in the transcript to look for. A task that says "make the refund window 12 hours" leaves "done" to the model's sense of when it has written enough.
The difference shows up most when something goes wrong partway through. Suppose the agent changes the refund rule, runs the tests, sees two failures in schedule that have nothing to do with refunds, and concludes they were failing before it started. It may be right. Its summary will say the change is complete either way, and only the transcript, with its test output, lets you decide whether "were failing before" is a fact or a guess. Chapter 5 turns this into how you write a task, and Chapter 8 into how you use tests.
Many Steps per Request
One request can produce dozens of tool calls. Each result is appended to the context, so a long task fills it, and early material starts to lose weight against everything that came after. Each call costs tokens. Each is also a separate point where a permission rule applies, which is why the permission settings in Chapter 3 are written per kind of call rather than per request.
The length of a run says nothing good about its care. A run of 40 tool calls for a one-line change usually means one of two things: the agent was searching for context you could have pointed it to, or it was stuck. A stuck agent does not slow down. It goes round the same steps, editing, running, failing, editing again, and each pass looks like progress in the transcript.
Where the Building Is Taught
The system instructions, the tool definitions, the stop conditions, the sandbox and the evaluation of a thing that acts are the builder's work. Agentic AI from Scratch builds this loop from nothing in its first chapter, then spends thirteen more on the machinery around it. If you want the mechanism, take it from there.
This book treats the agent as finished and you as its supervisor. None of the habits in the chapters ahead needs more of the mechanism than this page: the model, at the provider, asks, the harness acts with the access of the machine it runs on, the results pile up in the context, and the run ends when the model says so.
- "The agent plans the whole task and then executes it." Unless you ask for a plan first, it decides one step at a time from what is in its context now. A file it reads at step 12 can change everything it does after that.
- "When it says the tests pass, they passed." The claim is a generated sentence. The transcript shows whether the command ran and what it printed, and the two disagree often enough that you check the transcript, not the summary.
- "A longer run means more careful work." A long run is more steps, not more care. Forty tool calls for a one-line change usually means it was searching for context you could have named, or going in circles.
- "The model runs the commands." The model only writes requests. The harness on your laptop or in the cloud runs them, with whatever access that environment has, which is why where the agent runs matters as much as what it is asked.
- "Supervising means watching every step." It means setting the conditions before the run, the task, the context and the permissions, and checking the evidence after it, the diff and the tests. Watching is optional; reading the result is not.
- Read the transcript when a change surprises you. It shows what the agent read and ran, which is what the change was built from.
- Define "done" as a command that can pass or fail. The loop's own stopping point is a judgement; a green test run is evidence.
- Stop a run that is reading files unrelated to the task. Everything it reads now is context that every later step works from.
- Take the mechanism from Agentic AI from Scratch if you want it. None of the supervising habits in this book needs more than this page.
Knowledge Check
The agent asks to run the test runner and the command fails with an error. What happens next in the loop?
- The harness ends the run and reports the failure to you at once
- The error output joins the context and the model picks its next step
- The harness retries the same command until it finally succeeds
- A permission rule pauses the run until you approve a fix for it
An agent ends a run with "Done, all tests pass." What does that sentence prove on its own?
- That the harness checked the claim before letting the run end
- That the full suite ran and passed in the agent's environment
- Only that the model stopped asking for tools and wrote a summary
- That the change is correct, as long as the tests themselves exist
A one-line change took the agent 40 tool calls. What does that most likely suggest?
- It was hunting for context you could have named, or going in circles
- It was being thorough, so the change is more likely to be correct
- The step limit was set too high, so it kept going until it hit it
- The harness split the single edit into 40 smaller tool requests
An agent runs on your laptop and asks to run a shell command. Who runs it, and with what access?
- The model runs it, in an isolated space owned by the provider
- The harness runs it on your laptop with your account's access
- The harness runs it, limited to the files you named in the task
- The provider's servers run it, then send the output back to you
Where in the loop does a permission rule take effect?
- When the model writes its reply, stopping it asking for the tool
- At the end of the run, when the harness reviews the full transcript
- Before the harness runs each tool call, once for every call made
- Once per message you send, covering every call that follows it
You got correct