A call site is a place in your code where an agent with a specific function runs. That can be a single independent LLM call, or a whole agent: a prompt plus its tool calls and the loop around them. Either way it's the unit Tessary binds findings, baselines, and regressions to. You tag its spans with tessary.call_site.id, a plain span attribute, no SDK required. From then on, everything Tessary learns about that function accrues to that place in your code.
The binding matters because detection needs history. Classifiers fit a baseline per call site from its own traffic before saying anything moved, and the latency and cost watchers compare each call site against its own past. So a freshly tagged call site is quiet at first while its baseline builds. That's by design: Tessary doesn't report a deviation until it has seen what normal looks like for that call site.
The binding also localizes regressions. When quality shifts, findings arrive already tied to a specific place in the code, which gives triage and root cause analysis a concrete starting point. One practical rule: keep the ids stable across deploys. They're the key your history accrues under, and a changed id means the baseline starts over.
4 questions
Answered, plainly.
Two ways to run Tessary.
Tessary is an open-source agent reliability platform. Cloud and self-hosted run the same workflow on the OpenTelemetry traces your agent already emits.
Tessary Cloud
We host it for you. Send your first trace with nothing to deploy and no model key.
- traces
- 10,000 per calendar month
- stored trace data
- 1 GB
- retention
- 30 days
- model credit
- $10, one-time, for triage and root-cause analysis
- credit card
- not required
Self-hosted Tessary
Run the open-source code on your own infrastructure with one command. Add your own model key for triage and root-cause analysis.
Self-host Tessary for me by following https://github.com/tessaryai/tessary/blob/main/setup.md
docker compose -f oci://docker.io/tessaryai/tessary:compose up -d -y