.png&w=640&q=75){kind=small}
Overview
If you run a platform that ships LangGraph agents to many customers, you have to decide how to slice LangSmith resources. The two main constructs are workspaces and projects, and they are not interchangeable.
Short version:
Workspaces isolate unrelated teams. They are a hard boundary.
Projects group traces, Engine configs, and Context Hubs for one agent or deployment, inside a workspace.
For multi-tenant platforms, the tenant unit is the project (and on LangGraph, the assistant), not the workspace.
Do not use workspace-per-customer
Workspaces are a strict isolation boundary. Evaluators, dashboards, prompt libraries, and Context Hubs cannot be shared or aggregated across workspaces. Enterprise plans also cap the number of workspaces.
If you put each customer in their own workspace, you lose:
Cross-customer evaluator sharing
Aggregated dashboards across your customer base
Cross-customer benchmarking
You also pay operational overhead for provisioning a workspace per customer, and you will eventually hit the workspace ceiling.
Use workspaces to separate teams that don't work together (for example, a research team and a production team in the same org). Not customers.
Use one project per assistant
The right tenant unit is the LangSmith project, with one project per customer deployment of a given graph. On LangGraph, that lines up one-to-one with the assistant object, so "project per customer" and "project per assistant" mean the same thing.
Each per-assistant project gives you:
LangSmith Engine configured per assistant
Context Hub scoped to that assistant
Prompt Hub entries referenced by that assistant
Clean per-assistant trace history
Decision rule:
Assistants differ meaningfully (different tools, models, prompts): separate project per assistant.
One graph with minor per-user config differences: one shared project with filter-based segmentation is acceptable. This case can go either way.
Benchmark across assistants with a shared project
Because projects are isolated, cross-assistant analytics need a shared destination. The pattern:
Each assistant traces to its own dedicated project.
Traces are also duplicated to a shared benchmark project, one per graph type or sector.
The benchmark project is where you do cross-customer aggregate analysis, prompt comparison, and best-practice extraction.
For live benchmarks, duplicate in real time rather than via a cron job.
Prompts: custom per assistant
When assistants have meaningfully different tools and behaviors, give each one its own prompt in Prompt Hub and reference it by prompt ID in the assistant's context schema. Trying to extend one universal base prompt with per-customer overrides costs you configurability and makes cross-assistant prompt benchmarking harder to read.
Reference architecture
LangSmith Workspace (one per platform operator)
│
├── Project: {customer_A}-{graph_name} ← per-assistant tracing project
│ ├── Engine: enabled for customer A
│ ├── Context Hub: customer A-specific
│ └── Prompts: customer A's prompt IDs
│
├── Project: {customer_B}-{graph_name} ← per-assistant tracing project
│ ├── Engine: enabled for customer B
│ ├── Context Hub: customer B-specific
│ └── Prompts: customer B's prompt IDs
│
└── Project: benchmark-{graph_name} ← shared benchmark project
└── Receives duplicated traces from all per-assistant projects
Evaluators, dashboards, and members live at the workspace level and are shared across every project, so the platform operator keeps a single view across all customers.
Why the LangGraph assistant is the tenant layer
On LangGraph, the assistant object holds the per-customer configuration: tool selection, model, prompt IDs, tracing project, Context Hub. End users of your platform operate inside an assistant; they are not themselves the tenant unit. One assistant per customer (or per customer-graph pair) keeps the LangSmith project and the LangGraph assistant aligned one-to-one.
References
LangSmith Projects documentation
LangSmith Context Hub documentation
LangSmith Prompt Hub documentation
LangGraph Assistants API documentation