Module 4.7

What Is the Kanban Task Board Pattern?

The kanban task board pattern is using a structured board — physical, digital, or just a Markdown file — as the handoff point between you and your AI agent. You create tasks when you have them. The agent picks them up and executes them when it's running. You wake up to completed work.

This sounds simple. The implications are not. It's a fundamentally different mode of working with AI compared to chat. Chat is synchronous — you ask, you wait, you get a response. The kanban pattern is asynchronous — you leave work, the agent does it, you review results. You're not interacting with the AI. You're delegating to it.

The agent doesn't care that it's 3am. It doesn't get bored. It doesn't resent being handed five tasks before you go to bed. And you don't have to be present while it works. The kanban board is the interface that makes this handoff explicit, structured, and auditable.

Real-World Use Cases

• Overnight research pipeline — dump five research questions before bed. Agent works through them via heartbeat, saves results to files, marks each task done. You wake up with a folder of answered questions.
• Content production queue — add draft requests to the board throughout the week. Agent processes them on a nightly cron, saves drafts to a folder. You review and edit, not write from scratch.
• Client deliverables — before a client call, add "summarize competitor X" and "pull pricing data for Y" to the board. Everything's ready before you log on.
• Developer task queue — add code review requests, test-run tasks, and documentation drafts. Agent works through them while you focus on deeper work.
• Consulting leverage — your billable time shifts from execution to strategy and review. The agent does the first-pass work; you add the judgment.

Key Terms

Kanban board — a visual task management system with columns representing stages of work (e.g., To Do → In Progress → Done). Originally a manufacturing concept (Toyota, 1940s). The digital version used here has 5 statuses: Inbox, Up Next, In Progress, In Review, Done.

State machine — a system where tasks can only exist in one status at a time and can only move between defined transitions. A task can go from In Progress → In Review, but not from Inbox → Done. The rules enforce discipline.

ClawDeck — the main open-source kanban board built for OpenClaw. Rails backend, PostgreSQL, real-time Hotwire UI, REST API for agent integration.

Task spec — a well-written task description that gives the agent everything it needs to execute: what to do, where to save output, what format, and how to handle failures. The quality of your task specs determines the quality of your results.

The Core Insight: Handoff, Not Chat

Here's why this pattern matters beyond the mechanics.

Most people use AI reactively: something comes up, they open the chat, they ask. The kanban pattern flips that. You build up a queue of deferred work. The agent works through that queue autonomously. Your role shifts from prompt-writing to task-spec writing and result reviewing.

Think of it like the difference between managing a contractor in real-time versus assigning them a sprint. Real-time management is high-friction and demands your presence. Sprint-based work lets you delegate, step away, and review output in batch.

The agent is a remarkably good sprint executor — as long as the tasks are well-specified. That last part is the skill you're developing when you learn this pattern.

You (async input)              Task Board               Agent (async execution)
━━━━━━━━━━━━━━━━━━━━━━━        ━━━━━━━━━━━               ━━━━━━━━━━━━━━━━━━━━━━
Create task at 11pm:           [ Inbox      ]
"Research top 5                [ Up Next    ] ←── Agent picks up, starts
competitors for X,             [ In Progress]     working on it
pricing + positioning"         [ In Review  ] ←── Agent posts result, flags
                               [ Done       ] ←── You approve, task complete

The Five Statuses

Every task has exactly one status at any time. Transitions flow in one direction:

Inbox — raw capture. You dumped the idea here. It might be half-formed. Not ready for the agent yet.

Up Next — ready to execute. The task is fully specified. The agent can pick it up immediately. Moving a task from Inbox to Up Next is your commitment that the spec is complete.

In Progress — the agent is working on it. Only one task should typically be In Progress at a time (unless you've designed parallel sub-agent execution).

In Review — the agent completed the task and saved results. You need to look at the output. This is the human gate — nothing moves to Done without your review.

Done — reviewed, approved, closed.

The "In Review" status is the most important and the most skipped. It's the point where you verify the agent did what you intended. Skip it habitually and you'll eventually discover that the agent has been producing subtly wrong results for weeks and you didn't catch it.

The Minimal Version: A Markdown Task File

You don't need ClawDeck to use this pattern. The minimum viable kanban is a single Markdown file your agent can read and update:

Your agent's SOUL.md instructs it to check this file on every heartbeat:

That's the entire system. One file. One SOUL.md instruction block. Zero infrastructure. It works.

ClawDeck: The Full Version

ClawDeck is what the Markdown pattern grows into when you want a real UI, real-time updates, and multiple people or agents using it.

Tech stack: Ruby on Rails 8.1, PostgreSQL, Solid Queue for job processing, Hotwire (Turbo + Stimulus) for live updates, Tailwind CSS. Self-hosted.

How it works:

1. You create and organize tasks in the browser UI — drag them through columns, set priority, add descriptions
2. OpenClaw polls ClawDeck's REST API via heartbeat or cron for tasks in "Up Next" status
3. Agent picks up the highest-priority task, calls the API to move it to "In Progress"
4. Agent executes, calls the API to move to "In Review", posts a result summary to the activity feed
5. You see the update in real-time in the browser, review the output, move to "Done"

The agent integrates via REST API calls — standard HTTP GET/PATCH requests with token authentication. You can drive this with any skill that has web_fetch or exec access to a curl command.

A ClawDeck integration skill:

Other tools in the ecosystem:

• Claw Control — real-time dashboard with agent status monitoring, multi-agent coordination
• Convex for Claw — real-time multi-agent command center with threaded discussions and live activity feed
• Claw-Kanban — routes tasks to specific agent types (Claude Code, Codex, Gemini) based on task category

Writing Good Task Specs

This is the most important skill in the entire pattern. The quality of the agent's output is almost entirely determined by the quality of the task spec. Not the model. Not the tool access. The spec.

A bad task spec produces bad results — not because the agent is dumb, but because it doesn't have the information it needs to do the job well. A good task spec produces reliable, usable results.

The anatomy of a good task spec:

[WHAT] Clear, bounded action in one sentence
[OUTPUT] Exactly where to save results and in what format
[SCOPE] Any constraints on depth, length, or number of items
[FAILURE] What to do if the task can't be fully completed
[CONTEXT] Any background the agent needs to understand the task

Bad spec:

Research AI trends

Good spec:

Search for the top 5 enterprise AI adoption case studies published between
Jan 2025 and Feb 2026. For each: company name, industry, what AI tool they
deployed, measurable outcome (% improvement, cost saved, etc.), and source URL.

Save as a table to ~/research/enterprise-ai-cases.md.
If you can't find 5 with measurable outcomes, include what you found and note
the gap. No paywalled sources.

The bad spec gives the agent infinite scope and no success criteria. The good spec gives it a bounded question, an explicit output format, a save location, a count target, a failure mode, and a source constraint.

Common spec failures:

The Overnight Workflow

Here's the complete workflow for using the kanban pattern to maximize what gets done while you sleep.

Before bed (5–10 minutes):

1. Open your task file or ClawDeck
2. Move rough ideas from Inbox → Up Next for any task that's fully specified
3. Write or refine specs for 3–5 tasks (quality over quantity — 3 well-specified tasks beat 10 vague ones)
4. Verify your cron job or heartbeat is running: openclaw cron list
5. Confirm the health ping is active

Overnight:

The agent heartbeats every 30 minutes. Each cycle:

• Checks the task queue
• If there's a task in Up Next and nothing In Progress, picks it up
• Executes, saves output, moves to In Review
• Repeats on the next heartbeat

Five tasks across 8 hours of sleep = easily handled, assuming each task takes 1–4 heartbeat cycles.

In the morning:

1. Check your Telegram — you likely have completion notifications
2. Open your task file or ClawDeck — scan In Review items
3. For each In Review task:
   • Read the output file
   • Is it usable? Move to Done.
   • Needs refinement? Add a note, move back to Up Next with a revised spec.
   • Missed the mark entirely? Move to Inbox, rewrite the spec from scratch.
4. Look at what's remaining in Up Next and prioritize

The review step compounds. The first week, you'll move a lot of tasks back to Inbox because the specs weren't clear enough. That's normal. By week three, you've learned what the agent needs and your specs are tighter. By week six, most tasks land in Done on the first try. The investment in spec quality pays returns indefinitely.

The Business Angle

The kanban pattern is where OpenClaw becomes a consulting leverage tool.

Here's what changes when you build this well: your billable time shifts from execution to judgment. Instead of spending 3 hours researching a client's competitive landscape, you spend 20 minutes writing tight task specs and 30 minutes reviewing agent output. The research still happens — you just don't do it.

Multiply that across a consulting practice. Client proposals, market research, due diligence, first-draft content, competitive analysis, pricing research — all of this is execution work that an agent can do to 80% quality overnight, leaving you to apply judgment and refinement.

The product opportunity. The kanban interface for AI task delegation is a nascent product category. Power users are cobbling it together manually with ClawDeck and OpenClaw. A polished SaaS version targeting a specific vertical — legal research, property management, e-commerce operations, financial analysis — is a real gap.

The specific value proposition: a client-facing task board where clients submit requests, your AI agent works through them overnight, and you review and deliver results by morning. You're not selling AI — you're selling a service delivery model that AI enables. The client doesn't need to know how it works. They need to know it works.

What this looks like as a consulting product:

Client submits request via simple form or WhatsApp:
  "I need a competitive analysis of the top 3 meal kit delivery services"

→ Task appears in your ClawDeck board (In Progress)
→ OpenClaw agent runs overnight research
→ You wake up to a structured draft in your workspace
→ You review, add your expert framing (30 min)
→ Deliver to client by 9am

Your billable time: 30–45 minutes
Client's perceived experience: fast, thorough, professional
Your actual margin: high

The skill here isn't AI — it's task spec quality, workflow design, and the judgment layer you add on review. Those are hard to commoditize. The execution layer — the overnight research — scales.

Gotchas

One task at a time, or design for parallel explicitly. The default heartbeat pattern picks up one task at a time. If you put 10 tasks in Up Next expecting them all to run in parallel overnight, only one will be In Progress at any given moment. You'll get through 5–8 tasks in a typical night, sequentially. If you need parallel execution, design it with sessions_spawn explicitly — don't assume it happens.

"In Review" is not optional. Skip it and you'll eventually trust output you shouldn't. The agent occasionally misunderstands scope, uses a bad source, produces a first draft in the wrong format, or misses something important. The review step exists to catch this before it compounds. Keep the habit, especially in the first month.

Spec clarity is the bottleneck, not model capability. If you're getting poor results, rewrite the spec before switching models. 90% of "the agent can't do this" problems are actually "the spec didn't tell the agent what I actually needed." Opus on a vague spec still produces vague results. Sonnet on a tight spec produces excellent results.

The task file itself can get messy. A Markdown queue file that accumulates over weeks without pruning becomes a scroll of hundreds of tasks, many Done. Archive completed tasks weekly. Keep the active board focused on In Progress and Up Next. The agent has to read the file on every heartbeat — a 500-line file is slower to parse and slightly more expensive than a 50-line file.

Don't put sensitive information in task specs. Your task spec is passed to the agent as a prompt, stored in session transcripts, and potentially visible in log files. Don't put credentials, client names that are confidential, or private data directly in task descriptions. Reference files instead: "Use the client context from ~/clients/acme/brief.md" rather than pasting the brief inline.

Sources

• ClawDeck GitHub
• DEV Task Board Discussion (GitHub)
• Claw Control — Kanban Dashboard
• Convex for Claw
• Everything I've Done with OpenClaw So Far (madebynathan.com)