Asking before guessing

Most of the interesting decisions in a computer-use agent are not about capability. They are about what it does when it is not sure — because the actions land on somebody's real machine, with their real accounts, and a wrong one frequently cannot be undone.

The cheapest question is the one asked first

A wrong assumption discovered at step one costs one model call. The same assumption discovered at step nineteen has already been built on eighteen times. That is the whole argument for thinking before acting rather than reasoning your way forward one click at a time.

So the deliberation writes down what it is assuming — "they did not say which browser; using Chrome, it is the default here" — and what it genuinely cannot know until it looks. Both ride into the run, where the half that can actually look is asked to check them rather than assume them.

When to stop entirely

Sometimes the honest answer is that the request cannot be acted on. "Message Riya about the thing" is unanswerable if there are three Riyas. The system has a property for exactly that conclusion, and it is deliberately hard to trip: it needs a real question, and either no plan at all or confidence below 0.35.

Those guards matter, because a model handed a field called "ask a question" will use it. An assistant that opens every task with a clarifying question is worse than one that guesses and says what it guessed. So a question asked alongside a confident plan does not count. Nor does a bare "shall I proceed?". Nor does a statement with no question mark.

When it does fire, the run stops before its first step and touches nothing. Both interfaces render it as a question rather than an error — because it is not a failure. Nothing was done, on purpose.

Asking permission for the right things

The other half of this is the permission model, and its failure mode is the opposite: asking too often.

Every shell command used to be classified as "runs arbitrary code", which is the right answer for Stop-Process and a badly wrong one for Get-Date. Under the default policy that meant Helix interrupted you to ask permission to read the clock.

That is not merely annoying. An agent that asks permission to read the clock teaches people to approve without reading — which is precisely the habit the whole permission layer depends on not forming.

Commands are now judged by what they do, through an allowlist rather than a denylist, so being wrong means one unnecessary prompt and never a missing one. Every segment of a pipeline has to be read-only; any redirection into a file disqualifies the whole thing, because Get-Process > kill.ps1 begins with a read and is not one. Tools whose read and write forms differ only by an argument — route, arp, reg, wmic — are not on the list at all. And a Python snippet is never a read: it is an arbitrary program.

Reporting honestly when it is over

The last place this shows up is the end of a run, and it is the one users notice. A run that does the work and then withholds the result has, from your side, failed — because the thing you asked for was the information.

So a question-shaped task that finishes without an answer gets pushed back once, with the demand made explicit: the text itself, quoted, not a description of having found it. And a finish that points at where the answer lives rather than saying what it is now gets caught by the same guard — on two conditions, because the second is what keeps it from trapping real answers: the message says the thing is open or shown somewhere, and carries no number and no quotation. "The file is open and shows 42 rows" points elsewhere and also contains the answer, so it passes.

None of this makes the agent cleverer. It makes it easier to trust, which on a machine you actually use is the more valuable property.