Slack Integration

Your runner runs on your own machine. Slack is how your team reaches it: @mention the Evident bot in a channel or send it a direct message, and your message is routed to your runner. Replies come back in the same thread, with a link to open the full conversation in the chat.

Setup

1. Connect your Slack workspace

Open your Slack settings and start the Slack OAuth flow from the integrations page. Authorize the Evident app in Slack, and you'll be redirected back to the integrations page showing Connected.

The connection belongs to your team, not to the person who set it up: everyone on the team shares the same connection, default runner, and enabled state. Each team has its own, isolated Slack connection — connecting (or disconnecting) one team never affects another.

2. Set a default runner

Choose the default runner that handles Slack messages. Unless a per-channel or inline override applies, every message routes to this runner.

If no default runner has been configured yet, the bot will tell whoever messages it that a runner needs to be set up first — it won't silently do nothing.

3. Start messaging

In a channel the bot is in, @mention it (for example @Evident help me with this code). Or send the Evident bot a direct message. Either way, a conversation is created for that thread and the message is sent to your runner.

How messages flow

1. You @mention the bot in a channel, or DM it directly.
2. The bot reacts to your message to acknowledge it was received — a "waiting" reaction while the message is queued, swapped for a "running" reaction once the runner actually starts working on it.
3. Once the runner starts running, a notice with a small "View in Evident" link is posted at the top of the thread so you can watch progress live in the chat. (No link is posted while the message is only queued — there's nowhere specific to point at yet. The link is posted once per thread.)
4. When the agent finishes, its reply is posted back in the same Slack thread and the acknowledgement reaction is removed.

Channels, threads, and DMs

• The bot only acts when mentioned. Plain channel chatter that doesn't @mention the bot is left alone — no response, no conversation created.
• Each thread is its own conversation. Two different threads in the same channel create two separate conversations, each with its own context. Follow-up messages in a thread continue the same conversation.
• Direct messages create a conversation too, and the agent replies in the DM.
• Thread context. When you mention the bot in an ongoing thread, the runner is given the thread's messages since its last reply as context — so it can act on earlier instructions it wasn't directly mentioned on. The first message in a brand-new thread has no prior context.

Choosing the runner for a new thread

There are three levels of control, in increasing precedence. An inline override on a new thread wins over a per-channel override, which in turn wins over the workspace default runner.

Per-channel overrides

From your Slack settings you can assign a specific runner (and OpenCode agent/model) to a channel. For example, assign code-reviewer to #pull-requests: messages there route to code-reviewer, while messages in other channels keep going to the default runner.

Inline message overrides

You can also choose, right inside a message, which runner, which OpenCode agent, and which model handle it — without an admin changing any settings. Write the choices at the start of the message, after the bot mention:

• Runner — in square brackets: [runner] (by name or by its identifier)
• OpenCode agent — after a plus sign: +agent-name
• Model — in curly braces: {model}

Each part is optional, and they may appear in any order. For example:

@Evident [code-reviewer] +plan {anthropic/claude-opus-4.8} review this PR

This sends "review this PR" to the code-reviewer runner, with the plan agent, using the anthropic/claude-opus-4.8 model. The choice markers themselves are never part of what the runner is asked to work on — only the remaining text is.

How they behave:

• Any order, all optional. {model} [runner] +agent-name … works just as well as [runner] +agent-name {model} ….
• Runner choices start a new thread. A reply stays with the runner that started its thread; naming a different runner in a reply is privately refused. OpenCode agent and model choices continue in the thread until replaced. Each inline choice on a new thread overrides per-channel or default settings.
• Only leading markers count. Markers must come first, before the rest of your message; a bracket or brace mid-sentence is treated as ordinary text.
• The same syntax works in direct messages.
• Unknown runner → graceful fallback. If you name a runner that isn't in your team (or belongs to another team), you're privately told it couldn't be found and your default runner is used. Your message is never routed to anyone else's runner.

Questions and permissions

Sometimes the agent needs interactive input mid-task — it has a question, or it's asking for permission to do something. Evident does not try to collect that answer in Slack. Instead:

• A notice is posted in the thread saying the agent has a question (or is requesting permission), @mentioning the person whose message triggered it.
• The notice carries an "Open" button that opens the conversation in your chat — at that specific conversation when its location is known.
• You make the decision in your chat, not in Slack. There are no answer buttons, and no Approve/Deny buttons, in Slack.
• While the agent waits for your answer, the turn is not reported as done and no reply is posted yet. A repeated request for the same input posts only one notice.

As soon as you answer in your chat, the same turn resumes: its reply is posted to the Slack thread, the processing reaction is removed, and the original notice updates to show the request was answered (the "Open" action is removed). If the turn ends without succeeding, the notice updates to show the request is no longer active.

The "View in Evident" link

Every reply posted back to a thread includes a small "View in Evident" link. It opens the conversation in your chat so you can dig into the full answer — at that specific conversation when the working location is known, or the chat otherwise. This is also how you watch a long-running task live. The link keeps working if your runner restarts or the conversation moves to another runner.

When your runner is offline

Slack messages are never rejected for being offline. If your runner isn't connected when a message arrives, the bot still reacts to acknowledge it, and the message is held. When the runner connects and processes the message, the response is posted back to the Slack thread and the acknowledgement reaction is removed on completion. You never lose a message.

Disconnecting

Disconnecting Slack unlinks the workspace for the whole team and stops the bot responding, so it's an admin-only action: a regular member who tries is told they don't have permission, and the connection is left unchanged. An organization owner or admin can disconnect from the integrations page — and then connect a different workspace if they want.

Tips

• Use threads for multi-turn work — each thread maps to a single conversation.
• Keep your runner connected so messages are answered promptly (offline messages are still queued and answered on reconnect).
• Use the "View in Evident" link to answer questions, grant permissions, and read the full response.

Next steps

• Local runner — keep your runner reachable from your machine
• Teams & auth — roles, scoping, and who can disconnect Slack
• Model providers — connect a provider so your runner can answer