Command Palette

Search for a command to run...

Hectal
Back to the lesson: Topic 7.5 — Feeding Errors Back
LLM Engineering · Example 2 of 2

Unexpected failures stay private, repeats are limited

The 'server only' line stands for your log system. The model never sees it.

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.

01

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.

02

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

01

Why should tool failures be returned to the model instead of raising an exception out of the loop?

02

How do you decide what error text the model gets and what stays in the logs?

03

How do you stop a model from retrying a failing tool call forever?

Unexpected failures stay private, repeats are limited
Sign in to run this example in your browser.

Expected output

step 1: lookup_order {"order_id":"A17"}
  log (server only): connection to db.internal:5432 refused
  tool message: {"error":"the tool failed unexpectedly"}
step 2: lookup_order {"order_id":"A17"}
  log (server only): connection to db.internal:5432 refused
  tool message: {"error":"the tool failed unexpectedly"}
  the same call failed 2 times: giving up
final: Sorry, I could not look up that order.