Automations

An automation is a rule that turns an event into work for your agents, so nobody has to start it by hand. A ticket is created in Jira, Linear or Notion, someone comments on a GitHub pull request, a job finishes, or a schedule comes round, and Kadmo starts a playbook on the ticket or runs a workflow on an agent. A typical rule: every new Bug in the ENG project starts the Bug Fix playbook. After that, filing the bug is all it takes. A person can also ask Kadmo in plain words where they work, with a @kadmo comment or a label on a Jira ticket, a Slack message or a Teams chat, and Kadmo decides which of the allowed playbooks and workflows the request asks for (Kadmo LLM decides).

How a request becomes work:

Each automation has three parts:

Part	In the form	What it is
Trigger	When — Trigger	The source of the event (Jira, Linear, Notion, GitHub, Figma, Kadmo or Cron) and its filters
Action	What — Action	A Playbook run on the ticket, a single Workflow job, or Kadmo LLM decides (Jira only): Kadmo reads a person's request and starts one of the actions the workspace offers
Options	Under the action	Where it runs, how it is approved, and how it reports back

Before you start

• Connect the source under Integrations. See Jira, Linear, Notion and Integrations. Until a source is connected, the form shows a notice such as Jira connection required or GitHub App installation required instead of its filters. Filters you saved earlier are kept.
• Have a playbook or workflow to run. The seeded playbooks (Bug Fix, Feature Implementation, Hotfix, …) are ready to use.
• Have an agent that can run the roles the playbook needs. See Agents.
• Optional: link the tracker project to a workspace, so runs land in the right repository. See Workspaces.
• For requests, tick what a request may start in the workspace's Started by request list.

Kadmo receives Jira and Linear events through webhooks, set up from the Integrations page when you connect the tracker. Notion boards are checked for changes every 5 minutes.

Create an automation

Only account admins can create, edit, switch off or delete automations.

1. Open Settings → Automations (app.kadmo.ai/automations).
2. Click New automation.
3. Enter a Name, for example Bugs to Bug Fix.
4. Under When — Trigger, pick the Trigger type and set its filters (see Triggers).
5. Under What — Action, choose Playbook, Workflow or Kadmo LLM decides and set its options (see Actions).
6. Click Save. The rule is live as soon as it appears in the list.

If something is missing, the form says so: Name is required, Trigger type is required, Workflow is required or Playbook is required.

Triggers

Every filter you set must match (they are combined with AND). A filter left at Any matches everything.

Jira

Filter	Matches
Project	The issue's project
Issue Type	The issue type, for example Bug
Assignee	A Jira user. Type a name and pick from the suggestions.
Status	The issue's current status name. This is not a from–to transition.
Trigger on events	Issue created, Issue updated, Comment added, Issue assigned (Jira app only)
Label added (optional), under Issue updated	Only updates that add this label, once, when it is added. One label, no spaces.
Mention, under Comment added	None — every comment, or Kadmo: only comments that mention Kadmo, through its app user, its Rovo agent, or @kadmo typed as text. Typed text counts only on a comment that mentions nobody else.

Label added and Mention work on every Jira rule, whatever its action. Each is greyed out until its event is ticked, and a filter on an event that is off is saved as none. Picking Kadmo LLM decides as the action ticks Comment added and sets Mention to Kadmo.

Linear

Filter	Matches
Team	The Linear team
Label	The issue's first label. Linear has no issue types, so a label stands in for one.
Assignee	A Linear user, picked from the suggestions
Status	The workflow state name
Trigger on events	Issue created, Issue updated, Comment added. With none checked, created and updated both count.

Comment events carry no labels, so a rule with a Label filter never fires on comments.

Notion

Filter	Matches
Data source	The board (database) the card belongs to
Type, Assignee, Status	The card's properties
Trigger on events	Card created, Card updated (properties)

Comment added is shown but not available yet: comments on Notion cards are not delivered. Cards created before the board was connected are not picked up.

GitHub

GitHub events come from the GitHub App you install under Integrations; there is no webhook for you to set up.

Filter	Matches
Trigger on events	Comment added (the default), Review submitted, PR opened, PR ready for review, PR updated, PR closed
Repositories	Repositories the app covers. None checked means all of them.
Mention	Any comment (no mention required), Connected GitHub identity, Kadmo AI handle or Custom login…
Minimum comment author	From Anyone (no floor) to Repository owner only. The default is Collaborator or better, so strangers cannot start work on public repositories.
Review verdict, Merge outcome, Base branch	Narrow review and PR events

A GitHub rule with a playbook action needs a specific playbook (not routed by issue type), and it works the ticket named in the pull request's description. A GitHub workflow rule needs the repository attached to a workspace.

Figma

Starts work from Figma: a comment is posted, a layer's Dev Mode status changes, a named version is saved, a library is published, and more. It needs a Figma connection and a Figma team, project or file bound to a workspace. Filters include Bindings, Mention, Keyword and Who can start work.

Kadmo

Fires when one of your own agent jobs completes. Filter by Workflow and Agent. Use it to chain work, for example running a check after a deploy workflow. With Same agent (from trigger) as the action's agent, the follow-up runs on the agent that did the first job.

Jobs started by an automation never fire a Kadmo trigger, so rules cannot loop.

Cron

Runs a workflow on a schedule. Enter a cron expression in Schedule (for example 0 9 * * 1-5), or pick a preset: Every hour, Daily 9am, Weekdays 9am or Weekly Mon 9am. A scheduled run is skipped while the previous one is still going. Changes take effect within a minute.

Actions

Playbook

Available for Jira, Linear, Notion, GitHub and Figma triggers. Choose the playbook:

• By issue type (recommended): each ticket runs the playbook its issue type maps to under Issue type routing. Types set to skip create nothing, and unmapped types are pooled for you to pick. See Issue type routing.
• Always use: <playbook>: every matching ticket runs that playbook.

Option	Choices	What it does
Run via	Add to Tasks (default) / Run immediately	Add to Tasks puts the ticket in Tasks, where runs start in dependency order. Run immediately starts the run at once.
Approval	Auto-approve / Hold for review	Auto-approve lands the task as Waiting; it starts when its blockers clear. Hold adds it to Tasks as Needs approval.
Sync ticket status	on (default) / off	Moves the ticket through its statuses as the run progresses.
Validate resolution	on (default) / off	Checks the finished work against the ticket's acceptance criteria.
Hint (optional)	free text	Instructions added to every run this rule starts
Effort tier	Auto or one of your tiers	The run's effort tier

Workflow

Runs one workflow as a single job. Choose the Workflow from your enabled workflows and the Agent:

Agent	Meaning
Any available agent	The first eligible agent takes it.
Same agent (from trigger)	Kadmo trigger only: the agent that ran the triggering job
All agents	One job per agent
A named agent	Only that agent

Under Workflow Parameters you can set a hint. A tracker-triggered workflow job also receives the ticket's URL, key, project, issue type, assignee and status as inputs. Cron rules always run on any available agent.

GitHub workflow rules can also acknowledge the comment (React with 👀, Reply on the pull request or Do nothing) and continue a live session. Figma workflow rules can reply when the job ends.

Kadmo LLM decides

The third action names no playbook or workflow: Kadmo picks one per request. It is described in its own section, Kadmo LLM decides.

Kadmo LLM decides

A Jira rule with this action turns a person's words into work. Someone writes @kadmo and what they need in a comment on a ticket, or adds the rule's label to it. Kadmo reads the request, decides which of the workspace's Started by request actions it asks for, and starts that action on the ticket with the rule's options. What the person sees on the ticket, and how they answer a question, is on Requests by comment.

Slack and Teams take requests through the same decision, set up on their own cards rather than with a rule: see Slack and Microsoft Teams.

Set up a request rule

1. On the workspace the Jira project is linked to, tick what a request may start under Started by request, and choose who may ask. An empty list starts nothing.
2. Open Settings → Automations, click New automation and pick Jira as the Trigger type.
3. Under What — Action, choose Kadmo LLM decides. The form ticks Comment added and sets Mention to Kadmo. To take requests by label as well, or instead, tick Issue updated and enter a Label added, for example kadmo.
4. Set a Project filter, or leave it at any project.
5. Set the options and click Save.

The form describes the action as: Kadmo reads the comment (or the labelled ticket), decides which of the workspace's Started by request actions it asks for, and starts it on the ticket. The list is set on the workspace's settings page.

There is no workspace picker. Each request reads the list of the workspace its ticket's project is linked to (see Tracker routing); a ticket in a project linked to no workspace is refused. Admins can also open this form filled in from New request rule in the Jira dialog on Integrations (see Jira); nothing is saved until you click Save.

The form says	Fix
Kadmo LLM decides needs Comment added with Mention: Kadmo, or Issue updated with a Label added	Tick Comment added and set Mention to Kadmo, or tick Issue updated and enter a label.
A label is one word — Jira labels have no spaces	Enter the label without spaces.

What Kadmo reads

• The request: the comment without the mention that addressed Kadmo (other people's mentions stay part of it). With a label, the ticket's summary and description are the request.
• The ticket: its key, type, status and summary, and the first 2,048 characters of its description.
• Kadmo's last reply on the ticket, so a follow-up request can refer to it.
• The person's name.
• The offered actions: the playbooks and workflows this person may start here, with their titles, descriptions and inputs. The workspace's list is narrowed by the person's own list, never widened (see Started by request).

Everything the ticket and the person wrote is read as data, never as instructions to Kadmo.

The decision

The model proposes; Kadmo starts only an action that is on the offered list as it stands at that moment.

Situation	What happens
Nothing is offered to this person	Refused, with no model call: Nothing can be started by request in this workspace yet., You are not on the list of people who may start work here. or Your Jira account is not linked to a person who may start work here.
The request is exactly an offered action's title, slug or workflow name (case and spacing ignored)	The fast path: it starts with no model call. An action with an input that has no default asks for it first.
One offered action fits, its inputs are complete and the model is sure	It starts.
More than one action could fit, or the model is not sure	A question with up to five numbered options.
The action needs an input the request does not give	A question for that input, by name.
The person asks what Kadmo can do here	The list of what they may start, up to 20 actions.
Nothing offered fits	The menu: I am not sure what to start for that. Here I can start: and up to five numbered actions.
The call fails, takes longer than 30 seconds, or the account's provider refuses it (out of credit, a budget used up)	The menu: Which one should I start? and up to five numbered actions.
The account has no provider	The menu, with no model call. Only the fast path and the menu run.
Confirm before starting is on	Instead of starting, Kadmo replies with what it would start and waits for go.

A question and the menu both wait for the same person's answer; Requests by comment explains how they answer and for how long. An answer is checked against the person's list again before anything starts, so a list that changed while the question waited is respected.

Options

The box is titled Options. It holds the playbook options, applied to whatever the decision starts, plus one of its own:

Option	Choices	What it does
Run via	Add to Tasks (default) / Run immediately	How a playbook it starts runs. A workflow is always queued as a job.
Approval	Auto-approve / Hold for review	For a playbook added to Tasks: the task lands Waiting, or Needs approval in Tasks.
Sync ticket status	on (default) / off	Transitions the ticket as the run progresses.
Validate resolution	on (default) / off	Checks the finished work against the ticket's acceptance criteria.
Confirm before starting	off (default) / on	Kadmo replies with what it would start and waits for “go” from the person who asked.
Hint (optional)	free text	Added after the request in what the work receives.
Effort tier	Auto or one of your tiers	The effort tier of what it starts

The action has no Agent and no Workflow Parameters. A workflow it starts runs on any available agent and receives the inputs the decision found, plus the ticket's URL, key, project, issue type and status. The work receives the request framed as the person's, never as system text: the decision restates it for the agent and adds nothing, with their name and the ticket.

The replies

Kadmo answers on the ticket with a new comment, posted as the Jira connection's identity, that mentions the person and links the comment that asked. By default every reply below is posted: that is the Standard setting for requests. Whether each one goes, and where else it goes (a Slack DM, a channel), is set on Reporting.

Reply	Moment	It reads
Started	Started	▶ QA Pass for @Ada on ENG-12: "the request", then the work line, for example Task #4 · queued, starts when an agent is free · Open in Kadmo
A question, or the menu	Needs you	The question, the numbered options, and Reply with the number.
An input is missing	Needs you	To start QA Pass I need environment. and Reply with the value.
Confirm	Needs you	I would start QA Pass: "the request" and Reply go to start it.
The list	Needs you	Here I can start:, the numbered actions, and Mention me with the one you need.
Refused	Needs you	The reason, for example You are not on the list of people who may start work here.
Could not be started	Needs you	QA Pass could not be started: and why, for example ENG-12 is already Task #4 in the task pool (waiting)
Busy	Needs you	ENG-12 is already being worked: the run's playbook, and the run's work line
Done	Done	✓ QA Pass on ENG-12 — done (or partly done), a headline, a short summary, findings, Next:, the files and pull requests, and the work line
Failed	Done	✗ QA Pass on ENG-12 — failed (or cancelled), laid out like Done

The Done reply follows the work: Kadmo looks for its end a minute after the start, then less often, at most every quarter hour. A playbook run ends when it is resolved, ended without action, escalated, failed, cancelled or sent back for rework; a pause is not an end. Work that has not ended seven days after the request gets no Done reply. The headline and summary come from the result call; when there is no provider or the call fails, the reply carries the facts from the records alone. What a run itself writes on the ticket, such as the comment when it halts, is on Reporting.

What it costs

A request makes at most two model calls, on the account's provider:

Call	When	Its answer
Decide	Once per request, unless the fast path or the menu answers it	At most 1,500 tokens
Result	Once, when the work has ended and a Done way writes text (a comment, a reply, a DM, a channel post, an e-mail)	At most 1,200 tokens

Each call is charged as every call is (How a call is charged), counts against the workspace's budget, and shows under Settings › Billing › Where it went as the lane Automations. Requests from Slack and Teams count under the lanes Slack and Teams. The work a request starts is charged as any run or job.

Nothing is sent, and nothing is charged, when nothing is offered, on the fast path, when the person answers a question, when the account has no provider or its provider refuses the call, and when no Done way writes text (a Done that only assigns, sets a field or a label, reacts with ✅, or is Silent).

What happens when an event arrives

1. Kadmo checks the event against every enabled rule of the source.
2. A rule that matches is checked further. It is skipped when:
   • webhook processing is paused for the account;
   • the event was caused by Kadmo itself, such as an agent's own comment or status change;
   • the ticket already has an active run (a ticket is never worked twice at once);
   • the event is a duplicate delivery;
   • the account is out of credit or over its daily cap.
3. Otherwise the action runs: the ticket is pooled or a run starts, or a job is queued.

The rule's page records the outcome, and the run reports back on the ticket as it goes.

Firing again on the same ticket is safe. The task's details are refreshed, but approvals and dependencies you set by hand are kept.

Comments and requests on Jira.

• An edited comment never fires a rule: it was already an event when it was written.
• Rules that address Kadmo (a Mention: Kadmo filter or the Kadmo LLM decides action) are checked first. Once one of them takes a comment, a comment rule without a mention filter skips it, so a status-and-comment rule does not also fire on @kadmo start QA Pass. Its log says comment claimed by rule #N.
• Each comment, or each label added, is one request. A redelivery finds it already claimed and does nothing.
• A request on a ticket a playbook run already drives is not skipped silently: Kadmo answers that the ticket is already being worked.
• A comment that does not mention Kadmo reaches a request rule only as the answer to a question the rule asked that person on that ticket. A rule that takes requests by label gets those answers too, without Comment added. A new mention starts over.
• While the account is out of credit or a budget is used up, the decide call is not sent and the person gets the menu.

Pause all webhooks

To stop all tracker-triggered work at once, switch Webhooks off on Issue type routing (Settings → Task setup). Incoming Jira and Linear events are then acknowledged but ignored; manual runs and the task scheduler are not affected. While it is off, the Automations page shows Webhook processing is paused for this account. with a Resume webhooks button.

The automation page

The list shows each rule with its trigger, its action (for example Playbook · Routed by issue type or Kadmo LLM decides), a Holds for review chip when approval is held, an Off chip when it is switched off, and N jobs linking to the jobs it has queued.

Click a rule to open its page. Under its name, the page says where it listens and what it starts, for example Jira → Kadmo LLM decides.

• Enabled / Disabled, plus Trigger now, Edit and Delete
• A Configuration card with the trigger, action, approval (Holds for review or Starts automatically), status sync, workspace, agent and effort tier
• Trigger execution logs: every matched event, 20 per page, marked MATCH or SKIPPED with the reason. Each links to what it started: Job #N, Run #N or Added to Tasks. Every webhook delivery → opens the account's webhook log.

Trigger now runs the rule by hand. A playbook rule asks for a Ticket URL (required), then Start run reports Run started. Run #N. A workflow rule's Start job reports Queued., with links to the queue and to the job. Trigger now is not available for GitHub rules, and not while the rule is disabled.

Every incoming event across all rules, matched or not, is listed under Settings → General → Logs → Webhooks.

Cost is not shown on the automation page. Open the run or the job it started to see what it cost.

A Kadmo LLM decides rule's page

A request rule has no Trigger now: it runs on what a person writes. Its Configuration card says the request filters and options in words:

Row	It reads
Mention	Kadmo, Comments that mention Kadmo
Label added	The label, Updates that add this label
Action	Kadmo LLM decides
Run via	Add to Tasks or Run immediately, for a playbook it starts; a workflow is queued as a job
Approval	With Add to Tasks: Holds for review or Starts automatically
Sync status, Validate	On or Off
Confirm	Confirm before starting (waits for “go” from the person who asked) or Starts without asking

The Started by request panel lists what the rule may start: the workspace, linked to the rule's project or named by the rule, Who may ask, and each offered action with a Playbook or Workflow chip. Edit the list opens the workspace's settings at the list. A person’s own list on the Team page can narrow this one, never widen it. Instead of the list, the panel may show a warning:

The panel says	Why
Nothing is offered — every request is answered with a refusal until actions are ticked on the workspace.	The workspace's list is empty.
No workspace bound — project ENG is linked to no workspace, so every request on it is refused.	The rule's project is linked to no workspace. Link it on a workspace's settings page.
No workspace bound to this rule — it listens on every project, …	The rule has no project. Each request reads the list of the workspace its ticket's project is linked to; pick a project on the rule to see that list here.

Each log row adds the decision in words after the event, for example comment_created — ENG-12 (In Progress) · decided: started QA Pass (pooled):

Words	Meaning
decided: started QA Pass (pooled)	Started: (pooled) in the task pool, (started now) as a run, (queued job) as a workflow job
asked — 3 options	A question with numbered options, or the menu's
asked for an input	A question for a missing input
asked to confirm QA Pass	Confirm before starting is on
answered: option → started QA Pass (pooled)	The person answered (option, input or go) and the work started
answered	The question was let go: the answer could not be read twice
listed the actions	The person asked what Kadmo can start
refused — no_list	The workspace's list is empty; not_listed: the person is not on it or is paused; not_linked: Who is Listed people only and the Jira account is not linked to a person
busy — active run #N	A run already drives the ticket
menu — no provider	The menu answered. Other reasons: declined (nothing fits), timeout, provider refused, provider error, invalid, cut off, unresolved
failed — …	The work could not be started, and why

Switch off or delete

Use the toggle on the list or the rule's page to pause a rule without losing it. A disabled rule matches nothing. Delete removes the rule and its logs; this cannot be undone.

Rules Kadmo creates for you

When you connect Jira or Notion, Kadmo adds a rule called Assigned to Kadmo Agent (Assigned to Kadmo Agent (Notion) for Notion). Assigning a ticket to Kadmo pools it with the playbook its issue type routes to. Edit or switch it off like any other rule. Switching it off is the lasting opt-out: a deleted rule comes back the next time the Jira site is linked, or the next time an admin tests the Notion connection.

Troubleshooting

Symptom	Check
Nothing fires	Is the source connected under Integrations? Is the rule enabled? Is webhook processing paused?
Fires on the wrong tickets	Filters are combined with AND, and an unset filter matches everything. In Linear, the label filter matches only the first label.
Comment events never fire	Comment added must be checked. On Linear, remove the Label filter. On Notion, comments are not delivered yet.
The log says matched but nothing started	Read the SKIPPED reason. Common ones: the ticket already has an active run, the task is pooled and waiting for approval or blockers, or the account is out of credit.
A pooled task never starts	See When an approved task does not start.
Runs land in the wrong repository	Link the tracker project to the right workspace.
A GitHub comment is ignored	Check Mention and Minimum comment author, and that the repository is covered by the app.
Nothing happens on @kadmo	The rule needs Comment added with Mention: Kadmo. Typed @kadmo counts only on a comment that mentions nobody else. The log may say no Kadmo identity is known for this Jira connection yet (reconnect or test the Jira connection), the comment could not be read, or a request rule on comments needs Mention: Kadmo. An edited comment never fires: write a new one.
A label does nothing	Tick Issue updated and enter the exact label; it fires once, when the label is added. The log may say a request rule on updates needs a Label added filter.
Kadmo answers Nothing can be started by request in this workspace yet.	Tick actions under Started by request, and link the ticket's project to that workspace.
Kadmo answers Your Jira account is not linked to a person who may start work here.	Who is Listed people only and the commenter's Jira account is linked to no person. Link it under People.
Kadmo answers You are not on the list of people who may start work here.	The person is paused, or their own list shares nothing with the workspace's. Check them under People.
The question was not answered	Only the same person's next comment on that ticket answers, without a mention, within the time on Requests by comment. A comment that mentions Kadmo starts a new request.
The menu came instead of a start	Read the log's menu — reason. no provider or provider refused: the account has no provider, is out of credit or over a budget (The Kadmo provider). timeout or provider error: try again. declined: the request matched nothing offered; name the action.
ENG-12 is already being worked	A playbook run already drives the ticket. Wait for it to end, or stop it.
… could not be started: ENG-12 is already Task #N in the task pool	The ticket already has a task in the pool; the brackets give its status, such as (waiting) or (done). Approve it in Tasks, or ↻ Reopen it there when it has finished.
The halt comment arrives about two minutes after the run paused	A paused run's comment waits about two minutes and is dropped if the run moves on: see How a notice is delivered.
No replies on the ticket	The request's ticket cells are set to post nothing: see Reporting.

Related

• Playbooks: what a playbook action runs
• Tasks: where pooled tickets wait and run
• Integrations: connect the sources
• Workflows: what a workflow action runs
• Reporting: what Kadmo writes back, and how to silence it
• Requests by comment: a request from the person's side, on the ticket