The Agent Detective Tool Is Broken. Here’s What It’s Really Telling You.

You’ve spent three hours debugging an agent workflow. Logs are a mess. The LLM spat out something that looked right but wasn’t. You’re asking the same question every developer asks: which part broke?

Enter Agent Detective — a shiny new open-source tool that promises to answer exactly that. “Which of the agents broke in my system?” Finally, a debugger for the black box of LLM pipelines. You install it, run it, and… it tells you something broke. But what does that even mean?

The top comment on the Hacker News post cuts straight to the bone:

“How do you define quality broke? For me it broke when nothing broke. Score from LLM moved, >=4 filter after it meant something else. Gating on exit code would have passed the whole time.”

That comment isn’t just a bug report. It’s the thesis of this entire article.

Here’s the uncomfortable truth: The tool’s core assumption — that ‘broke’ is a well-defined state — is itself broken. Quality failures in agent systems are subjective, context-dependent, and often invisible to automated checks. An exit code says “pass” while your users are screaming. A score threshold says “fail” while the behavior is actually correct. The tool doesn’t know. It can’t know.

So what do we do? Throw the tool away? No. That would be the easy answer. The hard answer is more interesting — and more useful.

The real value of Agent Detective isn’t in detecting breaks. It’s in forcing you to define what ‘good’ looks like in the first place.

When you sit down to use this tool, you have to answer: What would a successful agent output look like? What’s the boundary between acceptable and broken? How do you measure quality in a non-deterministic system? That conversation — the one you have with your team, your stakeholders, yourself — is where the actual debugging happens. The tool is just the excuse.

I’ve seen this firsthand. A team running a customer support agent insisted the tool was “broken” because it flagged a perfectly good response. But the flagged response contained a subtle hallucination — a wrong date in a confirmation email. The tool didn’t know the date was wrong. It just saw a score that drifted. But the team had to look at the flagged case, discuss it, and finally agree on what ‘correct’ actually meant for that scenario. That agreement was worth more than any automated detection.

So here’s the golden quote you should screenshot and send to your team:

“The problem isn’t that the agent broke. The problem is that you couldn’t agree on what ‘working’ looks like.”

Most developers miss this. They treat agent evaluation like unit testing — a binary pass/fail. But agents are probabilistic, context-rich, and the definition of ‘broken’ changes with every deployment. A tool that claims to automate that definition is selling you a lie. But a tool that forces you to define it yourself? That’s a gift.

Let me be clear: I’m not saying Agent Detective is useless. I’m saying its actual usefulness is the opposite of what its marketing promises. It’s not a detective that finds the culprit. It’s a mirror that shows you how little you actually understand your own system.

And that’s terrifying. And liberating.

Because once you accept that there is no universal ‘broke’, you stop looking for a magic tool and start investing in the hard work of defining quality, case by case, context by context. You build better tests. You write better prompts. You have better conversations.

The twist? The best bug detector isn’t a tool. It’s a conversation.

So go ahead, install Agent Detective. Run it. But when it tells you something broke, don’t ask “what’s wrong with the agent?” Ask “what’s wrong with our definition of good?” That question will lead you to the real bugs — the ones in your system’s design, not its execution.

And that’s the kind of detective work that actually matters.