Read vs write mode
Read tools auto-execute and stream a thinking trace; write tools never auto-run — they surface as editable cards you confirm.
The assistant has two kinds of tools, and the difference between them is the entire safety model: reads happen automatically; writes never do. You don't choose a mode — the assistant picks the right tool for what you asked, and the boundary is enforced server-side.
Read mode — answers, auto-executed
To answer a question, the assistant calls read-only tools. These run server-side, immediately, with no confirmation — they only ever look, never change. Each one streams to the chat as a thinking trace line that resolves with a check mark, so you can see exactly what it inspected.
legacy_checkout— fully rolled out, no rule references itdark_mode— at 100% since March, experiment finishedbeta_banner— superseded bynux_banner
Prop
Type
The assistant doesn't answer product questions from its training data. It calls
search_docs first and grounds the answer in the returned sections, ending with a
Sources: line of links — so every claim traces back to a doc page.
Write mode — proposals, never auto-run
To change something, the assistant emits the matching write tool with its best-guess arguments — but write tools have no server-side executor. The model's call streams to the client and stops. It surfaces as an editable confirmation card, and the underlying change runs only after you press Confirm.
That inversion is deliberate: because nothing mutates until you confirm, it's safe — and expected — for the assistant to propose a mutation directly rather than asking "should I?" first.
Tweak the title and the highlighted controls here. To change anything else, ask in the chat and the assistant revises the plan.
The write tools cover the full resource set:
release_flags_create / release_flags_update / release_flags_enable
release_flags_disable / release_flags_rollout / release_flags_archive
release_configs_create / release_configs_update / release_configs_draft
release_configs_publish / release_configs_archive
release_killswitch_create / release_killswitch_update
release_killswitch_set / release_killswitch_unset / release_killswitch_archive
metrics_create / metrics_archive
events_create / events_update / events_approve / events_archive
ops_create / ops_update / ops_notify
ops_alerts_create / ops_alerts_update / ops_alerts_archiveThey are the same names the MCP server advertises — the assistant and an external coding agent drive one surface, not two.
The assistant never says an action "is done." It hands you the card; you apply it. If you cancel, nothing happened. Deleting resources is also available directly in the dashboard UI.
Why the split holds
Reads are pure
Read tools only fetch — listing resources, reading docs, fetching a site page — so running them automatically can't surprise you. They're how the assistant grounds an answer.
Writes have no executor on the server
Write tools are registered without an execute function. The model can call
them, but the server can't run them — the call becomes a card on the client.
You are the executor
The matching Server Action runs only after you confirm the card. Your session scopes everything to the project you're viewing.
There's a third kind of tool — presentation tools (ask_user, suggest_plan, select_slack_channel) — that also skip
auto-execution but render as an interactive chooser or plan rather than a confirmation card. Those
are covered next.