Kadmo for Slack

What Kadmo does in Slack

Write what you need in a channel that Kadmo was invited to and that an admin of your Kadmo account connected. Nobody has to mention the bot: Kadmo treats every new message there, at the top level or in a thread, as a possible request, and skips edits, joins, thread replies also sent to the channel, and messages from bots, its own included.

Kadmo reacts to a new request with the eyes emoji, 👀, and works out which of the channel’s allowed playbooks and workflows it asks for. When the request is complete, the work starts right away and Kadmo confirms it in the thread. When it is unsure, it asks in the thread, with a numbered list of choices or a question for the one input it lacks, and only the person who asked can answer. While that question waits, their reply in the thread is read as the answer, and replies from anyone else there are not taken as requests.

Every playbook needs a Jira ticket to work on: the one the message names by key or link, or, when it names none, the one Kadmo asks for. When the playbook run ends, Kadmo replies in the thread with the outcome: a headline, a summary, what the agents found, the files and pull requests they made, and a link to open it in Kadmo. A workflow job answers instead with its agent’s own report. The reaction and every one of these replies are defaults: your admins choose under Kadmo’s notices where they go, or that they go nowhere.

Nothing starts in a channel Kadmo has not joined, and nothing starts that an admin did not allow for that channel and that person.

Who installs it, and what it needs

• A Kadmo account. One of its admins connects each channel and picks what may be started from it: a workspace’s playbooks and workflows, narrowed for the channel, or a list of the channel’s own, and narrowed again per person.
• A Slack admin. Where this page shows an Add to Slack button, a Slack admin installs Kadmo’s app for the workspace with it. Without the button, you create the app in your Slack workspace yourself, step by step in the docs’ setup guide.
• The channels you invite it to. Kadmo hears only the channels it is a member of.

The app asks Slack for these scopes, each for one reason:

• chat:write: to confirm a request, ask its questions and reply with the result in the thread
• reactions:write: to mark a message it has picked up with the eyes emoji
• users:read, users:read.email: to read the name of the person who asked, to link a Slack user to a person in your Kadmo account, and to find that person by e-mail when Kadmo writes to them directly
• channels:read, groups:read: to list the public and private channels an admin can connect
• files:read: to hand a file posted with a request to the agent doing the work

It subscribes to two events, message.channels and message.groups, which bring new messages from the public and private channels it is a member of. With them Slack grants channels:history and groups:history, which Kadmo also uses to read the thread above a reply.

What it reads

• The message as it was typed, and who wrote it: their Slack user id and name.
• For a reply in a thread, the conversation above it. Of that, the newest fifty messages, each cut to fifteen hundred characters and twelve thousand in all, go on to the model.
• For a ticket the message names: its key, type, status and summary, the start of its description, and Kadmo’s last reply on it.
• For a posted file, its name, type and size. When the work needs the file, the agent downloads it through a signed Kadmo link that stops working after seven days, and Kadmo streams it from Slack as it is read. Kadmo stores no copy of the file. The link is part of the request’s text, so the model’s first call and the request record carry it too, and whoever holds it can download the file until it expires.
• For an admin connecting channels: the names of the channels Kadmo is a member of. For an admin linking Slack users to people in your account: the workspace’s member list, names and e-mail addresses included, read for the search as it is typed, held in memory for a minute and not stored.

Kadmo reads no messages from a channel it is not connected to, and nothing older than the thread a reply stands in.

What it keeps, and for how long

• The connection of each channel: the Slack team and channel, the bot’s token and the signing secret, both encrypted at rest, the bot user, and the workspace the channel runs in.
• A record of each request it handled: the text as typed, with the links to any posted files, who asked, what Kadmo decided or asked, the replies it posted, the work it started and its result, and, for each model call, the model and the number of tokens. The prompts sent to the model are not kept.
• The Slack users linked to people in your account.

These stay for as long as your Kadmo account exists. Removing a channel deletes its connection and its list of allowed work. Unlinking a person removes the link. Deleting the account deletes all of it. To get a copy of what Kadmo holds about you, or to have it erased, write to the address under Your data on the support page; the privacy policy lists your rights.

The AI behind the answer

Each request makes at most two model calls: one to decide what was asked, and one to sum up the result when the work ends. They run on your account’s AI provider: the default model your admins chose on Kadmo or, where your plan includes it, a key of your own. The first call receives the message, the asker’s name, the thread excerpt, a named ticket’s details and the work the person may start, with its descriptions; the second receives the request again, the instructions the agents were given and what the work produced. The work itself is done by your account’s agents, on the models your admins set for them.

Kadmo does not train AI models on your Slack data.

AI output can be wrong. That is why Kadmo asks rather than guesses when a request is unclear and starts only work an admin allowed. Your admins also decide, in each playbook, what an agent may do on its own and where the run waits for a person in your team.