Kanban for AI agents: one board, two actors

One board, two actors and a single backlog

The difference between an ordinary kanban board and a board with agents in it is not the columns: it is who can move them. A classic board has one actor, the person, and everything that happens on it is done by somebody with a name and an open session. A board with agents has two actors over the same work: the person and the process that executes tasks on their behalf. They are not two mirrored boards or two queues somebody replicates by hand: it is a single backlog where cards change column, get commented on and get closed with the same operations, no matter who presses the button.

That is why the first useful question is not what integrations it has, but if the agent moves a card, what is written behind it. A board where the agent works on its own queue and somebody then replicates the result by hand is a task list with a bridge: the real state and the visible state drift apart, and the real state is the one nobody can audit. The second question is equally concrete: if the agent and the person share the backlog but not the trail, there are not two actors but two anonymous authors in the same document.

The hierarchy they both share

The AI Tasker hierarchy is Workspace → Project → Task → Subtask, and both actors work inside it. There is no tree for people and another one for agents: there is one tree, four levels deep, and every level has its job.

• Workspace: the level where each actor’s identity lives. Every agent API key is tied to its workspace, and that is where permissions, quotas and lifecycle are resolved.
• Project: the work container, with a tree of nested projects, project notes and an auditable activity timeline.
• Task: the card. It holds status, priority, sprint and attachments; it is the unit that moves between columns, the one that gets commented on and the one that gets closed.
• Subtask: a task inside another one. It is the unit the agent uses to break down a job without opening another project or leaving the board.

The flow: human, agent, human

1. The person describes the goal and the acceptance criteria. Not "fix the API bug", but "stop returning 500 when the payload arrives without a total field, with a test that covers it". The acceptance criteria are the part the agent cannot negotiate: they are the contract that gets reviewed afterwards.
2. The agent takes the task. With the same tools a person would use, it creates the card with create_task, assigns it, moves it between columns with move_task and updates what changed with update_task. On the board there is no area reserved for the agent: the card sits in the same column as the others, with its actor recorded.
3. The agent comments what it did and why. It posts the work report with add_task_comment: what changed, what it could not do and what it leaves pending. That comment is the deliverable, not decoration.
4. The person reviews the comment trail and closes. They read what the agent wrote, check it against the acceptance criteria on the task and, if it holds, move the card to the final column and close it. If it does not, they send it back with a comment: the loop goes back to the second step with more information, not with more demands.

The comment trail is the interface between the two actors, not a chat window. In a chat the conversation is lost when you close the tab and the messages carry no reliable author. On a task, every comment stays attached to the card, with its author and its date, and survives the column change and the closure. That difference is what lets a person review the work of a process three days later, and it is what turns a board with agents into something auditable.

The 40 tools and who uses them

The MCP server exposes 40 tools grouped into nine areas. The useful question is not how many there are, but who needs each one: a tool that makes sense for the person and another that makes sense for the agent sit in the same catalogue and arrive through different channels.

The 40 tools of the AI Tasker MCP server, grouped by area and by main actor.

Area	What it is for	Who uses it
agent — agent identity and lifecycle	Register the agent, request the human authorisation link, rotate the key, check the lifecycle status and issue a recovery token: register_agent, request_agent_link, request_agent_key_rotation, get_agent_lifecycle_status, request_agent_recovery_token (5 tools).	The agent registers itself; the person authorises the link, rotates the key and reclaims the workspace if it expires.
comments — task comments	Read, add, edit and delete (soft delete) comments: list_task_comments, add_task_comment, update_task_comment, delete_task_comment (4 tools).	The agent writes the work report; the person writes the review and decides.
credits — credits and balance	Check the balance, see the one-off packs, apply a referral code and debit credits: credits.balance, credits.packs, credits.applyReferral, credits.spend (4 tools).	The person manages the budget; the agent can check how much is left.
decision — decision engine	Ask the engine that returns typed probabilities instead of generated text: decide (1 tool), with the choice, noul and score primitives.	The agent decides with data; the person defines the questions and the state being evaluated.
discovery — service discovery	Read the canonical service info, the onboarding status and the limits, and list the workspaces the API key reaches: get_service_info, list_workspaces (2 tools).	Both: the person to get oriented, the agent before operating.
projects — projects and notes	List projects as a tree, read a project activity timeline, search and read notes, create and update projects: list_projects, list_project_activity, list_project_notes, get_project_note, create_project, update_project (6 tools).	The person creates and edits projects; the agent reads the tree, the activity and the notes.
relations — task relations	Declare that one task blocks another, remove that block and relate two tasks: task_block, task_unblock, task_rel (3 tools).	The agent chains dependencies while breaking work down; the person reviews them.
sprints — sprints and planning	List, create and update sprints, add and remove tasks from a sprint and compute the plan: list_sprints, create_sprint, update_sprint, sprint_add_tasks, sprint_remove_tasks, plan_sprint_from_backlog (6 tools).	The person plans; the agent reads the sprint it is working on.
tasks — tasks and attachments	List and search tasks, read one by id or code, create it, update it, move it between columns, archive it and handle attachments: list_tasks, search_tasks, get_task, create_task, update_task, move_task, delete_task, list_task_attachments, create_task_attachment_download_link (9 tools).	Both: the agent moves and comments, the person prioritises and reviews.

The person’s side

• Create and edit the project and its tree with create_project and update_project; creating projects requires the owner or admin role.
• Write the task with its acceptance criteria and publish it to the backlog with create_task.
• Plan the sprint with the server-side deterministic planner, plan_sprint_from_backlog, which applies the canonical priority, date and id rules; in the API, the hosted AI operation AI_SPRINT_PLAN covers the same planning ground.
• Generate tasks from natural language (AI_GENERATE_TASKS) and break a task down into subtasks (AI_BREAKDOWN). Both are hosted AI operations and both cost one unit.
• Comment, attach and review: task comments, attachments with their temporary download link and reading the activity feed.

The agent’s side

• Work the card: create_task, update_task, move_task and delete_task (soft archive) are the same operations a person with an open session would run.
• Write the report: add_task_comment leaves the what and the why; list_task_comments lets it read what the person said before touching anything.
• Get oriented before operating: list_tasks, search_tasks, get_task, list_projects, list_sprints and get_service_info give the sprint context and the workspace limits.
• Chain dependencies: task_block, task_unblock and task_rel express which task blocks which when the agent breaks a job down.
• Decide with data: decide returns typed probabilities over a concrete state instead of generated text, and it costs 5 tokens per call.
• Look after its own identity: register_agent for sign-up, request_agent_link to ask for human authorisation, get_agent_lifecycle_status to know whether its workspace is at risk and request_agent_recovery_token so a person can reclaim it before the purge.

The audit trail: who did what

Every change on the board is recorded with its actor: the person’s id when it was a browser session, or the channel and the API key id when it was a process. There are four possible channels: human, cli, llm and agent. Every authenticated request also leaves a usage row with the apiKeyId, the workspace, the method, the route and the channel. The activity feed applies two redaction layers: an allowlist one on write and a deep one on read.

• What is redacted: passwords, full API keys, Authorization headers and cookies, JWT and session or OAuth tokens, OTP and reset codes, sign-up, linking and rotation tokens, webhook secrets, private keys, the credential ciphertext and x402 signatures or payloads.
• What is kept: the non-secret identifiers, the event id, the apiKeyId, the actor (userId or channel), the correlationId, the dates and the field labels. Without those there would be no trail at all: the value of the audit is being able to say who without being able to read what.
• The fail-safe: if redaction fails (a getter that throws, a cycle, an unreadable structure), the feed returns a minimal skeleton with no raw payload and the redactionFailed=true flag. The problematic content is never written to logs.

Why this is the thing a board with agents has to prove: on a human board, "who did what" is a curiosity. On a board where a process executes work without asking permission, it is the condition for trust to exist. If the agent can move a card, change its priority and close it, and none of that is attributed to a concrete credential, the board stops being a place of work and becomes an open entry point. The activity feed is what turns the task table into a record: the list_project_activity tool returns the timeline of a project, newest first. On the free plan, activity retention is 30 days.

Comparison with the classic kanban tools

The table collects the official price read on each product’s own page on 20 October 2026, and those prices can change: check the source before you sign anything. The MCP column says whether there is a verifiable MCP server, not whether the tool uses AI.

Official prices read on 2026-10-20 and MCP surface of each tool.

Tool	Official price read	MCP	What it does not solve
Trello	Standard $5/user/month (annual) · Premium $10 (annual) · Enterprise $17.50	Yes (trello.com/mcp)	It is pure kanban: no agent actor, no budget and no lifecycle
Plane	Free $0/seat/month · Pro $6 · Business $13	No (/mcp returns 404)	No visible MCP and no lifecycle
ClickUp	Free $0 · Unlimited $7/user/month · Business $12 (annual)	Yes, in the high tier	Its consumption unit is MCP calls per day (100/300/1,000/25,000), not lifecycle
Notion	Free $0 · Plus €9.50/member/month · Business €19.50	No (/mcp returns 404)	It is not a sprint board; its AI is billed at $10 per 1,000 credits
Linear	Free $0 · Basic $10/user/month (annual) · Business $16 (annual)	Yes (linear.app/docs/mcp), with OAuth	MCP as a bridge: no lifecycle and no per-agent budget
Taskade	Free $0 (2 users) · Pro $10/month · Business $25/month · Max $100/month	Yes (taskade.com/mcp)	It charges about 5× per unit and its AI writes text, it does not decide
Asana	Personal $0 · Starter $10.99/user/month (annual) · Advanced $24.99 (annual)	Not documented on the pricing page	No agent actor and no governance; its AI is $0.50 per request
Monday.com	Free €0 · Basic €9/seat/month · Standard €12 · Pro €19	No (/mcp returns 404)	No MCP and no agent actor
AgentTask	Free $0 · Pro $7/month annual ($9 monthly) · Team $12/seat/month annual ($15)	Yes, remote (Streamable HTTP, OAuth 2.1 + API key with scopes)	15 crews and 25 hosted agent actions per month on Free; it charges 5-6× per unit and never expires the agent identity
AI Tasker	Free plan 0 € + billable unit of 2.00 €/month per approved unit	Yes, remote (streamable-http), 40 tools, listed in the official MCP Registry	The price is per live unit, with 7+7 lifecycle and an audit trail with actor and channel

The comparison asks for an honest reading: for a human team that wants a fast, well-made board, Trello at $5 or Linear at $10 do that job and have nothing to prove. The problem AI Tasker solves is a different one: a process that executes work inside the same backlog and a person who has to be able to prove afterwards who moved each card. If nobody needs to audit an agent, the table above is enough and it is cheaper.

The five Kanban AI criteria applied to this flow

Kanban AI defines five criteria for choosing a kanban board with MCP: board fidelity, team sharing, AI planning, setup friction and MCP design. Applied to this flow they are not a list of adjectives: they are questions with a verifiable answer.

1. Board fidelity: the agent moves the card between columns with move_task, the same operation the person uses. The hierarchy is Workspace → Project → Task → Subtask and the card keeps its status, its priority and its sprint when it changes place. If the agent had its own area on the board, this criterion would fail immediately.
2. Team sharing: person and agent see the same backlog, the same sprint and the same cards. The free plan includes 1 workspace, 1 human and 2 API keys, so the minimum case, one person and one process, fits without extra configuration.
3. AI planning: the AI proposes the planning instead of writing text. plan_sprint_from_backlog orders the backlog with server-side deterministic rules, and the three hosted AI operations in the catalogue (AI_SPRINT_PLAN, AI_GENERATE_TASKS, AI_BREAKDOWN) plan, generate tasks and break down jobs. To decide with probabilities over a concrete state there is decide.
4. Setup friction: an API key with the atkr_ prefix, an endpoint and a JSON configuration file. The MCP server is listed in the official registry (dev.theboomer/ai-tasker, version 1.1.8) and exposes server.json, llms.txt and llms-full.txt, so it can be audited before you call anybody.
5. MCP design: 40 tools that each do one thing, grouped into nine areas, instead of a surface that exposes the database. The machine-readable catalogue lets you read the description of each tool before invoking it.

The sixth criterion: governance

The criterion this niche adds is governance: who can do what, with which budget and with which lifecycle. In practice it is four verifiable rules. The human link is mandatory: a self-registration grants no privileges by redirection and the agent asks for its authorisation with request_agent_link. The budget is measured in units: 2.00 €/month per approved unit (an accepted human member, a created agent API key or an extra workspace for the owner), with a daily ceiling of 200 agent operations and 10 hosted AI operations per workspace. The lifecycle expires: a warning at 48 hours, archiving at 7 days and 7 days more of recovery window with a one-time token. And the separation between identities is real: every API key lives in its workspace, a revoked key returns 401 and an archived workspace blocks normal access with 403.

Checklist for setting the flow up in your team

• Does the task the agent takes include the acceptance criteria the person will review? (contract)
• Does the agent write a comment with the what and the why before moving the card to the final column? (work report)
• Does the person review that comment and decide, instead of reading the whole task again? (review)
• Is every change recorded with an actor (userId or apiKeyId) and a channel (human, cli, llm or agent)? (traceability)
• Is the activity feed read with both redaction layers active and the fail-safe in place? (trail security)
• Does the agent have a visible budget and know how much is left? (budget)
• Do sign-up, human link, key rotation and recovery all have their place? (governance)
• Was the price compared per live unit rather than per seat? (honest pricing)

What is left to decide

The gap is narrow and it is better stated with data than with adjectives: there are mature kanban boards from $5 per user per month, and there are coordinators for people and agents from $6. What none of them publishes is a 2.00 € unit per live process, with a lifecycle that expires after 7 days and an activity feed that attributes every change. If your team just needs columns and cards, use the ones in the table. If it needs a process to work in the same backlog and months later to be able to prove what it did, the starting point is this: 40 tools, a trail with actor and channel, two redaction layers and a four-level hierarchy both actors share.

The loop of a board with agents, in four steps

The short, verifiable path: create the task with its acceptance criteria, let the agent claim it, review the comment and the audit trail, and close by feeding the result back into the next sprint.

1. Create the task with the acceptance criteria

   Write the goal and the conditions that must hold, and publish it to the backlog with create_task or from the dashboard. The criteria are the contract: they are what the agent cannot negotiate and what the person will check in step 3.

2. Let the agent claim it

   The agent lists what is there with list_tasks and list_sprints, takes the task, moves it between columns with move_task and updates what changed with update_task. If the job is large, it breaks it down into subtasks and chains dependencies with task_block and task_rel.

3. Review the comment and the audit trail

   Read the add_task_comment from the agent: what it did, what it could not do and what it leaves pending. Check it against the acceptance criteria and, if needed, look at the project activity feed with list_project_activity to see who touched each card and through which channel.

4. Close and feed the result into the next sprint

   If it holds, move the card to the final column and close it; if not, send it back with a comment explaining what is missing. The next sprint is planned with plan_sprint_from_backlog or with the hosted AI operation AI_SPRINT_PLAN, and what the review taught goes into the next task as a criterion.

Frequently asked questions

What changes when the agent works on the same board as the person?

What changes is who can act on the same work and who ends up on record. Both sides use the same operations on the same card: create, assign, move, comment and close. The difference is that every action is attributed to a concrete actor, the person’s id or the channel and API key of the agent, so the later review depends on the record rather than on trust.

Can you tell what the agent did on a task?

Yes, by two routes. The comment trail of the task, read with list_task_comments, where the agent leaves the what and the why of its work; and the activity feed, which records the actor and channel of every change, with two redaction layers and a fail-safe that stops a redaction failure from leaking the raw content.

Why is an ordinary kanban board not enough?

Because an ordinary board solves coordination between people, a problem that has been solved for years. What a board with agents has to solve is another one: a process that writes without asking permission and a person who has to be able to prove months later what changed and who changed it. A kanban board at $5 per user covers the first case; the second needs identity per actor, a budget per unit and a lifecycle that expires.

Sources

• Kanban AI — comparison of AI kanban boards with MCP (the five criteria)
  https://kanbanai.dev
• Trello — pricing
  https://trello.com/pricing
• Plane — pricing
  https://plane.so/pricing
• ClickUp — pricing
  https://clickup.com/pricing
• Notion — pricing
  https://notion.com/pricing
• Linear — pricing
  https://linear.app/pricing
• Taskade — pricing
  https://taskade.com/pricing
• Asana — pricing
  https://asana.com/pricing
• Monday.com — pricing
  https://monday.com/pricing
• AgentTask — pricing
  https://agent-task.com/pricing
• AI Tasker — live plans and operations
  https://api.ai-tasker.theboomer.dev/api/plans
• AI Tasker — MCP server manifest
  https://ai-tasker.theboomer.dev/server.json
• AI Tasker — machine-readable catalogue
  https://ai-tasker.theboomer.dev/llms-full.txt

Figures verified against the live API and each product’s official page on 21 October 2026. Third-party prices can change: check the official page before you commit.

Related guides

• All guides — How to choose a task manager, MCP and agent lifecycle tooling for AI agents.
• Task manager for AI agents: 2026 guide — How to choose a task manager for AI agents: MCP, lifecycle, credits and human supervision. A comparison and a checklist.
• MCP for task management: guide and comparison — What a task-management MCP server is, which tools each one exposes and how to choose. A table with the real price of every server.
• Alternatives to Linear, Jira and ClickUp — A comparison of ten alternatives to Linear, Jira and ClickUp for teams using AI agents, with verified real prices and the coordination gap.
• Pricing — Real prices: free plan and a 2.00 €/month billable unit.
• MCP integration — https://mcp.ai-tasker.theboomer.dev/mcp
• /llms.txt — Machine-readable contract.