Assistant use cases
Three worked chat flows — set up an experiment, generate a measurement plan, and run a read-mode audit of your flags.
The assistant is most useful on concrete tasks. Here are three real flows, each showing what you type, what it does, and where the safety rails are.
1. Set up an experiment by chat
You want to test a new pricing page but don't want to hand-build the universe, groups, and metric.
You: "Set up a 50/50 experiment on the pricing page, conversion as the goal."
The assistant scopes the whole thing and surfaces it as confirmation cards you approve — it never just creates resources silently:
It proposes the metric
A conversion success metric over the event you'll fire, plus any guardrail metrics
— created directly once you confirm.
It drafts the experiment
Groups, 50/50 weights, allocation, and the universe — pre-filled in an editable card. Change the split or rename a group before confirming.
It files the instrumentation
The one thing it can't do from a chat — wiring flags.getExperiment(...) and the
track call into your code — is filed as a ticket for an agent.
You confirm the cards; the experiment is drafted and ready to start.
checkout_completed · count_usersTweak the title and the highlighted controls here. To change anything else, ask in the chat and the assistant revises the plan.
2. Generate a measurement plan
You shipped a change and want to know if it worked, but the instrumentation isn't there yet.
You: "Did the new onboarding flow improve activation? Set up whatever we need to measure it."
The assistant produces a measurement plan: it creates the activation metric directly, proposes the experiment or flag as cards, and files precise measure_plan tickets for the code it can't write — "fire activated on the first project created", "wrap step 3 in getExperiment".
The in-dashboard assistant has no repo access. A measurement plan is its way of being complete: it builds the parts it can and hands off an unambiguous spec for the parts it can't, so a developer or ops:work agent can finish the wiring.
3. Read-mode audit of your flags
Sometimes you just want answers, not changes. In read mode the assistant executes read tools directly — no confirmation cards, because nothing is mutated.
You: "Which feature flags are still at 100% but haven't been touched in 90 days? Any I can retire?"
It queries your flags, configs, and experiments and answers in the chat — listing stale flags, configs no targeting rule references, and experiments that finished but were never archived. It cites what it found; you decide what to clean up.
legacy_checkout— fully rolled out, no rule references itdark_mode— at 100% since March, experiment finishedbeta_banner— superseded bynux_banner
Prop
Type
This read/write split is the assistant's core safety model: reads are free, writes are always confirmed.