A tool call failed and the agent reported a confident answer anyway, how do you stop that?

It is primarily a tool design problem, and the reason is worth internalising: a model does not experience an error, it reads one.

When your tool returns an error object, that is just more text arriving in the context. There is no exception, no stack unwinding, nothing that stops execution. The model reads it, weighs it against everything else it has, and decides what to do next - and a model that has been asked to produce an answer is heavily inclined to produce one.

So the error has to be unambiguous enough that continuing is clearly wrong, which means:

Make failures loud in the text itself. Not a status field buried in a JSON blob. Something that reads as a failure: the word failed, what failed, and explicitly that the result is not available.

Say what to do. Errors that state the next action get acted on. Something like: this call failed, do not use a value for this field, tell the user the data could not be retrieved.

Never return a shape that looks like success. An error object with the same fields as a success response, with nulls or zeros in them, is an invitation to use them. This is the single most common cause of what you saw.

Distinguish empty from failed. No results found and could not check are completely different, and tools routinely return the same thing for both.

Adding the parts that are prompting and orchestration, since tool design alone will not get you all the way.

In the system prompt, state the rule explicitly. Something to the effect that if a tool fails, it must be reported and no value may be invented or estimated in its place. It is not a guarantee and it measurably helps, particularly combined with clear error text.

Do not let the agent be the last word on whether it succeeded. If a result is supposed to come from a specific tool, check in your own code that the tool actually returned successfully before you accept the run. That is a five line check and it converts a silent wrong answer into a visible failed run.

Consider failing the run outright for tools where a missing value makes the whole answer meaningless. Not everything should be recoverable, an authentication failure usually means stop, not improvise.

Retry the retryable ones in your code, not by asking the model to try again. An auth error should be surfaced; a transient network error should be retried once before the model ever sees it. Letting the model decide about retries wastes tokens and produces inconsistent behaviour.

The general principle: the model orchestrates, your code enforces. Anything you actually require should be checked outside the model.

And the checking-afterwards part, because you will not eliminate this entirely and you found it by luck this time.

Log every tool call with its outcome, and keep them alongside the final output. You did have this, which is why you caught it: make it something you can query rather than something you happen to look at.

Alert on the combination. A run that contains a failed tool call and also produced a confident final answer is exactly the pattern to flag. That is a query you can write once and it catches this class permanently.

Make the agent cite. If every figure in the output has to name the tool call it came from, an invented number has nowhere to hide - either it has no citation, or it cites a call that failed, and both are detectable automatically.

Spot check runs regularly, particularly after any prompt or model change. This behaviour varies between models and between versions of the same model, so a setup that was reliable can become less so without you touching it.

One uncomfortable thing worth accepting: this failure mode is not fully solvable at the model layer. Build so that a wrong answer is caught by something other than a human noticing, because the whole problem is that it does not look wrong.