Start with work already described.
Every playbook below comes from the same first-party catalog inside Boring. It creates a private, editable draft — never a live agent. Connect the required tools, review its permissions and approval gates, test it, then publish when the behavior is right.
Daily executive brief
Every morning, digest Linear, Fireflies, Gmail & Calendar into a stack-ranked Slack brief.
Meeting action tracker
Turn meeting decisions into reviewed tasks and a lasting decision log.
Weekly stakeholder update
Draft a source-linked weekly update from project systems for human review.
Weekly backlog hygiene
Propose and apply reviewed cleanup for stale, duplicate and unowned issues.
Invoice approval routing
Route incoming invoices for approval.
Invoice and receipt ledger
File new billing documents and maintain a duplicate-safe expense ledger.
New hire welcome kit
Send first-day resources and schedule intros.
Onboard new employee
Provision access across Okta, Slack & Calendar.
Weekly website quality audit
Check public pages for accessibility issues, broken links, and copy mistakes.
Source-backed research brief
Turn a research question and public sources into a cited brief and review-ready Notion draft.
Inbound lead router
Enrich and route new leads to reps.
Triage support email
Summarize, search docs and open a ticket.
Choosing an AI agent playbook for your team
Start with a recurring job and a named owner
An AI agent playbook is a starting definition for work your team already understands: the inputs it needs, the steps it should attempt, and the rules it must follow. It is useful when the same outcome comes up repeatedly but the path depends on context. An invoice may need a purchase-order check, a support email may need a severity decision, and a weekly update may need evidence from several project systems. The playbook gives that work a concrete starting point.
Pick a workflow whose owner can explain a good result and recognize a bad one. That person should also know which exceptions deserve attention. Avoid starting with an entire department or a promise to automate everything in an inbox. A narrow job is easier to test, easier to review, and easier to stop when the instructions do not match reality. Keep one person accountable for the first version, even if several teammates will review its work.
Read the steps and guardrails before choosing
Every published playbook shows the instructions behind its workflow and the tools it expects to use. Read those details before treating the title as a fit. Invoice approval routing, for example, is about checking and routing an invoice; it is not permission to make payments. Lead routing assigns work internally; it is not an outbound sales campaign. The guardrails explain where the draft should stop, ask, or hand a decision to someone else.
Compare those assumptions with your team's process. Write down the source of truth for amounts, ownership, severity, or access rights. If two systems disagree, decide which one wins before the agent runs. A useful draft makes missing information visible. It should not guess an approver or silently choose a customer record because that is the quickest way to finish the task. Review any instruction that leaves that choice ambiguous.
Review the invoice approval playbookConnect the tools the workflow actually needs
The integration names on a playbook describe its expected working environment. You still need to connect the accounts in your workspace and review the exact actions available to the agent. A logo in the catalog does not establish that your account has the necessary access, that a particular action is enabled, or that a destination exists. Check the mailbox, project, channel, folder, and account before testing a write.
Keep the first setup small. If the work needs Gmail and Jira, begin with the relevant mailbox and project rather than attaching every tool your team uses. Record who owns each connection and who can repair it if access changes. When adapting a playbook to a different system, review the instructions as well as the tool selection. Replacing a CRM name does not automatically translate field mappings, duplicate rules, or team ownership.
Check the integrations catalogDecide which actions need a reviewer
Review should happen where a decision matters. Reading a source document and drafting an internal summary may need different controls from sending a customer reply, changing access, or writing to a shared system. Name the reviewer for consequential actions and make sure they can see the destination, proposed change, and supporting context. A request that says only approve or reject leaves too much work with the person holding the gate.
The playbook's written guardrails describe intended behavior; review the configured permissions and approval gates during setup too. Decide what should happen when the reviewer rejects a request or the required information is missing. Keep the first draft private until those paths make sense. Starting from the library does not publish an agent, connect its tools, or grant permission for every action mentioned in the instructions.
Plan the approval pathTest the ordinary case and the awkward cases
A clean example proves less than it appears to. For invoice routing, include a missing purchase order, an amount mismatch, and a duplicate invoice. For support triage, include an unclear product area and a message that needs immediate human attention. For onboarding, leave out a required field and verify that the workflow asks instead of inventing it. These examples reveal whether the instructions express your real policy.
Inspect the result and the run trace together. Confirm that the right records were read, the intended destination was used, and the reviewer saw enough information. Use controlled accounts or destinations for tests that may write to connected systems. Keep a short record of what passed, what failed, and which instruction changed. The goal is a workflow the owner can explain, not just a run that reaches a completed state.
Publish deliberately and keep reviewing the work
Choose the trigger only after the draft behaves as expected. A schedule, an event, and a manual run each need a clear input boundary. Decide who checks the first runs and where unresolved cases should go. When the workflow reports a partial result, read what actually happened before trying again. Repeating a run without checking existing records can create extra work in the very system you are trying to simplify.
Keep dependable fixed automations where they already serve the team well. An agent earns its place when context, judgment, and review are part of the job. If you want help shaping that first workflow, Boring's services team can discuss the process and implementation with you. The same questions still apply: who owns it, which tools it touches, what needs approval, and what evidence counts as a successful result.
Discuss implementation helpCommon questions
Does choosing a playbook start a live agent?
No. It creates a private, editable draft. Connect the tools, review permissions and approval gates, test representative cases, and publish only when the behavior is right for your workspace.
Can I change the playbook's tools or instructions?
Yes. Treat the playbook as a starting point. If you change a system or destination, also review the instructions, expected fields, permissions, and exception handling. Test the adapted draft before publishing.
Which playbook should we try first?
Choose a recurring job with a clear owner, available inputs, and a result you can check. Start where review or coordination takes time, and keep the first workflow small enough to evaluate with real examples.
Are these templates a guarantee of autonomous completion?
No. Connected account access, input quality, configured actions, and human decisions all affect a run. The playbooks include guardrails and setup requirements so you can evaluate the workflow before using it for live work.
Start with a playbook. Make it yours.
Request access and tell us which agent fits — or bring your own workflow and we'll shape the private draft with you.