Appearance
Integrations
The Integrations page in the app is where your account connects to the outside world: the git hosts your agents work in, the trackers that hand them tickets, the files and designs they read, the chat tools people start work from and the cloud accounts the agents run on. Every connection here belongs to the account, not to a single person, and every agent and workspace in the account uses it.
Open it from the sidebar (Integrations, at app.kadmo.ai/integrations). Cards are grouped, and each group header shows how many of its cards are connected. The AI providers (Kadmo, your own keys and Voice) have a page of their own, BYOK (see BYOK › Providers).
Who can connect what
Every member can open the page and read the cards. Connecting, testing a new credential, changing a connection and Disconnect are Admin actions: a User who tries one gets Forbidden: admin role required. Roles are set on the Team page (see Account and team).
Two exceptions are deliberately narrower than "an admin of this account":
- Some connections also need an admin on the other side — a Jira site admin installs the Jira app, a Linear workspace admin approves the Linear app, a Notion workspace owner creates the Notion integration, a GitHub organization owner installs the GitHub App.
- Microsoft Teams is connected by the Kadmo team for you (see Chat).
The cards at a glance
| Group | Card | How it connects | Line on the card |
|---|---|---|---|
| Git Hosting | GitHub | Personal access token, plus the optional GitHub App | Personal Access Token |
| Git Hosting | Bitbucket | Username + app password | App password |
| Git Hosting | GitLab | Personal access token | Personal Access Token |
| Issue Tracking | Jira | The Kadmo for Jira app, or a self-managed API token | Jira app (Forge) / Atlassian Jira Cloud |
| Issue Tracking | Linear | The Linear app (OAuth), or a personal API key | Linear app (OAuth) / Personal API key |
| Issue Tracking | Notion | Internal-integration token | Internal integration |
| Knowledge Sources | Google Drive | Google sign-in (OAuth), read-only | Read-only Drive access |
| Design | Figma | Figma sign-in (OAuth) as one Figma user | Design files, read as one Figma user |
| Messaging | Slack | Your own Slack app, one channel at a time | Drive agents from channels |
| Messaging | Microsoft Teams | Assisted tenant link, then people added by an admin | Start jobs from a 1:1 chat |
| Cloud | AWS | Access keys of an IAM user | Amazon Web Services |
| Cloud | Hetzner | Hetzner Cloud API token | Hetzner Cloud |
| Cloud | GCP | Not available yet — shown as coming soon | Google Cloud |
Each card opens a dialog with the connection's details, a Test button where there is something to test, and a Disconnect button in the footer. The Disconnect confirmation always says what stops working and what is kept — automations, workspace bindings and routing survive a disconnect, so reconnecting picks up where you left off.
Code hosting
The git-host credential is used by Kadmo itself, not handed to agents: it validates the connection, reads a skill-pack repository you bring yourself, and — when you allow Kadmo to edit your skill pack — commits or opens pull requests on that pack repository only. Your workspace repositories are never pushed to by Kadmo; agents push with their own credentials. Read-only access is therefore enough for the scopes below.
| Card | What to create | Scopes the card asks for |
|---|---|---|
| GitHub | A token at github.com/settings/tokens | repo, read:user |
| Bitbucket | An app password at bitbucket.org/account/settings/app-passwords, plus your Bitbucket username | account, repository (read) |
| GitLab | A token at gitlab.com/-/user_settings/personal_access_tokens | read_user, read_repository |
Paste the credential, press Test, then Save. A broader token is accepted — a GitHub token with user covers read:user, a GitLab token with api covers both read scopes. GitHub fine-grained tokens are accepted too; GitHub does not report their scopes, so a missing permission shows up only when an operation first needs it.
GitLab tokens expire. The card warns in amber when the token expires within 30 days and in red once it has expired — create a new token with the longest expiry you can and save it over the old one.
The GitHub App
The GitHub dialog has a second section, GitHub App. The token above is how agents push; the App is how GitHub reaches Kadmo: issue and pull-request comments arrive as events your automation rules can act on.
- Install sends an admin to GitHub to pick an organization and All repositories or a selection. The App requests read access to metadata and write access to contents, issues and pull requests.
- Installing wires the transport only. Nothing runs until you write a rule — the New mention rule link opens the automations form filled in, and saves nothing until you save it.
- The connected GitHub identity is the fleet's actor, and its own comments never trigger rules. Connect a dedicated agent user if you want mentions from your own account to be acted on.
- Unlink removes the link; tick Also uninstall from GitHub to remove the App from the organization too.
Trackers
Trackers hand tickets to your agents and receive their progress. Each has its own page:
| Tracker | What the connection is | Details |
|---|---|---|
| Jira | The Kadmo for Jira app (installed by a Jira site admin), or a self-managed API token with a webhook | Jira |
| Linear | The Linear app (an app user, not a billable seat), or a personal API key with a webhook | Linear |
| Notion | An internal integration that you share each board with | Notion |
After connecting, link a tracker project, team or board to a workspace on its Work intake card, so tickets route to the right repository and agents: see Tracker routing. How a run then reports on its ticket is on What a run writes on the ticket.
Per-account webhooks
On the self-managed paths, a Jira API token or a Linear personal key, tracker events reach Kadmo through a webhook for your account, which you register with Deploy in the tracker's dialog. The app paths need none: the tracker's app delivers its own events. The webhook URL carries a secret token for your account. Keep it private; if it leaks, press Regenerate, then Deploy again. Test Webhook checks delivery, and Logs → opens the webhook log.
Files and design
Google Drive
Connect Google Drive signs you in with Google and grants Kadmo read-only access (the drive.readonly scope) to the Drive of the account you sign in with. Kadmo sees exactly what that Google account can see, and never writes back. Chat agents read documents from it as a knowledge source (see Chat agents).
- One Google account per Kadmo account; connecting another replaces it. Sign in with the account that owns the shared folder, not a personal login — the card shows which account is connected.
- If the token stops renewing, the card reads Refresh failing or Expired; press Reconnect. Reconnecting the same Google account resumes syncing for documents already indexed.
Figma
Connect Figma signs in as one Figma user, and your agents act as that user. Sign in as a dedicated Figma user, not a designer's own login: its own comments never start work. Give it a Full or Dev seat and access to the folders your workspaces build from — a seat on Figma's low rate tier can read designs only 20 times a month, and the card says so when it sees one.
| Scopes requested | current_user:read, file_content:read, file_metadata:read, file_versions:read, file_comments:read, file_comments:write, file_dev_resources:read, file_dev_resources:write, folder_metadata:read, webhooks:read, webhooks:write |
| Binding | Bind a Figma team, folder or file to a workspace in the Design section of the workspace's edit page. The Figma dialog lists every binding under Bound workspaces. |
| Automation | New comment rule and New Ready-for-dev rule open the automations form filled in. Kadmo registers the Figma webhooks a saved rule needs by itself (when the rule is saved, and again every 15 minutes) and lists them under Webhooks with their last ping and delivery. |
| Limits | One Figma user per Kadmo account, and one Kadmo account per Figma user. |
Disconnecting stops Kadmo reading designs. Figma cannot revoke the app from Kadmo's side — also remove Kadmo from that user's connected apps in Figma if you want it gone.
Chat
People ask Kadmo for work in plain words where they already talk: a message in a Slack channel, or a 1:1 chat with the Kadmo app in Teams. Both are the same step as a request by comment on a Jira ticket. Kadmo reads the message, picks one of the actions that may be started there, and starts it, asks which one, or asks for what is missing. How it decides is under Kadmo LLM decides, and what a request costs on your AI provider under What it costs. The two channels differ in where the list of startable actions comes from, and in one gate: Slack starts as soon as the request is complete, Teams only after the person presses Approve.
Slack
Slack connects one channel at a time, through a Slack app you create in your own Slack workspace. Every message a person posts in a connected channel is a request, unless it answers a question Kadmo asked. Adding and removing channels and changing a channel's settings are admin-only. A member sees the channels and their lists, and reads Only an account admin can add or remove channels.
Setting up the Slack app
The Slack app setup guide at the bottom of the dialog walks through it:
- Go to api.slack.com/apps and create a new app.
- Under OAuth & Permissions, add the bot scopes
chat:write,reactions:write,users:read,users:read.email(direct messages),channels:readandgroups:read(the channel list), andfiles:read(files posted with a request). - Install the app to your workspace and copy the Bot User OAuth Token (starts with
xoxb-). - Under Basic Information, copy the Signing Secret.
- Under Event Subscriptions, enable events and set the Request URL to the address the guide shows. Today that is
https://app.kadmo.ai/api/slack/events. - Subscribe to the bot events
message.channelsandmessage.groups. - Invite the bot to your channel and add the channel details under Add a channel.
A Slack app set up earlier
The guide now asks for seven scopes, four more than the first guide: users:read.email, channels:read, groups:read and files:read. Add them to an existing Slack app under OAuth & Permissions and reinstall the app to your workspace; Socket Mode stays off. Until then, direct messages, the channel list and files posted with a request do not work.
Adding a channel
Add a channel opens the form:
| Field | What to enter |
|---|---|
| Team ID | Your Slack workspace's id, for example T0123ABC |
| Channel ID | The channel's id, for example C0123ABC |
| Channel name | Optional: the name shown on the channel's row |
| Bot token | The Bot User OAuth Token (xoxb-…) |
| Signing secret | The app's Signing Secret |
| Bot user ID | Filled in by Test connection. |
| Runs in workspace | The workspace the channel's jobs run in and are listed under, or Account only — no workspace |
| Started from this channel | The playbooks and workflows to tick (see below) |
Test connection checks the bot token with Slack, shows Connected: [team] ([user]) and fills in the bot user ID. Add channel saves.
Each connected channel is a row with its name, its team id and Remove. Under it, Runs in workspace can be changed in place, followed by the line that says where the channel's list comes from and the Started from this channel list with its count (None ticked, 3 ticked).
What may be started from a channel
What a channel offers depends on Runs in workspace:
| The channel runs in | The line reads | The list |
|---|---|---|
| A workspace | Inherits from [workspace], linking to that workspace's list | The workspace's Started by request list is the base. Ticks under Started from this channel narrow it: only the actions also on the workspace's list may be started here. Nothing ticked means no narrowing, so the workspace's whole list may be started from the channel. |
| No workspace | Account only — this channel’s list is the whole list | Only what is ticked may be started. With nothing ticked, the channel warns Nothing can be started from this channel until something is ticked below. |
A channel with no workspace keeps exactly what is ticked. Ticking every action holds the ones that exist now: a playbook or workflow added later must be ticked here. An action that has been switched off stays on the list, marked (off), and is not offered until it is switched on again. The person who writes narrows the list further through their own list on the Team page, and a workspace that allows listed people only needs their Slack user linked there (see People).
A message in the channel
Every message a person posts in the channel, at the top level or in a thread, is handled. Edits, joins and other message events are not, and neither are messages from bots, Kadmo's own included. You do not need to mention the bot.
A file posted with the message, a screen recording or a log, reaches the work: the agent reads it from Slack through a signed link that lasts seven days when it needs it, and Kadmo keeps no copy. The Slack app needs the files:read scope (Setting up the Slack app).
- Kadmo reacts with 👀 on the message straight away.
- It decides over the actions this person may start from this channel. A complete request starts at once: a channel has no Confirm before starting.
- It confirms in the thread: Got it — starting [title] on ENG-12. for a workflow job, or Started [title] on ENG-12: Run #N with a link for a playbook run. A playbook runs on a Jira ticket: the one the message names (a key or a link). If the message names none, Kadmo asks Which ticket should [title] run on?
- When it needs you, it asks in the thread with a numbered menu (Reply with a number or a name, or cancel to stop.) or for one missing input (What's the value for [input]? Reply skip to leave it empty, or cancel to stop.).
A question waits 24 hours, and only the person who asked can answer it, by replying in the same thread with a number, a name, a value, or a ticket key or link. A reply from anyone else in that thread starts nothing. cancel ends the request. An answer Kadmo cannot read is asked once more, and the next unreadable one is treated as a new request. A new message from the same person also starts over.
A reply in a thread is decided with the thread before it: who wrote each message, a bot's report read from its blocks, the newest 50 messages within 12,000 characters. continue starts the step the last report proposed, with the inputs said there.
When a playbook run that a message started ends, Kadmo replies in the thread with the result: its headline, summary and findings, the files and pull requests, and an Open in Kadmo link. It then edits its confirmation to the outcome: ✔ Done, ✖ Failed or ■ Ended, with the headline. A workflow job answers in the thread with the agent's own report when it ends: the verdict, the summary, a short body and the links the agent chose; the Done reply names its job once.
Those are the defaults. Where each of these messages goes, and whether it goes at all, is set by the Requests row of Kadmo's notices, Slack column. Silent posts nothing, and the request still moves on. See Kadmo's notices.
The dialog's first row, AI provider, shows what Slack decides on: Kadmo and its model, or your own key. With Kadmo, the row's Edit opens Settings › Models. An amber Needs an AI provider means nothing can serve. Then, and while Kadmo's credit or your budget is used up, the channel answers every message with its numbered menu instead of deciding.
Microsoft Teams
People write what they need in a 1:1 chat with the Kadmo app in Teams. Linking your Microsoft tenant is an assisted step: the Kadmo team links it for you, and your admins then add the people who may use it. Once a tenant is linked, the dialog shows it under Microsoft tenant with its last activity, and then the AI provider row, which reads like Slack's.
People
People are added one by one under Add a person (admins only; a member reads Only an account admin can add or remove people.):
| Field | What to enter |
|---|---|
| Work address | The address they sign in to Teams with (their user principal name). A guest is added by the address your tenant gives them, #EXT# and all. |
| Microsoft tenant | Only when the account has more than one tenant |
| Workflows this person can run | All current workflows — a workflow added later must be ticked here. or Only the ones checked below, with one checkbox per workflow. Neither starts selected. |
Each person's row shows their address and their state:
| State | Meaning |
|---|---|
| Waiting for first message | Added, not yet linked. Their first message in the 1:1 chat links the address to their Microsoft account. |
| Linked | They have written once, and their messages are handled. |
| Linked · Paused, Waiting for first message · Paused | Paused, and treated as not added |
Remove takes a person off the list. Anyone you have not added, have removed or have paused gets one reply to each message, You're not set up to start jobs from Teams yet — ask your Kadmo admin to add you., and nothing starts.
What a person may start
Workflows this person can run is the person's own list on the Team page (see People):
- All current workflows — a workflow added later must be ticked here. ticks every workflow the account has now. A workflow added later is not included until someone ticks it. Earlier, All workflows included later ones.
- Only the ones checked below keeps exactly the ticked workflows.
- The Teams dialog edits workflows only. Playbooks are given to a person under Team › People, and saving the Teams list keeps them.
When the message names a Jira ticket, as a link or as the key of a project linked to a workspace, that workspace's Started by request list is the base, and the person's list narrows it. Without a ticket, the person's list alone decides.
A Teams message
Teams always asks before it starts: Confirm before starting is on for every Teams request.
- Kadmo decides over what this person may start. When it knows what to run, it sends the Approve card: Run [title]?, the action's description, the ticket (On ENG-12), the request as restated for the agent, every input with its value (marked (default) or (empty)), and Nothing starts until you approve., with Approve and Cancel.
- When it is not sure, or the person asks what they can run, it sends the menu card instead: a lead line (for example Which of these should I run?), an Action choice and Choose. After a pick, it asks for any missing input, and for a playbook the ticket (Which ticket should [title] run on?), then sends the Approve card.
- On Approve, Kadmo checks the person, their list, the action and the inputs again, then starts. A ticket that already has an active run is refused as busy. A card works once and expires after 24 hours (That card has expired — send your request again.), and a new message replaces the waiting card. Typing
cancelends a waiting request. - A workflow job answers Queued — I'll post here when it finishes., and the job's follow-up posts its outcome in the chat. A playbook run answers Started [title] on ENG-12: Run #N with a link. No result message comes back in Teams for a run that Teams started: follow it on the run's page or on the ticket.
These replies follow the Requests row of Kadmo's notices, Teams column (by default, a reply in the chat). The Approve card is a Needs you reply, so a Teams Needs you cell set to nothing (as Silent sets it) means nothing can be started from Teams. See Kadmo's notices.
Clouds
The AWS and Hetzner cards hold the cloud accounts your agent machines are created in. Setting one up: Connect AWS, Connect Hetzner.
The connection card
Once connected, a cloud card shows the Connection, Region, Status and when it was Validated. Its buttons:
| Button | What it does |
|---|---|
| Validate | Checks the stored credentials again: "Credentials valid ✓" |
| Rotate credentials | Replaces the credentials (Rotate & validate) and keeps the connection's name |
| Disconnect | Removes the connection and the account's agent firewall. Refused while agents still use it |
The AWS card also sets the Agent subnet: until one is set, agents cannot launch there (see The agent subnet). Credentials are stored encrypted (AES-256-GCM) and never returned by the app. Settings → Cloud lists the same connections under Providers, next to the firewall allowlist and the cloud audit log (see Cloud).
The agent firewall
Kadmo keeps one firewall per account in your cloud, shared by every agent there: a security group per VPC on AWS, a firewall on Hetzner. It admits:
| Port | From | Why |
|---|---|---|
| 9876 (TCP) and ICMP | Kadmo's app network only | The app talks to the agent runtime |
| 22 (SSH) and 3389 (RDP) | The addresses on your firewall allowlist and, where Kadmo's deployment names them, Kadmo's operations ranges | So people can reach the machine directly |
On AWS the address you launch from, and on Hetzner the address you connect from, is added to the allowlist. Edit the list under Settings → Cloud → Firewall allowlist (Add, Add my current IP, Save allowlist). You never type a Kadmo address into your cloud: the app writes the rules.
Voice
The Voice row on BYOK › Providers turns speech into text for the chat: the microphone in the Ask box, in a goal's chat and on the chat page (Speak). It is on for every account, with nothing to connect, and its dialog has a Try that records up to 20 seconds and shows the text it heard.
| Where it runs | Through Kadmo, in the EU, by default. An account whose plan includes own keys can transcribe on its own OpenAI key instead (Your own keys) |
| What it costs | Per second of audio, from your Kadmo credit; the price is on kadmo.ai/pricing. It shows as a Voice lane in the credit's Where it went |
| Limits | A note runs up to two minutes. English and German; the workspace's own names are given to it so it spells them right |
Errors you may see
| Message | What it means | Fix |
|---|---|---|
Forbidden: admin role required | You are a User, and the action is admin-only. | Ask an Admin, or have your role raised on the Team page. |
| Connection not completed — The connection was declined. A workspace admin has to approve the Kadmo app… | The provider's admin has not approved the app (Linear and similar). | Ask the workspace admin to approve the pending request, then connect again. |
| Connection not completed — The approval did not grant every permission Kadmo needs. | A permission was unticked on the consent screen. | Reconnect and accept every requested permission. |
| Connection not completed — The user you authorized is already connected to another account. | That Figma (or other) user is linked to a different Kadmo account. | Disconnect it there first, or sign in as a different user. |
| Connection not completed — The connection session expired before you got back. | The sign-in took too long, or ran in another browser session. | Start connecting again from the card, in the same browser. |
| Refresh failing / Expired on a card | The stored grant can no longer be renewed. | Press Reconnect in the card's dialog. |
| …is not available on this deployment — the … app credentials are not configured. | The provider's app is not set up on this installation. | Contact Kadmo support. |
| Nothing is enabled for this channel yet — ask your Kadmo admin to choose it under Integrations → Slack. | The Slack channel runs in no workspace and nothing that can be started is ticked on its list, or its ticks share nothing with its workspace's list. | Tick actions under Started from this channel (on a channel with a workspace, ones that are on the workspace's list), or pick a workspace under Runs in workspace. |
| Nothing can be started by request in the [workspace] workspace yet — … | The channel's workspace has an empty Started by request list. | Fill the list on the workspace (see Started by request). |
| You are not on the list of people who may start work from this channel — … | Your own list, the workspace's and the channel's have nothing in common, or you are paused. | Ask an admin to change your list under Team › People. |
| Your Slack account is not linked to a person who may start work here — … | The workspace allows listed people only, and your Slack user is linked to nobody. | Ask an admin to link your Slack user under Team › People. |
| You're not set up to start jobs from Teams yet — ask your Kadmo admin to add you. | You are not on the Teams list, or you are removed or paused. | Ask an admin to add you in the Microsoft Teams dialog. |
| No workflows are enabled for you yet — ask your Kadmo admin to choose them under Integrations → Microsoft Teams. | Your Teams list names nothing that can be started. | Ask an admin to tick workflows for you, or give you playbooks under Team › People. |
| No workflows are configured on this account yet — ask your Kadmo admin to set them up. | The account has no workflow that can be started. | Create a workflow, then tick it on the Teams list. |
| Nothing can be started by request in ENG-12's workspace yet — … | The message names a ticket whose workspace has an empty Started by request list. | Fill the list on the workspace (see Started by request). |
| You are not on the list of people who may start work in ENG-12's workspace — … | Your own list and the ticket's workspace list have nothing in common. | Ask an admin to change your list under Team › People. |
| Your Teams account is not linked to a person who may start work here — … | The ticket's workspace allows listed people only, and your Teams person is linked to nobody. | Ask an admin to add you on the Team page. |
| That card has expired — send your request again. / That card was already used or replaced. | A Teams card works once, for 24 hours, and a newer message replaces it. | Send the request again. |