Agent Context Management

AgentKanban solves two problems that usually get split across different tools.

First, you need a clear way to organise projects and tasks.

Second, once AI agents are part of the workflow, you need task context to survive beyond a single chat session.

Most chat tools handle the first few prompts well enough, but they break down as work stretches across multiple sessions, contributors, and revisions. A useful conversation becomes hard to resume. Important decisions disappear into chat history. New sessions start noisy because the model has to be reloaded with too much background or too little of the right context.

AgentKanban turns that into a task-based workflow.

The Problem With Ephemeral Agent Chats

An agent chat is good at local reasoning. It is not a reliable system of record for project work.

Common failure modes:

That gets worse when multiple people are involved, when a task pauses for a few days, or when a feature needs to be revisited after earlier implementation work.

What AgentKanban Changes

AgentKanban keeps the project structure and the agent context attached to the same task.

The kanban board gives you the project management layer:

The VS Code integration gives you the context-management layer:

This makes the board more than a task tracker. It becomes the place where execution context is stored, shared, and resumed.

How Resume Works

When you come back to a task, AgentKanban can reopen the work with retrieved task context instead of forcing you to reconstruct it from memory.

Resume is useful because it lowers noise.

Instead of dragging forward a bloated chat transcript, the system can reload the context that actually belongs to the task:

That gives the next session a cleaner starting point and reduces repetitive prompting.

Turn Curation

Once conversations are captured against a task, the Turns tab gives you tools to curate which turns matter and how context is organised going forward.

Every captured conversation turn — user prompt, agent response — appears on the task's Turns tab in chronological order. Over time, some turns become noise: test prompts, dead-ends, superseded approaches. Turn curation lets you mark what matters and remove what doesn't.

The available actions fall into two groups:

Pinning

Pinning marks a turn as important. A pinned turn is guaranteed to survive the plan's retention cutoff.

When to pin. Pin turns that contain key decisions, architecture choices, or context you'll need when resuming the task weeks later. Think of pinning as "this turn is part of the task's permanent record."

How it works. Hover over any turn in the Turns tab. A small pin icon appears at the top right. Click it to pin; click again to unpin. Pinned turns show an amber pin indicator next to the timestamp.

Excluding

Excluding removes a turn from the agent's context without deleting it. Excluded turns are hidden from the normal turns view and won't be injected into future agent sessions.

When to exclude. Exclude turns that add noise: test prompts, debugging dead-ends, verbose outputs that were useful once but aren't relevant going forward. The turn stays in the database for audit and can be re-included at any time.

How it works. Hover over a turn and click the eye-slash icon to exclude it. The turn disappears from the default view.

Inline excluded placeholders. When one or more consecutive turns are excluded, a compact placeholder appears in the timeline showing "N excluded". Clicking the placeholder expands it to reveal the excluded turns (shown dimmed). A "Hide N excluded" button collapses the group again. This lets you review what was excluded without cluttering the main view.

Show all excluded. A toggle at the top-right of the Turns tab reads "Show all N excluded" when there are excluded turns. Clicking it reveals every excluded turn inline (dimmed). Click again to collapse them back into inline placeholders.

Re-including a turn. Reveal an excluded turn using either the inline placeholder or the global toggle, hover over it, and click the eye icon (Include). The turn returns to normal status immediately.

Context Actions

Between every pair of visible turns, a Context Actions label marks a split point. Clicking it opens a menu with three actions: Fork, Split, and Delete.

Each action shows a count of how many turns will be affected, including any excluded turns. If excluded turns fall within the range, the count notes this — for example, "Copy 5 previous turns (2 excluded) to a new task". The confirmation dialog repeats this information so you always know what's being moved, copied, or removed.

Default task names. Fork and Split pre-fill the new task title with a prefix — "(Forked) Original Task" or "(Split) Original Task". If a task with that name already exists on the board, a numeric suffix is added automatically: "(Forked) Original Task (2)", and so on.

Excluded turns carry over. When forking or splitting, excluded turns within the affected range keep their excluded status on the new task. You don't need to re-exclude them.

Fork

Fork copies previous turns up to and including the selected point into a new task. The original task is unchanged — all its turns remain in place.

Use fork when a conversation has gone in a direction worth preserving separately. The original task keeps its full history; the new task starts with a clean copy of the relevant portion.

Split

Split moves following turns from the selected point onward into a new task. Those turns are removed from the original task.

Use split when a conversation has shifted to a different piece of work. The original task keeps the earlier context; the new task continues from the split point.

Delete

Delete removes all turns from the selected point onward permanently. This cannot be undone.

Use delete when the tail of a conversation is noise — failed experiments, test runs — and you want a clean endpoint.

Why This Matters For Teams

Task context is not only for the original author.

Because the context is persisted on the board, it becomes shareable across people and sessions:

This is one of the main practical advantages over raw chat workflows. The chat becomes part of the task history rather than the only place the history exists.

Wider Context Through The API And MCP

AgentKanban is also designed so the agent does not have to operate in isolation from the rest of the board.

Through the External API and MCP surfaces, an agent can be directed to pull broader context when needed:

That means the active chat can start from the current task, then widen into the relevant project context when the work requires it.

Local Document Caches

The VS Code extension syncs board memory and the technical document as read-only local files inside .agentkanban/:

These files are refreshed automatically whenever the extension activates, a task is selected, or the documents change on the server. They are gitignored and never committed.

Agents read these files directly as local workspace files — no API call needed. To update them, agents use the MCP tools update_board_memory and update_board_technical, which support both full replacement and patch mode. The local caches are overwritten on the next sync.

This pattern keeps board-level context available to agents at all times while keeping the remote board as the single source of truth. See Board Settings and Agent Instructions for more detail on what to put in each document.

What You Get In Practice

For individual developers:

For teams: