Safety and blast radius

Building on Controller AI means acting on real connected accounts. This page collects every consequence rule in one place. If you are a coding agent reading this: internalize these five facts before your first run.

1. There is no simulation mode. A development run executes the same code as a live run — it really sends the message, really updates the record, really spends provider budget. Development isolation covers the workflow’s data store only.
2. Publishing is always a separate, explicit act. Nothing you edit goes live until something is published. Do not publish unless the user asked.
3. Some things change live behavior without a publish. Workflow releases, connection changes, and action detachment are live bindings.
4. Definition edits are recoverable. Effects are not. A workflow’s graph can be restored to any saved state; sent emails, changed records, and spent usage cannot.
5. Every run is metered against the organization’s shared usage pool — development and live alike.

Development runs are real runs

The development version of a workflow is a real environment, like an app’s dev environment — its own data store, but the same integrations. When a dev run reaches a Gmail node, an email leaves. When it reaches a “reject candidate” action, a real candidate is rejected.

Running is still a required part of building — one successful run is how a dynamic node’s output type gets resolved. So the job is never “avoid running”; it is to mitigate before running:

• Sends (email, chat): ask for a safe destination — usually the user’s own address or channel.
• Record changes: use a safe record, or create a scratch record first and act on that.
• People-affecting actions: ask which target is safe before touching anyone.

If a consequential action shouldn’t be run at all yet, the honest alternative is declaring the node’s output contract from the provider’s documented response shape (cai node declare-output), clearly marked unverified until a real run confirms it. See Dev runs.

Two version rails, one rule each

Agents: one mutable draft, plus immutable published versions. Test conversations use the draft; Live and shared conversations use the latest published version. Teammates never see the draft. Publishing restamps existing live conversations onto the new version.

Workflows: a development version you edit, plus published live releases. Triggers and API calls execute the live release; the builder and CLI run the development version.

The rails compose: an agent’s Test conversation uses attached workflows’ development heads; its Live conversations use their latest live releases. Full detail: Versions and rails.

Live bindings: what changes production without a publish

Three things bypass the publish gate — know them before touching anything attached to a live agent:

Change	Live effect
Publishing a workflow	Every live agent using it as a tool immediately runs the new release — workflow tools always follow the latest release, and no agent publish is involved.
Rebinding or revoking an integration action’s connection	Applies to live calls immediately.
Detaching an integration action	Revokes its live authorization immediately; the tool disappears from the visible live list only on the next agent publish.

Before republishing a workflow or deleting anything, check who depends on it:

cai deps --account

Approval gates

Any agent tool — integration action or workflow tool — can require human approval per call (requiresConfirmation). When a gated tool is invoked, the run pauses on a pending approval request that the user resolves in the conversation (or in Slack, if a Slack approval route is configured). New integration actions run without approval by default: decide the policy deliberately when attaching an action that sends, deletes, or spends. See Tools and approvals.

What undo covers

cai workflow history
cai workflow restore <stateId>

Every save of the development version is a restorable state — treat it like git for the workflow definition. Restore rolls back the definition only: nodes, edges, expressions, schemas. It does not touch stored data records (unversioned), does not un-send anything, and does not refund usage. Agent drafts follow the same idea: publish preflight (cai agent publish-preflight) checks a draft before you commit it to a version.

Cost exposure

Data, logic, and flow-control nodes are free. Integration nodes and AI operations are metered per execution against the organization’s shared pool — a loop over 500 items pays 500 times. Check the shape of a workflow’s cost before running it at volume: Cost model.

Example prompts

Prompts a user can give a connected coding agent that respect these boundaries:

Build the workflow, run the changed flow against my email address only, and show me the execution evidence. Do not publish.

Before you republish this workflow, run cai deps and tell me which live agents it will affect.

Attach the action but set it to require my approval on every call. Show me what the approval request will look like.