Project workspaces in OneOrg.
OneOrg projects work best when each project has a clear operating boundary: the right members, channels, dashboard, instructions, skills, agents, labels, and time views for one body of work.
Set up the project boundary
Create a project from the Projects area when work needs its own context. Give it a name that will still make sense in search later, then use the description to explain the project's purpose, not its current task list. After creation, configure the project before inviting heavy activity into it: add members, create the first channels, define labels, write instructions, and decide whether the project needs skills, agents, slides, files, or dashboard widgets.
Use project settings as the control plane. Members decide who participates. Labels decide how tasks are grouped. Instructions tell AI assistants what stays true about the project. Skills capture repeatable procedures. Agents handle recurring roles. The dashboard gives the team a visible operating surface.
A project should be large enough to hold real context and small enough that its tools still point at the same work. If two teams need different access, different instructions, or different AI behavior, split the work into separate projects.
The project boundary is load-bearing.
A practical setup sequence is members first, then channels, then labels and instructions, then skills or agents. That order prevents the team from building AI behavior before the project boundary is clear.
Use the project as the smallest container that can hold the work cleanly. If the team, access rules, instructions, labels, and dashboard all point at the same outcome, one project is enough. If those things diverge, split the work before the project becomes a dumping ground. Review the project setup after the first real week of work. By then the team usually knows which channels are missing, which labels are noise, and whether agents or skills would remove repeated coordination.
Split before context drifts
Use projects for client work, internal initiatives, product areas, delivery streams, or any effort that needs persistent context across people and tools. Review projects periodically: archive or delete only when the team no longer needs the workspace history and configuration.
Do not create a project for every small conversation. Use a channel, task, file, or huddle inside an existing project when the work shares the same team, access model, and operating context.