An error goes back, the model corrects itself
The model's recovery is scripted. A real model decides it itself, and clear error messages make that more likely.
A tool will fail: bad arguments, unknown records, outages. Catch every failure, turn it into a short tool message the model can read, and let the model correct itself, with a limit on repeats and without leaking internal details.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 6 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Write run_tool(registry, name, args) that returns a JSON string: the result as JSON on success, {"error": "<message>"} for ValueError, and {"error": "the tool failed unexpectedly"} for any other exception.
Write Limiter(max_failures) with a method failed(key) that returns True once the same key has failed max_failures times.
Explain it without notes
Why should tool failures be returned to the model instead of raising an exception out of the loop?
How do you decide what error text the model gets and what stays in the logs?
How do you stop a model from retrying a failing tool call forever?
Expected output
step 1: model asks get_weather {"city":"Punee"}
step 1: tool message {"error":"unknown city: Punee. Known cities: Pune, Mumbai, Delhi"}
step 2: model asks get_weather {"city":"Pune"}
step 2: tool message {"city":"Pune","temp_c":31}
step 3: model answers: It is 31 C in Pune.