Turns 4–6: recovery, resolution, stop

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

Run trace — turn 4 of 6

Tool result (carrier_track):

{ "tracking_id": "SS-99Z-4410", "status": "exception",
  "detail": "Package damaged in sorting facility 2026-09-02. Declared lost 2026-09-04.",
  "last_scan": "PORTLAND OR DISTRIBUTION CENTER" }

Model (reasoning summary): Carrier confirms loss — the policy’s refund condition is met. Order total $89.50 ≤ $100, so no human approval needed. Refund, then close the ticket. → issue_refund

Model (tool call):

{ "tool": "issue_refund",
  "arguments": { "order_id": "A-7734", "amount": 89.50, "reason": "carrier_confirmed_loss" } }

Runtime: schema valid · gated tool → checking: amount 89.50 ≤ 100.00 ✓ · executing… (1,762 ms)

Turn 4 is the run’s moment of real consequence, and it shows the same policy being checked twice, by two different kinds of machine. The model checked it in its reasoning: carrier confirms loss, $89.50 is under the threshold. That check is probabilistic — it will be right nearly always. Then the runtime checked amount ≤ 100 in plain code, and that check is right always. The model’s check makes the agent behave well; the runtime’s check makes the system safe when it doesn’t. Neither replaces the other — this is defense in depth, and you met the principle back in lesson one.

Notice, too, what the gate does not evaluate: the model’s reasons. A gate that trusted stated justifications would be a gate an injected instruction could talk its way through. The gate reads arguments, not arguments-for.

Run trace — turns 5–6 of 6

Turn 5 — tool result (issue_refund):

{ "refund_id": "R-2201", "status": "processed", "amount": 89.50, "eta_business_days": "3-5" }

Model: refund done; policy says close the ticket before replying. → close_ticket

{ "tool": "close_ticket", "arguments": { "order_id": "A-7734", "resolution": "refund_issued_carrier_loss" } }

Turn 6 — tool result (close_ticket): { "status": "closed" }

Model (final message): Bad news and good news. SwiftShip confirmed your boots were damaged in transit and declared the package lost — I’m sorry, that’s a rough break before a trip. I’ve refunded the full $89.50 to your original payment method; it should appear within 3–5 business days. If you’d like to reorder with expedited shipping so they arrive before Friday, I can help right away.

Runtime: response contains no tool call → run complete · 5 tool calls used · 41.8 s elapsed · transcript archived

And that is a stop. Nothing announced it: the model simply produced a message containing no tool call, and the runtime recognised that as the natural stopping condition. Every run ends in one of three ways — the model decides it is done (this run), a budget runs out (the 10-call cap, the clock), or the runtime halts it (a failed gate, a kill switch, an unrecoverable error). Designing an agent means making sure the first kind is common, and the other two are possible.

One more detail rewards attention: the final message. It resolves the issue, states the number the tools reported (not an invented one), respects the one-apology rule, and turns the customer’s Friday deadline — mentioned once, five turns ago — into a useful offer. Held context, not magic.

Be the runtime: gate this tool call?

Interactive decision tree — outcomes:

Execute, log, move on
Reads carry privacy risk but no side effects — gating every lookup_order would add friction with no safety return. Log it and let it run.
Execute with an audit trail
Reversible writes like close_ticket usually run ungated but fully logged — if the model closes a ticket prematurely, the fix is a reopen, not an incident.
Auto-approve — this is turn 4
The code check passed, so the refund executes without a human. The threshold is the product decision; enforcing it in the runtime is the engineering decision. Both were made before the run started.
Hold for human approval
Above the threshold, the runtime parks the call and a human approves or rejects — human-in-the-loop applied exactly where blast radius justifies the latency.
You just built a prompt-deep control
The model’s policy reasoning is probably right — and "probably" is not a control. On the run where the model misreads the amount, or an injected instruction supplies the reasoning, nothing stands between the text and the money. Gates read arguments, not the model’s stated justification.

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