Turn 3: the error is just more text
Lesson 3 of 5 in Anatomy of a Real Agent: One Run, Every Part Named.
The carrier API rejects the mistaken call. Here is the most instructive turn of the run — watch exactly what the failure looks like from the model’s side of the glass.
Nothing in the runtime "handled" this error. No retry logic fired, no exception propagated, no engineer was paged. The error came back in-band — appended to the transcript exactly like a success would have been — and on the next turn the model read it as one more observation and reasoned its way out.
Trace the recovery to its source and you find something worth money: the model retried with different arguments because the error message told it what right looks like. "SS-XXX-XXXX" let the model recognise its own mistake and locate the real tracking id already sitting in context from turn 2. Had the tool returned a bare 500 Internal Error, the model would have had nothing to reason with — and the likely outcomes are retrying the same wrong call, apologising to the customer, or worst of all, inventing a status. Error messages are prompts. When you build tools for agents, you are writing for a reader that will act on every word — design your errors to be recovered from, not just reported.
What if the error had been a bare "500 Internal Server Error"?
The model would have no signal to distinguish my arguments are wrong from the carrier is down. Common outcomes: retrying the identical call (burning budget), switching to an apology without an answer, or fabricating a plausible status. The fix belongs to the tool author: return errors that say what was wrong and what right looks like.
What if the model had retried the same wrong arguments in a loop?
This happens — models sometimes re-emit a failed call verbatim, especially when the error gives no foothold. The 10-call budget is the backstop: the loop costs at most seven more calls before the runtime kills the run and escalates. Loop-detection (same tool + same arguments twice) is a cheap runtime guard many production agents add.
Should the runtime have retried automatically instead?
Runtime-level retries suit transient faults — timeouts, rate limits — where the same call may simply succeed. This failure was semantic: the arguments were wrong, and no amount of re-sending fixes them. Rule of thumb: runtimes retry identical calls for flaky infrastructure; only the model can retry with different arguments, because only it can reinterpret the error.
Could the model have just asked the customer for the tracking number?
It could — and with no order record it should have. But the tracking id was already in context, so asking would export the agent’s confusion to the customer. Good agents exhaust what they already know before spending a human interaction; the reasoning summary shows exactly that instinct.
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.