Skip to main content

Why a Jury?

A single judge gives you one judgment. A jury aggregates multiple judgments into a verdict with diagnostic information — when something fails, you can see which checks failed, which tier failed, and why. Agent Judge provides two jury types:
JuryUse when
SimpleJuryAll judges run as peers — aggregate with voting
CascadedJuryJudges are organized in cost tiers — fail fast on cheap checks, escalate to expensive ones
The snippets below omit imports for brevity. See API Reference for package names.

SimpleJury

Run multiple judges and aggregate results with a voting strategy:

Builder API

MethodDescriptionDefault
.judge(Judge)Add judge with weight 1.0—
.judge(Judge, double)Add judge with custom weight—
.votingStrategy(VotingStrategy)Aggregation method (required)—
.parallel(boolean)Concurrent executiontrue
.executor(Executor)Custom thread pool for parallel executionCommon pool

Reading the Verdict

SimpleJury aggregates peers. It does not provide fail-fast cost control. Use CascadedJury when you want cheap checks to prevent expensive judges from running.

Voting Strategies

StrategyPass conditionBest for
MajorityVotingStrategypassCount > failCountGeneral purpose
ConsensusStrategyAll judges agreeHigh-stakes evaluation
AverageVotingStrategyaverage(scores) >= 0.5Continuous scores
WeightedAverageStrategyweightedAvg(scores) >= 0.5Judges with different importance
MedianVotingStrategymedian(scores) >= 0.5Outlier-resistant scoring

Configuring MajorityVotingStrategy

TiePolicy — when pass count equals fail count:
PolicyBehavior
TiePolicy.PASSOptimistic — resolve ties as PASS
TiePolicy.FAILPessimistic — resolve ties as FAIL (default)
TiePolicy.ABSTAINNeutral — no verdict
ErrorPolicy — when a judge returns JudgmentStatus.ERROR:
PolicyBehavior
ErrorPolicy.TREAT_AS_FAILCount errors as failures (default)
ErrorPolicy.TREAT_AS_ABSTAINCount the judge as having abstained
ErrorPolicy.IGNOREExclude the errored judge from the vote count and diagnostics

CascadedJury

A cascaded jury organizes judges into tiers. Each tier is itself a jury (typically a SimpleJury). Tiers execute sequentially — if a cheap tier already has a verdict, expensive tiers never run.

Tier Policies

PolicyBehaviorTypical use
REJECT_ON_ANY_FAILStop immediately if any judge in this tier failsGuardrails: must compile, files must exist
ACCEPT_ON_ALL_PASSStop if all judges pass — accept without escalating to later tiersConsensus gate when this tier is strong enough on its own
FINAL_TIERRuns when reached and produces the final verdictLast tier (required)
The last tier in a CascadedJury must use TierPolicy.FINAL_TIER. The builder validates this at build time.

Inspecting Tier Results


Jury Composition

Named Judges

Wrap any judge with a name for readable verdict output:
Without names, judges get auto-generated identifiers in the verdict.

Combining Juries

The Juries utility class provides shortcuts:

Choosing a Pattern

ScenarioUse
Same-tier judges, single voteSimpleJury with majority or consensus
Weighted importance among judgesSimpleJury with WeightedAverageStrategy
Cheap-then-expensive evaluationCascadedJury with 2-3 tiers
Multiple evaluation dimensionsJuries.combine() to merge sub-juries
Quick one-off checkJudges.and() or Judges.allOf() (no jury overhead)

Built-in Judges

Catalog of judges to wire into juries

Writing Custom Judges

Build domain-specific judges for your evaluation criteria