In our work at Calibre with AI product teams, we are often surprised by how many PMs have never written an eval rubric. Even those building agents with customers in production won’t have this vital part of an AI PRD that enables most of any sophisticated strategies downstream. Last week, we ran a workshop sponsored by Reforge with 800 PMs to show how to write good eval rubrics for agents with 2 case studies and many templates, shared at the end of this article. Hope you find them useful!
What’s an eval rubric and why you need one
Think of an eval rubric as a set of behavior contracts for an agent. PMs must document what great performance by their agent looks like, in terms specific enough to check against a real session. That written-down definition is an eval rubric.
In the past, product teams had screens and workflows that they could review together. But there is no happy path design critique in this world. Every user is technically having a unique experience every time they use your agent and you can’t personally verify them. You need code based and LLM judges at scale to ensure quality stays high. New classifier models like Jev (more about this in our next article) will make evaluation cheap and scalable to all your user interactions.
However, eval rubrics enable far more than quality measurement.
Eval rubrics are AI product strategy. They open up 3 strategic moves that will take your company from AI hobbyist to AI-native: self-improving products, routing to open source and training custom models.
Want a coding agent to verify its own work and ship autonomously? It needs something to check its work against, that’s the rubric.
Want to swap in open source models with confidence, so you can deliver the same user experience cheaper and more securely than competitors? You need to document what “great” experience means, and that’s the rubric.
Want to eventually post train your own model on your own traffic? The rubric becomes the reward function for verifiers.
Models on their own don’t generate human-aligned evaluations. Without your judgement and product strategy in the form of a rubric, generated evals are just more slop.
The four parts every eval rubric needs
So what actually goes in an eval rubric? After working with dozens of AI-native teams, we have come up with a framework around four questions that your rubric must answer: Outcome, Trajectory, Experience and Governance.
Outcome: What did the agent produce, and is it actually correct?
Trajectory: Did it get there the right way, or did it stumble into the right answer through a path you wouldn’t want it repeating?
Experience: How did the interaction feel, in this specific channel, to this specific customer?
Governance: What must it never do, and what must it always do, no matter what the user asks?
None of these are new PM concepts. What’s new is the process of writing them well because there’s no UI walkthrough that substitutes for them later. Below are two examples (one consumer and the other enterprise) that explain the four part eval rubric. We built them live last week in our workshop: Corner, an SMS agent that buys from local shops, and Ledger, a finance agent that runs your CFO’s end-of-quarter workflows. Both eval rubrics had the same four sections but very different kind of metrics given the nature of the product and target customer.
Eval rubric examples: Corner and Ledger
Corner is a consumer agent that lives in your text messages. You text it “my usual, iced, blue bottle near the office” and it checks your preferences, finds the store, places the order, charges your saved card, and texts you back. The buyer is impatient, the purchase is small, and success is measured in seconds and in the absence of friction.
Ledger is a finance agent that works for a CFO’s team. It reads the bonus policy and the closed-deals sheet, computes what eight salespeople are owed, and drafts the payout table for review. The numbers move real money, the CFO answers to an auditor, and success is measured in whether every figure traces back to a policy clause. Slow is fine. Wrong is not.
Both rubrics have the same four sections: outcome, trajectory, experience and governance. Almost nothing else is the same.
Corner’s Outcome can only be checked against what the user asked for: right item, right store, right pickup time. Ledger’s can be checked against arithmetic, so the line is stricter: every number matches a reference computation, and every deal/revenue source is counted exactly once.
For Corner, the cost of a wrong guess is small and recoverable (one annoyed person, one wrong coffee shop), so the Trajectory line reads guess well, then disclose before you charge the card. For Ledger, a wrong guess is large and compounding, possibly with legal exposure attached, so the line is closer to the opposite: never guess, always ask, and asking costs you nothing because the CFO expects it.
Corner’s Experience wants brevity and friendliness over SMS. Ledger’s wants a five-line summary a CFO can audit without redoing the math themselves.
Corner’s Governance is about money leaving an account it shouldn’t (no default tips, no unapproved substitutions, nothing over $100 without confirmation). Ledger’s Governance is about a draft becoming a system-of-record write nobody signed off on.
Who you’re building for decides which of the four sections is carrying the real product risk. That’s also why you can’t copy a rubric template off the internet and call it done. The structure is reusable. The content is not.
Rubric writing best practices
There is no way to write the perfect eval rubric as the first step. It needs to be an iterative process, informed by trace analysis. Here’s the rough sequence of steps you want to follow:
Write a high level PRD with a v1 eval rubric and build the v1 prototype of your agent based on these documents & datasets
Review at least 10 diverse traces to see where the agent’s behavior either deviates from the rubric or surprises you with unanticipated patterns
Iterate on your PRD and rubric based on your learnings: clarify vague parts of the rubric, add new missing elements and even remove unnecessary ones
Rinse and repeat till its time for wider dogfooding/alpha version
The part most teams skip on: reading the traces. You can’t trust your agent’s confirmation messages, you have to look at the data to see how it got there and whether it met the bar. Here’s a video walkthrough of what reviewing the trace should look like.
For instance, when we ran a real session through Corner: “my usual but iced, blue bottle near the office, picking up in 20.”, the final SMS looked completely clean. The trace was not. Reading it turned up four separate misses, and each one landed in a genuinely different category of mistake:
v1 rubric caught it. The agent added a 20% tip without asking. Governance already had a line for exactly this (”never charge beyond the explicit order without opt-in”), so the rubric did its job the first time.
v1 rubric caused it. The agent asked four questions the customer had already answered in one text. The Trajectory line said “confirm details before placing,” and the agent followed that instruction literally, into a worse experience. The rubric wasn’t missing, it was too blunt.
We didn’t predict it. Oat milk was out of stock. The agent substituted almond, said nothing, and the confirmation read as a total success. No v1 line covered silent substitution, because nobody had thought to write one yet.
Only visible at volume. Two Blue Bottle locations matched. The agent picked the farther one because it had a slightly higher rating, and never checked store hours first. You need to see this pattern more than once before you’d know to write a rule for it.
When you write the first version, you can write Outcome and Governance cold, because they come from your definition of success and your company’s actual policies. Trajectory and Experience will be thin and mostly guesswork at this stage, and that’s fine. You don’t yet know what your agent will actually do wrong.
Rubrics need to have cross-functional input. The PM should own writing it, but not alone. Engineering owns how a criterion actually gets checked against a tool call. Design owns how the experience feels. Legal, finance, and security should be reviewing the must-nevers with you eventually, before GA.
How rubrics fit into the AI PRD
AI product requirements need a few new sections that reflect the nature of building with LLMs. An eval rubric is one. Others would be release thresholds for cost, quality and performance as well as the process of sourcing datasets for testing.
The rubric is the one thing you can’t delegate or automate. Get the rubric wrong (or skip it) and you are stuck with manual processes in the age of AI or you’ve automated the wrong thing at scale, faster than you would have gotten it wrong by hand. Everything else can scale with tokens. Get the eval rubric right first.
Resources
Annotated trace sessions for Corner , and Ledger - read through this to understand how to analyze a trace and what decisions to make based on them
Reforge-AI-Evals repo (star it) with a folder for AI PRD and rubric templates across multiple examples - personal shopper, financne agent, support triage, etc.