Should a guardrail result be graded separately from the output?

Yes. A guardrail is answering a different question than the final output is: not “was this response good” but “should this input or output have been blocked,” and folding the two into one grade hides whichever one is actually wrong. An agent can give a correct answer while a guardrail that should have tripped stayed silent, and a passing eval that only scores the final response never catches it.

Build the guardrail’s own eval set the same way you’d build one for a classifier: cases that should trip it and cases that shouldn’t, each labeled with the right verdict, and score precision and recall against that set directly rather than inferring them from downstream behavior. The SDK’s guardrail result carries its own pass or fail independent of what the agent did with it, which is what makes this scoring possible without touching the agent’s output at all. A dataset built from real production traces is a better source for the should-trip cases than ones written from imagination, since a guardrail tuned on hypothetical inputs tends to miss the phrasing real users actually use.

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