Approvals

The core rule of the entire platform: agents propose, humans approve. No agent pauses, escalates, or autonomously changes anything that costs money or acts outward — it puts forward a proposal with visible scope, and a human decides.

When approval is mandatory

Every tool on the platform declares its effect — sends, deletes, costs credits, writes inside the workspace. Exactly two of those trigger an approval:

• Sends — leaves the workspace and touches a person: an email, LinkedIn or WhatsApp send, arming a sequence.
• Deletes — is irreversible: a table, a sequence, a playbook, a sender, an entry removed from the blocklist.

Building needs no approval. Creating a table, adding a column, changing a playbook, writing a sequence — none of that acts outward, and none of it is put in front of you. That is deliberate: the brake sits where something happens, not where someone works. Creating a sequence sends nothing; only enrolling a lead starts the sending, and that is gated.

Credits are a cap, not an approval. A paid run is not put forward for approval — it requires a max_credits value, a number that hard-bounds the cost. See Costs.

A dry run never needs approval — it only shows what would happen. Pure read access (status, evaluation) doesn’t either.

The feed

Every pending approval shows up in the feed as an open Run: scope, affected rows, cost cap, a link to the detail view. You see exactly what approving would trigger before you do it — not after.

Why this rule is a rule, not a special case

Every new capability in the system — a new column type, a new workflow type, a new integration category — computes its approval requirement from the same formula (mode × effect), instead of bringing its own check. That prevents the gap that opens up when approval is only built into one of several execution paths.

See also: Costs for the cost cap that bounds every live run.