ForgeForge
DocsBlogChangelog
Platform/Tasks & the live board

Getting Started

  • What is ForgeAI
  • Prerequisites
  • Quickstart

CLI

  • Installing the CLI
  • Authenticating the CLI
  • Connecting projects
  • CLI command reference

Platform

  • Organizations & members
  • Projects
  • BMAD workflows
  • Tasks & the live board
  • Releases & merge-back
  • Your account

Reference

  • Security
  • Plans & billing
  • Troubleshooting & FAQ

Forge

AI-driven development platform. Plan, build, and ship software with methodology-guided workflows and integrated task board.

Product

BlogDocumentationDashboardAccount

Company

AboutContact

Legal

TermsPrivacy

© 2025 Forge. All rights reserved.

Tasks & the live board

How the Kanban board works: columns, task groups and dependencies, automatic agent dispatch, live session streaming, answering agent questions, and resync after disconnects.

The Kanban board is where AI agents actually build your software. Tasks generated from a BMAD workflow land on the board, ForgeAI dispatches them to agents running on your machine through the CLI, and you watch progress, stream agent output, and answer agent questions — all in real time.

The board

The board is the project page itself: /orgs/<orgSlug>/projects/<projectSlug>. Archived projects redirect to their settings page instead.

Columns are dynamic. When no workflow defines a pipeline, the defaults are To Do, In Progress, Review, and Done. Once workflows run, the pipelines of all active workflows' skills are merged into the column set — the seeded BMAD skill, for example, uses a six-column pipeline (Todo, In Progress, Tests Passing, PR Ready, In Review, Merged). You can override columns per project with the column customization dialog: add or remove columns, set a per-column retry limit (maxRequeue, default 5), and refine the agent effort (and optionally the model) per column — heavy reasoning for an implementation step, lighter for mechanical ones; unset columns inherit the project/organization defaults (see Organizations & members). Removing a column that carries an agent command shows an explicit warning, because agents will no longer run that step.

Board filters (group filter, a hide-done toggle, and a search box) are stored in the URL, so filtered views are shareable. The bottom status bar shows a live CLI summary ("N CLIs", "X/Y agents" with slot dots) or "No CLI connected", plus live "merged today" and "awaiting input" counts.

Dragging is meaningful: dropping a task into the last column of its pipeline marks it completed, and dragging a completed task backward reopens it (clearing its completion, CLI assignment, and retry counter).

Task statuses

Each task carries a sub-status that reflects where the agent is:

Sub-statusBoard labelMeaning
(none)NewTask created, not yet picked up
WAITINGWaitingQueued for dispatch to a CLI agent
ACTIVEActiveAn agent is working on it right now
AWAITING_HUMANAwaiting InputThe agent asked a question and is paused
PENDING_CORRECTIONCorrections RequestedYou requested changes; the agent is revising
DONECompletedFinished

Tasks also have a priority (LOW, MEDIUM, HIGH, CRITICAL — default MEDIUM) and optional story points. Estimated durations come from your project's own history: a rolling window of the last 50 completed tasks (minimum 3, with a fallback of 15 minutes per story point).

Task groups and dependencies

Generated tasks are organized into task groups (typically one per epic) with group-to-group dependencies, viewable at /orgs/<orgSlug>/projects/<projectSlug>/task-groups in a List or Graph view.

A task is blocked when any of its blocking dependency tasks is not completed; a group is blocked when any blocking group is not done. Blocked tasks — and every task inside a blocked group — are excluded from agent dispatch. Dependency cycles are rejected when created, so the graph always resolves.

Blocked state is visible on the board: blocked group headers render at reduced opacity with a lock icon, and task cards show a "Blocked by Workflow/Group" reason line. When a task completes, ForgeAI cascades: dependent tasks unblock and are dispatched immediately, and a group automatically flips to done when all of its tasks are completed, unblocking downstream groups. Groups blocked by an in-progress workflow unblock when that workflow completes.

Starting execution

You do not start tasks one by one — dispatch is automatic. For agents to run, you need:

  1. A connected CLI — forge connect running on your machine, with Docker available.
  2. Stored credentials for your agent engine — forge auth setup-claude by default, or setup-codex / setup-opencode / setup-kilo (see Authenticating the CLI).
  3. Tasks on the board — generated with Generate Tasks on the workflow completion screen.

Manual task creation is not available in the cockpit yet: a New Task dialog (title, optional description, priority from Low to Critical) exists in the codebase, but its button is not currently rendered on the board. Today, tasks arrive through workflow generation, plus the system tasks ForgeAI creates for releases and merge-back.

When the organization or project demands a specific model, only devices declaring it are considered; if none does, the task waits with a "No compatible device" badge until a device list or the demand changes. The dispatcher assigns unblocked tasks to CLIs with free agent slots (default 5 per device, configurable 1–20), preferring the task creator's own CLI, then the org CLI with the most available slots. Ordering is: release and merge-back system tasks first, then tasks in the most advanced pipeline column, then by priority (CRITICAL → LOW), then oldest first. Columns without an agent command are skipped by agents entirely. CLIs reporting an unhealthy MCP bridge are excluded from dispatch until they recover.

You can pause dispatch at several levels — the whole organization (a switch in org settings), a project, the board's standard tasks, a release, a task group, or a single task. When project dispatch is paused, the board toolbar shows a "Board paused" badge.

How agents run on your machine

Execution happens entirely on the developer's machine, through the CLI (see Installing the CLI):

  • Each task gets its own Docker container from the getforgeai/agent image (Ubuntu 24.04, Node.js 20, git, and the agent CLIs preinstalled — Claude Code, Codex, OpenCode, and Kilo). The device's configured agent engine runs inside it, and the repository is cloned to /session/workspace.
  • Your own AI credentials are configured in the container at spawn time — agents run on your subscription or API key, and your code never leaves your machine except through your own git remote.
  • The agent works on a dedicated task branch created from the workflow's base branch, named like feature/<workflow-slug>/<task-title-slug>-<short-id>. Commits are authored as ForgeAI Agent <agent@forgeai.dev>, and a safety net auto-commits and pushes any leftover changes when the agent finishes.
  • When the agent completes a pipeline step, the CLI advances the task: it moves to the next column as Waiting and is re-dispatched for that column's command; columns without commands are skipped automatically; reaching the terminal column marks the task completed. Board-task containers are destroyed as soon as the agent exits.

To inspect an agent's work locally, check out its branch with:

forge task open <taskId>

This clones the task branch under ~/.forgeai/open/ and opens it with your configured opener (terminal, VS Code, or file manager).

Live streaming and real-time updates

The cockpit holds a WebSocket-only Socket.io connection to your organization. Everything on the board updates live for every viewer: task moves and status changes, agent questions, task group changes, and even column configuration edits propagate instantly.

Agent sessions stream in real time too. Clicking a task opens a right-side detail panel with the task's dependencies, description, the agent conversation (when a question exists), an assign dialog, and a live activity timeline fed by streamed agent text, tool activity (which tool the agent is using, with details), and status events. When an agent restarts after advancing to a new column, a labeled separator marks the new session in the timeline.

Responding to agent questions

When an agent needs a decision, it pauses and the task enters Awaiting Input. The board updates live and the task detail panel shows an "Agent asked" section with the question rendered as markdown. Type your answer (up to 2000 characters) and the agent resumes; the task returns to Active.

You can also answer from the terminal:

forge session respond <taskId> "Use PostgreSQL, not SQLite"

This sends your response through the cloud and prints "Response sent — agent will resume shortly."

One beta limitation: there is no approve/request-changes review panel in the cockpit yet — a review flow exists in the codebase but is not surfaced in the task detail panel. When a task reaches a review column, inspect the agent's branch locally with forge task open <taskId> and complete the task by dragging it into the last column of its pipeline.

Retries, requeue, and cooldown

Failed tasks are automatically requeued up to the column's maxRequeue limit (default 5). When the limit is reached, the task is released back to the backlog — unassigned, sub-status cleared — instead of retrying forever. The retry counter resets whenever a task advances to a new column.

Exhausted AI credits are handled separately: a token-exhaustion error does not consume retry budget. Instead, the CLI device enters a cooldown (default 20 minutes, configurable 1–120) during which it is excluded from dispatch. The Settings → CLI Devices page shows a countdown and a "Re-include" button to clear the cooldown early.

Resync after disconnect

The CLI journals every event it emits as NDJSON files under ~/.forgeai/events/. If the WebSocket drops, events keep accumulating locally and are replayed to the cloud over REST when the connection returns. The sync endpoint deduplicates events by ID within a 24-hour window and rate-limits each CLI to 10 sync requests per minute, so replays are safe and idempotent. You can inspect the journal with forge journal status.

When a CLI disconnects mid-work, its Active tasks transition back to Waiting and are re-dispatched to other available CLIs in the org. Tasks in Awaiting Input or Corrections Requested keep their state — human-intervention states survive disconnects. CLI presence itself is tracked by heartbeats with a 60-second timeout.

One beta limitation: task updates replayed through the resync endpoint are relayed to connected browsers but not yet persisted to the database, so a board refresh reflects the last state written over the live connection. See Troubleshooting if a board looks stale after a disconnect.

When all of a workflow's tasks are done, the board's work feeds into releases and merge-back.

BMAD workflowsReleases & merge-back

On This Page

The boardTask statusesTask groups and dependenciesStarting executionHow agents run on your machineLive streaming and real-time updatesResponding to agent questionsRetries, requeue, and cooldownResync after disconnect
Sign in