How a run works
There is no planner, no reviewer, no committee of agents. One actor decides what to do next, does it with real tools, and every step is on screen while it happens.
One actor, real tools#
Most agent products are a committee: a planner hands to a coder, a reviewer grades it, a verifier signs it off. Every hand-off is another model call you pay for, and every one of them can lie to the next.
W1 is one actor. It decides for itself whether the next thing to do is inspect, search, edit, run a command, test, revise, ask you something, or stop — and it does it with the same tools you would use. The runtime around it does not make those decisions. It enforces five things and nothing else:
- Transport — that a tool call is complete, exact and well-formed before anything runs.
- Execution — that commands run where they should, with the working directory they should have.
- Safety — workspace confinement, the command denylist, access mode and approvals.
- Context fidelity — that what the thread carries forward is what actually happened.
- Honest terminal states — that the run ends saying what really became of it.
The shape of a turn#
- You state an outcome
Your message goes in exactly as you wrote it, along with the thread's context and whatever the project itself makes available — skills, memory, and any plugin tools.
- W1 works
It reads, searches, edits, runs commands, and reads the output. Each step is announced and shown. Steps that need permission stop and ask you. Steps that would leave the project are refused.
- W1 checks
Where the task has a check that matters — a test suite, a type check, a build, a page that has to load — it runs it and reads the real result. A check is not a formality: a failing one is reported as a failure, not narrated into a success.
- The turn ends in a state
Finished, interrupted, blocked, or failed — and the thread records which. The next turn starts from what actually happened.
Tool calls are all-or-nothing#
A tool call reaches the runtime as exact, complete JSON or it does not run at all. Unknown tools, extra fields, arguments truncated halfway through, two JSON objects glued together — none of these execute. They are reported back as a malformed call and W1 tries again.
This matters most for edits. A multi-hunk patch is validated in full before the first byte is written, so a patch that would fail at hunk four never half-applies and leaves you with a file in two states.
Terminal states#
Every run ends in exactly one state, and it is recorded in the trace. This is the vocabulary:
| State | What it means |
|---|---|
model_finished | The actor finished and said so. The only state that means the work is done. |
awaiting_job | Work is continuing in the background and the turn handed off cleanly. |
interrupted_user | You stopped it. |
permission_denied | A step needed permission it did not have, and the run stopped rather than working around you. |
context_limit | The thread ran out of room. Start a fresh thread, or narrow the task. |
configured_limit | A limit you or your plan set was reached. |
provider_stall / provider_error | The model provider stopped responding or returned an error. |
tool_error | A tool failed in a way the run could not recover from. |
blocked | The run was stopped by a safety rule. |
internal_error | W1's own fault. If you see one, it is worth reporting. |
"Finished" is a claim about the run, not about your happiness with it.
model_finished means the actor completed and reported. It does not mean the tests passed, and W1's own summaries never treat a terminal state, an exit code or a token count as proof that the outcome was good. Read the checks.
What gets carried to the next turn#
The thread keeps your exact messages, each turn's outcome and terminal state, what changed in the workspace, compact receipts of the work, and the usage totals. It does not replay internal reasoning, full file writes or complete command output.
That is a deliberate trade. Re-sending everything would make each turn slower and more expensive and would not make it smarter — the useful part of a finished step is the conclusion it produced, not the transcript of producing it.
Long runs and background work#
Some work outlives a single turn. W1 can start background tasks and report on them as they finish, and long-running processes — a dev server, a watcher — are started as services rather than as commands the run has to sit and wait on. You keep working in the thread while they run.
If a run does stall, you will see it: the app shows a provider retry, a compaction, a permission request or a "needs input" state. Repeatedly pressing Continue on a run that has not actually paused is the one thing that makes it worse — see Troubleshooting.