Let the Sazabi agent read your Langfuse traces and scores

Last verified on Nov 8, 2026.

When an LLM feature misbehaves, two records matter. One is your application's: requests, errors, the downstream calls. The other is Langfuse's: the trace of model calls, what each step received and returned, and the scores attached afterward. Reading them separately means you find a bad answer in one place and a failing service in another, then guess whether they are related.

Sazabi, the AI-native observability and security platform, lets its agent read Langfuse during an investigation. Langfuse is not a log source here. It is something the agent consults, next to the logs Sazabi already holds.

What the Sazabi agent can do with Langfuse

The MCP connector reaches Langfuse's hosted server at /api/public/mcp, scoped to Langfuse Cloud US, EU or JP. Sazabi sends a project API key pair, the pk-lf- and sk-lf- keys, as Basic Auth. From there the agent can:

• Query traces and observations
• Retrieve metrics, scores and evaluation results
• Read comments attached to traces and observations
• Fetch managed prompts from Prompt Management

The sandbox CLI is the second route. langfuse runs inside the agent's sandbox with LANGFUSE_PUBLIC_KEY and LANGFUSE_SECRET_KEY, plus LANGFUSE_HOST if you run your own instance. It is meant for traces, prompts, datasets and scores.

Langfuse's own docs shape what you can ask. An observation is one step of a trace, whether an LLM call, a tool call or a retrieval. A trace groups observations that share a trace_id. Attributes such as user_id, session_id, tags and metadata sit on every observation in the trace, and sessions group traces from one conversation. Langfuse also notes that its server exposes write tools alongside read tools by default, so treat the key you hand over as the boundary.

Questions it answers

• Which traces from the last hour carry a low score, and what did the model see in them?
• Did a prompt version change before the quality drop?
• Is this user's session a one-off, or do other sessions show the same failure?
• What did reviewers say in comments on the worst traces?
• Do the slow traces line up with errors in our own services?

A worked example: a score drop on one tag

Your app attaches a numeric correctness score to traces, which Langfuse's SDKs support by trace_id. Scores can also be categorical, boolean or text. After a deploy, the on-call engineer sees complaints that answers from the billing assistant are wrong.

Ask in a Sazabi thread:

In Langfuse, find production traces tagged billing-assistant since 14:00 with a
correctness score under 0.5. Group them by prompt version and show any comments.
Then check our API logs for errors between 14:00 and now.

The agent reads traces, scores, comments and the managed prompt from Langfuse, then queries your logs in Sazabi. Two answers are useful. If every low-scoring trace used the new prompt version, the prompt change is the suspect and you have the exact versions to diff. If the scores are low across versions and the API logs show timeouts from a retrieval service, the model is reacting to missing context, and the fix is in the service. Both conclusions rest on specific traces, because you can name them.

How it fits with other integrations

Langfuse sits in the same corner as LangSmith, Braintrust and Respan, all of which reach Sazabi through an agent connector. They are listed under AI frameworks. Langfuse is built on OpenTelemetry, so your app's own spans can also go to Sazabi through the OpenTelemetry integration. See pricing for how volume counts.