Failure attribution should not choose the repair owner

A stronger model might recover from a failure. I would not let that observation decide who has to repair the system.

The paper Model or Harness? An Interaction-Centric Taxonomy of Agentic Failures offers 41 failure modes and an attribution rule: if a more capable model could avoid or recover from a failure under the same conditions, the failure can be treated as model-side. It also distinguishes a wrapper that suppresses an error from a model that receives the error and ignores it.

That is a useful way to organise what happened at the interaction boundary. It is not, by itself, a procurement recommendation or a maintenance assignment. An attribution category answers a different question from “which change will reliably prevent the next occurrence?”

My preference is to keep those questions separate in an incident review. Otherwise an informative label can become an expensive habit of upgrading the model whenever recovery was theoretically possible.

Recovery capacity and initiating fault can coexist

Consider a hypothetical agent calling a service that times out. The wrapper returns an ambiguous empty result. A stronger model may infer that the response is suspicious and try another route. A weaker model may confidently continue as though there were no matching records.

The stronger model's recovery would be useful. It would not make the wrapper's ambiguous response a good interface. A clear, typed error could remove the need for the model to guess what happened.

Now change the example: the wrapper returns a clear retryable error and the agent ignores it. That supplies evidence about the model's behaviour. Even then, a bounded application-level retry might be an appropriate repair if the operation and its side effects permit it.

I am not claiming that every retry belongs outside the model. Some recovery requires interpretation, and an indiscriminate retry can repeat a harmful action. The point is that the most useful intervention depends on the task and failure mechanism, not just the label attached to the last decision.

A taxonomy can help us name those distinctions. Trouble begins when the category replaces the investigation instead of supporting it.

Keep a second column for the repair

I would record the initiating problem, the information available to the agent, the missed recovery opportunity and the proposed repair. Those fields can point to different owners without turning the review into a blame contest.

For the timeout example, compare a clearer wrapper response with a model change against the same relevant cases. If the interface repair works across model versions, that is evidence for a durable application improvement. If better reasoning is still needed, the model change has a clearer justification.

The comparison should include the new failure paths introduced by the repair. A wrapper that retries must distinguish safe repetition from a request that might already have succeeded. A model that recovers more often must still be checked for unsupported assumptions.

The paper's catalogue should also be read as a taxonomy, not a measurement of how frequently each problem occurs in production. Counting categories does not establish the distribution of real incidents.

I want better models and better surrounding systems. Keeping attribution separate from repair makes it possible to improve either without pretending one must absolve the other.

Use a failure label to explain the interaction, then choose the repair by evidence about reliability, cost and the task's actual constraints.