The final symptom is often the least useful name for an agent failure. “Bad answer” does not tell you whether the skill failed to activate, chose the wrong path, ignored evidence, or stopped too early.
A failure taxonomy should point back to a decision the team can change. The categories below are a review vocabulary, not a claim about how often each failure occurs.
Label the decision
Start at the first consequential divergence in the trace. Later mistakes may be downstream effects. If the agent opened the wrong package and then edited the wrong adapter, the useful label is scope selection, not code quality.
Record one primary class and optional contributing classes. This preserves a countable signal without pretending a multi-step failure had one cause.
Activation failures
Missed activation means the skill should have applied but did not shape the run. Unnecessary activation means it entered a nearby task and added work or constraints that did not belong.
Activation failures usually call for a clearer trigger, stronger negative boundary, or better runtime discovery. They are rarely fixed by adding more procedure to the body of the skill.
Planning and execution failures
| Class | First visible evidence |
|---|---|
| Scope selection | The agent chooses the wrong subsystem, artifact, or time range. |
| Sequence | It acts before gathering a prerequisite or verifying a constraint. |
| Tool choice | It selects an incapable, costly, or disallowed tool. |
| Argument construction | The tool is right, but its query or target changes the task. |
| Evidence use | The result is present, but the agent ignores or misinterprets it. |
The first two classes are planning failures. The next three happen at the tool boundary. Keeping that distinction helps decide whether to change the skill’s mental model, its procedure, or the tool contract.
Verification failures
An agent may complete the edit but verify the wrong property. Running a formatter does not establish behavior. Running a broad test suite can still miss the contract the skill was meant to protect.
Label missing verification, irrelevant verification, and misread verification separately. Each leaves different evidence and suggests a different repair.
Interaction failures
Some failures concern the relationship with the user: silently expanding scope, requesting unnecessary authority, failing to surface uncertainty, or presenting an irreversible action as routine.
These behaviors can coexist with a technically correct artifact. They still reduce trust and should remain visible beside outcome quality.
Use the taxonomy to change work
Review the distribution only after individual labels are defensible. Look for classes that repeat across tasks and inspect the traces before changing the skill.
The taxonomy earns its keep when it changes a decision: narrow a trigger, reorder a procedure, strengthen a tool boundary, add a verification step, or retire an instruction that creates more variance than value.