Rules (guardrails)
Rules are your Worker's guardrails: they state, action by action, what it can do on its own, what it must ask about, and what it must never do. It's the tool that lets you trust your Worker without losing control. This article explains what a rule is, how it acts, and its limits.
The right picture: the initiative (see the Behavior Studio article) sets the Worker's general temperament. The rules are the precise instructions that override it: "for this, don't ask" / "for this, always ask" / "this, never".
1. What a rule is
A rule has a title, an optional description, and above all a scope among three:
| Scope | Worker behavior |
|---|---|
Always (always) |
Performs the action without asking |
Ask (ask) |
Asks for confirmation before acting |
Never (never) |
Refuses the action |
Examples:
- "Send external emails" → Ask
- "Delete data" → Never
- "Create a draft" → Always

2. Where to create them
- At the Worker's creation: the Skills & Guardrails step.
- Later: the Worker's page → Behavior Studio → rules section.
- Worker templates (admin) can pre-fill rules, which are then copied into each Worker hired from the template.
To add a rule
- Click Add a rule
- Enter a clear title (the action concerned)
- Choose the scope: Always / Ask / Never
- Save

3. What happens under the hood
- Your active rules are injected into the Worker's instructions, in a dedicated # RULES section.
- The Worker reads them as behavior instructions:
- ask scope → it calls a confirmation tool that pauses the action until you approve;
- never scope → it refuses;
- always scope → it acts directly.
Important — these are instructions, not a technical lock. Rules strongly guide the Worker, but they're not a code-level permission system. For sensitive actions, combine an ask/never rule with a cautious initiative level.
4. The limits to know
- Maximum 20 active rules per Worker. Beyond that, you must delete one before adding a new one (explicit error message).
- No explicit priority/order. Rules are evaluated in the order they appear. Avoid contradictory rules.
- Rules don't automatically propagate to sub-agents. If your Worker delegates to a sub-agent, you must explicitly restate the constraints in the delegation instructions.
- The ask scope requires a real confirmation. The Worker calls a confirmation tool that suspends execution — it doesn't just "hesitate".
5. Rules, instructions, missions: don't mix them up
| Concept | Role | When it acts |
|---|---|---|
| Rule | Per-action guardrail (always / ask / never) | At each decision to act |
| Onboarding instructions | Framing text given at hire | Continuously, as context |
| Initiative | General temperament (passive → autonomous) | At each decision to act |
| Mission / Task | Triggered work (recurring, scheduled, on event) | When the trigger fires |
In summary
- Rules = precise, per-action guardrails, in three scopes.
- They are injected into the Worker's behavior (strong instructions, not a lock).
- Cap of 20, no priority, must be restated to sub-agents.
- Combine them with the right initiative level for a Worker that's both autonomous and safe.