> ## Documentation Index
> Fetch the complete documentation index at: https://langchain-5e9cc07a-preview-docsby-1791319236-3be7a15.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Workload isolation
LangSmith uses a hierarchical structure to organize your work: [*organizations*](/langsmith/administration-overview#organizations), [*workspaces*](/langsmith/administration-overview#workspaces), [*agents or applications*](/langsmith/administration-overview#agents-and-applications), and [*resources*](/langsmith/administration-overview#resources). This structure lets you balance collaboration with access control, allowing you to choose the right level of isolation for your team's needs.
What the grouping level is called depends on which information architecture your workspace uses, and the control at the top left tells you which one you are on. An agent-based workspace groups resources by [agent](/langsmith/agents), and each agent's traces divide across [environments](/langsmith/agent-environments) drawn from a fixed set of four. A project-based workspace groups them by application instead, with no environment tier, so environments are approximated with separate tracing projects. Agent-based organization is in [beta](/langsmith/release-stages). The models below apply to both, and the differences are called out where they matter.
The LangSmith permission system builds on this hierarchy. With [role-based access control (RBAC)](/langsmith/rbac), user [permissions](/langsmith/organization-workspace-operations) are scoped to one or more workspaces, enforcing isolation between workspaces. With more fine-grained [attribute-based access control](/langsmith/organization-workspace-operations#access-policies) (ABAC), access can be further restricted or granted based on attributes such as tags, agents, or applications within a workspace, allowing users to access only development resources or only resources associated with a specific agent or application.
This page explains two common approaches to organizing workspaces based on your team's isolation requirements:
* [Team-centric workspaces](#team-centric-workspaces): Single workspace per team (recommended for most customers)
* [Collaborative workspaces](#collaborative-workspaces): Multiple teams per workspace
For details on setting up organizations and workspaces, refer to [Set up hierarchy](/langsmith/set-up-hierarchy).
## Team-centric workspaces
This is the default model and recommended choice for most customers.
This model (single workspace per team) uses a single organization as the top-level boundary. Within the organization, multiple workspaces are used to isolate different teams or business units. Each workspace represents a logical boundary for a specific team and governs which data and resources that team can access. Within a workspace, teams group the resources that support the same application by agent or by application, depending on the workspace.
In the diagram below, production and staging are an agent's environments in an agent-based workspace, and separate tracing projects in a project-based one.
```mermaid actions={false} theme={null}
graph LR
Org[Organization]
WS1[Workspace: Team A]
WS2[Workspace: Team B]
AgentA[Agent or application]
AgentB[Agent or application]
ProdA[Production]
StagingA[Staging]
DatasetA[Dataset]
ProdB[Production]
StagingB[Staging]
DatasetB[Dataset]
Org --> WS1
Org --> WS2
WS1 --> AgentA
WS2 --> AgentB
AgentA --> ProdA
AgentA --> StagingA
AgentA --> DatasetA
AgentB --> ProdB
AgentB --> StagingB
AgentB --> DatasetB
classDef orgStyle fill:#B2DEFF,stroke:#006DDD,stroke-width:2px,color:#030710
classDef wsStyle fill:#E5F4FF,stroke:#006DDD,stroke-width:2px,color:#030710
classDef appStyle fill:#F6FFDB,stroke:#6E8900,stroke-width:2px,color:#2E3900
classDef resourceStyle fill:#F2FAFF,stroke:#40668D,stroke-width:1px,color:#2F4B68
class Org orgStyle
class WS1,WS2 wsStyle
class AgentA,AgentB appStyle
class ProdA,StagingA,DatasetA,ProdB,StagingB,DatasetB resourceStyle
```
* **Pros:** A single workspace allows all team resources to be shared, making collaboration and iteration within a team straightforward. It also simplifies promotion from development to production. For example, the same [prompt](/langsmith/prompt-context-hub#prompts) can be versioned and promoted to production using tags, without copying or duplication.
* **Cons:** Development, test, and production work coexists in one workspace, so workspace-scoped [RBAC](/langsmith/rbac) alone does not separate them. In an agent-based workspace, environments divide an agent's traces without any convention to maintain. In a project-based workspace, separation depends on a naming convention, such as paired projects `checkout-production` and `checkout-staging`. [ABAC](/langsmith/organization-workspace-operations#access-policies) provides more granular permissions within a workspace by restricting access based on resource attributes, such as allowing a user to access only development resources.
## Collaborative workspaces
In this model (multiple teams per workspace), multiple teams share a single workspace within an organization and use agents or applications, together with [ABAC](/langsmith/organization-workspace-operations#access-policies), to separate resources and govern access. As a result, shared resources such as [prompts](/langsmith/prompt-context-hub#prompts) and [deployments](/langsmith/deployment) can be reused across teams, while access to sensitive resources like [traces](/langsmith/observability-concepts#traces) and [datasets](/langsmith/evaluation-concepts#datasets) is limited to the owning team.
```mermaid actions={false} theme={null}
graph LR
Org[Organization]
WS[Shared Workspace]
AgentA[Agent or application: Team A]
AgentB[Agent or application: Team B]
TracesA[Traces: Team A]
DatasetA[Dataset: Team A]
PromptA[Prompt: Shared]
TracesB[Traces: Team B]
DatasetB[Dataset: Team B]
PromptB[Prompt: Shared]
Org --> WS
WS --> AgentA
WS --> AgentB
AgentA --> TracesA
AgentA --> DatasetA
AgentA --> PromptA
AgentB --> TracesB
AgentB --> DatasetB
AgentB --> PromptB
classDef orgStyle fill:#B2DEFF,stroke:#006DDD,stroke-width:2px,color:#030710
classDef wsStyle fill:#E5F4FF,stroke:#006DDD,stroke-width:2px,color:#030710
classDef appStyle fill:#F6FFDB,stroke:#6E8900,stroke-width:2px,color:#2E3900
classDef restrictedStyle fill:#F8E8E6,stroke:#B27D75,stroke-width:1px,color:#634643
classDef sharedStyle fill:#FDF3FF,stroke:#7E65AE,stroke-width:1px,color:#504B5F
class Org orgStyle
class WS wsStyle
class AgentA,AgentB appStyle
class TracesA,DatasetA,TracesB,DatasetB restrictedStyle
class PromptA,PromptB sharedStyle
```
* **Pros:** Common resources such as prompts and deployments can be shared and reused across teams, increasing collaboration and reducing duplicated work. Unlike the team-centric workspace model, collaboration is not limited to a single team and can span all teams within the workspace.
* **Cons:** Isolation between teams is weaker than in multi-workspace models and depends on correct use of ABAC. Misconfigured tags or policies can expose sensitive [traces](/langsmith/observability-concepts#traces) or [datasets](/langsmith/evaluation-concepts#datasets) across teams, and managing permissions across multiple teams adds operational complexity.
***
[Connect these docs](/use-these-docs) to your agent of choice via MCP for real-time answers.
[Edit this page on GitHub](https://github.com/langchain-ai/docs/edit/main/src/langsmith/workload-isolation.mdx) or [file an issue](https://github.com/langchain-ai/docs/issues/new/choose).