Teams are sub-organization groupings that map your real structure — engineering, security, product — onto exactly the agents and resources each group should reach. Members gain access through a team role, administrators can delegate team management without granting org-wide privileges, and per-team budgets enforce spend limits at the group level. Organization-level roles set the outer boundary; teams add the finer-grained layer on top. For a broader view of how roles and permissions compose across the platform, see RBAC and custom roles for AI operations.
Why org roles alone are not enough
An organization-level role model tells you whether a user is an owner, a billing administrator, or a regular member. It does not tell you which agents a particular product team should be able to run, or whether a junior developer on the platform team should see security dashboards. Without a second layer, you end up with two bad choices: give everyone the same broad access, or try to encode team-level access control entirely through org-level roles, which quickly becomes unmanageable.
Teams solve this by adding a functional layer beneath the organization boundary. Every team has its own membership list, its own role assignments, and its own set of scoped resources. A user can belong to multiple teams simultaneously, carrying a different role in each. The org-level role still governs what they can do to the organization itself, but the team role governs what they can do within that team's scope.
Team roles and what they allow
Praesidia defines three team roles, each matched to a real function:
Team Admin can manage the team itself — adding and removing members, updating roles, and configuring team settings. This makes it possible to delegate team administration to a team lead without granting org-owner access.
Developer has the working access a builder needs: run agents, view tasks, interact with connections, and manage workflows within the team's scope. This is the default role for most practitioners on a team.
Security Viewer has read-only access to security-relevant metrics and dashboards for the team. It is designed for auditors, compliance officers, or security engineers who need visibility without the ability to trigger actions.
These roles are enforced consistently at the platform level — not just in the UI. A Security Viewer on one team cannot trigger agent runs even if the UI surfaces a button: the API will reject the call regardless of how the request arrives.
Creating teams and managing hierarchy
An org owner or an existing team admin can create a team under an organization. Teams support a parent-child hierarchy, which means you can model nested structures — a parent "Platform" team with child teams for "Infrastructure" and "Developer Experience" — without having to flatten your org chart.
Deleting a team that still has active sub-teams is blocked until those sub-teams are removed or re-parented. This guard prevents accidental orphaning of teams that are still in active use.
The team list a user sees is role-scoped: org owners see all teams in the organization, while regular members see only the teams they belong to. This scoping is enforced uniformly, so the view is consistent whether accessed through the API or the UI.
Per-team quotas
Each team can be assigned a usage quota — a cap on how much agent compute or LLM spend the team can consume in a given period. When a team reaches its limit, the quota guard blocks new activity that would exceed the cap.
Quotas serve two purposes. The first is cost control: team leads can set a team budget that is independent of, and nested within, the organization-level budget. The second is fairness: in a large organization with many teams competing for a shared pool of agent capacity, quotas prevent one active team from crowding out the others. For a deeper look at how spend limits layer across teams and the organization, see Budgets and Quotas: Preventing Runaway Agent Costs.
Per-team quota management is available through both the API and the dashboard, so team admins can view their current usage and adjust limits without escalating to an org owner.
The role-scoped team dashboard
Each team has a dashboard that surfaces the metrics relevant to that team's function. What appears on the dashboard depends on the viewer's team role: a Developer sees task history, agent status, and connection health; a Security Viewer sees the security and compliance metrics for the team's agents.
This role-scoped view matters because a single dashboard for everyone either exposes too much or hides too much. Surfacing security metrics to everyone on the team is often unnecessary noise; hiding them from the people responsible for security is the wrong trade-off in the other direction. Role-based dashboard scoping lets both audiences get the view they actually need.
Team agents
Each team has a set of agents associated with it. The team agents view lists the agents scoped to that team, which makes it straightforward for developers to see what is available to them without filtering through an organization-wide agent list that may include dozens of agents they have no context on.
Agent association at the team level also means access decisions are explicit. An agent must be deliberately associated with a team; it does not automatically become available to all teams in the organization. This prevents the kind of capability creep where an agent built for one use case gradually gets used by teams that were never intended to have access to it. For the full agent identity and access model, see How to Give an AI Agent Its Own Identity.
SCIM integration with teams
The team model integrates with SCIM 2.0 Group provisioning. When your identity provider pushes a group membership change via SCIM, the platform maps that group to the corresponding team and updates membership accordingly. Each team carries an external identifier that links it to the IdP-side group identity.
This means the joiner-mover-leaver lifecycle for teams can be driven entirely from your IdP. When a new hire is added to the "Platform Engineering" group in your directory, they appear in the Platform Engineering team with the appropriate role — no manual step required. When they leave or move teams, the same SCIM push removes them or reassigns them.
The combination of SCIM provisioning and team-role enforcement closes the loop between your identity management tooling and the access control layer in the AI control plane. For a full walkthrough of how SCIM provisioning works end-to-end, see automating user lifecycle with SCIM 2.0.
Common questions
Can the same user have different roles in different teams?
Yes. A user can belong to multiple teams simultaneously, with a distinct team role in each. A developer who is a Team Admin on the platform team and a Developer on the product team carries both role assignments independently. Their effective access in any context is determined by the role they hold in the specific team being accessed.
Can a Developer add new members to a team?
No. Adding members requires the Team Admin role. The platform also checks whether adding a new member would push the team over its configured quota, and blocks the operation if so. Both checks are enforced server-side, not just in the UI.
How do teams relate to organization roles?
Organization roles and team roles operate at different layers. An org-level member role grants entry to the organization but not to any team-scoped capability. A team role then grants additional capabilities within that team's scope. The two checks are independent and both must pass — a user who holds a Team Admin role but has been removed from the organization entirely loses all team access immediately.
If you want to see how teams fit into the broader access control model alongside RBAC and SCIM, see SSO and SCIM: enterprise identity for AI tools for how these layers work together end to end.
How do per-team budgets interact with the organization-wide budget? Per-team quotas are nested within the organization-level budget. A team cannot exceed its own quota even if the organization still has capacity remaining, and the organization-level cap applies regardless of how individual team budgets are set. This two-layer model lets you delegate cost ownership to team leads without losing the overall spending ceiling that protects the organization. For more on how spend limits are structured across the platform, see budgets and quotas: preventing runaway agent costs.