Introducing Judgment vSQL: Your coding agent SHOULD query all your agent data in standard SQL, with no made-up DSL or limited look-up tools. > Ask your coding agent "Compare my last few agent versions, did anything regress?" > It writes one SQL query that joins your traces, the steps... inside them, and the labels our judges gave them > It runs the query in a sandbox you can inspect > It brings back a ranked list of where your agents are failingshow more

Your coding agent now gets the full analytical power of Judgment. When fixed lookup tools or a restrictive DSL can’t express the full question, your agent has to: - fetch traces, spans and scores separately - carry the intermediate results in context - join and compare everything itself The more data involved, the more your agent has to piece together before it can answer. Judgment’s Virtual SQL (vSQL) gives it one clean, opinionated schema over traces, spans, judge results and datasets. The data for common investigation questions is already organized into queryable tables. Your agent asks for what it wants and builds on those tables with compound SQL. Our data layer compiles each query, handles joins, filtering and comparisons on intermediate data inside a investigate-able sandbox. Your agent gets the computed results. It never held the underlying data in context window, and can spend more of its context reasoning & testing explanations instead.

New dev-tier orgs get 1,000 free JUs in the first month! Sign up today at Get started with our Docs:

Technical deep dive coming soon!

Whoop !

Plain SQL is the right call since coding agents already write it well. The part I'd want to trust is the judge labels, a ranked failure list is only as good as those.

clean af

Standard SQL over another custom DSL is absolutely the right call—much easier to inspect and debug.

SQL over traces is a smart call. every coding agent already knows SQL, so nobody has to teach it a new query language just to ask "did v3 get worse"

zero rows and no regressions render identically. an agent that doesn't know the schema moved will query a renamed column, get nothing back, and call the run clean. have it print the row count and the schema it queried against before it says pass or fail.

I'd save the SQL alongside a regression report. Then a teammate can rerun the actual comparison instead of trying to reconstruct what the agent meant by 'version B got worse'.