Confirmation cards & plans

How the assistant turns an intent into an editable card you confirm — and how plan cards split instant resources from ship-code work.

Production readyOn this page · 5 min readUpdated · June 19, 2026Works with · In-dashboard assistant

When the assistant decides a change should happen, it never just does it. It renders the change as an editable card. You review, tweak the fields, and confirm — only then does the mutation run. This is the whole safety model of write mode.

Confirmation cards

A confirmation card is a form pre-filled with the assistant's proposal. Every write resource has one:

Prop

Type

The fields are the real resource schema — what you edit in the card is exactly what gets written. Nothing is hidden behind the assistant.

write · confirm

⧉Create experiment

new-checkout-flow

Groups

control · 34variant_a · 33variant_b · 33

Allocation10% of the universe

Goal↑ checkout_completed · count_users

Guardrailsavg(latency_ms)error_shownrefund

Tweak the title and the highlighted controls here. To change anything else, ask in the chat and the assistant revises the plan.

ConfirmCancel

An experiment proposal: groups, weights, allocation, and the success + guardrail metrics — editable, applied only on Confirm.

The assistant proposes

It calls a write tool. Instead of executing, the call surfaces as a card with its arguments pre-filled.

You edit

Change the rollout, rename the flag, swap the metric — every field is editable.

You confirm

The mutation runs against the same admin endpoints the dashboard and CLI use. The card collapses into a result.

The chooser

When the assistant needs a decision from you mid-flow, the ask_user tool renders a chooser — a small set of options — rather than guessing. Pick one and it continues.

A chooser comes in two shapes. Single-choice offers radio options and resumes the moment you pick one; multi-select offers checkboxes and submits the set together on Confirm. Both can carry a free-text "Something else…" escape hatch.

ask_user

Which outcome should we optimise for?

SignupsMaximise completed registrations

RevenueMaximise checkout value

RetentionMaximise 7-day return rate

Something else…

Confirm

Single-choice: radio options the assistant offers when it needs one decision to continue. Picking one resumes the chat.

ask_user

Which guardrails should we watch?

Latencyp95 response time

Error rate5xx / client errors

Refundspost-purchase refunds

Something else…

Confirm (2)Clear

Multi-select: checkboxes, submitted together on Confirm — for picking a set of guardrails.

Plan cards

For anything bigger than a single resource, the suggest_plan tool renders a plan card — an ordered set of steps. A plan separates two kinds of work:

Instant resources — flags, configs, metrics the assistant can create directly via confirmation cards.
Ship-code work — changes that need a developer or a coding agent (wiring the SDK, instrumenting an event). These are filed as tickets for ops:work or an external agent via the MCP server, not executed in the chat.

suggest_plan

PlanMeasure checkout funnel

Create metric checkout_conversion_rate⚡ Instant

count_users(checkout_completed) / count_users(checkout_started)

Create experiment new-checkout-flow⚡ Instant

control 50% · variant 50% · goal ↑ checkout_conversion_rate

Instrument checkout_completed⚒ Ship run

Emit on the order-confirmation screen.

1 code edit → filed to your ship crew · 2 instant

Approve planDismiss

A plan separates Instant resources (created on approve) from Ship-code work (filed as a ticket). One approvable unit for a whole measurement.

This is why the assistant can scope an entire experiment — metric, variants, instrumentation — even though it only writes the parts that are safe to write from a chat.

Was this page helpful?

✎ Edit this page