How it works: a closer walk

Let us trace one real turn, the kind Bolin describes in the Codex write-up.

1. You type: "Add an architecture diagram to the README."
2. The harness builds a prompt (Chapter 3 covers exactly what goes in it) and calls the model.
3. The model thinks, then asks for a tool call: shell with command cat README.md. It does not run anything; it asks.
4. The harness runs cat README.md, captures the output, and appends two things to the history: the tool call and its result, linked by a shared call_id so the model knows which result belongs to which call.
5. The harness calls the model again, now with the README contents included.
6. The model asks for another tool call: an edit that inserts the diagram.
7. The harness applies the edit, appends the result, calls again.
8. This time the model returns plain text: "I added a diagram explaining the client/server architecture." Turn over.

Notice that step 4's appended history is what makes step 5 smarter than step 2. Each tool result feeds back in. That feedback is the whole point; it is why the loop can course-correct instead of blindly executing a fixed plan.