Tasks & Kanban Board (Beta)
A visual board over your sessions and durable Tasks — editable columns, drag-to-move status transitions, and DAG-orchestrated multi-session runs.
The Kanban task board turns a workspace's sessions and tasks into draggable cards over per-project, fully editable columns. Under it sits a durable Tasks system: tasks live independently of chat, can be edited and re-run, and — for bigger jobs — decomposed into dependency DAGs that an orchestrator executes over real child sessions.
Beta: the board and Tasks (including DAG runs) ship as beta. Board behaviors and the task spec format may still change between releases.
The board
Switch between the list and board views with the toggle in the session list header.
- Columns are yours — add, rename, recolor, and reorder columns per project.
- Drop status — a column can carry an optional status (set it from the board header); moving a card into that column transitions the underlying session's status.
- Cards auto-move as their state changes, keep stable ordering, and never auto-close — closing a card stays your decision.
Tasks
A task is durable work that outlives any single chat turn:
- Task editor — create/edit modes, acceptance criteria, per-task labels, and a results tab with live session binding.
- Create vs. create-then-run — draft a task without starting it, or kick it off immediately. Tasks can be re-run.
- Project inheritance — tasks inherit their project's working directory.
- Task label — task flows tag the whole family (orchestrator + subtasks) with a reserved
Tasklabel so they're filterable from the moment they exist.
Subtasks & DAG runs
Bigger tasks can be decomposed into a task.yaml dependency DAG. The orchestrator then:
- Spawns a real child session per DAG node.
- Executes nodes in dependency order, supervising each child.
- Resumes durably after interruption — a restarted app picks the run back up.
- Shows union progress on the task tile while children run; subtask nodes render colored state pills.
When a task's output doesn't meet its acceptance criteria, a repair loop re-checks the result and dispatches fixes.
Background agents
Background subagents are no longer tied to the turn that spawned them: a persistent query keeps the session alive across turns, and when an agent finishes while the session is idle, the session wakes itself and presents the result. Running work shows as chips above the input, with a floating completion chip when results land.
This is on by default — set FABRIC_KEEP_BG_AGENTS_ALIVE=0 to opt out and return to per-turn teardown.
Pages (Beta)
Agent-built dashboards, reports, trackers, and small tools that live in your workspace, keep their own data, refresh on a schedule, and render inside the app.
Interactions
How you drive Fabric Agents from the keyboard — mentions, slash commands, attachments, shortcuts, permission modes, thinking levels, drafts, and plan approval.