Plan mode is everywhere lately. Claude Code has it. Cursor has it. The agent reads the repo, works out an approach, and waits before changing files.
Good. Coding before understanding the problem is a very fast way to make the wrong thing.
Still, most plans live in a private conversation between one person and one agent. The agent presents a tidy list. One person clicks approve. Everyone else meets the idea later, when it has already become a pull request.
That feels like we stopped one step too early.
The cheapest time to disagree
A plan is where the agent tells you what it thinks you asked for.
It might want to add a new table when the data already exists. Or it found a clean refactor that would quietly break the weird workaround your team discussed two months ago. The code can be perfectly reasonable and still begin from the wrong understanding.
The best person to catch that may not be the person running the agent. A designer knows the interaction is wrong. An engineer recognizes the old workaround. Both should be able to say something before the agent spends twenty minutes making the mistake more expensive.
This is one reason coding agents need to live where the team talks. The plan carries useful context, but only if the people with context can see it.
What we built in hilos
On August 17, we shipped plan mode for hosted hilos agents.
When a task reaches the routing card in hilos, you can choose Plan first. The agent investigates the repository and writes an implementation plan. That plan comes back on the run card in the same room where the task started.
Nothing has been pushed at this point. During the planning turn, hilos skips the git stage and disconnects the sandbox from the repository's origin before the coding agent starts. The prompt asks it not to write; the runtime makes sure it cannot push anyway.
The card lets you approve the plan, send it back with a revision, or dismiss the run.
Revise starts another planning pass with the feedback from the room and the earlier plan attached. Approve resumes the same run and the same agent session in build posture. It does not throw away the investigation and ask a fresh agent to reconstruct it. When the code is ready, the pull request comes back to the room for the ordinary review decision.
The plan gets shaped in the room. Later, the code does too.
A better door for the ideas person
The pull request is a late place to join the work. By then the structure is set, the files have changed, and the conversation has become code review.
That works for the engineer holding the merge. It is a lousy entrance for the designer or product person who understands what the feature should do but does not want to pretend they are reviewing TypeScript.
A plan gives them something they can question without translating the diff first. Why does this need a new setting? Can we cut the second half and ship the useful part today?
Those are implementation decisions too. In a team room, the person with the product context can make them before the agent commits to an approach. The engineer still reviews what ships. They just stop being the only person who can affect the work.
Approval is a very small gesture
A generated plan can still become another thing we rubber-stamp.
We have all clicked through a permission dialog without reading it. A long plan can hide a weak idea, and a green Approve button tells us only that somebody clicked it.
A quiet approval tells us almost nothing. The reply asking why a migration is needed, or the note that removes half the scope, tells us somebody looked. The agent goes back into the repo and returns with a plan that carries those decisions.
This is also why the plan stays on the run card after approval. The team can compare what was proposed with what came back. If the code wandered, the earlier decision did not disappear into a private transcript.
What the team decided stays beside what the agent shipped.
Not every change needs a meeting
Plan mode adds time. Anthropic's own Claude Code guidance says to skip it for a typo, a log line, or a small change whose diff is already obvious.
Fair. Asking an agent to write a plan for changing one label is how we recreate enterprise software with robots.
In hilos, Plan first is a choice on the routing card. Use it when the approach is unsettled or the people affected should see the direction before it hardens into code. Let the tiny jobs stay tiny.
The plan is part of the work
Coding agents are getting better at running for longer stretches. Interfaces are adapting too. GitHub's SDK now distinguishes steering from queueing: one redirects the current turn, the other waits for the next one.
hilos does not pretend those are the same. A reply on a plan asks for another planning pass. On a hosted build that opens a pull request, a steering note waits and joins that pull request on the next pass. The room says when the feedback will land.
An agent can arrive with a thoughtful approach. Then people question it and decide whether it deserves to become code.
Somebody needs to say, "Wait, why are we adding another table?" before the table exists.
That one reply can save an entire wrong pass. Better to hear it while the table is still imaginary.