Definition
An agent turn is the span of work between one conversation boundary and the next. Depending on the harness, it may contain multiple model invocations, tool calls, tool results, and state changes before a response appears.
You ask an agent to fix one failing test. It works for several minutes and returns three sentences. The conversation makes this look like a clean exchange: one message in, one message out.
That is the interface. It is not the execution.
Open the turn
Tap any field in the record to trace it back to the work.
The agent said “done.” It had a day.
One agent reply can contain many invocations and tool calls
Between your message and the final reply, an agent may ask a model what to do, request a tool action, receive the result, and ask the model what that new evidence means. This loop can repeat many times before the next visible chat message.
The exact loop is harness-dependent. Some systems expose intermediate assistant messages. Some treat the whole loop as one turn. Some add approval steps or run several tools together. The durable mental model is simpler: a visible reply is a rendering of work that may contain many events.
The chat shows the conversation boundary. The turn contains the execution between boundaries.
What is a model invocation?
A model invocation is one request to a model and its response. It includes the context provided for that request: instructions, available tools, relevant conversation history, and any results already returned.
If the model requests a tool, the harness executes that tool outside the model. To react to the result, the harness commonly invokes the model again with the result added to context. A turn with several tool calls can therefore contain several invocations.
This is why “one turn” and “one model request” are not synonyms.
Tool call vs. tool result: two halves of one action
The model does not open a file or run a test directly. It emits a structured request. The harness decides whether and how to execute it, then returns a structured result.
| Tool call | The request: tool name plus arguments, such as Read with a file path. |
|---|---|
| Tool result | The outcome: status, output, timing, and any error returned by the harness. |
| Invocation | The model request that chose the action—or interpreted what came back. |
| Turn | The harness-defined container that connects these events to the conversation. |
Keeping call and result separate matters. A valid request can fail. Two requests can use the same tool with different arguments. One slow result can dominate the time of an otherwise short turn.
How to tell when two tool calls are the same action
Read(backoff.py) and Read(config.py) share a tool name, but they are different actions. Comparing only tool names collapses meaningful differences. Arguments preserve the identity of the request.
The inverse is also useful: two calls with the same normalized arguments may be repeats. An args_hash makes that comparison mechanical. If their result fingerprints also match, the calls returned byte-identical information.
That still does not prove the second call was waste. The file may have changed and needed verification. Structure gives you a boundary to inspect; it does not supply intent.
Why a transcript alone can’t reliably answer questions about an agent turn
A transcript can be searched. You can grep it, read it, run full-text search over it, or hand it to a model or an embedding index. What a transcript cannot do on its own is turn into consistent measurements. The prose narrates what the agent believed happened; it does not carry the structured events the harness actually recorded.
A transcript tells the story. Structured records let you measure it.
So a transcript stays useful, but questions like these become fragile inference problems without structured event data:
- Which actions failed?
- How long did each tool call take?
- Were two calls made with identical arguments?
- Which result belongs to which tool call?
- Which invocation generated a particular action?
- What was the token and cost boundary around an invocation?
Structured session telemetry is a different and necessary class of evidence. It preserves names, arguments, status, duration, identity, and the links between events, so those questions resolve by lookup rather than reconstruction. The agent’s prose and the structured record are both useful; they answer different things.
The mental model: an agent turn is a container for work
When you see a single assistant bubble, picture a small execution trace beneath it:
The boxed loop repeats until the model answers instead of acting. Tap any stage.
The number of loops varies. The distinction does not. An agent turn is not merely text. It is a container for work.
What teams lose when they keep only the reply
If a system retains the visible conversation but never the execution beneath it, whole categories of evidence were never recorded in the first place:
- failed actions and retries disappear
- tool behavior and timing disappear
- the structure that links a result to the call that produced it disappears
That is the argument for capturing the execution itself, beyond the chat transcript. See AI session capture.