Slack agent
How the Slack agent works
The Slack app lives inside the platform API and calls the MCP as the linked customer user, with that user's permissions.
How the Slack agent works
The HockeyStick Slack agent is not a separate product. It is a Slack adapter inside the platform API, a thin agent layer, and the same MCP and Public API that every other client uses. Know these pieces and most support questions answer themselves.
The pieces
| Layer | What it does | Where it lives |
|---|---|---|
| Slack app | Receives signed events and button clicks at /slack/events, handles install, App Home and private replies | backend/src/slack/ |
| Agent layer | Works out what the person wants, plans reads, builds confirmations, renders replies | backend/src/assistant/ |
| MCP and Public API | Does the actual reads and writes, with the linked user's token | The existing MCP server and API |
There is no separate Slack container and no Socket Mode. The receiver is mounted into the API process only when SLACK_ENABLED=true.
The agent runs as the customer user
When a person links their account, they sign in through HockeyStick sign-in and the agent stores a delegated grant for them. Every tool call in a turn goes to the MCP with that user's own token. So:
- The agent sees exactly what that user sees in HockeyStick, nothing more.
- A licence admits the person to the agent. It never adds business permissions.
- If their role or organisation changes, the next request reflects it.
What admission checks, every turn
Before any model call or tool call, the agent re-checks, fresh from the database:
- The Slack user is a full member of the workspace (guests are refused).
- The workspace is bound to the user's own organisation.
- The personal link is live (not revoked, not past its 365-day deadline).
- The user is a current
clientuser with an active licence on the current seat agreement, and Slack use is turned on for the organisation. - Pricing terms are current and the user and organisation have funded credit.
Any change to these between proposal and Confirm cancels the action.
What the model does and does not do
The model (claude-sonnet-5) extracts the request and, for open read questions, plans which read tools to call. It never chooses write tools freely, never writes confirmation text, and any partner name, month or amount it returns that is not in the person's own message is dropped. Diagnose, Prove and Activate are deterministic code paths.
Private by design
Business requests run only in the person's private Messages conversation with the app. A channel @mention gets a private nudge to continue in Messages; channel text is never forwarded into a turn.