Notifications
Clear all
Topic starter
20/08/2026 5:51 pm
TL;DR: Raw agent trace logs do not automatically produce reliable eval datasets, because random sampling misses rare failures and hand-written tests usually mirror pre-launch assumptions. Braintrust argues that clustering production usage by task, sentiment, and issue type gives product and engineering teams a better way to turn real interactions into targeted evaluation slices.
NHIMG editorial — based on content published by Braintrust: How to analyze AI agent usage patterns to build eval datasets (2026)
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
Questions worth separating out
Q: How should teams turn production AI agent traces into eval datasets?
A: Start with clustered production traces, not random samples.
Q: Why do random samples fail to give good AI agent eval coverage?
A: Random samples scatter rare failures too thinly to notice and often miss the exact edge cases that create production risk.
Q: What do security and AI teams get wrong about trace-based evals?
A: They often assume any log sample is good enough.
Practitioner guidance
- Build eval slices from clustered production traces Start with Task, Sentiment, and Issues to identify high-volume workflows, concentrated frustration, and concrete failures, then promote only the trace groups that represent real regression risk.
- Review rare failures before they disappear in sampling noise Use clustering to pull low-frequency but high-severity traces into visible review groups, especially where a small failure rate could still affect production outcomes.
- Add custom facets for governance-relevant labels Create domain-specific facets for regulated workflows, compliance flags, or access-sensitive interactions when the built-in labels do not answer the control question you are testing.
What's in the full article
Braintrust's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step Topics workflow for clustering traces from raw logs into reviewable datasets
- Example SQL and API patterns for promoting filtered trace groups into datasets
- Custom facet prompt design examples for domain-specific trace classification
- Daily regeneration and review cadence for keeping eval data aligned with production behaviour
👉 Read Braintrust's guide to turning production usage patterns into eval datasets →
Production trace clustering for eval datasets: what teams need to know?
Explore further
20/08/2026 6:30 pm
Production-derived evals are becoming a governance control, not just a QA convenience. When AI agents operate in live environments, the traces they produce describe behaviour, scope, and failure patterns that should inform control design. That makes eval datasets part of operational governance, especially where agent decisions interact with data access, tool use, or delegated actions. The broader lesson is that teams can no longer separate test quality from control assurance. Practitioners should treat trace-derived evals as a standing part of AI governance.
A question worth separating out:
Q: How do organisations know if their AI eval rubric is actually useful?
A: They should calibrate it against human review on a sample of cases and measure disagreement. If the automated scorer diverges from practitioner judgment too often, the rubric is optimizing the wrong thing. The best evals are domain-specific, explainable, and tied to the outcomes the team actually cares about.
👉 Read our full editorial: Production usage patterns are the right starting point for evals
