Let the Sazabi agent inspect your LangSmith runs and traces

Last verified on Nov 8, 2026.

An agent built on LLM calls can fail without raising anything. A tool returns an error string, the model improvises, and the user gets a confident wrong answer. LangSmith keeps the record of each step. Your logs keep the record of what the services behind those tools were doing.

Sazabi, the AI-native observability and security platform, lets its agent read LangSmith while it investigates. It does not copy LangSmith data into your logs. It looks things up when a thread needs them, then uses what it found with the log data Sazabi already holds.

What the Sazabi agent can do with LangSmith

The MCP connector authenticates with OAuth 2.1 and dynamic client registration. During connection you choose the region your organization is in: GCP US, GCP EU, GCP APAC or AWS US. With it, the agent can:

• Browse LangSmith tracing projects
• Inspect runs, traces, and their inputs and outputs
• Look up datasets and dataset examples
• Review evaluation results and experiments

The sandbox CLI is the second route. langsmith is already installed in the sandbox, and connecting it stores LANGSMITH_API_KEY, plus LANGSMITH_WORKSPACE_ID if you want to scope it.

LangSmith's vocabulary matters when you phrase a question. A run is one unit of work, such as a model call or a tool call, and runs that belong to one operation form a trace through a shared trace ID. A thread is a sequence of traces from one multi-turn session, grouped by a thread_id metadata key. Each run record carries fields such as run_type, status, error, parent_run_id, tags, total_tokens and feedback_stats.

Questions it answers

• Which runs in this project ended with an error, and which tool did they call?
• Did the failing traces share a thread_id, or are they spread across users?
• What inputs and outputs did the model see just before a bad answer?
• Did an experiment's evaluation results change after the last release?
• Are services behind the tools logging errors at the same time as the failed runs?

A worked example: a trace that never stops growing

LangSmith limits each trace to 25,000 runs and rejects any more sent for it. A loop in an agent can reach that. The signature is odd: one trace, enormous, and a service somewhere being called over and over.

Say a customer reports that one support conversation hung. Ask in a Sazabi thread:

In LangSmith, find the largest trace from the last two hours in the support-agent
project. Show the run_type of the repeating runs and the error field of the last few.
Then look at the logs of the tool service they call for the same window.

The agent uses the connector to find the trace and its runs. If the repeating runs have run_type tool and the same error text each time, the agent is retrying a failing tool. The tool service's logs then say why it fails: a 429 from an upstream API, a missing record, a timeout. You know which end to fix, and you can state it with a trace ID. If the runs are llm calls with no errors, the loop is a prompt or control-flow problem, and the logs rule the service out.

A failing run has status set to error and the message in error, which is why those two field names are worth putting in the question.

How it fits with other integrations

LangSmith belongs with Langfuse, Braintrust and Respan in AI frameworks. Your application's own telemetry reaches Sazabi separately, through OpenTelemetry or a platform source. The integrations index lists all of them, and pricing explains how volume counts.