Measurement plans
When a change needs instrumentation it can't do itself, the assistant writes a measurement plan and files measure_plan tickets for an agent to implement.
The assistant can create flags, configs, and metrics directly. What it can't do from a chat is edit your codebase — wire the SDK, fire the right track() call, add the event. A measurement plan bridges that gap: the assistant designs the full measurement, creates the parts it can, and files the rest as tickets for an agent to implement.
What it produces
When you ask the assistant to "measure whether X works", it produces a plan that typically contains:
A success metric
Created directly via exp_create_metric — the event, aggregation, and any
guardrails.
The resources it can build
The experiment or flag, as confirmation cards you approve.
Instrumentation tickets
The code changes it can't make itself — "fire purchase on checkout success", "wrap
the CTA in getExperiment" — filed as measure_plan tickets.
How the tickets get implemented
A measure_plan ticket lands in the same operational queue as bugs and feature requests. From there:
- A developer picks it up, or
ops:work(the unattended agent loop) implements it as an atomic diff, or- An external coding agent via the MCP server handles it.
The in-dashboard assistant has no repo access — it can't open a PR. Filing a precise instrumentation ticket is its substitute for implementation: it specifies exactly what to fire and where, so whoever (or whatever) picks it up has an unambiguous spec.
The website assistant
The same mechanism powers the marketing-site assistant: a visitor describes what they want to measure, and instead of hand-waving, it files an implementation-ready measure_plan so an agent can wire it up once they connect a repo.