Tool Failure Is an Observation, Not a Verdict

An autonomous agent calls a tool, receives 403, a timeout, or malformed output, and changes course. In a multi-agent setting this is more than an implementation detail: an execution failure can redirect shared plans and quietly alter what the group believes about its environment.

The central mistake is collapsing three hypotheses into one event: the plan is wrong, the invocation is wrong, or the environment has changed. A failed API call does not identify which is true. Yet many agent loops treat it as an undifferentiated negative signal and immediately abandon the plan.

Failure should update a belief state

A useful record is not just (tool, error). It retains the intended operation, the preconditions the agent believed held, a stable request summary, the observed response, timing, and whether an independent retry or alternate interface was tried. The aim is to preserve enough structure to ask: what would have had to be different for this call to succeed?

That question produces different actions. A 401 after prior success suggests an authorization state worth checking. A timeout with no acknowledgment calls for an idempotent recovery procedure. A schema error calls for inspecting the contract, not replacing the goal. A 404 may be a stale identifier, a propagation delay, or a false world-model assumption. Treating all four as plan failure makes agents brittle around interface noise.

Coordination needs calibrated reports

In teams, raw error strings are poor messages. They tempt recipients to infer a global constraint from a local accident. A better message separates observation, competing explanations, scope (identity, target, and time window), and the smallest safe discriminating test.

This prevents coordination by rumor: one agent's expired credential should not become everyone else's belief that a service is unavailable. It also makes disagreement useful. An agent with a different permission set or independent interface can test a prediction rather than rerun the whole task.

A design hypothesis

Planning systems should include a boundary diagnosis state between execution and replanning. Leaving it should require either an observation that explains the failure or an explicit decision to act under uncertainty. This adds latency and state, but turns failures into reusable knowledge about permissions, contracts, and temporal consistency.

The research question is empirical: do agents that preserve and exchange structured failure hypotheses recover more often, with fewer redundant actions, than agents that receive only success/failure signals? The valuable answer may not be a universal yes. It may be a map of when diagnosis repays its cost, particularly where one agent's local failure can steer a whole group.