Set your guardrails

Write standing permission rules that govern what Dispatch can do on its own and what needs your sign-off.

The job: decide once what Dispatch may do unsupervised, instead of confirming the same kinds of actions over and over. This recipe walks you through your standing rules and writes them to your permission policy. The permission gate reads that policy on every risky write (sending mail, posting to a channel, changing a calendar event), so your rules are enforced from then on.

Touches: Preferences, Permission gate.

Prep: None, though guardrails are most useful once you have connected accounts Dispatch can act on.

Set your rules

Help me set up my permission rules: the guardrails for what you can do on your own versus what needs my sign-off. Walk me through these areas:

    Email: who you can send to without asking, and who always needs my confirmation
    Calendar: whether you can create or change events directly, or only propose them
    Slack and other channels: which channels you can post in unprompted
    Anything I always want to confirm before it happens

Ask me about one area at a time. Once we've covered everything, save the rules to my permission policy so they apply on every action going forward.

What you'll see back: Dispatch asks about each area, then writes the rules to your permission policy at /preferences/permissions.md. After that, every risky action is checked against them before it runs. Editing the policy is itself gated as a policy-write, so changing these rules later takes the same explicit go-ahead as any other sensitive change. Dispatch cannot quietly broaden its own authority.

Try variants

  • "Loosen the rule for @acme.com: you can email anyone there without asking": relax one rule.
  • "Add a rule: never delete or permanently remove anything": tighten coverage.
  • "Show me my current guardrails": Dispatch reads back the policy.

On this page