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
List of rules in the Behavior Studio, each line with an Always / Ask / Never badge

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

  1. Click Add a rule
  2. Enter a clear title (the action concerned)
  3. Choose the scope: Always / Ask / Never
  4. Save
Rule add form: title field + scope selector (Always / Ask / Never)

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

  1. Maximum 20 active rules per Worker. Beyond that, you must delete one before adding a new one (explicit error message).
  2. No explicit priority/order. Rules are evaluated in the order they appear. Avoid contradictory rules.
  3. 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.
  4. 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.