Task management for AI agents: board and worktrees

What a task needs when an agent does it

A line in a list says what to do. It does not say when the work is done, who owns it if the agent is replaced, what must happen first, or where on disk the change is made. A person keeps those answers in their head. An agent does not carry them from one session to the next, so the board has to.

The harnsy board gives each task four things: criteria the agent checks off with evidence, an owner that stays, a place in an order, and a git worktree.

One task, from “new” to “done”

A task is an item on the project’s board. It has a type (bug, feature, research or task) and a priority (high, medium or low). It moves through states: new, taken, in progress, blocked, in review and done. It can also be dropped, or parked in the backlog until its time comes. A lead can hand a part of a task to a role below it, as a sub-item.

Each criterion is a check. The agent that does the task closes a check with evidence, and a reviewer adds what it finds as new checks. When the work is ready, it waits in review. On the card you accept it, send it back for rework with a comment, or defer it.

The task belongs to a role

The owner of a task is a role, not a session. When an agent runs out of context, it writes a handover note and a fresh agent takes the role. The task, its checks and its history stay on the board.

Order of work: dependencies and chains

Some tasks have to wait for others. In harnsy you say which task blocks which, also across projects. A card names the tasks that hold it, and when they are done it says “Ready to start”. When a blocker is done or dropped, the blocked task’s agent and its lead are told once.

A dependency is a plan, not a lock: nothing stops you from sending a task to work early. Tasks › Chains draws linked tasks as chains, step by step from left to right, and the Dependencies of a task show its whole chain.

Where the work happens: a worktree on the card

Two agents in one checkout step on each other’s changes. The usual answer in git is a worktree: a second working folder on its own branch. A worktree works with Claude Code and with any other coding agent, because it is plain git. In harnsy a task can name its worktree, and the card shows the branch and the folder, with a button to copy the path.

The Changes tab collects every worktree of a project in one place. For each one it shows what it changed against the base branch, the task it belongs to and the agent that works in it. It points out worktrees left behind, and when two live worktrees change the same file it tells the lead. When a change has landed, you remove its worktree with one button. The commands an agent runs are linked to the task whose worktree they ran in.

Documents and screenshots on the card

A task keeps more than notes. Whoever works on it can attach a document: a report, a plan, a review, as Markdown or as a self-contained HTML page, or a screenshot. The files sit on the card, grouped by kind (reports, plans, mockups, screenshots, logs, data), and the lead and the person read them there, next to the task’s history, instead of in a chat or in a file left on someone’s disk. The same file name attached again becomes a new version.

On our own board the editor’s review of a text sits on the card as a report, and the designer’s mockups as screenshots. The real case below kept its record as notes on the task and had no attachments.

One real case: a node that read its database at 86 MB a second

On 6 October 2026 the lead agent of our own harnsy project measured the node we run every day. harnsy’s process was using one to four cores and reading its database at about 86 MB a second. The lead filed it as a bug, with the measurements in the task’s criteria.

A developer agent took the task, found the first cause about seven minutes after the bug was filed and fixed it in a worktree. A reviewer read the change, ran the tests and accepted it. The lead landed it.

That was the first of four fixes. After it the node read 30 to 50 MB a second: better, not enough, so the card stayed open. The second fix came from the notification bell, which read the whole task table for every row.

Then a temporary diagnostic ran for an hour on the live node and ranked who reads most. It pointed at two things: the Links and traces view, which re-read the whole message log on every call and became a task of its own, and the dashboard’s flood of requests. Each got a fix, and every fix was reviewed before it landed.

After the last landing the node reads 2 to 7 MB a second, about 5 on average, and uses 7 to 15 percent of one core. The target was under 5, so it sits right at the edge. What is left is a bigger change, and the lead decides on it.

The task holds every step as notes: the measurements, the cause, each fix with its review and what landed. We did not rebuild it afterwards. It is the record the agents wrote as they went.

What this shows is a bug with criteria, an owner role, fixes made in worktrees and a review before every landing. It does not show that harnsy is faster than another way of working; we did not measure that.

What you do in all this

You decide and accept. You answer an agent’s question when it asks, accept finished work, send it back with a comment or defer it. The agents keep the board current, and Home shows what waits for you in one place.

Several coding agents are hard to manage, and hard to join into a process you control. The board is one answer: you can see the process, and you step in when something needs your attention.

What it is not

• It does not replace your company’s tracker. harnsy does not read or write Jira or Linear.
• Checklists are read-only in the dashboard: the agents close the checks, you read them.
• A dependency orders the work, it does not lock it.
• Milestones, a release of tasks with progress and statistics, are part of harnsy Max.

Install it with one sentence

Tell your agent: “Install harnsy following https://harnsy.dev/llms.txt”. Your agent shows the plan and then installs it.