How a coding agent works: the loop, tools and the context window

You don’t need to know how the model is trained to use an agent well. You do need a working mental model of the machine around it, because almost every surprising behavior traces back to one of three parts: the loop, the tools and the context window.

Part 1: the loop

A coding agent repeats the same cycle until it decides the task is done or it runs out of road.

1. 📥ReadYour request plus everything in context
2. ↓→
3. 🤔DecidePick the next action
4. ↓→
5. 🛠️ActCall a tool: read, edit, run
6. ↓→
7. 👀ObserveTool output goes back into context

↺ Repeat until done, stuck, or stopped

The model itself only produces text. The “agent” is the harness that turns some of that text into actions, runs them, and feeds the result back. That’s why a failing test is gold: it’s an observation the agent can react to on the next turn.

Part 2: the tools

Most coding agents come with a similar toolbox, even if the names differ.

Tool family	What it lets the agent do	What it means for you
Read and search	Open files, grep, list directories	It explores; it doesn’t magically know your repo
Edit	Write or patch files	Changes land in your working tree, review them
Run	Execute shell commands, tests, builds	Your test suite becomes its feedback
Fetch or extra tools	Docs, issue trackers, custom scripts	Covered in Module 5

An agent without a way to run things is back to guessing. The single biggest upgrade you can give it is a fast, reliable command that says “this works” or “this doesn’t”.

Part 3: the context window

Everything the agent “knows” in a session lives in one finite buffer: your instructions, the files it opened, every command output. When it fills up, something has to give.

Different agents handle a full window differently: some summarize older turns, some drop them, some just stop. Either way, details from the start of a long session are the first to blur. We go deep on this in Module 2.

Check your mental model

🧠 Loop, tools, context

Score: 0 / 4

1. 1. The agent fixed a bug, then 'forgot' a constraint you gave it 30 turns ago. The most likely cause?

   The model is bad at following instructionsThe constraint got crowded out or summarized away in a long contextThe agent ignored you on purposeA tool call failed silently

   Long sessions dilute early instructions. Restate key constraints, or keep them in a repo instruction file (Module 2).

2. 2. Why does a failing test help an agent more than a vague 'it doesn't work'?

   Tests are written in codeIt's a precise observation the loop can react toAgents only read test filesIt makes the context smaller

   The loop runs on observations. Specific, repeatable feedback lets it converge.

3. 3. Where do the agent's code changes go?

   A separate cloud copy you must downloadNowhere until you approve each oneInto your working tree, like any other editOnly into the chat transcript

   For most local agents, edits land in your files. That's why version control and review matter from day one.

4. 4. What does the model itself produce?

   Text, some of which the harness turns into tool callsDirect changes to your file systemCompiled binariesTest results

   The model outputs text. The harness around it parses actions, runs them and feeds results back.

↺ Try again

Before you move on

✅ Key takeaways

0 / 4 completed

• I can draw the loop: read, decide, act, observe, repeat.
• I know the agent explores my repo through tools; it doesn't arrive knowing it.
• I have one fast command that tells an agent whether a change works.
• I understand why long sessions drift and why early instructions blur first.

↺ Reset