Article details
Recap from Sandhya and Justin's Reforge Event: Eval Rubrics that Drive AI Product Strategy
If you're building an AI agent and you don't have an eval rubric, you have a problem you probably can't see yet. The agent might look like it's working. The output might seem reasonable. And then someone looks at the trace and finds it gave the user almond milk instead of oat milk, picked the wrong coffee shop, and added a tip without asking.
That's the scenario Justin Bauer and Sandhya Hekte — co-founders of Caliber, the applied AI research and consulting firm behind Reforge's AI Evals course — used to open a session on how to build an eval rubric from scratch. They built two rubrics, live, for two completely different agents: Corner, a consumer SMS-based shopping assistant, and Ledger, a finance agent for CFO teams. The session is a practical demonstration of a framework that generalizes across agent types while producing rubrics that look nothing alike.
Why the rubric comes first
The session started with a deceptively simple exercise: which is the better coffee homepage, Starbucks or Phil's? The audience immediately split.
The answer, as it turned out, was that everyone was right — because each homepage was optimized for a completely different goal. Starbucks is built to support a familiar purchase: clear ordering cues, easy scanning, visual hierarchy pointed at checkout. Phil's is built for discovery: differentiated seasonal offers, comparison and contrast, imagery that invites exploration. Both are excellent at what they're designed to do. Which one is "better" depends entirely on your definition of good.
That's why a rubric matters. And for agents, it matters even more. A homepage is a screenshot you can compare at a glance. An agent is a conversation — a unique interaction for every single customer. Without a rubric, you're hoping the agent produces the experience you imagined without ever having written down what that experience is supposed to be.
The eval rubric is a behavior contract. It's not a list of screens, because agents don't have screens. It's the written definition of what good behavior looks like — the foundation from which everything downstream gets built: scores, datasets, dashboards, and eventually more advanced capabilities like autonomous shipping, model swaps, and custom training. A coding agent that verifies its own work needs something to check against. That's your rubric. A cheaper model swap requires knowing what "good enough" means. That's your rubric. A reward model for fine-tuning needs to know what to optimize toward. That's your rubric.
The PM owns writing it. Engineering helps think through how each criterion gets verified. Design owns how the experience feels. Legal, finance, and security define what the agent must never do. But the rubric is the PM's core deliverable — and everything else in the eval stack depends on getting it right.
The four sections every rubric needs
After building two rubrics across two very different products, Justin and Sandhya found that every agent rubric should have the same four categories.
Outcome. What did the agent produce, and was it correct? This is the most obvious category — did the order match the request, did the numbers match the policy — but it's also the smallest part of the story. Getting the outcome right doesn't mean the agent got there the right way.
Trajectory. How did the agent do the work? This is where most of the product strategy actually lives. Agents can sometimes arrive at a correct answer through a broken path — and that broken path will fail in future sessions when conditions are slightly different. Involving engineering here is essential: trajectory is about the agent's actual behavioral path through its tool calls, and engineering owns the harness.
Governance. What must the agent never do, regardless of the task? This section should be the most complete in version one, because it doesn't come from watching the agent — it comes from your company's policies, legal requirements, and business model. Legal, finance, and security should help write this section.
Experience. How did it feel? For an SMS agent, that means turn count, message length, conversational tone. For an enterprise finance agent, it means concision and auditability. Conversational designers, if you have them, are strong partners here. This section is partly about defaults you set upfront and partly about what you discover once you start reviewing real sessions.
Building the Corner rubric
Corner is a local shopping assistant that works entirely over SMS. You text it, it buys something from a store near you, and the order is ready for pickup or delivery. The metric that matters is efficiency: fast, frictionless, no unnecessary steps. A user who has a saved card and usual orders should be able to get coffee without thinking.
The first version of the rubric, written before a single trace exists, comes directly from the PRD. For Corner, the outcome section covers two things: the placed order matches the request, and the confirmation message clearly states the item, store, time, and price. The trajectory section is a placeholder at this stage — confirms before placing, checks store hours — because you don't yet know all the paths the agent will take. Governance is already detailed: no upsells, no sharing payment data, no new stores without confirmation, an order cap the user can edit. Experience: brief and clear for SMS.
That rubric is enough to hand to a coding agent and get a working prototype. But the prototype reveals things the rubric missed.
Running a simulated session — "I want my usual coffee but iced, use Blue Bottle near the office, I'm picking up in 20" — surfaces several problems almost immediately. The agent asks for clarification on whether the user wants it iced, even though the user already specified iced. It asks several other questions, two of which repeat information already provided. This is visible in the conversation.
What's not visible without looking at the trace: the agent found two nearby locations and picked the one with a higher rating, not the closer one. It gave the user almond milk without mentioning it. It added a tip without asking. None of these showed up in the SMS exchange — they only appeared in the raw record of everything that happened underneath.
Version two of the rubric adds what the first test revealed: if there's any deviation from the request, the agent must disclose it and give the user the chance to cancel. The trajectory criteria get more specific — the agent must confirm modifiers before placing, not just "confirm details." Governance stays largely the same but gets reinforced in the system prompt.
Building the Ledger rubric
Ledger is a finance agent for teams that need a senior analyst's output: running bonuses, calculating sales compensation, producing expense summaries, checking budgets, and generating drafts that the finance team can review and approve. It sits atop the company's spreadsheets and financial policy documents.
Everything about the success criteria is different from the Corner example. Speed is irrelevant. Accuracy is everything. The output has to be auditable. There is no room for confident wrong answers.
The outcome section reflects this: every computed number must match a source in a policy document, with a link or reference the reviewer can click into. No conflicting data — every field has a single unique source of truth. The trajectory section starts with two criteria: read the policy document fresh every session before computing anything (because it may have been updated since the last run), and flag anything unusual rather than making an assumption. Governance: only produce drafts, never write directly to a system of record, never modify source data. Experience: concise.
Simulating a task — run bonuses for the sales team this quarter — produces output that looks correct on its surface. The numbers seem right. But looking at the trace: the agent had a governance violation. It counted some data twice. When the policy was ambiguous about how to handle two sales reps on the same deal, it made an assumption without flagging it. The summary was longer than necessary.
None of this was visible in the output, but it was revealed by the trace.
Version two of the rubric adds: every computed number must show the policy clause that produced it, and the summary must be formatted so a reviewer can scan it quickly without having to parse dense text.
What's the same, what's different
Corner and Ledger used the same overarching frameworks, but the rubrics they produced were nothing alike.
You can't copy someone else's rubric and apply it to your product. You can take the template, write your own version, watch real sessions, and iterate — but the judgment about what good looks like for your specific agent and your specific customers can't be automated or borrowed.
A few things that came up in Q&A
Don't use an LLM to write your rubric. You can use one to brainstorm, react to drafts, or compare options — but you own the rubric. Everything else in the eval stack will be automated off of it. The one thing that requires genuine human judgment is the thing you shouldn't outsource.
Write the first version in under an hour. You have what you need: your PRD, your company policies, your business model. Outcome and governance in particular can be drafted before a single trace exists. Trajectory and experience will evolve significantly once you start reviewing sessions, but write placeholders so the prototype has something to work toward.
Scoring targets aren't all the same. Must-haves should be close to 100% before you ship. Ambitious, differentiating capabilities might be acceptable at 50% — in fact, if you're hitting 100% on everything, you probably waited too long. Part of writing a rubric is deciding, for each criterion, what score gives you the confidence to release.
Negative traces often aren't system prompt problems. When an agent doesn't follow instructions, the instinct is to fix the prompt. But the issue might be in the retrieval pipeline — if the agent can't actually find the right data from a legacy database, no prompt fixes that. Or the tools themselves are poorly defined. The trace is the only way to see which of these is the actual problem.
Build taste by using the best products. There's no shortcut to knowing what acceptable latency feels like, or what a good confirmation message sounds like. Use the most advanced agents you can find, form opinions, and let those opinions sharpen your rubric. What felt impressive two months ago may be table stakes now.
Where to start
Write version one of your eval rubric before your prototype exists. Use your PRD. Start with governance — it's the section you can most fully define on day one, and it tends to be the longest and most important. Write placeholder criteria for trajectory. Sketch the experience you want.
Then build the prototype, run some sessions, and look at the traces. Not just the output — the traces. Add everything you find back into the rubric. That's the flywheel. It doesn't stop after version two, because your agent will keep expanding and your users' expectations will keep moving.
The rubric is what you do before you can automate anything else. It's how the team agrees on what good looks like. It's the document a coding agent will use to generate your system prompt, and later to verify its own work. Getting it right is the most important job in the entire eval process.
Watch the full recording here
Find out more about Sandhya and Justin's upcoming cohort of AI Evals