Why we're looking at this
When people say an agent “hallucinated,” the cause is often not the model inventing facts — it's a tool call that failed silently or returned malformed data, and the agent continued as if it had succeeded. We treat this as an engineering problem, not a model problem.
What we're seeing
- Explicit, typed error responses from tools (rather than bare exceptions or empty strings) dramatically improve an agent's ability to recover — this is one of the practical benefits of well-designed MCP servers over ad hoc function calls.
- Retrying the exact same call after a failure rarely helps; agents recover better when the harness nudges them to try an alternate tool or ask a clarifying question instead.
- Timeouts need to be tuned per tool, not globally — a simulation run and a database lookup have very different acceptable latencies, and a single global timeout either kills slow-but-valid calls or lets broken ones hang too long.
Open questions we're still chasing
We're testing how much of this recovery logic can be handled generically inside a shared agent harness versus how much needs per-tool recovery logic — this is directly informing how we build agent harness engineering as a repeatable practice rather than bespoke code per client.