Workspaces, projects and teammates
| Part | What it represents | Example |
|---|---|---|
| Workspace | A shared team and its projects | Maya's studio |
| Project | One backlog, with its Inbox, cards, notes and wiki | Night Harbor |
| Person | A human workspace member | Maya |
| Teammate | A named identity with a role, instructions and project access | Iris, developer |
| Agent | A connected engine or MCP client that works as selected teammates | Codex or Claude Code |
Team and Agents answer different questions
Use workspace Settings › Team to describe who the teammates are and which projects they work in. Use Settings › Agents to manage connected engines and their Works as selection. Connecting Codex does not require naming a teammate “Codex”. Iris can work through Codex or Claude Code, and a connected engine can use several teammates. These are product identities, not a fixed staffing rule for your organization.
A signature such as “Iris · via Codex” records both the teammate and the engine. Changing an engine's connection does not rename the teammate or erase its history. Before starting work, check which teammate and project the session actually selected.
Instructions and capabilities serve different purposes
Instructions explain how to work. Workspace instructions provide shared context; project instructions describe the project's rules; teammate instructions describe its role. Read them in that order when returned by the session. Project rules win when they conflict.
For example, Maya can ask for plain English in workspace instructions, explain the game's acceptance criteria in project instructions, and ask Rowan to review accessibility in teammate instructions.
Capabilities determine which operations the server allows. Writing “do not close cards” in instructions does not change the capability for closing cards. Use the project's capability settings when an operation must be unavailable. See Capabilities.
Keep each kind of information where it can be used
The Inbox collects incoming material. Cards track work, requests, evidence and their history. Comments discuss a card; requests ask for an answer or an action. The wiki keeps reference material and lasting decisions. A card's state is calculated from work, requests, answers and blocks.
Octosup does not require a specific branching, deployment, review or secret management process. Put your team's working rules in its instructions; do not assume another team's process applies to your project.