Projects and your workspace
Everything in CommandChain sits inside two containers: your workspace, which is your company, and the projects inside it, which are the things your company is building and taking to market.
The workspace is your company
Section titled “The workspace is your company”A workspace holds one company’s work, and it is the boundary the platform enforces. Your agents, your history, your knowledge, and your settings belong to it, and nothing crosses from one workspace to another.
Some things are deliberately workspace-wide rather than per project, because they describe the company rather than one piece of work:
- Your AI team. Agents are hired once and work across every project.
- The company profile. One canonical understanding of who you are, which every agent reads.
- Autonomy levels and budgets. The limits on what agents may do and spend.
- People, roles, and permissions. Who can see and change what.
- Knowledge. What the platform remembers, searchable across the workspace.
A project builds and markets one thing
Section titled “A project builds and markets one thing”A project is not a code repository and it is not a campaign. It is the single unit that owns both sides of one product: the building of it and the taking of it to market.
That pairing is the point. A launch post written in the same project that shipped the feature can be grounded in what actually shipped, rather than in a roadmap somebody pasted into a brief.
A project holds:
| What | Why it lives here |
|---|---|
| Repositories | The code this product is built from, and what agents may touch |
| Environments | Variables and secrets, released to a run one attempt at a time |
| Tasks | The work, each with a short key minted from the project key |
| Meetings | The conversations that shape this product |
| Intent | The objectives, requirements, and decisions the project is working from |
| Marketing | Campaigns, content, and the calendar behind them |
| Initiatives | The threads that connect a decision to a shipped and marketed change |
How everything attaches
Section titled “How everything attaches”Most objects in the product point at a project, and the connection is what makes the trail readable later.
- A task normally belongs to a project, and its short key comes from the project key: a project keyed
SUMmintsSUM-14,SUM-15, and so on. - A meeting is held in a project, so the drafts it produces merge into that project’s tasks.
- An initiative is anchored to the meeting where the intent was expressed, and therefore to that project.
- A campaign and its assets hang off the project’s marketing side.
- A run inherits its repository and environment from the task’s project.
When to create a second project
Section titled “When to create a second project”One product usually wants one project. Create another when the work has a genuinely different audience, repository set, or launch, in the way that a product and its go-to-market effort can be separate bodies of work with their own tasks and their own meetings.
Splitting a single product across many projects fragments the trail: a decision made in one project’s meeting cannot ground the marketing that runs in another.
Next steps
Section titled “Next steps”- Tasks: the unit of work a project holds, and the spec agents receive.
- Initiatives and flow: how work is tracked from intent to shipped.
- Using CommandChain: the guides for creating projects, connecting repositories, and setting environments.