Skip to main content
A playbook is a whole job, ready to install: what starts it, the steps to follow, the Apps it needs and the writes it may make. Installing one sets up its triggers, schedules and skills for you, then a teammate runs it each time an event comes in.

​
Available playbooks

Playbooks have their own page in the sidebar, Playbooks: the ones installed, then a Catalog of the ones you can still install. Brigade ships one today:

​
Support and bugs

Sorts the support inbox, answers customers, fixes the bugs they report and tells them when it is fixed.
  • Apps: Gmail (read and write) and GitHub (read and write). Optional, read-only: Stripe, to look up a customer, and an analytics tool (Mixpanel or an MCP server).
  • Two roles: one teammate answers customers; another fixes bugs in the code, in sub-threads the first one hands it. The same teammate can do both.
  • Starts on: each email to your support address in the Gmail inbox you choose. Gmail’s Promotions, Social and Updates tabs and automatic replies never start a run.
  • Every Monday at 08:00: a weekly review of last week’s cases, what was answered and what is still open.
  • At most 100 runs a day. Past that, new events wait, and the owner gets a ticket.

​
Install a playbook

Installing happens in a conversation with a teammate.
  1. In Playbooks, choose Install next to a playbook in the Catalog. A new thread opens with a teammate, its first message ready to send.
  2. The teammate asks its settings one question at a time. For Support and bugs: which teammate answers customers, which product, which Gmail account receives the mail, which address customers write to, where your public docs are, which repository bugs are fixed in, which teammate fixes them, and an optional analytics account.
  3. When an App the playbook needs isn’t connected or given to the teammate, it asks for it in a ticket under Needs you. Connect or grant it there.
  4. The teammate offers a dry run, then a card with an Activate button.
Nothing runs until the playbook is activated. The playbook runs on the accounts of the member who installed it, its owner.

​
Dry run

A dry run tries the playbook on real past events before it goes live. For Support and bugs, it replays the latest 20 emails that match its search. Each event runs as it would once active, except that every write is simulated: nothing is sent, labeled, merged or pushed. The report shows, for each event, the case it found, what it would have done, and the session minutes it took, with an estimate for a week.

​
Activate

Choose Activate on the card in the thread, or in the playbook’s menu on its page. Only owners and admins can activate a playbook, since it then acts with no one checking each step. A member sees Ask to activate instead, which sends one ticket to owners and admins. Once active, each event starts a run. A run’s thread stays out of your sidebar until a person takes part in it, by sending a message or taking control. Each run’s thread has only the tools of the Apps the playbook declares.

​
What it does on its own

Each write a playbook may make is an action, with a level:
  • Asks first: a person approves each time, in the thread and under Needs you.
  • On its own: it acts without asking.
  • Never: it doesn’t.
Support and bugs starts with these levels: A write the playbook doesn’t list always asks. Each action also has a ceiling the playbook sets, which no one can go past.

​
How autonomy grows

  • Your decisions build trust. When 95% of the last 30 decisions on an action are approvals, its owner gets a ticket offering to let it act on its own. Nothing raises a level without a person.
  • You change levels yourself. On the playbook’s page, under Actions, use an action’s menu. The owner, an owner or an admin can change it. Only owners and admins can let it merge on its own.
  • Mistakes send it back. Under Done on its own, choose Mark as wrong on a call: its action goes back to Asks first, and trust counts again from then.
On its own holds only while the action’s conditions and daily caps do. Otherwise that call asks, and the level stays.

​
The playbook’s page

Open a playbook from Playbooks to see its status, whose accounts it runs on, the week’s numbers (runs, share unattended, first response time, bugs fixed and more), then its Actions, Apps, Entries (its triggers and schedules), Settings and Recent runs. From its menu, the owner, an owner or an admin can Pause, Resume or Uninstall it. Uninstalling removes its triggers, schedules and skills. A playbook’s triggers, schedules and skills belong to it: they change only through the playbook.

​
Update to a newer version

When Brigade ships a newer version, the page shows “Version 1.2.0 · 1.3.0 available” and an Update button, for the owner, an owner or an admin. The update dialog shows what changes.
  • Your answers are kept. A new required setting is asked first, in the dialog or in a chat.
  • Its triggers and schedules change in place, so a Gmail trigger misses or repeats no mail.
  • Its skills take the new version, except one your workspace edited, which you choose to keep or replace.
  • Autonomy never grows with an update. An action whose tools or conditions changed goes back to Asks first.
  • Its runs, numbers and history stay, and it stays active or paused as it was.