Does Tessary's frustration classifier ever read another call site's messages as context?

No. The classifier’s prior-turn context comes only from earlier turns of the same conversation that reached the same call site; a turn that only ran a router or a memory pass doesn’t count as one of them, even though it happened earlier in the same thread. That’s a fix, not always the behavior: the scorer used to pick a trace’s first root span regardless of which call site it belonged to, so a router’s prompt could get read as the user’s own message and a memory pass’s JSON reply as the assistant’s, and head-and-tail clipping on long messages sometimes kept that noise while cutting the real reply the user saw. Call sites exist so Tessary can tell a router’s prompt from a user’s message in the first place; frustration’s scoping is this classifier’s own use of that distinction. One user turn that fans out to a router call, a reply, and a memory pass behind the scenes only ever gets judged against the two earlier turns on the one call site that actually replied to the user.

sources

keep reading

More on this.

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.

what's includedper organization
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