Steer: settling the brief before the model generates
Surface the assumptions. Name the ambiguity. Decide, then generate.
A blank box invites a loose request, and a loose request invites a confident guess. The model fills the gaps you didn't specify (audience, goal, tone) silently, then hands back fluent output that's wrong in ways you notice only after you've shipped it. Steer moves the decision earlier. It parses the request into a visible brief, shows the assumptions as editable chips, flags the forks the model shouldn't resolve on its own, and lets the person steer before a word is written.
Live app: Steer, the intent composer.
The problem: confident output built on assumptions you never saw
The failure isn't a typo or a refusal. It's fluent, plausible output built on assumptions you never saw and never got to change.
Generative tools optimise for a frictionless first draft, so they treat every gap in your request as theirs to fill. Most of the time the guess is invisible, until the draft is aimed at the wrong audience, pushing the wrong goal, in the wrong voice. Correction then happens at the most expensive moment: after generation, by re-prompting, once you've already anchored on what you read. The cheap moment is before, when intent is still a decision rather than a guess.
Inferred assumptionsguesses, each one click to override
Genuine forkthe model will not resolve this for you
Reader
-
You type a loose request
“Write up the Q3 solar cost story for the board.” Natural, fast, and silent on reader, purpose, format, and what to do about the forecast.
-
The model fills the gaps, silently
Four or five unstated decisions get made on your behalf. None surface. None are flagged as guesses.
-
It generates, confidently
The output is fluent and well-formed. Fluency reads as correctness, so nothing prompts a second look.
-
You find the wrong assumption, too late
Aimed at strangers when you meant customers. Now it's a re-prompt and a re-read, after you've already anchored.
The thesis: an editable brief between the request and the output
The same model and the same request can produce a guess or an answer. The difference isn't the prompt. It's whether the gaps were decided on purpose.
Steer inserts one move between request and output: a brief the person can see and edit. Inferred details appear as assumptions, labelled as guesses, each one click to override. Real forks, the decisions a model has no business making for you, appear as choices instead of being resolved in the dark. Only then does it generate. Same effort as a re-prompt, spent before the mistake instead of after.
Blind versus steered, rendered live in the Minia design system, the same theme as the app above.
Inferred details shown as editable assumptions
Every inference the model makes is an editable assumption: visible, attributable, and one click to change.
The danger of a silent assumption isn't that it's wrong. It's that it's hidden, so it can't be corrected until it's expensive. Steer turns each inference into a chip (tone, length, CTA, sender) marked plainly as something the model guessed. Leaving one untouched is a real decision: you've accepted the default. Changing one updates the brief immediately. The person stays the author of intent. The model drafts a starting point.
Inferred assumptions, made visible, rendered live in the Minia design system, the same theme as the app above.
Real ambiguity becomes a fork the person resolves
Some gaps shouldn't be filled by a model at all. Those become forks, and an unresolved fork blocks a steered generation.
There's a line between a reasonable default and a decision that belongs to the person. Audience. Intent. The core goal. Guessing these isn't helpfulness, it's overreach. Steer draws that line explicitly: low-stakes inferences become editable assumptions, and real ambiguity becomes an either/or choice the person has to make. The model declines to resolve it silently, and says so. Naming the fork is the design. It teaches what the request was missing.
Ambiguity as an explicit choice, rendered live in the Minia design system, the same theme as the app above.
What a visible brief changes about the output
When the brief is visible, the output is explainable. Every choice traces back to a decision someone made on purpose, not a guess nobody saw.
Try it in the app above. Parse the request, change an assumption, and watch the brief on the right update. Resolve the forks and generate, then flip to Generate blind and watch the same model produce confidently wrong output from the gaps it filled on its own. The decision log records every steer, so a good result is reproducible and a bad one is diagnosable.
How the design changed from v1 to v6
The composer wasn't designed all at once. Each version moved one more decision earlier, from re-prompting after the fact to steering before generation.
It started as a better prompt box and ended as a negotiation. Every step closed a gap between what the person meant and what the model assumed, until the assumptions were visible, the real forks were the person's to decide, and nothing got generated on a silent guess.
-
1
A bigger prompt box
More room to type, with placeholder hints. People still under-specified. The model still guessed.
-
2
+ Parsed-intent summary
Echoed back what it understood before generating. Read only, but at least the guess was visible.
-
3
+ Editable assumptions
Turned the summary into chips you could override, so correcting a guess no longer meant re-prompting.
-
4
+ Ambiguity forks
Separated low-stakes inferences from real decisions. The real ones became explicit either/or choices.
-
5
+ Generation gate
An unresolved fork blocks a steered generation. The model won't fill a real gap without you saying so.
-
6
+ Blind/steered contrast · current
Made the value legible: run the same request blind and steered, side by side, and the difference speaks for itself.
Explore more in the AI Product Design Lab
Ground traces every claim back to what supports it, Oversee gates what an agent may do on its own, and Recall makes the notes it kept on you readable and revocable.