Projects

Members and teams are who does the work; projects are where the work lives. A project groups related tasks inside a workspace and gives each of them a readable identifier, so a project is the first thing you create once you have people and agents to do the work. Onboarding sets up your first project for exactly this reason — you need somewhere for tasks to land.

A project groups related work

A project holds the tasks that belong together, along with the labels that classify them, the board states they move through, and the goals assigned to it. Each project carries a short uppercase prefix you choose when you create it — like OPS or WEB — and that prefix is what makes task identifiers readable: it is the stable, human-friendly handle the work is referred to by. The prefix is unique within the workspace, so identifiers never collide across projects.

Goals are not owned by a single project. A goal is a workspace-level outcome that can span several projects, and projects and goals are linked through explicit assignments — a task may only attach to a goal that is assigned to that task's project. Goals covers that relationship from the other side; here, the thing to hold is that a project is the container for tasks and that goals reach into it rather than living under it.

Every project starts with a working board

When you create a project, its board is ready immediately, because every project shares the same fixed set of task states. The states are Backlog (where new tasks land by default), Todo, In progress, In review, Blocked, Done, and Cancelled — Done and Cancelled being the terminal states that end a task's work. These are the columns of every project's board and the lifecycle a task moves through.

This lifecycle is fixed: every project uses the same seven states, and the management screens say so plainly rather than offering controls that do nothing. The states are a single shared definition the whole product reads from, not per-project rows you configure — custom board columns are not a feature today. How tasks actually move through the board — assignment, dependencies, status, and the timeline — belongs to tasks.

Archiving keeps the history

When a project is done, you archive it rather than delete it. An archived project stops appearing as an active destination for new work, but every task, comment, label, and timeline entry it held stays available for review, and you can restore the project if work resumes. Creating and archiving projects, like editing their details, requires the project-management permission; members with only read access can see projects and their work but not change them. As with teams, an agent can propose a project and a permitted member approves it before it becomes active — from the inbox or the Proposed tab on the projects page, where pending proposals gather beside the Active and Archived views.

Projects organize tasks; the next chapter is about the outcomes those tasks add up to. Continue to goals.