July 14, 2026Ceren Kaya Akgün
Agentic Kanban Board: Loop Engineering for AI Agents
An agentic kanban board runs AI workflow chains when a card moves into a column. See how Heym turns loop engineering into a board your team can share.
TL;DR: An agentic kanban board is a kanban board where moving a card triggers AI work. Each column runs an ordered chain of workflows, each card is a persistent agentic job carrying context, comments, attachments, and outputs, and humans steer the loop through comment threads and reviews. Heym shipped this as the Board tab in v0.0.67, and this post explains how it implements loop engineering in practice, with a runnable planner template you can copy below.
Key Takeaways:
- An agentic kanban board inverts the AI kanban board generator pattern: instead of AI organizing tasks for humans, the board executes AI workflow chains when cards move between columns
- Loop engineering needs five things: work intake, context assembly, execution, verification, and a decision about what happens next. Board primitives map to all five
- Cards accumulate state as they cross the board: every workflow output, comment, move, and attachment becomes context for the next run
- The planning loop pattern holds a card in the Planning column until a human answers its clarifying questions in the comment thread; the answer is what releases the card
- Human-in-the-loop pauses, failure states, and per-workflow run history are first-class board states, not bolt-ons
Table of Contents
- What Is an Agentic Kanban Board?
- From Task Board to Loop Harness
- What Loop Engineering Actually Needs
- How Column Workflow Chains Work
- The Planning Loop: Comments Release Cards
- A Starter Planner Template You Can Import
- Human-in-the-Loop Pauses
- Attachments: Files as Agent Context
- Sharing the Board with Your Team
- Agentic Kanban vs Coding-Agent Boards
- Getting Started
- FAQ
What Is an Agentic Kanban Board?
I am a founding engineer at Heym, a source-available, self-hosted AI workflow automation platform with a visual canvas, and I spent the last few weeks shipping the Board tab: the agentic kanban board this post describes. What follows is how it works, why we built it the way we did, and the exact starter workflow we use on our own planning column.
Definition: An agentic kanban board is a kanban board where columns execute AI workflows. Moving a card into a column starts that column's ordered chain of workflows automatically, with the card's full context as input. Cards are persistent agentic jobs: they carry conversation history, execution state, attachments, and every output produced along the way.
The important word is agentic. Most tools that pair AI with kanban use the AI to generate cards, suggest columns, or summarize a sprint. The board stays a passive picture of work that humans do elsewhere. An agentic kanban board flips that relationship: the board is the execution surface. Dragging a card from Backlog to Planning is not a status update, it is a trigger. The column picks the card up, runs its workflows with everything the card knows, writes the results back, and the card either waits for you or moves on.
This makes the board a natural home for agentic workflows: multi-step AI pipelines that need memory between steps, human checkpoints, and a visible record of what happened. If you have ever lost track of which agent run produced which draft, or re-pasted the same context into a chat window for the fifth time, that is precisely the problem a card solves. The context travels with the work.
From Task Board to Loop Harness
Kanban boards have been through three eras, and it helps to name them, because the SERP for "ai kanban board" mixes all three.
The task era. Trello, Jira, Linear. Columns are statuses, cards are tickets, and every state change is a human action. The board is a shared picture of work.
The coding-agent era. Tools like Vibe Kanban (past 24,000 GitHub stars in 2026) and a wave of open-source boards put AI coding agents behind the cards. Each card is a coding task, an agent (Claude Code, Codex, or similar) executes it in an isolated worktree, and the board is mission control for parallel code generation. This era proved something valuable: a board is a great surface for supervising autonomous work.
The agentic era. The card stops being a coding task and becomes a general agentic job. The column stops being a status and becomes a stage in a loop: a configurable chain of workflows that can call any model, any API, any tool. Planning a feature, triaging a support ticket, producing a research brief, reviewing a contract. Anything you can express as a workflow can be a column.
Heym's Board tab is built for that third era. It is not limited to code, it does not assume a specific agent, and the loop logic lives in ordinary workflows you can open and edit on the canvas.
What Loop Engineering Actually Needs
Loop engineering is the term that stuck for the shift from writing prompts to designing the system around the agent. LangChain calls it the art of loop engineering, and Addy Osmani describes it as building a small system that finds the work, hands it out, checks it, and decides the next thing. Strip away the branding and a production agent loop needs five capabilities:
| Loop requirement | What it means | Board primitive |
|---|---|---|
| Work intake | Something decides what the agent works on next | A card, prioritized by its position in the column |
| Context assembly | The agent gets the right history, files, and constraints | The card payload: content, comments, attachments, previous outputs |
| Execution | The actual multi-step AI work | The column's workflow chain, run sequentially |
| Verification | A check before the work counts as done | Human review via comments, HITL pauses, or a review workflow in the chain |
| Next-step decision | Advance, retry, or escalate | Auto-advance on success, red stop on failure, follow-up rounds to iterate |
Most loop engineering writing covers the theory of these five and then hands you a terminal. The gap we kept hitting in practice was the harness: a place where non-terminal teammates can see the loop, feed it, and stop it. A kanban board turns out to be an unreasonably good answer, because every one of those five requirements maps to a primitive people already understand.
The same mapping is why I would call this a multi-agent system in the practical sense: different columns can run different chains with different models, and the card is the shared memory that coordinates them. You get the coordination benefit without inventing an agent-to-agent protocol; the handoff is a card move.
How Column Workflow Chains Work
Each column on a Heym board can be configured with an ordered list of workflows, the chain. When a card moves into a column that has a chain, four rules apply:
- The chain starts automatically in the background. The move itself never waits.
- Workflows run sequentially, and each workflow's output is appended to the card context before the next one starts.
- If a workflow fails, the chain stops: remaining links are skipped and the card turns red.
- When every link succeeds, the card turns green. While the chain runs, the card pulses amber.
Every run is recorded in Execution History with the board trigger source, and each card keeps its own run list with per-workflow outputs and errors. If you already use tracing for your agents, board runs show up in the same place as every other execution.
The workflow receives a standard payload as its input. Here is the shape, trimmed to the fields you will actually use:
{
"triggered_by": "board",
"rerun": false,
"card": {
"title": "Write launch email",
"content": "Draft the launch email for the beta",
"comments": [{ "author": "user", "content": "...", "created_at": "..." }],
"history": [{ "kind": "event", "content": "...", "created_at": "..." }],
"previous_outputs": [{ "workflow_name": "...", "output": {}, "finished_at": "..." }]
},
"board": { "id": "...", "name": "..." },
"move": { "from_column": "Backlog", "to_column": "Planning" },
"chain": { "position": 0, "length": 2, "previous_workflow_outputs": [] }
}Workflows read this with normal expressions such as $input.card.title or $input.card.comments. The history field carries the full activity timeline, capped at the most recent 200 entries, and previous_outputs holds the outputs of earlier completed runs from previous columns and follow-up rounds. On follow-up rounds, move is null and rerun is true, so a chain can tell a fresh arrival from an iteration.
There is one more piece that makes this practical: the Agentic Kanban Model. Every board requires one (a credential plus a model), and it is the translator between cards and workflows. It maps the card's free-form content into the specific input fields each workflow expects, and turns raw workflow output back into readable text on the card. Your workflows keep their normal typed inputs; the board model does the adaptation. This is the same philosophy as text to workflow: let a model handle the mapping between human language and structured pipeline inputs.
The Planning Loop: Comments Release Cards
The pattern we use most on our own board is a Planning column that interrogates the card before any real work happens. It is the loop engineering equivalent of a senior engineer refusing to start until the ticket makes sense.
Here is the full lifecycle:
- A card moves into Planning. The column's chain runs and writes an enriched plan plus clarifying questions back to the card as an output. Then the card waits. Cards in the first two columns never move on by themselves; they run their chain and hold position for you.
- You answer in the comment thread. The answer releases the card: it moves on to the next column, which picks it up with your answer already in context. The Planning chain is not run again on release, so you never pay for a redundant run.
- Or you iterate in place. If the plan needs another pass, press Run follow-up round. The same chain runs again with all accumulated context, and the card flows on once it succeeds.
From the third column on, the behavior changes: a successful chain advances the card to the right on its own, all the way to the last column. The first two columns are deliberately human-gated because that is where intent gets locked in; the later columns are where autonomous execution pays off. A card can only have one active run at a time, so a board never races against itself.
This split matters more than it looks. Fully autonomous pipelines fail at the start, where the problem is still ambiguous, and human-gated pipelines waste attention at the end, where the work is mechanical. Gating the first two columns and auto-advancing the rest matches where human judgment actually adds value. It is the same reasoning behind the evaluator-optimizer pattern in agent design: put the check where the variance is.
A Starter Planner Template You Can Import
This is the workflow running on the Planning column of our own board, reduced to its core. It takes the card's text (the Agentic Kanban Model maps the card content into the text input field), sends it to an LLM with a clarifying-questions instruction, and returns 3 to 5 questions as output. Small on purpose: it is the seed of a planning loop, and the chain structure is what makes it compound.
Explore the workflow below the same way you would on the Heym canvas: click a node to inspect its configuration. Copy the JSON or download the file, then import it as a new workflow in Heym. The template ships without a credential, so open the LLM node after import and pick your own credential and model. Any chat model works; we run it on a small fast model because clarifying questions do not need a frontier model.
View template JSON
{
"heym": true,
"nodes": [
{
"id": "input_1",
"type": "textInput",
"position": {
"x": 50,
"y": 200
},
"data": {
"label": "userInput",
"inputFields": [
{
"key": "text"
}
]
}
},
{
"id": "llm_1",
"type": "llm",
"position": {
"x": 345,
"y": 195
},
"data": {
"label": "clarifyFeature",
"model": "zai-glm-4.7",
"systemInstruction": "You are a helpful assistant that analyzes user inputs about features and asks clarifying questions to better understand what the user wants. Review the user's input and identify what aspects are unclear or need more detail. Generate 3-5 relevant clarifying questions that will help define the feature more precisely.",
"userMessage": "$userInput.body.text"
}
},
{
"id": "output_1",
"type": "output",
"position": {
"x": 650,
"y": 200
},
"data": {
"label": "questionsOutput",
"message": "$clarifyFeature.text"
}
}
],
"edges": [
{
"id": "edge_1",
"source": "input_1",
"target": "llm_1"
},
{
"id": "edge_2",
"source": "llm_1",
"target": "output_1"
}
]
}Wiring it into a board takes six steps:
- Create a board with an Agentic Kanban Model. Open the Board tab, create a board, and pick a credential plus model. This is mandatory: the board model maps each card into workflow inputs and turns raw output back into readable card updates
- Import the planner workflow. Copy or download the JSON above and import it as a new workflow. Open the LLM node and select your own credential and model
- Attach it to the Planning column. Open the column's settings and add the workflow to the chain
- Move a card into Planning. The chain starts in the background and the card pulses amber while it runs
- Answer in the comment thread. The questions land on the card; your answer releases it to the next column with the answers in context
- Iterate with follow-up rounds when needed. The same chain re-runs with all accumulated context instead of moving the card on
The card pulses amber, the questions appear, and the comment thread becomes your planning conversation.
From here the natural evolution is to grow the chain, not the workflow. Add a second link that drafts a spec from the answers. Add a third that breaks the spec into cards. Each link stays a small, testable workflow, which is the same argument for prompt chaining over one giant prompt: smaller steps, inspectable seams, cheaper retries. If you want to go deeper on building the workflows themselves, start with how to build an AI agent.
Human-in-the-Loop Pauses
Chains do not only stop on success or failure. If a workflow in the chain pauses, whether on a Human-in-the-Loop node, on an agent's HITL tool, or because a Codex node needs more information, the run is persisted as pending and the card shows a static amber state. A pulsing amber card is working; a static amber card is asking.
Each pause keeps its own answer surface: HITL pauses give you a review link, Codex pauses show the follow-up screen. Once you answer, the chain resumes on its own. The paused workflow finishes, its output lands on the card, the rest of that column's chain runs, and the card advances as usual. If the resumed run fails, the card turns red and the remaining links are skipped.
The design goal is that a paused agent looks exactly like a blocked teammate on the board: visible, attributable, and unblockable in one click. Human-in-the-loop stops being an architectural diagram and becomes a card color.
Attachments: Files as Agent Context
Cards accept file attachments, stored in Heym's Drive, and every run resolves the attachments before the workflows start:
- Documents (pdf, markdown, csv, json, text) are extracted to text, capped at 20,000 characters per file
- Images are handed over as a URL that vision-capable nodes load directly
- Everything else passes through as a plain reference with name, URL, and MIME type
Workflows read them at $input.card.attachments, and the Agentic Kanban Model sees the extracted text and image URLs too, so it can map an attachment straight into the field a workflow expects. Attach a PRD to a card and the planning chain reads it. Attach a screenshot to a bug card and a vision model in the Development chain sees the actual pixels. Context stops being something you paste and becomes something the card carries.
Sharing the Board with Your Team
A board can be shared with users by email and with teams, at read or write permission. Read means the board and its cards are visible but untouchable: no moves, no comments, no runs. Write means full use: cards, moves, comments, and runs. Only the owner can change the board's settings, its Agentic Kanban Model, or its shares.
The detail that makes sharing practical: chains on a shared board always run with the owner's credentials and model. Collaborators never need their own API keys to move cards and trigger work. One person configures the loop; the whole team operates it. That is a real difference from terminal-based agent harnesses, where every operator needs a configured environment before they can participate.
Agentic Kanban vs Coding-Agent Boards
Coding-agent boards are excellent at what they target, and if your only workload is parallel code generation with Claude Code or Codex, a dedicated tool is a fine choice. The comparison worth making is scope:
| Dimension | Coding-agent board (Vibe Kanban style) | Agentic kanban board (Heym Board) |
|---|---|---|
| Unit of work | A coding task for an AI coding agent | Any agentic job: planning, research, content, ops, code |
| Executor | Specific coding agents in isolated worktrees | Any Heym workflow: LLMs, agents, HTTP, MCP tools, Codex |
| Column semantics | Task status | An executable stage: an ordered workflow chain |
| Context carrier | Repo plus task description | The card: comments, attachments, history, prior outputs |
| Human feedback | Review the diff | Comments release cards, HITL pauses, follow-up rounds |
| Team access | Per-developer local setup | Shared board, runs on the owner's credentials |
| Hosting | Local or hosted app | Self-hosted with the rest of your workflows |
The honest one-line version: coding-agent boards orchestrate a specific kind of agent very well; an agentic kanban board turns the board itself into the orchestration layer for whatever workflows you already run.
Getting Started
The Board tab shipped in Heym v0.0.67 on July 13, 2026, with a follow-up round of refinements in v0.0.68 the next day: inline card title editing, a failed-card error history indicator, empty-column actions, and shared-board fixes. Fitting, since the feature itself was built as a loop.
To try it:
- Self-host Heym (a
docker-compose upgets you there; see the repository) - Open the Board tab in the dashboard and create a board. New boards start with Backlog, Planning, Development, and Done columns, all fully editable
- Import the planner template from this post and attach it to Planning
- Drag a card in and answer its questions
If you want to see what else the workflow engine can do before committing, the template gallery has ready-made workflows for most common pipelines, and the Board documentation covers every rule described here in reference form.
Key Takeaways
- An agentic kanban board executes AI work on card moves: columns hold ordered workflow chains, and cards are persistent agentic jobs that accumulate context
- Loop engineering needs intake, context, execution, verification, and a next-step decision. Board primitives cover all five, in a surface non-terminal teammates can operate
- The planning loop is the highest-leverage starter pattern: a chain writes clarifying questions to the card, and a human answer is what releases it downstream
- Failure and pause states are card colors: pulsing amber running, static amber waiting on a human, green success, red failed chain
- The first two columns are human-gated by design; from the third column on, success auto-advances the card
- Start with the three-node planner template above, then grow the chain link by link instead of growing one giant workflow
FAQ
What is an agentic kanban board?
An agentic kanban board is a kanban board where columns execute AI workflows. When a card moves into a column, that column's ordered chain of workflows runs automatically with the card's full context: title, content, comments, attachments, and outputs from earlier runs. The card is a persistent agentic job that accumulates state as it crosses the board.
How is it different from an AI kanban board generator?
Generators use AI to create or organize cards that humans then work on. An agentic kanban board inverts this: the board is the execution surface, moving a card triggers AI work, and humans steer through comments and reviews instead of doing the tasks themselves.
What is loop engineering?
Loop engineering is designing the system around an AI agent rather than writing individual prompts: how work is picked up, what context the agent receives, how results are verified, when a human intervenes, and what happens next. The board implements this loop with columns, chains, comments, and follow-up rounds.
How does the planning loop work?
The Planning column's chain writes an enriched plan and clarifying questions back to the card, then the card waits. Answering in the comment thread releases the card to the next column with your answer in context. To iterate in place instead, run a follow-up round and the same chain re-runs with all accumulated context.
What happens when a chain workflow fails?
The chain stops, remaining links are skipped, and the card turns red. The card keeps a per-workflow run list with outputs and errors, and the run also appears in Execution History with the board trigger source.
Can workflows on the board pause for human approval?
Yes. Human-in-the-Loop nodes, agent HITL tools, and Codex follow-up questions all persist the run as pending and show a static amber card. Answering resumes the chain automatically and the card advances as usual.
Build AI workflows without writing code.
Import ready-made AI automations directly into Heym — the source-available workflow platform.

Founding Engineer
Ceren is a founding engineer at Heym, working on AI workflow orchestration and the visual canvas editor. She writes about AI automation, multi-agent systems, and the practitioner experience of building production LLM pipelines.
Enjoyed this post? Get the next one in your inbox.
A monthly note with practical ideas for building AI workflows that hold up in production. No noise, and you can unsubscribe anytime.