You just put agents on a clock. That is power, and power without a brake is dangerous: an agent that can act on its own, on a schedule, can also break things on its own. This chapter is the brake, the line between what runs alone and what waits for you.
3.10.1Not every action is equal
Reading a dashboard and deleting a customer's account are not the same risk, so they must not have the same freedom. You sort every action an agent can take into two buckets.
Reversible, low-risk work runs on its own. Anything that touches money, real user data, security, or removes a capability stops and asks. That sort is the whole game.
3.10.2Fix what's safe, escalate what's not
Give every autonomous agent one standing rule: fix what you are allowed to fix, and for everything else, do not act, leave a card.
When a scheduled agent finds a problem it can safely repair, it repairs it and logs it. When it finds something only you should decide, raising the bill, swapping a vendor, changing a price, it writes a short decision card and stops. The agent never raises the stakes on its own.
3.10.3The decision queue
Every escalation lands in one place: a queue of decisions waiting on you. Each is one card, one question, one recommendation.
# decision: raise the DB plan?
Why: we hit 90% of storage twice this week.
Recommend: upgrade one tier (+$25/mo).
Options: approve / hold / do something else
You clear the queue on your own schedule, approving or rejecting each. An approved card becomes a line in the decision log back in your cockpit, so the call and its reason are recorded, not lost. This is what makes autonomy safe to live with: the system does the tireless work and hands you only the handful of calls that would hurt to get wrong.
3.10.4Write the hard lines down, once
The guardrails cannot live in your memory. They live in a rules file, always loaded, phrased as absolutes:
# rules/guardrails.md
- Never change billing or pricing without an explicit yes.
- Never delete user data without confirmation.
- Never send anything to a customer without approval.
Every rule earns its place by naming a specific way things go wrong. The list is short, blunt, and permanent, and it fires on every turn whether the agent thinks to consider it or not.
A rule the agent reads is a rule it can talk itself out of over a long, tired session. For the lines that must never break, add a second layer: a hook, a small script your tool runs automatically that mechanically blocks the action, no judgment involved. The rule tells the agent what not to do; the hook makes it impossible. Anything that spends money, deletes real data, or ships to production belongs behind a hook, not just a sentence.
3.10.5Draw your own lines
This prompt sets your guardrails before you let anything run alone:
Act as a senior engineer setting safety guardrails for my
autonomous agents. From what my system can touch, list which
actions are safe to run alone (reversible, low risk) and
which must wait for my approval (money, user data, security,
deletions). Then write a short always-on rules file that
encodes the must-wait lines as absolutes.
What my agents can do and touch:
Do this now: paste the prompt, get your safe/escalate split and a guardrails rules file, and add it to your agents' always-on rules before any of them run on a schedule.
