Add an AI agent to Slack, then give it an open-source runtime

Where the Slack quickstart stops

Slack's own guide to building agents is blunt about the division of work. "Agents are not inherently safe", it says, and it puts the permissions and the human checkpoints on the developer as engineering requirements (Slack's guide to building agents). That split is the whole setup problem. Slack hands you channels, threads, cards and an identity. The sandbox the agent runs in, the credentials it uses, and the record of what it ran stay with whoever builds the app.

A quickstart gets a bot that answers in a thread. Most teams read that reply as the finish line. Then they hit the second install: something has to hold a Gmail account and a database password, decide when a call needs a person, and keep the work after the thread goes quiet. None of that is a Slack setting.

A thread that keeps working

One Slack thread is one session. The first message in it starts that session, and later messages continue it. Behind the thread sits a session on its own sandbox, and that sandbox can stop and resume without losing the thread, so a question asked on Monday does not restart the work on Tuesday. That mapping decides how the thread behaves, which is worth knowing before you invite anyone. In a channel, only a mention reaches the session. A reply without a mention stays between people. A mention with no text and no file gets a help reply instead of a run. In a DM, every message reaches the session, and that session stays private to you.

The join policy decides who may join a session a channel message started. The default, project_open, lets any linked project member in. owner_approval puts Approve and Deny on the session owner for each new person. owner_only keeps the session to the person who started it.

Who the agent acts for

A Slack message carries no Kortix credential. Each person links an account once, and from then on the session runs on behalf of that person. Kortix checks that the sender may run the agent and holds project.session.start. The agent then acts with its own grant, not with the sender's role. One consequence is worth planning for. The sender's own connector accounts and provider keys reach only a DM, which is private to that person, while a channel gets the accounts shared with the whole project. An unlinked sender gets a prompt to connect instead of a run. A linked sender without access to the project gets a card to request it.

The call that waits

Approval gates you set. Off until you set them. Once a rule asks, the runtime holds the call before it runs. A connector call that needs approval returns 202 with status: "pending_approval", and nothing has happened yet. The thread gets a card with the action, the parameters the connector will receive, and the agent's description of the effect, marked as not verified. Approve or Deny sits on the same card. An approval covers one exact request: the same connector, action, arguments and account. A changed argument needs a new one. That is why the hold belongs on the runtime and not in the message. A Slack reply cannot stop a call that already ran.

What to check after the first run

Run kortix channels status and read the workspace, the bot user and the webhook URL it prints. Send /kortix whoami in Slack to confirm which account a person is linked as. Then mention the bot in a bound channel with a real task and watch where the session lands. A workspace can serve several projects, and the first message in an unbound channel asks which one. Decide the join policy for that channel before the second person arrives. Slack and Microsoft Teams are live. Email is experimental, per project.

• Read the guide: Getting started with Kortix.