What kind of failure is it
Reporting a failure rather than hiding it is half the job. The other half is saying which kind it was, because “it failed” tells you nothing about what to do next. Different failures want opposite responses, and treating them alike means retrying what can never succeed. The wider set of decisions this sits inside is Prompt engineering with Claude.
Reporting a failure rather than hiding it is half the job. What turns that report into the right next move is saying which kind of failure it was, because “it failed” on its own tells you nothing about what to do. Different failures want opposite responses, and a system that treats them all the same will retry the ones that can never succeed and give up on the ones a moment’s wait would have fixed.
There are roughly four kinds, and each points to a different move. Something briefly broke, a timeout or a passing blip, and trying again is likely to work. The request itself was wrong, malformed in a way that will fail the same until it is corrected, so the fix comes first and the retry after. A rule said no, a refund outside the returns window, where repeating it will never change the answer, so the honest no is explained to the person rather than retried. And something the system is simply not allowed to do, which is handed up to someone who can. The same blank “failed” hides all four. Naming the kind is what picks the response.
The sharpest version of this is a single question carried with the failure: is it even worth trying again? A network blip is worth a second attempt, while a policy no or a bad request will fail the same way every time. Saying so, plainly, stops a system hammering a wall it will never get through, and stops it abandoning the one case a brief wait would have resolved.
And when the answer is a genuine no, a rule rather than a breakage, the considerate move is to carry the reason with it. “Cannot do that” leaves the person stranded. “That order is past the thirty-day return window, but here is what I can offer instead” is a refusal they can act on. A no with its reason attached is a handled moment, not a dead end.
Say it another way
A ticket comes back from the kitchen unfilled, and a good waiter knows there are only a few reasons, each meaning a different move. The oven was briefly jammed, so re-fire the same ticket. The order was written illegibly, so rewrite it and send it again. The dish is off the menu, so go and tell the guest kindly rather than keep asking. The dish is chef’s-table only and not his to serve, so fetch the manager. Same empty ticket, four different right moves. A waiter who only says “it came back” leaves you to guess which.
Doing this with Claude Code
When you build a step that can fail, have it say enough about the failure for the next move to be obvious.
Have the failure name its kind. A passing blip, a bad request, a firm no or something off-limits are different things wanting different responses, so have the step say which it is rather than a flat “failed”.
Say whether it is worth retrying. Mark the passing problems as worth another attempt and the settled ones as not, so the system retries the blips and never hammers a rule that will not move.
Carry the reason on a no. When a rule blocks something, return the why in words a person can hear, so a refusal can be explained rather than landing as a blank wall.
Keep the shape the same every time. Have failures come back in one consistent form, the kind, whether to retry and a plain description, so whatever reads them always knows where to look.
Back to Prompt engineering with Claude. The craft around it is Working with Claude.