A plan nobody was following

Helix thinks before it acts. A dedicated reasoning call restates the request, names what it is assuming, considers more than one route and says why it rejected the others, picks the cheapest surface that can do the job, and writes success criteria specific enough to be held to later.

It is good reasoning. The problem was that most of it went nowhere.

The pattern

Auditing a layer like this, the useful question is not "is the reasoning any good?" It is who reads this field? Asked that way, seven answers came back "nobody".

A request with two things in it got no plan at all

The gate that decides whether a request deserves deliberation checked the trivial-verb list before the multi-clause check. So anything that merely started with a trivial verb never reached it:

"open spotify and play my liked songs"    -> not worth thinking about
"close all my windows then lock the pc"   -> not worth thinking about
"open the file and tell me what it says"  -> not worth thinking about

Every one of those is two tasks with an order between them, which is exactly the shape a plan exists for. They were skipped because "open" and "close" are on the trivial list and the whole request fitted inside its 40-character window.

The fix is a compound test that runs first, and it has to be narrow: "open the sales and marketing folder" is still one task, so the conjunction has to be followed by something that reads like another instruction. A first attempt treated a bare "next" as sequencing — and started deliberating over every "next track". The existing test suite caught that on the first run.

The blind plan beat the one that had looked

Two plans existed and they are not comparable. One comes from the routing call, which decides chat-or-automate and throws in "3-6 short concrete steps" on the way past, having seen nothing of the machine. The other comes from the deliberation, with the screen in front of it, knowing which surfaces are connected and what Helix already learned about this task.

The code said, in a comment: "it never overrides one the caller supplied". So the blind plan won on every phone-sent task, and the good one was computed, logged, shown to the user as reasoning — and discarded.

The plan had no state

It was written once and printed identically into every prompt for the rest of the run, under the words "follow it; skip steps already done". Skipping the steps already done requires knowing which those are, and nothing anywhere recorded it. So on step twenty the model received the same six lines it saw on step one and had to reconstruct its position from a history that had been trimmed to fit.

It now carries position — and only what is certain: the milestones the model itself declared, and how many steps have gone.

[WHERE YOU ARE IN YOUR PLAN]
Finished so far, in your own words: Opened Chrome
This is step 14; your plan has 3 step(s).
[BEHIND] You have spent 14 steps on a 3-step plan and reported 1 stage(s)
finished. Either the plan was wrong - say so and work to a different one -
or something is not working and repeating it will not help.

It deliberately does not guess which step is current. That would be a fuzzy match between prose written beforehand and prose written afterwards, and this codebase has been bitten by exactly that kind of matching before.

The check-in had never seen the plan

Every few steps the run stops and asks the one question nothing else catches: am I actually getting closer? It compared progress against the success criteria and nothing else — so the most useful thing it could have said, "you are still on step two of six and you have spent half the run", was unavailable to it. It had never been shown the six.

It could say "I must ask" and nothing listened

The deliberation has a carefully guarded property meaning this is genuinely unanswerable without asking. It requires a real question and that the model did not simultaneously produce a plan it was happy with. It was written, documented, and read by nothing. The planner could conclude, in as many words, "I cannot do this without knowing which of your three Riyas you mean" — and the run would set off and pick one.

A guess is not recoverable here. These actions land on a real machine and real accounts; one question costs a message, and a message sent to the wrong person cannot be taken back. The run now stops before its first step, asks, and touches nothing.

The progress bar counted actions

The desktop marked plan step N complete as soon as N actions had happened. A six-step plan displayed as finished by the sixth click, whatever those clicks achieved, and a run stuck on step two for thirty steps showed as done. It measured the one thing never in doubt — that something happened — and reported it as the thing you actually want to know: that something worked. Progress now advances only on milestones the agent declares.

"The answer is over there" counted as answering

Found by running the fixed planner against a real request — "open notepad and tell me what version of windows this is". Eleven steps, and it finished with:

"Notepad is open and displaying the Windows version information."

Not empty. Not a bare status. A sentence about where the answer could be found, which to somebody reading a chat on their phone is worth exactly as much as not answering. Same request afterwards: five steps, 24 seconds, and the version number.

Two more, while we were there

The same audit found two fields the reasoning fills in that the executing half never saw. unknowns is the deliberation naming its own blind spots — what it could not settle without looking. It went into the trace for the reader and nowhere else, so the one half of the system that can actually look was never told what to look at. And rejected — the routes considered and turned down — is stronger than naming the chosen route: a run drifts back to the mouse because by step six the screenshot in front of it argues for the mouse and the reasoning that rejected it is thirty turns back. Saying what was rejected answers the question the drift is actually asking.