Skip to main content
This page covers project addressing, which routes a trace by naming the tracing project it lands in. Agent addressing is the alternative, and a trace uses one or the other rather than both.
Project-based workspaces. This section applies if your workspace organizes traces by tracing project. To check, look at the control at the top left. In a project-based workspace, it shows the LangSmith logo, and the sidebar has an Application section with an application picker. If the control shows your workspace name instead, your workspace is agent-based, which is in beta. Skip this section and read Agents.
This page covers how to control where LangSmith sends your traces: To send every trace to more than one destination at once, see Write traces to multiple destinations with replicas.

Set the destination project statically

LangSmith uses the concept of a project to group traces. If left unspecified, the project is set to default. You can set the LANGSMITH_PROJECT environment variable to configure a custom project name for an entire application run. Set this before running your application:
The LANGSMITH_PROJECT flag is only supported in JS SDK 0.2.16 or later, use LANGCHAIN_PROJECT instead if you are using an older version.
If the project specified does not exist, LangSmith will automatically create it when the first trace is ingested.

Set the destination project dynamically

You can also set the project name at program runtime in various ways, depending on how you are annotating your code for tracing. This is useful when you want to log traces to different projects within the same application:
  • Pass the project name at decoration or configuration time.
  • Override it per individual call.
  • Set it when constructing a run directly.
Setting the project name dynamically using one of the following methods overrides the project name set by the LANGSMITH_PROJECT environment variable.

Set the destination workspace dynamically

If you need to route traces dynamically to different LangSmith workspaces based on runtime configuration (e.g., routing different users or tenants to separate workspaces), the approach differs by language:
  • Python: use workspace-specific LangSmith clients with tracing_context.
  • TypeScript: pass a custom client to traceable, or use LangChainTracer with callbacks.
This approach is useful for multi-tenant applications where you want to isolate traces by customer, environment, or team at the workspace level. It works with any LangSmith-compatible tracing, including LangChain, OpenAI, and custom functions decorated with @traceable.

Prerequisites

Generic cross-workspace tracing

Use this approach for general applications where you want to dynamically route traces to different workspaces based on runtime logic (e.g., customer ID, tenant, or environment). Key components:
  1. Initialize separate Client instances for each workspace with their respective workspace_id.
  2. Use tracing_context (Python) or pass the workspace-specific client to traceable (TypeScript) to route traces.
  3. Pass workspace configuration through your application’s runtime config.
  4. Override both the workspace and project name per route to organize traces further within each workspace.

Override default workspace for LangSmith deployments

When deploying agents to LangSmith, you can override the default workspace that traces are sent to by using a graph lifespan context manager. This is useful when you want to route traces from a deployed agent to different workspaces based on runtime configuration passed through the config parameter.
When deploying with cross-workspace tracing, ensure your service key or PAT has the necessary permissions for all target workspaces. We recommend using a multi-workspace service key for production deployments. For LangSmith deployments, you must add a service key with cross-workspace access to your environment variables (e.g., LS_CROSS_WORKSPACE_KEY) to override the default service key generated by your deployment.