Appearance
Tasks
The Tasks page is where you hand work to your agents. You drop tickets into the task pool: a list of keys, a whole epic, a query, or a new ticket you describe. Each ticket picks up a playbook, and the scheduler starts it once its blockers are done and a slot is free. The pool is built for batches you drop and leave. It is also where you start a single playbook run and watch it.
Every task maps to one playbook run, or to several if it is reworked or reopened. Every run is a chain of jobs worked by your agents.
How the pool works
- You add tickets. Each ticket becomes one task. A ticket is in the pool at most once per account.
- Each ticket gets a playbook. The playbook comes from its issue type through Issue type routing, so a bug gets Bug Fix and a story gets Feature Implementation. You can change it per ticket or for the whole batch.
- Blockers come from the ticket. A ticket's is blocked by links become task dependencies when the blocking ticket is in the pool too. Links to tickets outside the pool never hold a task back.
- You approve. An approved task is Waiting. The scheduler starts it as a playbook run when every blocker in the pool is Done and the workspace has a free slot.
- Agents work the tickets. Each run reports on its ticket step by step, and the task follows the run to Done, Failed or Cancelled.
Tasks can also arrive without you: an automation can pool a ticket from a tracker event, a goal pools the tasks of its plan, and the Kadmo MCP server's work_on_task tool pools a ticket from an AI client (see MCP).
Add tickets
The card at the top of the page has two sides: Add tickets and Run a playbook. Add tickets has four modes:
| Mode | What it adds |
|---|---|
| List | Each key or link becomes one task, from any project. Commas, spaces or new lines all work. Up to 200 keys per paste. |
| Epic | An epic and all of its child issues |
| JQL | Every issue that matches a Jira query |
| Create | A new ticket written from your description |
Epic and JQL read from a connected tracker. An account with no tracker sees only List and Create.
In Create, the first line of your description becomes the Title; you can edit it. Where chooses where the ticket is filed: an internal task, or a project of your tracker. You can also set the Type and the Priority, and Attach files.
Then commit the batch:
| Button | What happens |
|---|---|
| Add | Pools every ticket as Pending. Nothing runs until you approve each task. |
| Add & approve → | Approves every ticket with the playbook its type routes to, or the one set in Options. Runs start in dependency order. Shortcut ⌘↵. |
⚙ Options sets the playbook, effort tier, status sync, validation and a shared hint for the tickets you add now. Reset clears them.
Internal tasks
You do not need Jira, Linear or Notion. Without a tracker, a new ticket becomes an internal task kept by Kadmo, keyed TASK-n or with the workspace's own prefix. Internal tasks work like tracker tickets: agents read them and post their reports as comments, and their status follows the run. With a tracker connected, both kinds live side by side.
Run a single playbook
The Run a playbook side of the card starts one run now, on one ticket or a description. You pick the playbook and watch it run. The run starts at once, without waiting for approval or blockers, and lands in Active. See Start a run.
The views
Switch views with the lens bar under the card:
| View | Shows |
|---|---|
| Active | What needs you, then what is in flight. Its count lights up while something needs you. |
| Board | One column per task status, with the cards that need you first |
| List | The sortable ledger with every column |
| Runs | Every playbook run, newest first (see Run history and cost) |
| Validation | Judged deliveries: read a verdict and answer it |
Active
Needs you lists the tasks waiting on you: approve them, open a halted run, or resolve a blocker that failed. In flight lists what is running, waiting and halted.
- Approve → approves one task. It is disabled with Pick a playbook first until the task has a playbook.
- Approve all (N) → approves every pending task.
- Open run #N › opens a halted run so you can decide.
Click a task to open its run in a panel on the right: the live step ribbon, the activity feed, elapsed time and cost.
List
The columns are Task, Playbook, Priority, Blocked by, Progress, Status, Validation, Duration, Completed, Updated and Run. Click a column header to sort; the default is the most recently updated first. Search by key, title, playbook or blocker, and filter by playbook, type, status, validation verdict and priority. The list shows 50 rows per page.
Each row's ⋯ menu offers what fits its state:
- ⊘ Cancel run
- ↻ Reopen, which puts a finished task back to Pending with its playbook, blockers and options
- ✓ Validate resolution
- ▤ Archive now or ↥ Restore
- ✕ Remove from pool
Board
The board has one column per status in your Task statuses list, in that order: To Do, In Progress, In Review and Done out of the box. A card sits in the column of its ticket's current status. Inside a column, cards that need you come first, then cards by priority. The Done column keeps the past day; older tasks are in the List.
Archive
Done tasks are archived after 14 quiet days, unless a validation verdict is still open. The line at the foot of the page, ▤ Archived · N tasks finished more than 14 days ago, has Show archive to see them.
Priorities
A task's priority is its ticket's priority in your tracker. The tracker is the source of truth, and Kadmo refreshes the priority when the ticket changes and when a run starts. Internal tasks take the priority you set in Kadmo.
Kadmo uses five levels, and maps your tracker's names onto them:
| Level | Tracker names that map to it |
|---|---|
| Highest | Highest, Blocker, Critical, Urgent, Showstopper; Linear priority 1 |
| High | High, Major, Important; Linear priority 2 |
| Medium | Medium, Normal, Moderate, Standard; Linear priority 3 |
| Low | Low, Minor; Linear priority 4 |
| Lowest | Lowest, Trivial, Cosmetic |
Jira priority names not in this table are placed by their position in your site's priority list. A ticket with no priority counts as Medium. The chip keeps your tracker's own word. Highest is shown in red and High in amber; Medium shows no chip on rows.
Priority decides order in two places:
- Which task starts first. When a workspace has fewer free slots than ready tasks, the scheduler starts the highest priority first, then the oldest. A high-priority task never jumps ahead of its own blocker.
- Which queued job an agent takes first. The job queue is ordered by any manual reorder you made, then by ticket priority, then by age.
How an agent picks up a task
Work reaches an agent in two stages.
1. The scheduler starts runs. It runs on every approval, on tracker webhooks and every 60 seconds. For each waiting task it checks, in order:
- Blockers. If a blocker in the pool failed or was cancelled, the task is held and shows in Needs you. If a blocker is still unfinished, the task keeps waiting.
- Goal steps. If a step of its goal that only a person can do is still open, the task waits.
- The workspace pool. The workspace's Pool size caps how many pooled runs are active at once. A task that does not fit stays Waiting and is tried again on the next pass.
It then starts the task's playbook run, one dependency layer per pass.
2. An agent claims the step's job. Every 15 to 30 seconds the dispatcher offers each queued job to an eligible agent:
- The agent is online and reachable, and it is not already running a job. Each agent runs one job at a time.
- The agent holds the step's role, or it is unrestricted. You manage roles under Capabilities → Agents.
- The agent can work in the task's workspace.
- A job pinned to an agent waits for that agent.
Each job is claimed by exactly one agent; two agents never take the same job. Pool size caps starts; it does not reserve agents. If the pool is larger than the number of agents, the extra runs wait for a free agent.
Pool size is set per workspace under Run configuration (0 to 100). A pool size of 0 pauses playbook starts in that workspace: Playbook starts are paused in this workspace — its pool size is 0. Approved tasks keep waiting.
Task statuses
Where a task is in the pool
| Status | Meaning |
|---|---|
| Pending | In the pool, not approved yet. You can change its playbook and blockers. |
| Waiting | Approved, and waiting for its blockers or a free slot. A running task also shows Waiting while it is between steps. |
| Running | Its playbook run is working. |
| Paused | Its run is halted at a gate, or waiting for you to pick an experiment branch. |
| Done | The run resolved, or closed with nothing to do. |
| Failed | The run failed, escalated or ended as QA Fail. |
| Cancelled | The run was cancelled. |
A task's playbook and blockers are locked once its run has started. To change them, cancel the run or reopen the task.
The ticket's own status
Settings → Task setup → Task statuses (app.kadmo.ai/tasks/statuses) lists the status names your playbooks set on a ticket. Each has a category: new, in flight or done. The defaults are To Do (new), In Progress and In Review (in flight), and Done (done). The order of the list is the order of the board's columns.
- Names are matched against your tracker at run time. An unknown name is skipped and logged, and the run carries on.
- A status still used by a playbook or an issue cannot be deleted; the page lists where it is used.
- At least one done status must remain.
- Only admins can edit the list.
Validation
When Task validation is switched on (Settings → Task setup → Validation), a validation agent checks each finished run's ticket against its acceptance criteria and flags gaps. Its verdicts land in the Validation view, in three groups: To decide, Validating and Decided. A verdict to decide is one that found the work incomplete or could not verify it. Answer it with Re-validate, Reopen or Accept as is.
When an approved task does not start
The page says why next to the task:
| Reason | Fix |
|---|---|
| it has no playbook yet | Pick one on the row. |
| waiting on its blockers | Nothing to do; it starts when they finish. |
| a blocking ticket has failed/cancelled | Resolve the blocker on its row, or remove the dependency. |
| this account is over its daily run cap | It starts after the cap resets at midnight UTC. |
| no tracker is connected for its ticket | Connect the tracker under Settings → Integrations. |
| No agent on this account can run the X role… | Give an agent that role under Capabilities → Agents. |
| No agents in this workspace. | Assign an agent to the workspace, or create one. |
Other errors you may see:
| Message | Fix |
|---|---|
| Intake text is N KB, exceeding the 512 KB limit | Paste fewer tickets at a time. |
| Task is … — playbook and dependencies are locked once a run starts | Cancel the run or reopen the task first. |
| …a started task is a run; cancel the run instead of removing the task | Use ⊘ Cancel run. |
| only a finished task (done/failed/cancelled) can be reopened | Wait for the run to finish, or cancel it. |
Related
- Playbooks: the recipes tasks run, and the run page
- Automations: pool tickets automatically from tracker events
- Goals: plan an outcome into tasks
- Integrations: connect Jira, Linear or Notion