Columns

A column decides what happens to a task’s agent when the card arrives and when it leaves. This page covers the default columns, what a move does to the session, exactly what the agent is told, the Column Manager where you set each column up, and plan mode columns. A column can also run automations as a task enters, each time its agent finishes a turn there, and as the task leaves. A workflow runs a set of linked tasks through the columns on their own.

Default board layout

New projects start with seven columns. You can add, remove, rename, and reorder them to match your workflow.

Column	Purpose
To Do	Holding area. No agent runs. Dragging a task here ends its session, removes its worktree, and drops the PR link of a task that did its own work.
Planning	Spawns the agent in plan mode. It creates a plan, then the task auto-moves to Executing.
Executing	Spawns the agent with the default permission mode. The agent works on the task.
Code Review	Agent keeps running. A Send message to agent automation can tell it how to review.
Testing	Agent keeps running. The same automation can tell it how to test.
Merge	Agent keeps running. The same automation can tell it how to ship.
Done	Suspends the session (preserving context) and archives the task.

None of the seeded columns carries automations or a description. Apart from Planning’s plan mode and its exit to Executing, the defaults are names, icons, and colors only, because what a column should do when a task arrives depends on your repo and your agent. Both are yours to fill in from the Column Manager. A column’s message to its agent is one kind of automation, a Send message to agent row; see Automations.

These rows describe the session lifecycle. What the agent receives at each move, and why an unconfigured column tells it nothing, is covered in What the agent is told.

What happens when you drag a card

When you drag a task from one column to another, the source column’s On task exit automations run first, while the task’s session is still attached. Then Kangentic evaluates these rules in order:

Rule	Behavior
Target is To Do	Full reset: the session is killed and its history wiped, and the worktree is removed (with its branch, when Auto Cleanup is on). The task is treated as never started.
Target is Done	Session is suspended (resumable), task is archived.
Target has auto-spawn off	Session is suspended. The target’s other On task enter automations (a script, a webhook, a notification) still run.
Task already has a running agent	Agent keeps running. The target column’s On task enter automations run against the live session, so a Send message to agent row is typed into it.
Task has no running agent	A new agent is spawned (or a suspended session is resumed), and the target’s On task enter automations run.

A move that an automation or a workflow makes takes the same path as a drag: a Move to column row, a workflow moving a task along its route, and a plan approval’s auto-move all run the source column’s exit rows, one rule from this ladder, and the target’s enter rows.

A move is three steps: the source column's On task exit automations, one rule from the ladder, then the target column's On task enter automations. Moving between active columns never restarts a running agent unless the column changes what the agent runs with.

Moving between active columns does not restart the agent. The session stays alive, and only the destination’s automations run. Give a Code Review column a Send message to agent row and moving a task from Executing to Code Review hands the running agent a review prompt with no typing on your part.

What the agent is told

The board speaks to an agent at two kinds of moment: when its session first spawns, and when an automation hands it a message. That is a Send message to agent row, which can run as the task enters a column, as its agent ends a turn, or as the task leaves, or the message on a Move to column row, delivered in the column the row moved the task to. This section is the complete inventory of what crosses that boundary - there is no hidden context.

The first prompt

A task’s first move out of To Do spawns a fresh agent, and Kangentic passes it a single prompt as the agent CLI’s own prompt argument. The default spawn template is {{task_xml}}{{workflow_xml}}{{attachments}}. Outside a workflow, {{workflow_xml}} is empty and dropped, so the prompt renders as:

<task>
  <title>Fix login redirect</title>
  <description>
The login page bounces to /home even when ?next= is set.
Repro steps and the suspect handler are in src/auth/redirect.ts.
  </description>
</task>
/Users/you/Desktop/login-bug.png

The description body sits against the left margin so any markdown inside it, code fences included, survives verbatim. A one-line description is inlined on a single line, and a task with no description omits the <description> tag entirely. Attachments follow as bare absolute file paths, one per line, with no header; a task with no attachments ends at </task>.

That is the entire prompt. Kangentic adds no system preamble of its own, and the column is invisible to the agent: no template variable in the spawn prompt carries a column’s name or description, so the agent cannot tell whether it spawned into Executing, Merge, or a column you invented. Moving a task back to To Do kills its session, so its next move out spawns a fresh agent and sends the envelope again.

A workflow task is the one exception. Its prompt gets a <workflow> block after </task>: the workflow’s name, the task’s route (the columns it visits, in order), the tasks it builds on and the tasks waiting on it, and how its turns are judged. Those instructions tell the agent to end a turn only when the column’s work is done or when it needs you, because the end of each turn is what decides whether the task moves on.

Moves between active columns

Once a session exists, moving its task between active columns continues the same conversation. The title and description are not re-sent - the agent already has them, and repeating them would duplicate context. The only new input is the destination column’s message, delivered as an ordinary user message typed into the running session (when a move resumes or restarts a session, it rides along as the CLI’s prompt argument instead).

If the destination column has no message, nothing is delivered at all. Every column on the default board ships with no automations, so out of the box a column’s name carries no behavior of its own. Moving a card to Code Review, Testing, or Merge changes what Kangentic does with the session, not what the agent is told - “agent keeps running” means exactly that. To make arrival in a column mean something to the agent, give that column a Send message to agent automation.

A Move to column row can carry a message of its own for the column it moves the task to, such as a review’s findings in {{agentReply}}. It waits for the agent there to finish its turn, so it lands after that column’s own enter message.

The two moments can coincide: a task spawning straight into a column that has a message gets the envelope as its prompt and the message as a follow-up once the session shows its first activity (see delivery timing).

One built-in prompt

A plan approval moves the task out of plan mode while the agent is mid-turn, and the agent carries on with the implementation. When the destination column runs a different model or effort, the move has to restart the session to apply them. The resumed session then gets “The session restarted to apply the Executing column’s settings. Proceed with implementing the approved plan.”, with the destination column’s name. It is sent only when that column has no message of its own and the task has no command set over MCP, either of which takes its place. It is not sent when the move switches session (into or out of an isolated column) or changes agent, because those land in a conversation that never saw the plan.

Two already-documented cases adjust what a move delivers: an agent change with handoff context enabled prepends a handoff preamble, and the first move out of Done skips the message (see the note under Send message to agent).

Column Manager

Click a column header to open the Column Manager on that column, or Add column at the right-hand end of the board toolbar to open it on a new one. That button becomes a plain + once the toolbar runs short of room. The manager lists every column on the left, the selected column’s settings in the middle, and that column’s automations on the right. Add, rename, reorder, and configure columns from one place - there is no separate “Add Column” dialog. The manager can be maximized (the header toggle, a double-click on its title bar, or Ctrl+Shift+M / Cmd+Shift+M) when you have a lot of columns to work through.

Full size

The Column Manager dialog with the Code Review column selected: its name, icon, and color, Codex CLI on gpt-5.5 as the agent that starts when a task enters it, and empty automation slots for entering and leaving the column. v0.46.0 The real app on a sample install. The projects and terminals are recordings, connected to nothing, so click anything.

The column rail starts with an All columns entry that lays every column out side by side in one table, grouped as Agent (start, agent, model, effort, permissions), Conversation (handoff, session), and Automations (on enter, on turn end, on exit), so you can compare the whole ladder at a glance before opening one column. A column pinned to a model version that a newer one has superseded carries a small mark naming the newer version. Above the rail sits a Profile switcher for Board profiles - named alternate per-column strategy ladders - with buttons to create, duplicate, rename, and delete a profile. While a profile is selected, the editors show that profile’s values and column structure is locked (no add, reorder, or delete): structure belongs to the board, profiles only change what columns do. Automations are locked the same way, since every profile shares them.

Adding and editing columns

For each column you can configure:

Setting	Description
Name	Column display name
Description	Optional column description, shown as a tooltip on the column header and shared with your team through kangentic.json. Display only: it is never sent to the agent
Color	Header accent color
Icon	Lucide icon name (e.g., square-terminal, code, flask-conical)
Start an agent here	Whether moving a task here spawns an agent (the auto_spawn toggle; default: on). It applies live, with no card move: tasks already in the column spawn agents when you switch it on and suspend when you switch it off. Turning it off also switches off every Send message to agent automation on the column, since there is no agent to type at
Agent	Use a specific agent for sessions in this column instead of the project default. Hidden for To Do / Done columns
Model	Adapter-specific model identifier (e.g. opus, gpt-5-codex). The list has the same Latest group as the task pickers: a column set to a floating alias follows each new release of that model, while one pinned to a specific version stays put. A running session that moves into the column is suspended and resumed on the new model with its conversation intact. Hidden when the adapter has no --model flag
Effort	Adapter-specific reasoning level (e.g. low, medium, high, xhigh, max). A running session that moves into the column at a different level is suspended and resumed with the new --effort, the same restart a model change takes. Hidden when the adapter doesn’t expose effort levels
Permissions	Override the global permission mode for agents in this column. The dropdown re-populates based on what the selected agent supports. It applies when a session spawns or resumes here. A running session that moves in keeps its permission mode, since a change of permissions alone never restarts it
After Plan Mode	For plan-mode columns: where tasks auto-move when planning completes (see Plan mode columns). A task in a running workflow moves to the next column on its route instead
Hand off context when the agent changes	On a move that changes the agent (Codex to Claude, say), hand the previous agent’s conversation to the new one instead of starting it with just the task title and description (the handoff_context toggle)
Session	Which session a task runs on in this column: Main (the shared conversation carried between normal columns) or Isolated (this column’s own session, separate from the main one and started clean on every entry, which suits an adversarial code review). Forced to Main for To Do / Done

A column’s message to its agent is not a field here. It is an automation, a Send message to agent row in the list on the right; see Automations for the five types and how they run. Each group (On task enter, On agent turn end, On task exit) has its own Add automation control. To Do and Done run the exit group only, and a column whose agent cannot report the end of a turn shows the reason in place of the turn-end group’s control.

Toggle settings (Start an agent here, Hand off context when the agent changes) use a click-anywhere card affordance - the entire row is the click target, not just the switch.

Reordering columns

Drag a column by the grip in its header on the board, or drag rows in the Column Manager list, to reorder. From the keyboard, Tab to the grip, press Space to pick it up, move it with the arrow keys, and press Space again to drop it; Escape puts it back. To Do stays first.

Removing columns

Remove a column with the Remove column button at the left of the Column Manager’s footer. Columns can only be removed when they contain no tasks - move or delete all tasks first - and the role columns (To Do and Done) cannot be removed at all. Like adding and reordering, removal is staged until you Save, so Cancel still undoes it. Saving a removal also cleans up in one transaction: the column’s automations, other columns’ plan-exit targets, and any Board profile entries that referenced the column. The automations’ run history is kept, so a log entry still names what ran even after its column is gone.

Plan mode columns

A column whose permission mode is plan runs its agent with read-only tools and hands the task on when you approve the plan. The default board’s Planning column is one, with its plan exit target pointing to Executing:

1. You drag a task to Planning
2. Kangentic spawns the agent in plan mode (read-only tools only)
3. The agent analyzes the codebase and creates a plan
4. When the agent calls ExitPlanMode, Kangentic detects it
5. The task automatically moves to the column specified by plan_exit_target_id (default: Executing)
6. The agent resumes with full autonomy to implement the plan

Plan first, then execute, with the hand-off made by the board. A task in a running workflow is the exception to step 5: its plan approval moves it to the next column on its route, wherever the column’s plan exit target points.

Configuring plan exit targets

The plan_exit_target_id column setting controls where a task moves when a plan-mode agent calls ExitPlanMode. You can set this in the Column Manager under After Plan Mode.

• If plan_exit_target_id is set, the task auto-moves to that column when planning completes
• If not set (null), the task stays in the plan-mode column after planning finishes
• The target column typically has a less restrictive permission mode so the agent can execute the plan

You can chain multiple plan stages - for example, a “High-Level Plan” column that exits to a “Detailed Plan” column, which exits to “Executing.”

Tip

You can create your own plan-mode columns. Set a column’s permission mode to plan and point its plan exit target to any other column.

See also

• Automations - what a column runs as a task enters, at each turn end, and as it leaves
• Workflows - linked tasks that move through these columns on their own
• Creating tasks - the cards that move through the columns, and the per-task overrides that beat a column’s settings
• Board profiles - named alternate ladders of the per-column settings
• Board configuration - share your columns and automations through kangentic.json
• Settings - permission modes and the project defaults a column overrides