Build

Build is the fourth and final stage of the platform workflow. It takes the verbose implementation tasks produced in Design and executes them autonomously using a background coding agent. You manage the work through a Kanban board, approve task batches before they run, and monitor real-time progress as the agent writes code in your connected git repository.

Who can use it

Available to all authenticated users with an active subscription (both ORG Admins and ORG Members).

Navigate to Build in the sidebar or go directly to /board.

How it works

Board Selector

The Build section opens on a board selector page that lists all your Project Runs. Each Project Run has its own Kanban board. Select the project you want to work on to open its board.

Kanban Board

The Kanban board provides a visual overview of all tasks for a project. Each task card shows:

• Task title and description
• Current status
• Priority level

Tasks are managed in columns representing their status. Status and priority can be edited inline on each card. The board state synchronises bidirectionally with the API. Changes made to tasks by the coding agent are reflected on the board in real time.

The Task Queue (Layer 8)

Before the coding agent can work, the verbose tasks from the Design stage must be enqueued into the agent task queue. This is Layer 8 of the platform pipeline.

When you enqueue tasks from a Project Run:

1. The verbose tasks are converted into Agent Task records in the database.
2. Tasks are grouped into dependency-ordered batches based on the dependency graph computed in Design. Tasks within a batch can run in parallel; batches must complete in sequence.
3. An integration verification task is automatically appended to every batch. This task runs after each batch completes to verify that the newly added code integrates correctly with the existing codebase.

The batching ensures that the coding agent always works on a valid, buildable state of the codebase. It never starts a task that depends on incomplete work.

Batch Approval Workflow

Enqueued task batches do not run automatically. Each batch must be explicitly approved before the worker picks it up.

This is a deliberate design choice. It gives you the opportunity to:

• Review what the agent is about to work on before it touches your codebase
• Hold a batch if requirements have changed
• Stagger execution if you want to review code changes between batches

To approve a batch:

1. Open the board for the relevant project.
2. Review the tasks in the next pending batch.
3. Click Approve to release the batch to the worker.

The worker will pick up approved batches and begin executing tasks.

Worker Execution

A persistent background Layer 8 Worker runs alongside the platform. It polls the database for approved tasks and executes them against your connected git repository.

The worker respects batch ordering. It will not start a new batch until the previous batch (including the integration verification task) is complete or has failed.

As tasks execute, the board updates in real time:

• Task status changes to IN_PROGRESS when the worker picks it up
• Task status changes to COMPLETE or FAILED when the worker finishes
• Failed tasks can be restarted from the board

Stock Worker Mode

The default worker mode uses an Anthropic-backed agent loop. It is equipped with filesystem and git tools that allow it to:

• Read and write files in the repository
• Run shell commands to build, test, and lint the code
• Make git commits

The agent operates in an isolated execution environment against a mounted repository path. An optional read-only mode (AGENT_READ_MODE) can be enabled to allow the agent to inspect the codebase without making any changes, useful for analysis or review tasks.

Tengu Worker Mode

When WORKER_TYPE=tengu is configured by your platform operator, the worker uses the embedded Tengu agent runtime. Tengu provides a richer tool suite including:

• Subagents (explore, plan, verify, general purpose)
• MCP (Model Context Protocol) integration for external tool servers
• Tmux and iTerm2 backends for terminal multiplexing
• Full filesystem, bash, and git tooling

Tengu mode is appropriate for complex projects that require the agent to spawn specialised sub-tasks, use external tools, or work in a more interactive terminal environment.

Contact your platform operator to find out which worker mode is configured for your installation.

Task Restart

If a task fails, it is marked as FAILED on the board. You can:

1. Click Restart on the failed task to re-queue it.
2. Review the task detail to understand what the agent attempted and why it failed.
3. If the failure was caused by a gap in the task specification, return to Design, amend the verbose task via Planner Chat, and then restart.

Planner Chat on the Board

The Planner Chat panel is available on the Build board as well as in Define and Design. On the board, it operates against the backlog artefacts of the Project Run.

Use it to:

• Amend task descriptions before approving a batch: "Rewrite the authentication task to use sessions instead of JWT."
• Add missing tasks: "Add a task to configure the email verification flow."
• Ask questions about the current backlog: "Which tasks in batch 3 depend on the database migration completing?"

How to use it to solve your problem

Running your first build

1. Navigate to Build in the sidebar and select the project you want to build.
2. Click Enqueue tasks to convert the Design verbose tasks into the agent task queue. You will see the tasks appear on the board grouped into batches.
3. Review the first batch of tasks. Check that the descriptions are complete and accurate.
4. Click Approve to release the first batch to the worker.
5. Watch the board as tasks move to IN_PROGRESS and then COMPLETE.
6. When the first batch finishes (including the integration verification), review the second batch and approve it.
7. Continue approving batches until all tasks are complete.

Handling a failed task

1. Identify the failed task on the board (shown in the FAILED column or with a failure indicator).
2. Open the task detail to read the agent's execution log.
3. If it is a transient failure (network, timeout): click Restart.
4. If it is a specification issue: go to Design, amend the verbose task via Planner Chat, return to Build, and restart.

Making mid-build amendments

If requirements change after you have started building:

1. Open Planner Chat on the board.
2. Describe the change needed: "The search feature should use full-text search rather than prefix matching."
3. The chat will amend the affected task descriptions.
4. If tasks have already been completed and need to be reworked, add new tasks via Planner Chat to undo or update the affected code.

How it fits the broader picture

Build is where the platform produces a tangible output in your codebase. Everything from Discover through to Design has been building toward this stage. The problem is framed, the requirements are defined, the solution is designed, and the tasks are precisely specified. The coding agent can work confidently because it has full context for every task.

The Insights page tracks delivery progress across all your Build projects, so you can monitor throughput, identify blocked tasks, and understand agent performance over time. See Insights.