In the last lesson you learned the layers: you brief, the agent operates, the model reasons, files change, the runtime runs, deployment publishes. Now we zoom into the layer doing most of the visible work — the coding agent.

By the end of this lesson, you can describe the agent loop in your own words, explain why the same model behaves differently in different tools, and turn a vague chat request into a brief an agent can actually execute.

From CLI passenger to operator's supervisor

In Class 06 you sat in the driver's seat of the CLI: you typed commands, read output, approved edits. The coding agent is the operator working inside that same CLI or editor once you hand it a task.

The model is the brain. The agent is the hands, eyes, and short-term memory wrapped around that brain. It decides what to look at, what to try, what the result means, and whether to continue or stop.

Without the agent, a model can only talk. With the agent, its words become file edits, terminal commands, test runs, and verified results.

The agent loop

Every coding agent — Codex, Claude Code, Cursor, OpenCode — runs some version of this loop:

1. Read the task and context
2. Inspect files
3. Choose an action
4. Run a command or edit a file
5. Read the output
6. Revise, verify, or stop

Task brief + project contextRead + inspect filesModel: reason + propose actionAgent executes: edit file or run commandRead tool output, tests, errorsStop + report to human

Walk it slowly, because each step is a place things can go right or wrong:

1. Read the task and context. The agent loads your brief plus whatever context files, instructions, and conversation history it can see. Thin context here means guessing everywhere else. 2. Inspect files. Before writing anything, a good agent reads: directory structure, the files you named, configs, related code. An agent that skips this step writes confident fiction. 3. Choose an action. The agent sends what it has seen to the model, which proposes the next move: read another file, edit a component, run a test. One move at a time, not the whole project at once. 4. Run a command or edit a file. The agent — not the model directly — performs the action through its tools: file writes, shell commands, search, test runners. 5. Read the output. The result comes back: a diff, a passing test, an error trace, a changed page. This is the agent's reality check against the model's proposal. 6. Revise, verify, or stop. If the output shows progress, it continues. If the acceptance check passes, it stops and reports. If it is stuck, a good agent says so instead of churning.

The loop is why agent work costs more than chat: each turn sends files, instructions, and prior output back to the model. Ten loops means ten metered requests, not one.

Why the same model acts differently in different tools

This confuses beginners constantly: "I used the same model in ChatGPT and in Cursor and got completely different results. Which one is right?"

Both. The model is only one ingredient. What changes is the harness — everything the agent wraps around the model:

So the same underlying model can be a helpful pair-programmer in one harness and a confident guesser in another. When results differ, compare the harness, the tools, the permissions, and the context — not just the model name.

A chat request is not an agent brief

Compare these two:

Vague chat request:

This gives the agent no files to read, no definition of broken, no stop point, and no way to prove success. The agent will explore widely, change things hopefully, burn tokens, and possibly break working code while "fixing" the wrong thing.

Bounded agent brief:

>

The second brief works because it names the files, narrows the task, sets a boundary, demands evidence, and defines the stop. Small briefs produce checkable evidence. Big briefs produce long loops and hope.

A useful rule: if you cannot say how you will verify the answer, the brief is not ready.

Practical exercise: rewrite a vague request

Take one vague request you have actually made (or use this one): *"Make my site faster and fix the styling issues."*

Rewrite it as an agent brief with these five parts:

1. Files to read: name 1–3 specific files or folders. 2. Concrete task: one observable problem, quoted exactly ("homepage hero overflows on mobile at 375px"). 3. Boundaries: what not to touch ("Do not change the database schema. Do not deploy."). 4. Stop point: when to stop ("Stop after one fix and report changed files."). 5. Proof of success: the evidence you expect ("Before/after screenshot description + npm run build output").

Finish line: a brief of under 150 words containing all five parts, written so a stranger could execute it without asking a clarifying question.

Verify it: read your brief back and ask: could the agent prove it succeeded without my help? If the answer depends on your private judgment ("make it look nicer"), rewrite the proof until it is observable.

Common failure mode: writing a bounded task that is secretly three tasks ("fix checkout, redesign pricing, and update the docs"). Split it. One task per run keeps the loop short and the evidence clean.

Check your understanding

1. What are the six steps of the agent loop, and where does the model sit inside it? 2. Why can the same model give different results in ChatGPT, Codex, Claude Code, Cursor, and OpenCode? 3. What five parts turn a vague chat request into an executable agent brief? 4. Why does agent work typically use more tokens than a single chat answer?

Next, we follow one request all the way from your keyboard to a live product — and learn to find exactly where it breaks.