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.

​
Risk-tiered approval gates — propose the irreversible

Agent-tool approvals have their own dial: autonomy_gates. By default, propose gates every approval-gated agent action the same way — a budget change and the agent updating its own experiment record both raise a card, and the card that is actually about money arrives buried among bookkeeping ones. If that queue teaches you to rubber-stamp, the review the mode exists for is gone. autonomy_gates lets you say which risk classes of action still need a card when your autonomy is propose. Every approval-gated action declares one of four classes: Unset (the default for every organization), nothing changes: every gated action raises a card, exactly as before. Set it — say ["spend", "outbound", "destructive"] — and in propose mode only those classes raise cards; the rest execute directly, still recorded on the run’s activity. That makes propose mean propose the irreversible: a no-spend build phase runs to completion on its own, and the one card in your queue is the one about money. Three things never change with this setting: autopilot and strict are untouched (it narrows what propose asks about, never what other modes allow); an agent’s explicit request_approval always reaches a human; and a standing “always require” policy on an action outranks the tier setting. An action nobody has classified fails closed and always raises a card. autonomy_gates is the ORG’s dial — admin-set, org-wide, and propose-only. For your own queue there is a personal counterpart: approval settings select which risk classes still raise a card for agent runs YOU initiate, in any autonomy mode, so a heavy user can let page work flow without changing anything for their teammates. Read and set it beside the autonomy mode: the erdo_get_autonomy_gates / erdo_set_autonomy_gates MCP tools, or REST:

​
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.