Govern
Projects
A project is the workspace boundary for related agents, loops, conversations, integrations, data, and access.
Projects keep resources that should work together close and resources that need different security or operational boundaries apart. Most daily work in Mobius happens inside one project.
Project or organization?
An organization holds company-wide membership, billing, and administration. A project holds the actual agent work.
| Need | Boundary to use |
|---|---|
| Separate development, staging, and production | Projects |
| Separate products or teams with different access and integrations | Projects |
| Keep agents, loops, and provider connections together | One project |
| Separate unrelated companies and billing owners | Organizations |
Start with one project when the same people, agents, and integrations support the work. Split it when access, environment, audit, or lifecycle differences become real.
What belongs together
Resources in one project can intentionally connect: a loop can use the project's agents and integrations, an agent can use shared tables, and roles can grant access across that related work.
Resources do not cross project boundaries. If two loops should share an agent, Slack connection, or table, that is a strong signal they belong together. If production credentials and customer data should never be visible to a test agent, use separate projects.
Choose stable names and boundaries
Use a short handle that will still make sense in URLs, terminal commands, and
application configuration later. Names such as prod, staging, and
data-platform describe durable boundaries better than version numbers.
For a product that provisions one project per customer workspace, store your own stable workspace reference on the project. That lets callbacks and scheduled work map back to your tenant without relying on a display name. Exact provisioning fields belong in the API introduction.
Tags can add flexible organization inside a project, such as environment, owner, or data sensitivity. Use tags for filtering and ownership cues, not as a substitute for a real access boundary.
Work with projects in the app
Use the project switcher to move between workspaces. Open Settings > General to review the current project's identity and metadata, and Settings > Access to control who and what can act inside it.
Before creating a new project, ask which resource or policy must be isolated. If there is no clear answer, the existing project is usually the simpler home.
The CLI overview explains terminal project selection. The API introduction explains application scoping and tenant mapping.
Next
- Control access with roles and API clients.
- Connect providers with integrations.
- Trace configuration changes with audit logs.