Organizations and Workspaces
The two levels at which everything in AUMO is created, shared and billed.
Every AUMO setting belongs to one of two levels. The Organization represents the company; the Workspace represents a team, product or project within it.
Knowing which level something lives at answers three questions that come up all the time: who can change it, who can see it and where its consumption is counted.
Organization
An Organization is your company's outer boundary on the platform. It keeps the catalog of what is allowed and the rules that apply to everyone.
These belong to the Organization:
- Providers and Credentials: the AI model accounts and the access secrets for external systems.
- SuperAgents: the external agents registered for the company.
- MCPs and Integrations: the registry of what workspaces can install.
- Members and Quotas: who joins the company and how much it can spend.
A person can belong to more than one Organization, with a different role in each. Switching Organizations switches the whole context.
Workspace
A Workspace is where the work happens. It consumes the Organization's catalog and builds its own things on top of it.
These belong to the Workspace:
- Collections: the documents that feed the answers.
- Agents and Workflows: what people use in Chat.
- Installed MCPs and Integrations: the tools actually turned on.
- Models, Variables, Members, Quotas and API keys.
Workspaces don't see each other. A Collection in one workspace doesn't show up for another workspace's Agent, even within the same Organization.
Up to version 3, workspaces were called Projects. The name changed across the platform in v4; the concept is the same.
Catalog and installation
AI providers, MCPs, Integrations and SuperAgents exist at both levels, and that is on purpose. They are two different steps:
- The Organization registers the item once: the provider account, the MCP server, the SuperAgent URL. This is where secrets and approval live.
- The Workspace installs what it will use from that catalog, with its own name and configuration.
The same registry item can be installed several times in the same workspace, as long as each installation has a different name. The configuration belongs to the installation, not to the registry entry.
This design exists so that a credential is stored in a single place, while each team decides what to turn on. A workspace never creates a provider account on its own.
Where this shows up in practice
Three consequences worth remembering:
- Permission: your role in the Organization and your role in each Workspace are independent. You can be the company's Admin and not be a member of a specific workspace.
- Consumption: token spending is attributed to the workspace that made the call, and rolls up to the Organization total.
- Isolation: moving knowledge between workspaces means recreating the Collection, not sharing it.
Next steps
- See who can do what at each level in Roles and permissions.
- Understand how the model catalog flows down to the workspace in Providers and models.