RubricForge: Auditable AI Agent Evaluation Rules

Large language models are already common judges for AI-agent evaluations. That choice is understandable: environment rewards can be expensive to calculate, slow to obtain, or unavailable once an agent is deployed in a new workflow. A second model can inspect the agent’s trace and provide a quick verdict. The catch is that a polished-looking interaction can hide a failed task. An agent may sound confident, follow a plausible sequence, and still never complete the requested action. RubricForge targets this specific failure mode, called over-crediting: the tendency of an automated judge to give an agent more credit than the evidence deserves.

The distinction matters in production. A false failure may trigger another run or send a case to a human reviewer. A false pass can be more serious: it may allow an unreliable agent to move into a customer-facing or operational workflow. RubricForge is therefore not presented as a universal replacement for model-based evaluation. Its more focused goal is to make judges less generous when a trace appears successful without actually satisfying the task.

A readable alternative to opaque judge tuning

Existing approaches tend to make one of two tradeoffs. Teams can write detailed instructions for a judge, as in rubric-driven methods such as G-Eval, but those instructions become difficult to maintain as tasks change. Or they can fine-tune the judge’s parameters, potentially improving behavior while making the reason for each decision much harder to inspect. RubricForge takes a middle path: it generates the evaluation rubric itself as text, using a small collection of execution traces with trusted labels.

The method uses reflective evolution to repeatedly improve the wording and structure of the rubric. The optimization target is agreement with the real environment outcomes represented by the labeled traces. Once the rubric is selected, it is frozen. Held-out traces are then judged with a single model call and without consulting the environment reward. That separation is important: the reward signal helps create the rubric during development, but does not need to be available during the later evaluation process.

For an engineering team, the practical benefit is not merely that the rules are written in natural language. Each decision can be connected to a specific rubric item. If a trace receives a passing score, a reviewer can examine which requirement the judge considered satisfied. That is much easier to audit than a change in model weights whose internal reasoning is difficult to reconstruct. It also gives teams something concrete to revise when the evaluation standard changes.

What the reported tests actually show

The study used a frozen 7B model as both the agent and the evaluator. On tau-bench, the evaluation drew on 173 labeled traces from 220 rollbacks. The WebShop experiment used 160 traces. These are useful signals, but they are not a broad industry benchmark, and the size of the experiments should temper any sweeping claims about reliability across every agent task.

RubricForge’s strongest result was not a dramatic increase in overall agreement. Its main advantage was lower false-pass behavior. On tau-bench, the reported false-pass rate fell from 0.173 to 0.115, which is close to a 50 percent reduction. The method’s edge in some other comparisons was not statistically significant, and its absolute calibration was slightly behind the general G-Eval-style judge. That makes the result more nuanced than a simple “better judge” claim.

For reward-free evaluation, a false pass may be more damaging than a false failure: an incorrect pass can send a weak agent toward deployment, while an incorrect failure may only cause a retry or review.

There was also a modest ranking benefit on WebShop. RubricForge reached a Spearman correlation of 0.410, compared with 0.370 for the general judge in the reported comparison. The experiments identified three failures that the baseline would have incorrectly allowed through, with no reported case of the rubric incorrectly rejecting a successful example in that comparison. Those observations are encouraging, but the sample is too limited to treat them as a guarantee.

Where this approach fits in practice

RubricForge is most relevant when evaluation needs to be repeatable and inspectable, not merely cheap. Consider a team testing an agent that performs multi-step support or commerce tasks. The team may have a limited batch of traces with verified outcomes, but no dependable reward service available in its staging or production environment. Automatically deriving a rubric from those examples could provide a visible standard for future traces without requiring the team to hand-write every edge case.

• Agent evaluation teams can use generated rubrics as a starting point when manually maintained judge prompts drift away from real task outcomes.
• Audit-conscious deployments gain a text-based record of the conditions used to approve or reject an agent trace.
• Small-model testing setups can explore a workflow in which one frozen model handles both agent execution and judgment, avoiding a separate reward calculation step.

The approach also has clear boundaries. A rubric learned from a narrow set of labeled traces may preserve the blind spots in that data. If the task changes, the rubric may need to be regenerated rather than treated as a permanent policy. The reported work also leaves open how stable the method is across model sizes, domains, and more complicated interaction patterns. A readable rule is easier to inspect than opaque weights, but readability alone does not prove that the rule is complete or fair.

How developers should evaluate it

Teams considering a reproduction should measure the failure mode they actually care about. If the deployment risk is an agent being approved after an incomplete action, false-pass rate is more informative than a single overall agreement score. Keeping a held-out set of labeled traces is equally important; otherwise, an evolving rubric can appear effective simply because it has absorbed the examples used to build it.

It is also sensible to review the generated text before putting it into a continuous evaluation pipeline. Look for vague terms, requirements that overlap, and cases where the rubric rewards a persuasive explanation instead of a completed action. The 7B setup in the study offers a useful reference point, not a universal baseline. Different base models may interpret the same rubric differently, particularly when traces contain tool errors, partial completion, or ambiguous user requests.

RubricForge’s contribution is best understood as a direction for evaluation infrastructure: derive visible grading rules from trusted feedback instead of hiding every adjustment inside model parameters. The reported reduction in false approvals is meaningful for reliability-focused teams, while the limited experiments and mixed calibration results call for restraint. More tasks, larger models, and independent replications will determine whether this becomes a dependable pattern or mainly a promising research technique.