LangSmith/Agent/Environment

• LangSmith Agent Environment

  • Overview

    • In an agent-based LangSmith workspace, an agent identifies an application and an environment identifies where that application ran. Each trace belongs to one agent and one of its environments. LangSmith keeps their traces, alerts, evaluators, and built-in dashboards separate. Agents
    • The environment names are fixed: Production, Staging, Development, Local. They classify traces; choosing one does not change the application's code or instrumentation. Agent environments

  • How this differs from tracing projects

    • A project-based workspace groups traces in named tracing projects. A deployment in that model normally creates a same-named tracing project. An agent-based workspace groups traces under an agent and its fixed environments. These are different ways for a workspace to organize observability data. Observability concepts, LangSmith control plane
    • Agent-based workspaces are in beta. Enabling them for an organization affects new workspaces; existing project-based workspaces do not convert automatically. In the LangSmith UI, a workspace name in the top-left control indicates agent mode. The LangSmith logo there, together with an Application picker in the sidebar, indicates project mode. Agents, Observability concepts
    • The control-plane documentation still describes automatic creation of a tracing project named after each deployment. Read that statement in the context of the project-based model; it does not establish the trace destination of a deployment in an agent-based workspace. LangSmith control plane, Deploy to an agent environment

  • Agent, deployment, and revision

    • An agent has a stable identifier used by trace and deployment addressing, plus an editable display name. An agent created by a deployment, by a new-agent dialog, or by its first addressed trace starts with all four environments. An agent built in the LangSmith UI starts with Production; other environments appear when traces reach them. Agents, Create an agent
    • A deployment is a running Agent Server instance. It can be bound to one agent and one deployable environment: Production, Staging, or Development. Local is for traces from local runs and does not appear in the Deployments environment selector. A deployment has revisions: the initial server version and later iterations when code or secrets change. Deploy to an agent environment, LangSmith control plane
    • A deployment's type describes its hosting or capacity choice. Cloud documentation names Serverless and Dedicated; older deployment types include Development and Production. This setting is separate from the agent environment that receives traces. A deployment name containing stage, a Terraform environment tag, or a development-type capacity choice does not by itself prove that traces go to Staging. Cloud platform features, Deploy to an agent environment

  • Why one deployment can sit beside four environments

    • The four environment labels belong to the agent, not to a count of deployments. An agent created through a deployment begins with all four, even if only one deployment exists. Empty environment views mean no traces are visible there; their presence alone says nothing about which environment a deployment uses. Create an agent, Agent environments
    • LangSmith remembers different environment selections in different views. Tracing may open on Local or the last used environment, while Deployments may open on Production. Select the intended environment before interpreting an empty page. Agent environments

  • Binding and trace routing

    • The documented LangGraph and Managed Deep Agents deployment commands bind a deployment with an agent ID and an environment. Both flags must be supplied together; the allowed deployment environments are development, staging, and production. The agent's Overview lists bound deployments. The presence of the deployment in that list establishes the agent binding; inspect the selected deployment environment as well. Deploy to an agent environment
    • Application traces use agent addressing: LANGSMITH_AGENT_ID and LANGSMITH_AGENT_ENVIRONMENT, or an explicit agent address in code. The environment variable accepts local too. Both variables are required; setting only one leaves the call untraced. An address supplied in code takes precedence over the variables. Log traces to an agent
    • Project addressing uses a tracing project name instead. Agent and project addressing cannot be combined for one trace. A project name supplied in code can override agent environment variables. This matters when custom application traces and hosted Agent Server traces are inspected together. Log traces to an agent, Log traces to a specific project
    • To establish where a running deployment's traces land, inspect its agent and environment binding, then produce a known trace. Open that agent's Tracing view and select the expected environment. Check other environments and explicit trace-addressing settings if the trace is absent. An empty set of environment views cannot establish a destination. Deploy to an agent environment, Log traces to an agent

  • Terraform boundary

    • A Terraform deployment resource can describe a deployment's name and type without revealing its agent-environment trace binding. The documented agent binding uses deployment CLI flags. Check the Terraform provider schema and the resulting LangSmith agent Overview before treating Terraform configuration as evidence of that binding. Deploy to an agent environment, LangSmith control plane