Reviewed 6 October 2026. Product statements are grounded in the linked documentation. Workflows and fictional examples are editorial guidance.
Original AI-generated concept illustration.
Make the board explain the work
An agent task board is useful when it shows what needs doing, what is happening, and what evidence is required before work can finish. A collection of attractive cards is not enough. The board should make ownership, dependencies, and review visible so an unfinished draft does not appear completed. For teams handling research, code, or content, this can turn a scattered sequence of chats into a process someone else can understand and continue.
Hermes documentation describes Kanban as a durable task board for collaboration across agent profiles, with dashboard, command-line, and worker-tool surfaces. Use the official overview and tutorial for the current mechanics. The board design in this article is a suggested operating method. It does not promise that agents can manage any business automatically, and it does not replace a person's responsibility for confirming whether the delivered work meets the brief.
Documentation: Hermes Kanban overview.
Write cards with acceptance criteria
A card should describe an outcome, not merely an activity. Write prepare a sourced comparison of two transcription tools rather than research transcription. Include the intended reader, source requirements, output location, and definition of completion. A reviewer should be able to judge the result using the card without reading the original conversation. If the task needs a decision from the manager, identify that decision and mark the dependency instead of letting the agent guess.
For a fictional content task, require current official sources, a clear explanation of account limitations, a saved draft, and a fact-check note. Define what should happen when an important claim cannot be verified. The card can accept an article that clearly reports an unresolved point; it should not accept a confident assertion invented to satisfy a word target. Good acceptance criteria describe usable evidence rather than rewarding the appearance of completeness.
Keep states distinct and understandable
Choose states that reflect actual progress. Ideas are uncommitted possibilities. Ready work has enough information to begin. In-progress work has an active owner. Review work has a deliverable awaiting inspection. Blocked work needs a specific input or repair. Completed work has passed the required checks. Map these meanings to the states supported by your installed board instead of assuming a screenshot from another release is identical to your setup.
Do not use completed to mean the agent stopped generating. A draft can be finished from the writer's perspective while still needing factual or functional review. Add a short handoff note when moving it to review: output path, sources used, checks performed, and remaining uncertainty. If the reviewer requests changes, return the exact issue to the appropriate owner. This keeps the board's state tied to evidence instead of to how confident an agent sounds.
Assign roles according to the deliverable
Start with a small role arrangement. One worker can gather sources, another can draft from the approved evidence, and a reviewer can check the result. The same person may supervise all three roles. Give each role a clear responsibility and avoid letting everyone edit the same file at once. Independent research tasks can run separately, but a draft that depends on verified sources should wait until the necessary evidence is available.
Define the handoff format. A research output might contain the source URL, date, supported claim, and relevant qualification. A draft output might contain the article file and a list of claims requiring review. A review output should name defects and whether they prevent completion. This structure reduces the chance that a writer receives a promotional summary without evidence or that a reviewer receives only a link to a long chat.
Model dependencies without creating deadlocks
Link a task only when another result is genuinely required. Writing the final comparison depends on the source review, but preparing a blank content template may not. Avoid making every card dependent on the main parent task if the parent itself waits for those cards. Draw the logical order on paper or describe it in a short list before implementing complex relationships. A clear dependency graph is more valuable than maximum parallel activity.
When a card is blocked, record what will unblock it. Missing credentials, an unanswered editorial question, and a failed build are different problems with different owners. Give the next responsible person a concrete action. Periodically review old blocked cards rather than leaving them in an invisible backlog. If a dependency no longer matters, remove it through the documented board workflow and explain why. That preserves a readable history of the project's decisions.
Set limits on active work
Too many simultaneous tasks can overload the reviewer even when agents can generate quickly. Choose a small active-work limit based on the team's ability to inspect outputs. If research produces ten briefs while editing can handle two, the queue will accumulate stale material. Measure the bottleneck before adding workers. A board should help finish work, not simply display more cards moving at once.
Use smaller tasks when uncertainty is high. Instead of build a complete customer portal, begin with verify the required user roles and create a local prototype of one flow. The next card can use the reviewed result. This reduces the cost of wrong assumptions and makes completion easier to judge. A finite budget or stopping condition should produce a visible status when exhausted, so unfinished work reaches review rather than disappearing as an apparent success.
Review the deliverable and the process
Open the actual file or application. Compare it with the acceptance criteria and repeat the checks that matter. For an article, inspect sources, links, and rendered formatting. For code, run the relevant behavior and examine the change. Record the accepted version. If a self-check reports success, treat it as useful evidence to examine rather than the final decision. A reviewer may discover an issue the worker's own checklist omitted.
After several completed cards, inspect where time was spent. Were tasks waiting for missing briefs, repeated repairs, or an overloaded reviewer? Improve the card template or handoff format before increasing concurrency. Retire states nobody uses and simplify rules that create confusion. Keep the board's purpose visible: every finished card should correspond to a reviewed output, and every unfinished card should explain the next action needed to move forward.
A small first-board experiment
Create one board for a single project and add three cards: source review, draft creation, and publication review. Use a fictional or noncritical topic. Run the complete cycle, including one deliberate change request. Confirm that the source notes reach the writer and that the reviewer can locate the latest draft. Restart the application at a convenient checkpoint and check that the task state remains understandable.
Keep the experiment small enough to finish in one working session. The goal is to learn whether the board preserves context across roles and interruptions. Write down the most confusing handoff and improve it before using the setup for a large batch. Once the process works, add another project or role only when its separation has a clear benefit. Durable collaboration depends on comprehensible task records more than on the number of agents connected to them.
Frequently asked questions
Is a Kanban board useful for one person?
Yes. It can preserve task state across sessions and separate drafting from review. Start small so managing the board does not become more work than completing the task.
Should every card run automatically?
Only ready cards should have enough information to execute. Ideas and blocked tasks need clarification or dependencies resolved before a worker can produce a reliable result.
What belongs in a handoff note?
Include the output location, source evidence, checks performed, unresolved points, and next responsible role. Keep it short enough to inspect quickly.
When is a card complete?
When the agreed acceptance criteria have been checked against the actual deliverable. An agent finishing its response is not the same as a reviewed result.
Resources and related articles
Continue with Hermes and Obsidian: Create Maintainable Agent Memory, Combine AI Agents into a Content Workflow You Can Review, or Gemini for Project Managers: Create Reviewable Plans.
