Playbooks

A playbook is a reusable method: when it applies, what information it needs, the steps to follow, the moments that need approval, and what counts as done. The agent reads the playbook before it starts and follows it. Playbooks are how a firm’s methodology, templates and sign-off rules become the default way the agent works.

Built-in playbooks

superglue ships with four playbooks that cover the common workstreams:

Playbook	When it applies
Discover a system	Analyze a system’s capabilities, data structure, quality, and migration readiness
Migrate data	Plan or carry out a migration, define mappings and transformations, validate the result
Build an integration	Build tools that read, write, or move data, one-off or recurring
Create an MCP server	Expose selected tools to an MCP client such as Claude or Langdock

They appear on the session start screen. Select one, or describe the task and let the agent match it. Built-in playbooks are read-only. To adapt one, open it under Brain → Playbooks and duplicate it.

Write your own

Open Brain → Playbooks and create a playbook, or ask the agent to draft one from a completed engagement: “Turn the way we ran the Contoso vendor migration into a playbook for GP to Intacct migrations.”

A playbook has these parts:

• Name: a recognizable workstream, such as “GP to Intacct: vendor and AP migration”.
• When to run: the trigger the agent matches against requests. Name the systems, the action or the recurrence.
• Inputs: the information the agent must have before it starts, with defaults and mapping notes. The agent checks the project’s resources for these first and asks you for whatever is still missing in one message.
• Instructions: the steps, the decisions, and the approval moments. For example, “Never load production before the reconciliation artifact is signed off.”
• Completion criteria: the outputs and checks that establish the work is done.
• Attachments: your mapping template, conversion checklist, cutover runbook and similar reference material. Refer to them by name in the instructions and say when the agent should read each one.

Link the systems, tools and credentials the playbook usually uses. Links provide context and do not restrict the agent from other permitted resources.

i

Keep decisions, completion checks and approval requirements in the playbook text. Put long reference material in attachments. The agent reads the playbook in full before every run, so a focused playbook is followed more reliably than a long one.

Improve playbooks from real work

After a run, ask the agent what it would change. When a session revealed a reusable correction, such as a code translation the target always needs, the agent proposes adding it. Corrections that apply to one client stay in that project; corrections that apply to the method go into the playbook.

The playbook editor has an agent sidebar. Ask it to tighten wording, add an approval step, or reconcile the playbook with a newer template.

Share playbooks with the team

Playbooks are organization resources and follow the same access rules as tools and systems. Give every consultant Viewer access to the firm’s playbooks, and Editor access to the people who own the methodology. See Role-based access control.