Bad Agent or Bad System

August 1, 2026 6 min read

Never attribute to malice what is adequately explained by ignorance or error.

The QA Review Everyone Has Sat Through

The weekly ticket review. The dashboard is up. A ticket scored 1/5 on technical accuracy. The agent recommended a workaround that didn’t fix the problem, and the customer reopened the ticket twice.

The manager looks at the name on the ticket and says: “We need to talk to Sarah about this.”

Wait. Do we?

The instinct is reflexive: a bad ticket means a bad agent. But most of the time, that conclusion is wrong. Not because the agent is innocent, but because the question is aimed at the wrong target.

Hanlon’s Razor points it somewhere useful.

Why It Matters

Blame-based QA doesn’t fix quality. It does three things instead:

It teaches agents to hide mistakes. When a score feels like a verdict on your character, you stop surfacing problems and start covering them.
It games the rubric. The moment a QA score becomes a target, agents optimize the score, not the outcome — the exact Goodhart trap I wrote about in Why Your Support Metrics Are Lying to You.
It misses the actual cause. If three different agents make the same mistake this month, you have a system problem wearing an individual’s name. Blaming each agent one by one means never fixing the root cause.

Hanlon’s Razor gives you a better starting point: before you blame the person, check whether the system could have produced this.

The Core Concept

Hanlon’s Razor says: never attribute to malice that which is adequately explained by ignorance or error. Popularized in Murphy’s Law Book Two (1980), it’s the human-behavior counterpart to Occam’s Razor: where Occam cuts unnecessary complexity in explanations, Hanlon cuts unnecessary blame in judgments.

It’s not naive. It doesn’t say people never fail deliberately. It says intent is the last explanation you should reach for, not the first. The cost of a wrong malice verdict is a demotivated agent and a root cause that stays buried.

The Three-Gap Diagnosis

When a ticket scores low, don’t ask “who’s the bad agent?” Ask: which gap produced this?

Gap	The question	The fix
Skill gap	Did the agent know how?	Training, coaching, shadowing
Process gap	Could they have done it right even if they knew?	KB fix, workflow redesign, checklist
Tooling gap	Did the environment make it impossible?	System change, automation, permissions

Malice is the fourth, empty quadrant. If you find yourself concluding an agent deliberately wrote a bad ticket, you need extraordinary evidence — and you should still check gaps one through three first. Pattern usually wins over personality.

The Same Ticket, Three Different Fixes

A ticket gets flagged: agent gave a wrong resolution path, customer reopened.

Skill gap — Sarah never saw the KB article on this error because it was added last week and she wasn’t trained on it. Fix: add it to onboarding, assign a coaching session.
Process gap — The article exists but it’s buried under four outdated versions with the same title, so nobody can find it. Fix: consolidate the KB, add a routing rule.
Tooling gap — KB search is broken in the helpdesk UI and returns no results for known-error queries. Fix: ticket to engineering, escalate.

Same ticket. Same score. Three completely different fixes — and only one of them involves talking to the agent.

The diagnosis changes the conversation from “what’s wrong with Sarah?” to “what’s wrong with the environment that made this easy to get wrong?” That conversation improves quality.

The Multi-Agent Trap: Who Do You Blame?

Multi-agent tickets make this harder. Most tickets in a global support environment aren’t handled by one agent — they’re triaged, researched, handed off, and closed by three or four people.

If your QA program scores only the closing agent, you’re applying Hanlon’s Razor to the wrong person. The resolver who did the core diagnosis gets no credit; the closer gets blamed for a resolution quality they never controlled.

Before you score anyone on a multi-agent ticket, run the attribution question:

Who resolved? — the agent who diagnosed root cause and delivered the solution
Who collaborated? — input, research, partial handling
Who closed? — communicated the resolution, ticket hygiene, CSAT follow-up

Score the resolver on technical accuracy. Score the closer on closure quality. Score the handoff on documentation. If the handoff notes are missing, that’s not a resolver problem or a closer problem — that’s a process gap in how your team hands off tickets.

This is where the gap diagnosis proves itself: the low score usually sits in the seams between agents, not inside any single one of them.

Best Practices

Ask the one question that matters. Before every low score: “What would make this ticket easy to write correctly?” If you can’t answer with a system change, you haven’t diagnosed yet.
Pair the score with SBI feedback. SBI (Situation-Behavior-Impact) feedback: “Your ticket scored 2/5 on documentation because the resolution steps weren’t recorded” is data. “You’re sloppy” is a verdict.
Track gap patterns, not just scores. After a month of reviews, tally: how many fails were skill vs. process vs. tooling? If 60% are process gaps, your coaching program is aimed at the wrong layer.
In multi-agent tickets, attribute before you score. Tag the resolver, collaborator, and closer — score each on what they actually owned.

Common Mistakes

Hanlon’s as an excuse. “It’s always the system” is the same laziness as “it’s always the agent.” The razor is a starting point for diagnosis, not a blanket pardon.
Applying it to others, not yourself. Your QA review process can have gaps too — misweighted rubrics, sampled tickets that miss the pattern. Diagnose your own process with the same three gaps.
Skipping the pattern check. A one-off mistake is likely skill or circumstance. Five agents making the same mistake is a structure problem. The distinction changes the fix.
Only checking gaps when the score is low. Praise is diagnosis too — when an agent nails a hard ticket, ask which structures made that easy, and keep them.

Key Takeaways

A bad ticket is a symptom. The cause lives in one of three places: skill, process, or tooling.
Blame is a cost, not a diagnosis. It demotivates and buries the real root cause.
In multi-agent tickets, attribute the score to the right role before you judge anyone.
Track gaps, not just scores — the pattern tells you where to intervene.
Ask “what would make this ticket easy to write correctly?” before you ever say someone’s name.