Autonomy & the kill-switch

Letting workers run unattended only feels safe because of two controls: a per-worker allowlist that bounds what each one may do, and a single switch that halts everything.

What you’ll learn

• How a worker’s tool allowlist sets its autonomy.
• How per-tool and per-run limits stop runaway loops.
• Where the global kill-switch lives and what it stops.

Autonomy is the allowlist

A worker can only ever use the tools on its allowlist (its Skills tab) — least-privilege by default, so a writer never holds the shell. That allowlist is its autonomy: the broader it is, the more a worker can do on its own during an unattended Routine or Plan.

1. Open a worker’s Skills tab.
2. Add only the tools that job genuinely needs.
3. Leave irreversible tools off, or gate them (next lesson).

Bound each run

In Settings → Providers you can cap how many times a single tool runs in one run and how many back-and-forth iterations a run may take. Refused calls hand the model an error instead of executing — so nothing spins in circles.

The kill-switch

Above everything sits one Autonomy switch. Flip it off and all unattended activity pauses at once — Plans, Routines, channel replies, heartbeats.

The big red button

The kill-switch is for “stop the workforce now,” whatever is running. One click, everything stops — no per-worker hunting.

Set a global budget too

Before letting workers run alone, add a global budget with hard-stop on. The allowlist bounds what they do; the budget bounds how much they spend.

Recap

Each worker’s allowlist sets its autonomy; per-tool and per-run limits keep a run from running away; and the global kill-switch stops everything instantly. Next: the gate that lets agents prepare risky actions but keeps the final yes with you.

➡️ Next: Approvals: humans approve, agents prepare