Should Users Choose the AI Model — or the Desired Outcome?

There's a real design tension sitting underneath every AI product built on more than one model, and most teams resolve it without ever stating it explicitly: should the interface ask a person to pick which model answers their question, or should it ask what outcome they actually want and handle the model choice invisibly? The two approaches produce genuinely different products, and the field has been quietly working out which one is right — or whether the honest answer is both, depending on who's asking and what they're asking for.

Some of the more serious UX research on this in 2026 has gone as far as calling it a genuine interface paradigm shift, on the scale of the shift from command lines to graphical interfaces decades ago: intent-based outcome specification, where a person describes what they want rather than operating a specific tool to get there. That's a significant claim, and it's worth taking seriously rather than treating it as marketing language, because it reflects something real about how AI interfaces are actually diverging from the traditional software model they inherited.

Why "pick your model" made sense at first

Early multi-model products leaned heavily toward exposing model choice directly, and for good reason at the time. Models genuinely differed enough, and inconsistently enough, that knowing which one you were talking to actually mattered for predicting the kind of answer you'd get. A person who'd learned that one model tended to hedge more carefully, or that another wrote more naturally, or that a third was faster but less rigorous, was making a genuinely informed choice by selecting a specific model for a specific task. Exposing that choice treated the person as capable of making it well, and for anyone who'd built up that kind of working knowledge, hiding the choice would have felt like a step backward, not an improvement.

The cost of this approach is real too, though, and it's the reason the pendulum has started swinging the other way. Asking someone to understand the practical differences between a growing list of models, updated on an irregular schedule by several different labs, is a genuinely high bar — most people neither have the time nor the interest to become amateur model evaluators just to get a quick answer to a routine question. One of the sharper anti-patterns named in current UX research is over-explaining AI mechanics to users who just want an outcome — asking someone to make an informed technical decision before they can get the thing they actually came for is friction, not empowerment, for the large share of requests where the difference between models genuinely doesn't matter much.

Why "just tell me what you want" isn't a complete answer either

The opposite extreme — abstracting model choice away entirely and only ever asking for the desired outcome — solves the friction problem cleanly, but it introduces a different one: trust. If the system is making the model choice invisibly, the person using it has no way to verify that choice was actually a good one, and no way to correct it when it wasn't. That's a reasonable tradeoff for low-stakes, routine requests, where the practical difference between models is small enough not to matter and the convenience of not having to think about it outweighs the loss of control. It's a much less comfortable tradeoff for anything where the stakes are higher — a technical decision, a claim going into a client deliverable, a piece of analysis someone is about to act on — where knowing which model actually answered, and having the ability to override that choice, matters more than the marginal convenience of not having to think about it.

There's a related design anti-pattern worth naming directly here too: building the interface around the model's capabilities rather than the user's actual mental model of the task. A pure outcome-first design that hides everything about how the answer was produced risks becoming exactly that — optimized for architectural simplicity rather than for what a person actually needs to know to trust and act on the result they're getting.

The honest answer is a default plus a visible override

The resolution that's actually emerging from serious 2026 UX practice isn't a binary choice between these two philosophies — it's outcome-first by default, with model choice available and visible for the person who wants or needs it. That pattern shows up consistently in the design guidance: pick a small number of AI surfaces that matter for v1, make any AI-driven decision explainable rather than opaque, and give people a clear way to see and, where it matters, correct what the system decided on their behalf, rather than either overwhelming them with mechanics or hiding those mechanics from them entirely.

Applied to model choice specifically, that principle translates into something concrete: most requests should be handled automatically, with the system making a reasonable default choice about which model is best suited to the task, because most requests genuinely don't need a person to think carefully about model selection. But that default should be visible rather than invisible — a person should be able to see which model actually answered, and should be able to override that choice deliberately for the requests where it matters, rather than being locked into whatever the system decided with no way to check or change it. The failure mode isn't choosing one philosophy over the other. It's committing fully to either extreme — full manual control for every request, or full opacity with no way to verify or override — when most real usage actually needs a blend that shifts depending on the stakes of the specific request.

What this means for how people should actually think about it

For someone using an AI product day to day, the practical takeaway is that the "which should I choose" question is really a question about stakes, not a fixed preference to settle once. For a quick, low-stakes request, defaulting to whatever the system recommends and moving on is the right call — deliberating over model choice for a task where it barely matters is friction without a real payoff. For a request where getting it right actually matters, the ability to see which model is answering, and to deliberately choose or compare rather than trust a single default, becomes genuinely valuable — not because manual control is inherently better, but because the stakes of that specific request justify the extra attention.

Where Kahlo fits into this

This is exactly the balance Kahlo's design is built around, rather than committing to either extreme. The smart router handles the outcome-first default: most prompts get sent automatically to whichever model is actually suited to the task, without requiring anyone to think about model selection before they can get an answer. But that default stays visible rather than opaque — you can see which model responded, branch the conversation to try a different one, or override the router's choice outright when you have a specific reason to want a specific model for a specific job.

For the requests where the stakes genuinely call for more than a single default answer, Compare and Council give you the manual control that matters most in exactly those moments — comparing models directly, or bringing several into a single reconciled answer with disagreement surfaced rather than hidden. That's the practical version of the principle the UX research keeps landing on: most people don't want to operate a model selection tool, they want a good outcome — but the moments where model choice genuinely matters deserve real visibility and real control, not a system that's quietly decided on their behalf with no way to check its work.