The Agent Loop

If you remember one thing from this guide, remember this: the core of every coding agent is a small loop, and it is much simpler than you think.

Here is the entire idea, lifted almost verbatim from the open-source Codex codebase (the file is literally called turn.rs):

while needs_follow_up:
    1. Gather the conversation history
    2. Send it to the LLM, along with the list of available tools
    3. Look at the response:
       - If it contains tool calls -> run them, append the results, loop again
       - If it is just text     -> we are done

That is it. There is no separate "planning engine," no mysterious reasoning module. The agentic behavior you see (the way it investigates, tries things, course-corrects) all emerges from running this one loop until the model decides it is finished.

Anthropic describes the same thing with three friendlier words: gather context, take action, verify results, repeated until the task is done. Codex's lead engineer Michael Bolin draws it as a cycle of inference and tool calls. They are all the same loop.

The two outcomes of every model call

Each time the harness calls the model, the model does exactly one of two things:

1. It asks for a tool call: "run ls," "read this file," "apply this patch." The harness runs the tool, captures the output, appends it to the conversation, and calls the model again with the new information.
2. It produces an assistant message: plain text for the user. This signals the end of the turn. Control returns to you.

So the loop spins on outcome 1 and stops on outcome 2. A single user request ("fix the failing tests") might spin through that loop fifty times (run tests, read the error, search for the file, read it, edit it, run tests again) before the model finally says, in plain text, "Fixed it. The bug was a stale session token."

What "output" really means

Here is a subtle point that trips people up, and Bolin calls it out directly. When you think about what a coding agent "outputs," you picture that final text message. But for a software agent, the text is not the deliverable. The deliverable is the changes it made to your machine: the files it edited, the tests it made pass, the commit it created. The assistant message is just the termination signal, a polite "I'm done, your turn."

The practical consequence, which we will use later: you do not need the agent to produce flowery prose. You need it to produce reliable tool calls. Design your instructions to guide good actions, not good paragraphs.

Turn, thread, conversation

A bit of vocabulary that the sources use consistently:

• A turn is one cycle of "user input goes in, agent works, agent comes back with an assistant message." Inside a single turn, the inference-and-tool-call loop may run many times.
• A thread (Codex's word) or conversation is the whole back-and-forth, made of many turns.
• Every new turn includes the entire history of previous turns in the prompt. That detail seems innocent. It is actually the source of the biggest performance problem in the whole field, and Chapter 4 is devoted to it.