Skip to content

Route Slack work through repository playbooks

This agent is a Slack teammate for a product team. Mentions and direct messages reach it through an account-linked transport. New top-level posts in an allowlisted issue channel reach it through a dedicated Slack app, even without a mention. The agent then selects a repository playbook for triage, reproduction, fixes, reviews, on-call work, or design critique.

Use this example when Slack is the intake surface and your durable procedures already live as repository skills.

Browse the current playbook-router source.

Combine two Slack transports with repo skills

The playbook router uniquely combines three decisions:

  • Two Slack transports serve different engagement modes.
  • local.cwd keeps session workspaces inside the monorepo.
  • Instructions route work to inherited repository playbooks instead of authored agent/skills/.

The result is a thin agent project over a mature procedure library.

Follow an issue report

  1. A teammate creates a top-level post in the allowlisted issue channel.
  2. The dedicated Socket Mode channel accepts the allowlisted channel.
  3. A 15-second debounce lets edits settle. Deleting the post during that window cancels the dispatch.
  4. The Agent SDK creates a thread-scoped session and sends the report to the playbook router.
  5. The instructions select the matching triage playbook.
  6. The harness finds the repository root, opens the inherited playbook, and follows its procedure.
  7. The agent posts only in the source thread and reports the evidence it gathered.

Mentions and direct messages follow the same agent instructions. They don't need the watched-channel path.

Map the playbook router files

FilePurpose
agent/agent.tsNames the agent, selects its model, and keeps the harness under .agent-serve/harness.
agent/instructions.mdDefines engagement rules, evidence policy, and the playbook routing map.
agent/channels/slack.tsHandles account-linked mentions and direct messages.
agent/channels/slack-app.tsRuns the dedicated app and watches one allowlisted channel.
agent/storage.tsPersists sessions and events with cursorHostedStorage.
evals/evals.config.tsCaps eval run concurrency.
evals/smoke.eval.tsChecks the agent identity and expected triage route.

The playbook router authors no tools, MCP connections, subagents, schedules, hooks, A/B experiments, or sandbox seeds.

See why local.cwd matters

The Agent SDK normally keeps an ephemeral run or eval workspace outside a large monorepo. This prevents ancestor instruction and repository-rule files from leaking into an unrelated agent.

The playbook router needs the opposite. Its procedures live at the repository root, so agent.ts sets:

ts
local: {
  cwd: ".agent-serve/harness",
}

Each harness workspace lands under examples/benny/.agent-serve/harness/<sessionId>. Walking up the directory tree reaches the host repository and its inherited playbook directory.

Those playbooks are inherited context. agent-sdk info reports zero authored skills for the agent. Copying this project into another repository removes its main procedures unless you copy or replace the skill library too.

Connect both Slack paths

The account-linked path needs an agent-runtime login and a connected Slack account:

bash
agent-sdk login
agent-sdk whoami

It routes explicit mentions without a dedicated Slack token on the host.

For the watched-channel path, configure a dedicated Socket Mode app with:

  • subscribe to message.channels and message.groups,
  • have an App-Level Token with connections:write, and
  • be a member of the watched channel.

Run agent-sdk slack create --dir examples/benny --channel-posts for a dedicated Socket Mode app, then agent-sdk slack doctor.

Missing dedicated-app tokens leave that channel idle. They don't stop the account-linked channel.

Validate and start the server

bash
agent-sdk validate --dir examples/benny
agent-sdk info --dir examples/benny --json
agent-sdk dev examples/benny

The info output should show two Slack channels and no authored skill. That combination confirms the example is using inherited playbooks.

Exercise each engagement mode

Test the explicit account-linked path by asking:

Which playbook would you use to triage a product UI bug?

Test the dedicated app:

  1. Create a top-level post in the allowlisted issue channel.
  2. Don't mention the bot.
  3. Wait for the debounce window.
  4. Confirm the agent replies in the post's thread.

Thread replies don't trigger the proactive watch. Mentions still use Slack's normal mention path. Bot-authored posts are ignored to prevent loops.

The channel uses the default handler after filtering. It doesn't apply a second code-level classifier, so every accepted top-level post spends a model turn and reaches the prompt.

Inspect thread continuity

The Agent SDK keys Slack sessions by channel and thread timestamp. A follow-up in the same thread resumes the conversation and workspace. A new top-level issue gets a new session.

This lets a playbook gather evidence over several turns without mixing two reports. The playground shows both the account-linked and dedicated-app sessions while the dev server runs.

Run the smoke eval

bash
agent-sdk eval --dir examples/benny --list
agent-sdk eval --dir examples/benny smoke --json

The case asks for the agent identity and the playbook used for issue triage. It checks the configured identity and route label.

This is a lexical smoke test. It doesn't prove Slack delivery, skill selection, skill loading, procedure execution, or thread-only behavior. Add fixture-backed evals around the playbooks when you reuse this design.

Build a playbook-routed teammate

Use this structure when your organization already has tested skills:

  1. Put the playbooks under a stable repository path.
  2. Set local.cwd so harness workspaces can inherit that path.
  3. Write a short routing table in instructions.md.
  4. Use account-linked Slack for explicit requests.
  5. Add a dedicated app only for allowlisted proactive intake.
  6. Keep the channel allowlist narrow and debounce edited posts.
  7. Add an eval for every important request-to-playbook route.

If the procedures should ship with the agent, put them under agent/skills/ instead. Authored skills appear in the manifest and travel with the project.

Where to go next