Agent Reliability

Find what broke your agent in your Langfuse traces

Connect your existing Langfuse project as an upstream source and pull a slice of production traffic on demand. No new SDK, no re-instrumentation, and when a grader trend drops, Tessary names the change that caused it.

Start with your Langfuse traces

The gap

Traces show the failure, not the cause

A 2026 dev.to post about building an automated fix pipeline opens with an engineer staring at a Langfuse dashboard that read 'Fifty-three failed traces,' all from the same RAG pipeline he'd spent three weeks building. He went through four diagnose-and-redeploy cycles in six weeks, and each round surfaced an edge case the previous fix hadn't touched. The traces held the evidence the whole time. The step that took six weeks was getting from a failing trace to the change behind it, and that step was manual every round.

Dev.to case study ↗

Why signals still matter

Testing lags production traffic

Tracing tells you a trace happened. It doesn't tell you, at scale, whether that trace was a failure.

39.8%

of teams rely on offline evaluation as a testing strategy

LangChain State of AI Agents, 2024 (langchain.com/stateofaiagents)

32.5%

run online, in-production evaluation

LangChain State of AI Agents, 2024 (langchain.com/stateofaiagents)

What you get

One grader layer, no new tracing code

Connecting Langfuse adds detection and cause-finding over traffic you already capture, without touching the agent.

A grader layer over traffic you already have

No new tracing code in the agent. The connector reads what Langfuse already captured and runs graders against it, each one flagging a specific failure mode.

Alerts where your team already looks

Digests, briefs, and threshold alerts land where your team already triages, not a second dashboard to check.

Graders drafted, not hand-written

Tessary drafts graders from the behavior it observes in your Langfuse traffic; you correct them rather than write and maintain evaluators by hand. That intent lives outside the agent code and sharpens as bugs get fixed.

How it works

From Langfuse connection to cause in four steps

Start narrow, then widen the slice once the first graders prove out.

Connect your Langfuse project
Add your existing Langfuse project to Tessary as an upstream source. No changes to your agent code or tracing setup.
Pull a slice of production traffic
Choose a project, a date range, or a filtered set of traces, on demand, starting as narrow as one incident’s worth of traces.
Configure graders and alert routing
Define the failure modes to detect, in natural language or through automatic tool-error extraction, and choose where flagged traces should land.
Get the cause, not just the flag
When a grader trend drops, Tessary traces the failing quality dimension back through the agent’s chain to the change that caused it, and the alert arrives with that suspected cause attached.

Before and after

What changes once Tessary is connected

Langfuse keeps tracing, prompt management, and cost tracking. Tessary adds the step from a moved score to the change that moved it.

Langfuse alone

Scores can move; causes stay open

Every span and tool call is captured, and evaluators you configure can score them
When a score drops, neither the score nor the trace names the change behind it
Causes outside the diff, like a model update or an upstream shift, stay invisible

Tessary

Langfuse + Tessary

Drops are detected and attributed

Graders run over your Langfuse traffic and flag specific failure modes
A drop is traced back through the agent chain to the change that moved it
Alerts land where your team already triages, suspected cause attached

Full comparisonHow Tessary compares to Langfuse and Braintrust, and why teams run it alongside both.

FAQ

Questions about the Langfuse connector

It's a Tessary integration that connects to a Langfuse project you already run and pulls a chosen slice of production traces on demand. Nothing changes in your agent code: no new SDK, no dual tracing, no re-instrumentation. Once a trace lands, it's treated the same as traffic Tessary ingests directly: graders score it, trends are tracked, and a degradation gets traced back to a cause.

No. Langfuse keeps doing what it does: tracing, prompt management, cost tracking, and any evaluators you've configured. What it can tell you is that a score moved. Tessary adds the part it doesn't attempt, working out which change moved it. The two run side by side, with Tessary reading a slice of Langfuse traffic through the connector.

A signal is a grader that runs over your traces and flags a specific failure mode, defined either in natural language (turned into a classifier or a regex) or through automatic tool-error extraction. Tessary reads the trend across grader verdicts over time, not any single score. An imperfect grader misfires at a stable rate, so a trend that jumps from 3% to 11% marks a real change in behavior. Each signal has a precision mode for discovery versus tracking, so a new failure pattern surfaces without flooding the team with alerts for known issues.

The grader that fired names which dimension of quality broke. Tessary traces that dimension back through the agent's chain to the change that lines up with the drop: a prompt edit, a tool update, a dependency bump, an upstream agent's output shifting, or a model provider update that never touched your repo. The alert carries that suspected cause, so the fix starts from a candidate change rather than a pile of failing traces.

You choose the slice: a project, a date range, or a filtered set of traces. Tessary pulls that slice on demand rather than mirroring your entire Langfuse history, so you can start with a narrow window, like the traces behind a recent incident, before deciding whether to widen it.

The same destinations any Tessary signal can reach: Slack, a generic webhook, Sentry, Linear, and PagerDuty. Signals from Langfuse-sourced traces aren’t treated differently from signals over traffic ingested directly through the OTLP receiver; alert routing, digests, and threshold rules apply the same way regardless of source.

Attribution goes as far as the traces allow. When a trace goes dark partway to a cause, Tessary points at the gap, and that gap is the next node to instrument, through the Tessary SDK or your existing OTEL setup. Start with zero changes to your agent, add a node only where a cause hunt hits a wall, and the next degradation is easier to trace.

Before the mergeThe same attribution engine runs pre-deploy. See how flagged failures score the next pull request.

Keep exploring

Get started

Start with the traces you already have

The traces already exist in Langfuse. Point Tessary at them, and the next time a grader trend drops you get the change behind it, not just a flag. No credit card needed to connect a source.