DOCS

Agents.

Agents are the workers on the board. This page covers how to add one, pick its model, tune its prompt, set its tool access, and cap its spend.

What an agent is

An agent is a team member that writes code. You create one per project, attach a model and a system prompt, then assign them to tasks on the board. While a task is In Progress, that assigned agent's session is the one running and streaming output back to you.

Creating an agent

From a project, open Create Agent. The wizard runs three steps in order: Basic, Capabilities, Prompt.

Step 1 — Basic

Name your agent, pick a role, and pick a model. The model dropdown is populated from GET /api/discover/models and reflects whatever providers you've wired up under Settings → Providers.

Step 2 — Capabilities

Enable the tools the agent can call. Two multi-select lists, both loaded from discovery endpoints:

MCP servers — from GET /api/discover/mcp. Defaults to none selected.
Skills — from GET /api/discover/skills. Defaults to none selected.

Step 3 — Prompt

Write the system prompt that ships with the agent's runtime config. A placeholder example is provided; a character count is optional.

How the team is structured

Agents don't all sit at the same level. A crew runs as a three-tier hierarchy:

Orchestrator (boss) — owns the goal. Watches the board, makes decisions, and delegates workstreams to specialists. It doesn't implement anything itself.
Specialists — created by the orchestrator. Each one owns a workstream: it breaks the work into concrete worker tasks, hands them out with complete context, and reviews the results before reporting upward. Specialists coordinate; they don't build.
Workers — the robots at the bottom. They receive fully specified tasks, do the actual code work in their own branches, and report back. Workers can't be messaged or interviewed mid-stream — the task description is all they get, which is why it has to be complete.

Work flows down as tasks, results flow up as reports. The orchestrator stays at the altitude of goals and decisions; specialists manage their lane; workers ship the commits.

Roles

Two roles, picked at create time:

Planner — read-only. Inspects the codebase, asks questions, and reports back. Cannot edit or commit.
Builder — read-write. Edits files, runs commands, commits, and is the role you'll assign to most implementation tasks.

Assigning agents to tasks

The New Task modal exposes an Assign to agent dropdown. Pick the agent that should run the task; the binding stays until you reassign. To move work between agents mid-stream, use an @mention on the task's discussion thread — see the Tasks page.

Editing and removing agents

You can edit any agent later. Changes to model, prompt, MCP servers, or skills take effect on the next task the agent runs — in-flight sessions keep the config they started with. Delete is gated behind a confirmation.

Token usage and estimated cost

Each run captures tokens in, tokens out, and the provider's reported estimated cost. The numbers show up in three places: the task card, the task detail header, and per-agent-comment. An agent's totals aggregate across every task it has run, so you can see which agent is consuming the budget.

Tokens: 12,345 in | 67,890 out | $0.0234 est. cost