The scoreboard
Every number on this page is measured, dated and traceable to a command.Composition figures are measured from the eval datasets in the GreatBook backend at
4972f62, 2026-08-03.Pass rates come from named runs, each with its own date, because a pass rate is a property of a run and not of a repository.The board
104 is the count of distinct metric names.
The per-agent column sums to 109 because five names are shared across agents that grade the same behaviour -
decline_behaviour, handoff_named, no_fabricated_values, scope_gate_correct and terminal_status_correct.Pass rates, with their runs
The tracked sync covered 51 examples, 51 scored, 0 errored, 0 skipped - so every case really was exercised against a real agent, and none was silently skipped for a missing prerequisite.
What moved, and what has never moved
Two facts are worth more than the aggregate. The Typewriter’s numbers moved when a defect was fixed, and the eval is how that is known.
Read those rows in that order, because they say different things.
The first two are the defect: the line rows, where most of a document’s money lives, are clean on every run, and whole-payload type conformance reached 1.000.
The third is noisier, and not because amounts are still strings - that key scores a named field 0 when it is absent as well as when it is a string, so it also counts turns that produced no draft at all.
The Clerk’s failures are model variance, and they are named.
Two cases: one goods-receipt-note classification miss, and one judge verdict.
Neither is marked as an accepted baseline, deliberately - they are pre-existing variance that no change has investigated, and excusing an uninvestigated failure is the wrong use of that mechanism.
Every deterministic Clerk key scored 1.000 on every run for the first several weeks of this dataset’s life, and the only score that had ever moved was the judge.
That is no longer true, and this page says so rather than repeating a sentence that was accurate when it was written.
Coverage by dimension
Coverage is deliberate rather than incidental, and this is the table that shows it.Clerk · 15 cases
Bookkeeper · 11 cases
Auditor · 26 cases
Accountant · 5 cases
Typewriter · 11 cases
Every score key
One accordion per agent, with what a 0 on that key would mean.Clerk · 18 keys
Clerk · 18 keys
Bookkeeper · 16 keys
Bookkeeper · 16 keys
Auditor · 40 keys
Auditor · 40 keys
Accountant · 15 keys
Accountant · 15 keys
Typewriter · 20 keys
Typewriter · 20 keys
Where these experiments live
The datasets are upserted into LangSmith from the in-repo JSON, and each agent gets a tracked experiment namedws-eval-<agent>-<id> in a project of its own.
That separation is deliberate: a graded run never mixes with production traffic, and per-example traces and per-evaluator feedback keys are browsable per experiment - so a single score key such as numeric_fields_are_numbers has a trend line of its own.
The experiment names in the table above are the exact handles.
No link is published here, because the dashboard is workspace-scoped and a link no reader can open is not evidence.
Refreshing these numbers
EVAL-NUMBERS markers in this page’s source, and update the date at the top.
Composition figures come from the datasets themselves, so they change when a case is added, not when a run happens.
Related
- Never stub what you test - how these numbers are produced, and what would invalidate them
- The test-case reference - all 68 cases in one table, plus the Close checksums and the GL invariants
- Worked cases - the individual cases behind the rates, input to output
- How this gates a release - which of these runs on every PR
- Reading a run - the trace each graded run leaves behind