Turns 1–2: routing and the first tool call

Lesson 2 of 5 in Anatomy of a Real Agent: One Run, Every Part Named.

The customer arrives. Watch two things as you read: where each piece of text comes from (customer, model, tool, runtime), and what the model actually emits — because it is never an action. It is always text describing an action, which the runtime then performs. That gap is where agents are engineered.

Run trace — turn 1 of 6

Customer: my order never arrived?? order A-7734, it was supposed to be here last tuesday. i leave for a trip friday

Model (reasoning summary): Delivery issue with an order id supplied. Before promising anything I need the order record: items, ship date, carrier, tracking id. → lookup_order

Model (tool call):

{ "tool": "lookup_order", "arguments": { "order_id": "A-7734" } }

Runtime: schema valid · lookup_order is read-only, no gate · executing… (218 ms)

Turn 1 contains the quietest important act in the run: routing. Nobody built an intent classifier. The model read the message and its choice of which tool to reach for first — lookup_order, not issue_refund, not escalate_to_human — is the routing decision, implicit in function calling. Note also what the model did not do: it did not apologise and promise a refund it could not verify. The system prompt’s "never invent order details" is already earning its place.

And look at the runtime’s line. The model produced a JSON blob. The runtime validated it against the tool’s schema, checked whether a gate applies, executed the API call, and timed it. The model "calling a tool" is a convenient fiction — the model wrote a request; the runtime did the calling.

Run trace — turn 2 of 6

Tool result (lookup_order):

{ "order_id": "A-7734", "items": [{ "name": "Ridgeline trail boots", "price": 89.50 }],
  "shipped": "2026-08-28", "carrier": "SwiftShip", "tracking_id": "SS-99Z-4410",
  "status": "in_transit", "delivery_estimate": "2026-09-01" }

Model (reasoning summary): Shipped Aug 28, estimated Sep 1, still in_transit on Sep 9 — 8 days late. Check the carrier’s side before deciding anything. → carrier_track

Model (tool call):

{ "tool": "carrier_track", "arguments": { "tracking_id": "A-7734" } }

Runtime: schema valid · read-only, no gate · executing… (1,204 ms)

Before reading on: the model just made a mistake. carrier_track wants a tracking id (SS-99Z-4410, sitting right there in the order record), and the model passed the order id instead. Two plausible-looking identifiers in context, and it grabbed the wrong one. The runtime did not catch it — "A-7734" is a perfectly valid string, so the schema check passed. Schema validation confirms shape, never meaning.

This is the texture of real agent failures: not dramatic hallucinations, but small, boring confusions between adjacent fields. Hold that thought for turn 3 — and notice meanwhile how the transcript works. The model is stateless between turns: each turn, the runtime re-sends everything so far — system prompt, customer message, its own tool calls, every result — inside the context window. The transcript is the agent’s working memory, and it only ever grows.

One turn, mechanically

Runtime assembles context
System prompt + tool schemas + the full transcript so far, packed into the context window.
Model generates
One forward pass. Output is text: either a tool call (JSON) or a final message.
Tool call or final text?
Runtime validates + gates
Schema check, approval gate if the tool is dangerous, budget check.
Runtime executes tool
The actual API call happens here — outside the model.
Result appended to transcript
Success or error, the result becomes the next turn’s observation.
Run ends — reply sent

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.