Agent eval rubrics that travel across stacks

Defining a travel‑ready rubric

I start by writing the rubric before I look at any model output. The rubric must contain three independent axes: task success, tool correctness, and faithfulness. Each axis gets its own scoring guide that does not mention the model name, the framework version, or the exact prompt wording. I keep the guides in a plain‑text file that lives next to the test suite so anyone can check them.

Core properties

- Pre‑registered criteria – the success conditions are written down before the first run. - Axis isolation – scores for one axis never bleed into another. - Version‑free language – avoid phrases like “as of GPT‑4” or “when using LangChain 0.1”.

When I follow these properties the same rubric gives me comparable numbers whether I run the agent with OpenAI’s GPT‑4o, Anthropic’s Claude 3, or a local Llama 3 model.

Why task success must be outcome‑based

Task success answers the simple question: did the agent finish what was asked? I judge this against a checklist that looks at the final state of the world, not at the wording of the answer. For example, if the task is “update the user’s email address to alice@example.com”, I check the database record after the run. I do not care whether the agent said “I have updated your email” or “Your email is now alice@example.com”.

Concrete checklist

- Pre‑condition verified (e.g., user exists). - Post‑condition verified (e.g., email field equals alice@example.com). - No extra side‑effects (e.g., no other fields changed). - Optional: latency under a threshold (e.g., 2 seconds).

I record a binary pass/fail for each trajectory. If the agent fails the post‑condition, the task‑success score is zero, regardless of how fluent the prose looks.

Tool correctness as a separate axis

Tool correctness looks at the calls the agent makes to external APIs, functions, or databases. I treat each call as a mini‑experiment: did the agent pick the right tool, did it pass the right arguments, and did it call it the right number of times? I follow the guidance from the OWASP cheat sheets on safe tool use, for instance the LLM Prompt Injection Prevention Cheat Sheet and the SQL Injection Prevention Cheat Sheet to avoid accidental injection.

Scoring rubric

- Right tool selected – 1 point. - All arguments match the schema – 1 point per argument. - No extra calls – 1 point if call count equals expected. - No prohibited side‑effects (e.g., writing to a log that should stay read‑only) – 1 point.

The axis score is the sum of points divided by the maximum possible. I keep this axis separate so a mistake in tool use does not hide a success in task completion.

Faithfulness: tracing every claim

Faithfulness asks whether every statement in the agent’s output can be traced back to the tool results or the context that was given to the model. I treat the output as a set of claims and check each one against the evidence. If a claim cannot be supported, I mark it as a hallucination. This axis matters most when the agent summarises documents, cites sources, or answers questions that require external data.

Step‑by‑step verification

- Split the output into atomic sentences. - For each sentence, list the facts it asserts. - Match each fact to a line in the tool output or to a snippet from the provided context. - If a fact has no match, count it as a failure. - Faithfulness score = (number of supported facts) / (total number of facts).

I record the raw counts so I can see whether a drop in faithfulness comes from a few big hallucinations or many small slips.

What this is NOT

I want to be clear about the limits of a travel‑ready rubric. It does not guarantee that the agent is safe, cheap, or fast. It does not promise 100 % accuracy on every possible input. It does not replace a dedicated security review, a cost analysis, or a latency benchmark. The rubric only measures the three axes I defined above. If you need to know whether the agent leaks private keys, you must run a separate secrets‑management check, for example using the Secrets Management Cheat Sheet. If you need to know whether the agent stays within a budget, you must track token usage or API call costs outside of this rubric.

In short, the rubric is a tool for comparing agent quality across stacks, not a silver bullet for all production concerns.

Building comparable trajectories

A trajectory is the full log of what happened during one run: the initial prompt, every tool call with its arguments and results, and the final model output. I store each trajectory as a JSON object with a fixed schema so I can diff runs automatically. Below is an example of the schema I use.

Field | Type | Description prompt | string | The exact user or system prompt sent to the model. calls | array | Ordered list of tool executions. calls[].tool | string | Name of the tool or API. calls[].args | object | Arguments passed to the tool. calls[].result | any | Raw output from the tool. output | string | Final text returned by the model. metadata | object | Optional tags such as model name, framework version, timestamp.

Because the schema never changes, I can compute the three axis scores for each trajectory using the same scripts. I keep a master set of trajectories that covers the core tasks I ship and the common failure modes I have seen. When I change the model, I re‑run the same trajectories and compare the new scores to the baseline.

Running evals on every change

I integrate the evaluation step into my continuous‑integration pipeline. The pipeline does the following on each commit that can affect behaviour:

- Check out the latest code. - Install the agent dependencies. - Run the agent against the fixed trajectory set. - Parse the logs and compute task‑success, tool‑correctness, and faithfulness scores. - Post the results to a dashboard and flag any axis that drops more than five percent compared to the previous green build.

This practice catches regressions early. For example, when I switched the underlying retrieval library, the tool‑correctness axis fell from 0.96 to 0.82 because the new library returned results in a different order, causing the agent to make extra calls. The drop appeared in the CI report before any user noticed a problem.

I also keep a human‑scored hold‑out set of twenty trajectories. Every month I score those with a person and compare the average to the automatic scores. If the automatic judge drifts, I recalibrate the rubric or retrain the judge model.

Operator checklist for Agent eval rubrics that travel across stacks

I keep a written checklist next to every release that touches this topic. The list is boring on purpose: name the owner, name the evidence artifact, and name the rollback. If a step cannot produce a file, a ticket, or a log line, it is not a step — it is a wish.

Before you change production

- Freeze the branch or config revision you will measure against. - Record the current failure mode with one concrete input and one concrete output. - Confirm which identity the job runs as, and whether that identity can reach data it should not. - Open the primary references you will cite: https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html, https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html.

While you run the check

- Prefer one reproducible path over ten anecdotal screenshots. - Write the expected safe outcome before you trigger the tool or query. - Capture the exact command, prompt, schema, or regex under test — not a paraphrase. - If the system can act (send, write, delete, transfer), require a confirmation boundary in the same pass.

After you finish

- File residual risk with an owner and a date, even when the scan is clean. - Do not convert a green check into sales language that claims completeness. - Re-run the same checklist when the model, tool schema, or validation rules change.

Signal | What to record | Stop-ship? Unexpected write or send | Tool name, args, identity | Yes until gated Missing confirmation on destructive action | Call path and bypass | Yes Untrusted text treated as instruction | Source surface and resulting action | Yes for agent reach Scanner clean, judgment open | Deferred items + owner | Only if core path safe

agenteval helps with the measurable first pass. Architecture choices, legal sign-off, and customer-facing claims still need a human owner. Treat every checklist row as decision support, not a certificate.

How I explain limits to buyers

When a prospect asks whether the product "covers everything," I answer with the boundary: automated checks catch known patterns; novel chains and policy judgment still need review. That honesty keeps support load down and keeps the blog aligned with what the product actually does.

If you need a second opinion, pair this write-up with the references below and with your own staging reproduction. Do not skip the reproduction step just because a model wrote a confident summary.

References

- https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html - https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html - https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html - https://docs.agents-squads.com/guides/config-files

Frequently asked questions

How many test cases do we need?

Enough to cover the tasks you actually ship and the ways they fail. A handful of well-chosen trajectories beats a large set of easy ones.

Can we judge outputs with another model?

You can, but record that the judge is a model and keep a fixed sample scored by humans, so you can tell whether the judge itself drifted.

What is faithfulness, concretely?

Whether each claim in the output is supported by the tool results or context the agent was given, rather than produced from the model's own priors.

Should we score the final answer only?

No. Score the trajectory too — the tool calls are where most agent failures originate.

How often should evals run?

On every change that can affect behaviour: prompt, model, tool list, or retrieval configuration.

Does a good score mean the agent is safe?

No. It means it performed well on the tasks you tested. Security, cost and failure handling are separate evaluations.

References

- NIST — AI Risk Management Framework - Stanford CRFM — HELM (Holistic Evaluation of Language Models)

Try the product: AgentGrade

2026-09-20 · primary sources only · no fabricated traffic metrics · decision-support only

Related articles

- Offline eval vs online monitoring for AI agents - Explore the full AI micro-SaaS topic matrix →