Deep Research

mur deep-research runs a squad of workers over the web against one question, bounded by a budget you set, and saves a report. It is the simplified front door to the deep-research fleet — three verbs instead of the flag-based provision / run path.

mur deep-research setup          # one-time wizard: model, workers, budget, egress consent
mur deep-research                # status panel — the live run, or the last one's outcome
mur deep-research "question"     # preflight (start workers, re-pin gateway) + guarded run

provision / run remain as the advanced path. Egress is only ever granted in setup or provision --grant-egress — asking a question never touches grants, so a run can only reach the web if you already said it could.

From a murmur chat

Inside a murmur session the same thing is a slash command. It renders on your screen without costing the agent a turn, so the transcript the agent sees stays clean:

/deep-research                   # status panel
/deep-research ask <question>    # start a run, progress streams while you keep typing
/deep-research <question>        # `ask` is optional — any other text is the question
/deep-research stop              # end it (outcome = stopped)

/research is an alias for the same command. setup is the one verb the slash form will not run: it points you at mur deep-research setup in a terminal, because the wizard asks for egress consent and that belongs at a real prompt.

From an agent

Agents reach deep research through the built-in fleet_run tool, not the CLI. It dispatches and answers with a handle — always, because a research run outlasts any call timeout:

fleet_run 
→ 

Then poll the id:

mur_job_status fleet-deep-research-019bd4c1-…
→ run … — state: running, liveness: alive
  progress: iteration 2 · 3✓ 0✗ 2 pending · spend $0.31/$2.00

There is no flag for waiting instead — see Execution Limits → Long work returns a handle for why every long tool answers this way, and Run Status for what the state and liveness verdicts mean.

Where progress comes from

A run writes ~/.mur/fleet-state/deep-research/.run_progress.json as it goes: per-phase counts, running steps, spend against budget. It is best-effort and never affects the run — a corrupt or missing progress file costs you the detail, not the research.

Asking a question never rewrites the fleet. mur fleet show deep-research keeps the goal setup wrote; the question you asked is the question field of that run's progress record.

Two surfaces read it, and they are not interchangeable:

• mur deep-research (and the murmur rail) reads the file directly. This is the surface that shows a preflight failure: if starting the workers or re-pinning the gateway fails before the run exists, the error is recorded there and the panel shows it.
• mur_job_status <run_id> answers from the run record, and attaches the progress: line only when the progress file's own run_id matches the id you asked about. That match is the point: it stops an earlier run's progress being reported as this one's. Ask it about an id that never got a run record and it says no run recorded rather than guessing.

Preflight is tens of seconds, not sub-second — it starts workers and re-pins the gateway before the first progress appears. A freshly dispatched run that shows no progress yet is normal.

Budgets and stopping

The run is bounded by the deep-research fleet's limits (deadline / stuck / cost_usd), resolved the same way every fleet's are — mur limits deep-research shows what is in force and where it came from. /deep-research stop and mur fleet stop deep-research are the kill-switch; a stopped run settles with outcome stopped, not failed.

See Execution Limits for the three knobs and Fleet Loops for how iterations converge.