When a step goes wrong
In a system built from separate parts, failures are not rare events. They are a normal part of how it runs. What a step does when it cannot finish is a design decision, and the two obvious answers, hide it or crash, are both wrong. The wider set of decisions this sits inside is Prompt engineering with Claude.
When a mistake would be costly, the question that matters is what happens when a step goes wrong. In a system built from separate parts, where Claude may be doing several things or handing work to other steps, failures are not rare events but a normal part of how it runs. How you handle them is a design decision, not something to leave to chance.
There are two tempting ways to handle a failure that are both wrong. The first is to swallow it quietly and carry on as though nothing happened, which lets a wrong or empty answer slip into the final result with nobody knowing to question it. The second is to let one failure bring the whole job down, throwing away all the work the other parts did correctly. The better path sits between them. A step should fix small, passing problems itself. Where it genuinely cannot, it should report back what went wrong in enough detail for the system to decide what to do next.
Say it another way
Think of a cook who burns a sauce. Hiding it and sending the plate out anyway means a bad dish reaches the table with no one the wiser. Downing tools and stopping the whole kitchen punishes every other order for one mistake. The right move is to say what went wrong and what is to hand, the sauce is ruined but there is jus ready, so the head chef can choose what to send. A good system handles its own failures the same way.
A linked trap is treating the result as the verdict on whether a step worked. An empty answer can be perfectly valid, the honest result of a question with nothing to find, while a result coming back is no proof it succeeded, since it might be partial or stale from something that broke partway. Whether a step worked has to be reported as its own fact, kept apart from what it returned, so a failure is never read as a confirmed nothing.
The same honesty matters at the end, when the separate results are combined into one answer. A tidy, confident summary can quietly hide that part of the evidence never arrived because a source was unavailable. Marking which parts are well-supported and which are thin keeps the limits of the answer visible, so looks-good is never mistaken for is-good.
Doing this with Claude Code
When you build a step that can fail, a subagent, a tool or a skill, decide its failure path on purpose.
Write the failure path into the prompt. Tell the step that if it cannot finish it should report what it was attempting, anything it managed to get and what to try instead, rather than crashing or going blank.
Keep what broke apart from what it found. An empty result and a failed lookup are different facts. Have the step say which one it is, so a timeout is never taken for a confirmed nothing.
Ask for the gaps to be marked. When results are combined into one answer, have it note which parts are well-supported and which are thin because something was missing, so a neat summary does not hide what never arrived.
Back to Prompt engineering with Claude. The craft around it is Working with Claude.