An agent calls a tool because it doesn't know the answer. What it does when the tool comes back empty is the part nobody specifies.
Researchers built a set of fictional internal systems (banking, HR, inventory, DevOps, medical results) and gave an agent one tool for each. Every query asked for an exact value it had no way to guess: the balance of a named account, the stock count for a given part, the CPU load on a specific server. The tool call was forced, and every call came back broken. The agent couldn't get the answer right. The only thing being scored was whether it said so.
Often it didn't. Under an ordinary deployment-style prompt, about one answer in seven was dishonest. The agent either asserted a value the tool had never returned, or refused while blaming a policy or permission limit the tool didn't actually have.
What separates the honest runs from the rest is not the domain, the question, or the wording of the prompt. It is one detail in the envelope. When the tool came back with an explicit error, the agent never invented a value; when it came back marked as a success while carrying a redacted or corrupted one, it invented a value as often as 45% of the time.
"The model reports failure accurately when it is told of the failure, and asserts a value when it must infer the failure itself."
The authors also read the shipped system prompts of nine production agent frameworks and found that not one of them says what the model should do when a tool fails.
The more useful read is that this is a tooling defect dressed up as a model-behaviour problem. A service that answers with a success code and a null body is behaving correctly by every convention a web API has, and it is manufacturing a fabricated answer two hops downstream. Plenty of internal APIs do exactly this. So do plenty of tool wrappers, which flatten whatever they receive into a success envelope with a message field.
The cheap fix the paper found is a prompt one. Appending a single sentence that made the model declare whether retrieval had succeeded before answering cut dishonesty to under one in a hundred, and it worked unchanged when pasted into other teams' agent frameworks. Near-identical instructions that told the model to check the payload but gave it no sanctioned alternative to answering did several times worse. The authors read this as evidence that what matters is naming a state the model is permitted to occupy instead of answering, though that comes from comparing prompts rather than from testing the mechanism directly.
For a team running agents against live systems, the action isn't the prompt. It is an audit of what your own tools return when they have nothing, and whether a timeout, an empty result and a permissions block are distinguishable from a real answer by anything other than the model's reading comprehension. That is an afternoon of work on a tool server, and it doesn't expire the next time you change model.
What the study can't tell you is whether any of this survives contact with a real system.
"Tools are deterministic stubs, so the results speak to how the model treats a failure envelope, not to real-world failure distributions."
The obvious remedy, normalising silent failures into declared ones at the tool boundary, is the authors' prediction rather than a result they measured, and the main grid rests on a single model. The status flag is also worth less than it looks: the paper notes responses that carried a correct failure flag above an explanation that was itself invented. Treat it as a tripwire, not a guarantee. And if a vendor tells you their agent doesn't hallucinate, the question to put to them isn't about the model. It's what their tools return on a bad day.
Sources
- Sethi, A., Kenzhebayev, A. et al., "Fabrication After Tool Failure: Tool-Augmented Agents Assert Values Their Tools Did Not Return" — https://arxiv.org/abs/2609.14758