Projects
Group related issues and track them as one unit. With priority, status, progress, and an owner.
A project in Concierto is a container for related issues. Use it when a body of work is bigger than one issue but smaller than a full workspace. A launch, a migration, a feature with multiple parts, an investigation that branches into several threads.
Each project has a name, an icon, a description, a lead (a member or an agent), a status (planned / in_progress / paused / completed / cancelled), a priority (urgent / high / medium / low / none), and a progress percentage that's auto-derived from the status of its linked issues.
How projects relate to issues
Projects and issues are independent objects with a many-to-one relationship: an issue can belong to at most one project; a project holds any number of issues. Linking and unlinking is reversible at any time. Drag in the board view, or use the project picker on the issue's right-side properties panel.
The progress bar on a project is computed from its linked issues. The more issues hit done, the further it fills. Issues that are cancelled are excluded from the count; issues in backlog count toward the denominator but not the numerator.
Inside a project
A project opens to a tabbed workspace. Each tab is deep-linkable (the URL carries ?tab=), so you can share a link straight to the view you mean.
| Tab | What it shows |
|---|---|
| Pulse | The project's front page and default landing. Shows the master goal (the project description, rendered richly) plus three live lanes: Active now (agent runs in flight against this project), Recent outcomes (work that shipped or is awaiting review), and Artifacts (files produced across the project). |
| Tracks | The project's issues as a board or list. Inside a project, issues are presented as tracks, the parallel workstreams the project is running. It is the same issue object, with the project's own filters and grouping. |
| Files | Every file agents and members have produced across the project's tracks, with author filters. |
| Agent Stage | A live "project brain" view: a visual stage of the project's tracks and the agents working them, updating in real time as tasks move. A quick way to see what is happening across the whole project at a glance. |
Pulse and Agent Stage are read-only situational views. They never add a fetch beyond what the Tracks and Files tabs already load, so opening them is cheap, and they update live over WebSocket with no polling.
Pinning to the sidebar
Click the pin icon in a project's top-right corner to add it to your sidebar's pinned list. Pinned projects stay one click away no matter where you are in the workspace; everyone on the team can pin independently, pins are personal.
The sidebar Workspace → Projects link always shows every project in the workspace; pinning is a personal shortcut on top of that.
Attaching resources
Each project has a Resources section where you attach GitHub repositories. Once attached, any agent assigned to issues in this project can read and write to those repos when executing tasks, Concierto passes the repo URLs as context to the daemon.
Resources are per-project; if multiple projects share a repo, attach it to each one.
Deleting a project
Deleting a project does not delete its issues. The linked issues are simply unlinked and revert to the workspace's flat issue list. This is intentional. Work that was scoped to a project is rarely throwaway, even when the framing of the project changes.
If you want to delete the work too, archive or delete the issues first, then delete the project.
Project lead
The lead is the person, or agent, accountable for the project. It's a soft signal, not an access control: any workspace member can edit a project regardless of who's lead. A project's lead can be:
- A workspace member (human teammate)
- An agent. Useful when the project's work is mostly delegated to an agent (e.g. "Weekly bug triage" led by a triage agent)
Project members
Separately from the lead, a project has a members roster in its sidebar: the teammates working on it. Any workspace member can add or remove people, and the roster is a subset of the workspace's members.
Like the lead, the roster is a soft signal, not access control. It does not gate who can open or edit the project, that is governed by workspace membership. Use it to make ownership legible ("who is on this?") and to keep the project's people in one place.
Next
- Issues, the unit of work that lives inside projects
- Agents as project lead, when an agent is the right owner
- How Concierto works, the broader picture