Appearance
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.cwdkeeps 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
- A teammate creates a top-level post in the allowlisted issue channel.
- The dedicated Socket Mode channel accepts the allowlisted channel.
- A 15-second debounce lets edits settle. Deleting the post during that window cancels the dispatch.
- The Agent SDK creates a thread-scoped session and sends the report to the playbook router.
- The instructions select the matching triage playbook.
- The harness finds the repository root, opens the inherited playbook, and follows its procedure.
- 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
| File | Purpose |
|---|---|
agent/agent.ts | Names the agent, selects its model, and keeps the harness under .agent-serve/harness. |
agent/instructions.md | Defines engagement rules, evidence policy, and the playbook routing map. |
agent/channels/slack.ts | Handles account-linked mentions and direct messages. |
agent/channels/slack-app.ts | Runs the dedicated app and watches one allowlisted channel. |
agent/storage.ts | Persists sessions and events with cursorHostedStorage. |
evals/evals.config.ts | Caps eval run concurrency. |
evals/smoke.eval.ts | Checks 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 whoamiIt 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.channelsandmessage.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/bennyThe 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:
- Create a top-level post in the allowlisted issue channel.
- Don't mention the bot.
- Wait for the debounce window.
- 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 --jsonThe 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:
- Put the playbooks under a stable repository path.
- Set
local.cwdso harness workspaces can inherit that path. - Write a short routing table in
instructions.md. - Use account-linked Slack for explicit requests.
- Add a dedicated app only for allowlisted proactive intake.
- Keep the channel allowlist narrow and debounce edited posts.
- 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.