Connect Slack to a project and a message in a thread starts a session. The agent picks up its own cloud computer, does the work, and answers in the same thread. Nobody has to open a new tool to ask for something.
Slack today · Teams, email and voice behind a switch
A channel is a chat platform bound to a project — a closed set of four, not an open field. Here is the real state of each one, including the parts a marketing page usually leaves out.
On by default, no flag. Connect from the dashboard or the CLI, invite the bot to a channel, and mention it. Everything else on this page describes Slack.
Code complete and off by default. Your deployment turns it on and supplies Microsoft app credentials; a tenant admin then consents once. Same sessions, same identity rules as Slack.
A project inbox, so a message to an address starts a session and a reply continues it. Opt in per project under Customize → Settings → Experimental. Real, and not finished.
A realtime call the agent speaks in. Same per-project opt-in. It spawns a room and shares the link — it does not dial into a meeting you already started.
Telegram, WhatsApp, SMS and Discord are not channels, and this page will not imply they are on a roadmap it cannot promise. There is also no build-your-own-channel API — the platform list is a closed enum. What there is instead is a signed webhook trigger, and we would rather tell you its limits than sell you the word "extensible".
The honest alternative →The first message in a thread creates a session. Every later message in that thread reaches the same session — after the sandbox stops overnight, after the person who started it goes home. That mapping is a unique index in the database, not a convention two services agree to honour.
Open a change request against main?
launch-note.md · +64 −0
In a channel it has been invited to, or in a direct message. A bare mention with no task gets a reminder to add one, rather than a session nobody asked for.
Kortix cuts a branch and boots its own isolated cloud computer, exactly as it would for a session started from the dashboard or the CLI. You get a reaction on your own message, not a bot post saying “on it”.
It has a shell, a filesystem, the network, and whichever connectors and secrets its agent block grants it. The thread is where you watch. The machine is where the work happens.
The reply streams into the message it started, in the thread the question was asked in. Two people can watch. Neither had to open anything.
Two events for the same brand-new thread arriving at once do not produce two sessions: the second joins the first and is delivered as a follow-up. One Slack workspace bound to more than one project shows a project picker on the first mention instead of guessing.
On a host with the shared Slack app configured, kortix channels connect prints an install link and you are three clicks from done. On a deployment with no shared app, the same command falls back to manual mode by itself and hands you an app manifest to paste.
# managed: an install link, then pick the workspace$ kortix channels connect --wait→ connected: slack workspace acme-hq # self-hosting? the same command falls back to manual$ kortix channels manifest > slack-app.json$ kortix channels connect --manual \ --bot-token xoxb-... --signing-secret ... # check it, or take it away$ kortix channels status$ kortix channels disconnectA channel is only worth connecting if the answer arrives where the question was asked. Files go both directions, and the decisions an agent needs from you are buttons in the thread rather than a link to somewhere else.
The reply lands in the thread as one message that fills in, not a wall of updates. The agent finalises that message rather than posting a second one underneath it.
A file dropped in the thread is pulled into the agent’s cloud computer. A file the agent produces is uploaded back into the same thread. The deck lands where you asked for the deck.
When the agent needs a decision, it posts a card with buttons instead of blocking a turn forever. Your click is the verdict, and the session resumes from it in the same thread.
One honest limit: the card carries the decision and a link back into Kortix. Reading the actual diff of a change request happens in the web app, where a diff belongs — Slack is not a code review tool and we are not going to pretend it is.
Type these as /kortix <command> in Slack, or as plain text in a direct message. Most of what you would otherwise open the dashboard for is one line in the channel.
A message in Slack gets no privileges a session in the dashboard would not get. The surface changes. Nothing underneath it does.
There is no build-your-own-channel API — the platform list is a closed enum and we will not dress a gap up as a plug-in system. What ships is a signed webhook trigger that starts a session per conversation. It solves the inbound half well, and we will tell you exactly what it does not do.
# any conversational source, without channel-specific codetriggers: - slug: support-inbox type: webhook agent: support secret_env: WEBHOOK_SECRET # one session per conversation, not one per message session_mode: keyed session_key: "{{ body.data.conversation_id }}" # ignore the agent’s own outbound messages filter: "body.data.direction": "inbound" prompt: "{{ body.data.text }}"One session per conversation. session_key renders from the payload, so a single trigger fans out into a session per chat, per customer, or per repository — separate threads rather than one blended transcript.
A source that reports both sides of a conversation would otherwise fire the agent on its own reply. filter drops those deliveries with a 200 and no session. Signed with HMAC-SHA256, like every Kortix webhook.
No reply relay. A real channel streams the answer back for you; here the agent has to send the outbound message itself, through a connector you have granted it. Inbound is solved. Outbound is your wiring.
Open source and self-hostable. Any model, your keys. Kortix Cloud, your own VPC, or fully on-prem.