Skip to main content

​
Engine autonomy

As the engine runs more of your growth work — shifting traffic between page variants, settling which variant ships, re-grounding your personas in what your real audience does — the question becomes how much of that it should do on its own, and how much it should run past you first. Different clients want different answers, and the same client wants different answers for different work: a brand campaign you watch closely, a long tail of pages you’re happy to let run. So the answer is one dial, not a scatter of toggles.

​
The three modes

Autonomy is a single setting — autonomy_mode — with three values, set on your organization and overridable per workstream. Autopilot. The engine acts immediately and drops a note in your Activity feed telling you what it did. No waiting. Use it for work you trust the engine to run unattended. Propose (the default). The engine does the analysis, proposes the change, and gives you a 24-hour window to veto it. If you say nothing, the change applies when the window closes — the engine keeps its cadence, and you keep a veto. This is the mode that matches “I want both”: the work doesn’t stall waiting on you, but nothing customer-facing changes without you having had the chance to stop it. Strict. The engine proposes and then waits. The change applies only if you explicitly approve it; an unanswered proposal lapses to no, and the next engine cycle re-proposes from fresh data rather than acting on a stale plan. Use it when every customer-facing change needs a human yes. The effective mode for any given action is the workstream’s override if it has one, otherwise your organization default, otherwise propose. So you can run one workstream strict and another autopilot at the same time without moving the org-wide setting.

​
What the dial gates

The dial governs exactly the points where the engine changes live, customer-facing state:
  • Applying a traffic-allocation step to a running experiment.
  • Executing a settled ship-or-stop decision.
  • Adding a new variant into live traffic.
  • An engine-initiated edit to a published page.
  • Re-grounding a persona in place from measured behavior.
Everything else — reading your data, forecasting, running the panel, writing predictions and observations — is never gated. Forecasting is free; acting is governed. And the two approval systems stay separate: an agent-tool approval you grant mid-conversation is a different thing from the engine acting on its own clock, and an action approved through either channel is never re-gated by the other. One human yes is one human yes.

​
Answering a proposal

Proposals arrive as escalations in your Activity feed — the same place every other attention item lives, so there’s no separate approvals inbox. Each one is written to be judged without opening a dashboard: what the engine wants to do, why, the numbers, and exactly what happens when the window closes. Approve it to act now, veto it to cancel, or ignore it — under propose that means yes at the deadline, under strict it means no.

​
The ledger — what the engine has done

Every outcome is recorded, so “what has the engine actually done?” is always answerable. Approvals, vetoes, lapses, and autopilot actions all write an attributed entry noting which channel authorized it — autopilot, a human’s yes, or a lapsed window — and, for a human yes, who. The “Engine actions” filter preset on the Activity feed narrows to exactly these, so you can review the engine’s decisions as one stream rather than reconstructing them.

​
Changing the mode

Set your organization default in settings, or from the CLI:
Set a per-workstream override through the workstream — via the app, the erdo_update_work_state tool (autonomy_mode), or the REST API. Pass inherit to clear an override and fall back to the org default.