A settings page is an unfinished decision

Here is the most honest way to read a settings page: it’s a list of decisions the people who built the product couldn’t agree on, frozen into toggles and handed to you. Each one looks like a feature, like you’re being trusted with control. Mostly it’s the opposite. The builder had the data, the usage patterns, and the full context to pick the right value, and chose instead to make it your problem.

For ordinary software this is merely annoying. For agents it’s close to fatal, because the whole promise of an agent is that you delegate the doing. An agent that arrives with forty knobs you must turn before it works has quietly handed the configuration back to you. You wanted to stop doing the task. Now you’re doing the task’s setup.

A default is a decision you made on the user’s behalf

A good default is not laziness. It’s the opposite. It’s the builder saying: I have seen ten thousand of these, I know what the right answer is in the overwhelming majority of cases, and I am willing to pick it so you don’t have to. That takes more work and more spine than shipping a toggle, because a default is a position you can be wrong about and a setting is a position you can hide behind. “We let the user decide” is the safest, weakest thing a product team can say. It sounds like respect. It’s usually just an unmade decision wearing the costume of flexibility.

The user knows this in their bones. Nobody opens a settings page with joy. They open it because the default was wrong and they have to fix it, which means a setting that gets touched a lot is a bug report, and a setting that never gets touched is a default you should have just shipped without the toggle. Either way the existence of the option is an admission. The dream isn’t a powerful configuration screen. The dream is never opening it.

Agents make the stakes plain. Picture two of them. The first asks you, on day one, which model to route to, how aggressive to be on follow-ups, what tone to use, how often to check in, when to escalate, which fields to sync, and a dozen more. It’s “fully configurable.” It’s also useless until you’ve spent an afternoon answering questions you don’t yet have the experience to answer well, because you’ve never run this agent before and have no idea what aggressive means in practice.

The second one just starts working. It picked sensible defaults for all of it, told you the two or three that actually matter for your case, and let the rest ride. It’s correct out of the box for most people because the defaults encode what most people needed. When it’s wrong, you correct it in the moment, in plain language, against a concrete output you can see, which is exactly when you have enough context to decide. That correction becomes the new default, just for you. The settings page got replaced by a conversation that only happens when it has to.

That’s the whole move. Push the decisions back to the moment they’re actually decidable instead of forcing them up front when the user is least equipped. Good defaults handle the common case silently. A correction, stated once against real output, handles the exception and teaches the agent your preference going forward. Nobody had to predict their own needs on a form before they’d done the work even once.

There’s a real objection: some users genuinely need control, and stripping every option is its own arrogance. True. The answer isn’t zero settings, it’s earned ones. A setting should exist only when the right value really does differ between users in a way no default can cover, and even then it should be discoverable when you need it, not a wall you hit before you start. The test is simple and unforgiving: if you can pick a good default, picking one is your job, not the user’s. Shipping the toggle instead is shipping your indecision and calling it a feature. The product that wins isn’t the one with the most options. It’s the one you never had to configure.