Describe how LangSmith picks up LangChain calls with zero code change

Flashcard·Easy·4.0 · 0·~30s·Asked atFigure Ai Pwc Wandb

Attempt it

Your answer

LangChain ships with built-in tracing hooks. Every chain, agent, tool call, and LLM call inside the framework calls into a callback handler. By default that handler does nothing. When you set `LANGCHAIN_TRACING_V2=true`, the handler activates and starts shipping run data to LangSmith. The full setup is three environment variables: `LANGCHAIN_TRACING_V2=true` to turn it on, `LANGCHAIN_API_KEY=ls_...` to authenticate to the LangSmith backend, and `LANGCHAIN_PROJECT=my-app` to name the project the traces land in. No SDK install on top of LangChain (the LangSmith client is already a dependency). No code change. No decorators to add. The reason it is this easy is that LangSmith and LangChain are built by the same team. The instrumentation is wired in once at the framework level, and the LangSmith client is the default destination. For a team already on LangChain or LangGraph, this is the lowest-effort observability backend available. The same coupling is also the tradeoff: the easier the integration, the harder a future migration.

**The wire is three environment variables.** `LANGCHAIN_TRACING_V2=true`, `LANGCHAIN_API_KEY`, `LANGCHAIN_PROJECT`. Set them and any LangChain runnable, agent, tool, or chat model emits run records to LangSmith automatically. No SDK to install separately, no decorators, no callback registration. The framework hits a default LangSmith client every time it runs. **Why the bar is this low.** LangSmith and LangChain are products from the same team and they share the runtime. LangChain's `Runnable` interface has tracing baked into its execution path; every `invoke`, `stream`, `batch`, and `astream` call wraps in a `RunTree` that the LangSmith client knows how to serialize and ship. The two products were designed to fit each other, and the env-var entrypoint is the public expression of that. **Why teams pick it anyway, knowing the coupling.** For shops already standardized on LangChain or LangGraph, the alternative is wiring custom OTel instrumentation for every runnable, which is real engineering work. LangSmith trades portability for time to first trace. Teams on a tight delivery deadline rationally accept that trade. **The hidden cost.** Migration off LangSmith is non-trivial. The traces are in LangSmith's run-tree shape, not in OTel GenAI conventions. Datasets, prompts, and eval configurations live in the LangSmith UI by default. Teams that want optionality wire LangSmith as a callback but also emit OTel spans in parallel; both wires running keeps the door open at the cost of slight overhead.

TL;DR

Three env vars (LANGCHAIN_TRACING_V2, LANGCHAIN_API_KEY, LANGCHAIN_PROJECT) and LangChain's built-in callback emits traces. Same team built both, hence the zero-friction setup.

Memory aid

Easy to grasp

Imagine a smart home where the doorbell, the security camera, and the alarm are all made by the same company. You plug in the camera and the doorbell already knows how to send footage to it; nothing to configure. That convenience comes from the company designing both ends together. The flip side is that if you ever decide you want a third-party camera, the doorbell does not speak the new camera's language and you have to rewire most of the house. LangSmith and LangChain are that smart-home pair. The plug and play setup is the upside; the rewiring on migration is the downside.

Key concepts

Observability and Tracing LLM Frameworks

Concept explanation~2 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

LangSmith's zero code change tracing is its headline feature and its central tradeoff in one. The setup is genuinely as small as documentation claims: three environment variables, no SDK install, no decorators. The reason it can be that small is the same reason the migration cost off LangSmith is real: the LangChain runtime carries LangSmith inside it, by design.

This deep dive walks through the mechanism that makes the setup so small, the coupling implications, and the practical patterns teams use to keep optionality without giving up the convenience.

The three environment variables

The full setup for a LangChain or LangGraph app to start emitting traces to LangSmith is three variables.

LANGCHAIN_TRACING_V2

A boolean flag. When true, the LangChain runtime activates its tracing callback handler. When unset or false, the framework runs identically but the handler is a no-op. The v2 suffix is historical; an older v1 protocol existed and was retired.

LANGCHAIN_API_KEY

A token in the form ls__... (LangSmith) or lsv2__... (newer rotated keys). The handler reads this and uses it as the bearer credential when posting run data to the LangSmith backend. Without the key, the handler runs but every export fails silently in the background; you see no traces in the UI.

LANGCHAIN_PROJECT

A string name. Traces land in a project with this name; the project is auto-created on first write. Different services, different environments, and different test suites should each set their own project name to keep traces separated. A common pattern is ${service}-${env} (checkout-prod, checkout-staging).

What you do not need

No pip install langsmith separately (it is already a LangChain dependency). No callback handler registration in code. No decorator on functions. No tracer provider initialization. The integration is the framework's runtime, and it is on by default whenever the env vars are present.

Why it can be this small

Non-LangChain code: @traceable

Coupling versus lock-in

When the integration is clearly right

Situations where this technique stops working.

2–4 min · Everything important, quickly.

bash

# The entire LangSmith integration for a LangChain app:
export LANGCHAIN_TRACING_V2=true
export LANGCHAIN_API_KEY=ls__your_key_here
export LANGCHAIN_PROJECT=my prod app

# That is it. Start the app. Every chain.invoke(), agent.run(),
# llm.invoke(), and tool call emits a run to LangSmith. No code
# change. No decorator. No instrumentation library.

Real products, models, and research that use this idea.

Every LangChain quickstart notebook in the official docs sets `LANGCHAIN_TRACING_V2=true` as the first cell after imports.
LangGraph studios runs use the same env vars; visualizing a checkpointed graph in LangSmith requires no extra configuration beyond what LangChain already needs.

What an interviewer would ask next. Try answering before peeking at the approach.

QYour team is on LangChain but considering Langfuse for prompt versioning. How do you set up dual write so you can compare and migrate?

Keep LangSmith env vars in place for the runtime tracing. Add Langfuse's LangChain callback handler explicitly to RunnableConfig.callbacks so every call ships to both. Run for a month, compare cost, dashboards, and eval workflows, then commit to one. The dual-write cost is a slight ingest overhead and double observability spend during the comparison.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases that signal junior thinking. Click to expand.

Most common mistake

Setting only LANGCHAIN_TRACING_V2 without the API key, then wondering why local logs show traces being created but the LangSmith UI is empty.

60 second bullets to scan on the way to the call.

The three environment variables and what each does
Why no code change is required inside LangChain

Primary sources. Browse if you want the original framing.