Skip to main content
Teams let you organize agents, traces, and datasets by group — so your ML team sees their data and your product team sees theirs.
“Team” is the product label for what the SDK and API reference call a workspace — they’re the same entity. When the SDK docs say project/workspace, that’s the same scope this page calls a team.

​
Key Concepts

​
Roles

Each capability is granted per role. A check means the role can do it; a dash means it can’t. Organization admins can access all teams regardless of membership.
Billing is always at the organization level — only Admins manage it, and changes apply across every team in the org. See Pricing for per-plan limits.

​
Data Scoping

When you switch teams, you see only that team’s data:
  • Agents belong to the team where they were created
  • Traces are routed solely by the API key you send them with (see SDK Integration)
  • Datasets and experiments belong to the creating team
  • Skills have their own visibility rules (see below)
  • Billing is always at the organization level

​
SDK Integration

Behind the scenes, a “team” is the Workspace entity — the UI labels it “Team,” but the SDK and REST reference call it a workspace. There is no team= parameter or DECIMAL_TEAM env var; routing is resolved from your API key alone — the workspace the key is scoped to. The project you pass to init() does not affect where a trace lands. The reliable way to route traces to a specific team is a workspace-scoped API key. There is no screen for this: the create dialog in Settings → API keys always mints a global-scoped key, whichever team is active. Workspace scope is set on the API, by passing the team’s workspace id:
The global key that authenticates that call is the one you make in Settings → API keys. See Creating a key for the full parameter list. Then point your SDK at the workspace-scoped key it returns:
A key that carries no workspace scope — every key made in the dashboard — resolves to your Default team, so traces sent with it land there regardless of which team you had selected when you created it.

​
Managing Teams

In the sidebar: Click the team name dropdown to switch or manage teams. In Settings → Teams:
  • View all teams and members
  • Create new teams
  • Invite members, change roles
  • Rename a team, or delete it from the Danger zone under Team settings (admins only)
  • The Default team cannot be deleted or renamed
Delete team only works on an empty team. A team that still owns traces, datasets, manifests, skills, experiments, projects, or API keys can’t be deleted — the request comes back naming what’s still in it, so you can move or remove those first. Nothing is cascade-destroyed on your behalf.

​
Skill Visibility

Every skill has a visibility level set at creation time: The default visibility for new skills is Organization (maximum discoverability).

​
Sharing Skills

For Team and Personal skills, share access without changing visibility:
  1. Open the skill → Settings tab
  2. In Sharing & Access, click ”+ Share”
  3. Choose a team or person
  4. Set access: View (use the skill) or Edit (modify it)

​
Cloning Skills

When you clone a skill:
  • Gets its own name (you choose)
  • Copies the latest version’s content
  • Owned by your current team
  • Inherits the original’s visibility
  • Fully independent — edits don’t affect the original

​
Important Notes

  • Visibility is permanent. Once set, it cannot be changed. Clone the skill if you need a different level.
  • Organization skills don’t need sharing. Everyone can already see them.
  • Skills follow the team. Adding someone to a team gives them access to Team-visible skills automatically.

​
Next Steps

Skills Guide

Create, version, and publish skills.

Pricing

Per-plan member and workspace limits.