Stop your agent from breaking in production.
Tessary ingests your agent’s production traffic, detects failure signals, and fixes it automatically.
Tool call dropped a required field.
- Signal
- missing
customer_idon refund - Where
- checkout agent · refund tool
- Trace
- live · 2 turns
Slack #agent-alerts, with the failing trace attached.
Agents break from changes nobody connected to the agent.
A prompt edit, a model version bump, a refactor, an infrastructure change. Any of them can move behavior on inputs you never touched. Most teams find out from a support ticket, then spend the day reading traces by hand.
Two places we catch a failure: before it merges, and in production.
Both run at once, on one graph. What Tessary learns in production sharpens what it predicts on the next pull request.
Prevent obvious issues from shipping.
- Read the diff on every pull request.
- Predict the failure families the change endangers.
- Post a trouble report. The CI gate can block the merge.
Catch what slips through, on live traffic.
- Ingest traffic over OTLP, or pull a slice from Langfuse or Braintrust.
- Detect failure signals over the graph: classifiers and regex you write in plain language, tool-error extraction, per-tenant models.
- Alert your tools with the failing trace, and raise a fix.
Read the next pull request before it ships.
Observability watches production after the fact. CI runs the tests you wrote. Neither reads the development diff to predict which production failures a change will cause. Tessary does, and can block the merge before anyone is paged. Same graph, versioned by commit.
Two failure families at risk.
- Touched
- retrieval ranker, prompt v7
- Predicted
- context dropout, stale citation
- Lineage
- commit a1f9c2
Posted on the pull request. Merge held until a reviewer signs off.
It fits the stack you already run.
- Ingest
- OTLP gRPC / HTTP, gen_ai OpenTelemetry conventions
- SDKs
- TypeScript, Python
- Pull from
- Langfuse, Braintrust
- Alerts to
- Slack, Sentry, PagerDuty, Linear, webhook
- Runs on
- your own model providers
What it does, plainly.
Does it run before deploy or in production?
Both, in parallel, on one graph. Before merge, it reads the pull request and predicts which failures the change endangers, and the CI gate can block it. In production, it watches live traffic, detects failure signals, and raises a fix. What it catches in production sharpens what it predicts on the next pull request.
What does it watch?
Your agent’s production traffic, ingested over OTLP or pulled from Langfuse or Braintrust. Signals run over that traffic and record a verdict per check.
How does it catch problems from changes that are not prompt edits?
Detection runs on the agent’s actual output, and the pre-deploy report reads the diff itself. A refactor or a model version bump that shifts behavior is routed to the failure families it endangers, the same way a prompt change would be.
Where do alerts go?
Slack, Sentry, PagerDuty, Linear, or a webhook, as digests, briefs, or threshold alerts, with the failing trace attached.
Does it work with my trace tooling?
Connect Langfuse or Braintrust as an upstream source and pull a chosen slice on demand. Once it lands, it is first class for detection and for pre-deploy prediction.
What runs in CI?
A GitHub Action posts the pre-deploy trouble report on the pull request and can gate the merge. Commit-SHA lineage ties every run to the change that caused it.
Stop shipping agent changes blind.
Connect your repo or an existing trace source, see what your agent does in production, and read the next pull request before it ships.