LangChain Rubrics Make Agent Evals Part of the Runtime

TL;DR
LangChain rubrics for Deep Agents bring evals into the agent loop. Self-correction works only when rubrics are versioned, executable and checked by humans.
LangChain's new rubrics for Deep Agents are worth paying attention to because they move evals closer to the agent loop itself.
The headline feature is simple: give an agent a rubric, let it evaluate its own work against that rubric, and use the result to correct the output before handing it back.
That sounds like a small product feature. It is bigger than that.
It is a sign that agent evals are becoming runtime infrastructure, not only offline dashboards.
Last updated: June 23, 2026
The useful version is not "the model grades itself and declares victory." That would be too easy to game and too easy to trust blindly.
The useful version is a disciplined loop:
- define task-specific criteria
- run the agent
- evaluate against the criteria
- revise or stop
- store the trace
- sample against human review
That is where rubrics become practical.
What LangChain Shipped#
LangChain's post describes rubrics as a way to build agents that evaluate and correct their work. The feature lands in the Deep Agents context, which LangChain positions as a batteries-included agent harness for complex, multi-step tasks.
The surrounding product story matters:
- Deep Agents handles complex multi-step agent work.
- LangSmith evaluation gives teams an eval and observability surface.
- The LangSmith evaluation docs cover datasets, experiments, evaluators, and review workflows.
- Rubrics bring part of that quality-control thinking into the agent's working loop.
The direction is clear: agents should not only produce output. They should check whether the output meets a declared standard.
That is the right instinct.
Why Rubrics Matter for Agents#
Traditional evals happen after the fact.
You run a batch of examples. You score them. You compare model A to model B. You decide whether to ship a prompt, model, retrieval setting, or tool change.
That is still necessary. We covered that in agent evals need baseline receipts: a useful eval keeps the baseline, candidate, task fixture, trajectory, cost, and human review note together.
But agent work has another problem. The failure often happens during the run.
A coding agent may:
- forget a constraint from the task
- produce a diff without tests
- fix the happy path while missing the migration path
- use the wrong abstraction
- return a polished answer without receipts
- spend too much work on a low-value branch
If the agent only learns that after the run is complete, the system has already wasted time and tokens. A runtime rubric gives the agent a chance to catch obvious quality failures before the user becomes the evaluator.
That is not a replacement for offline evals. It is a new layer.
The Good Rubric Test#
A rubric is useful only if it changes behavior.
Bad rubric:
Make the answer good, correct, helpful, and safe.
Good rubric:
Before final response, verify:
1. Every factual claim cites a source URL or local file.
2. The answer separates verified facts from inference.
3. The recommendation names one case where it should not be used.
4. Any code change includes the exact command used to verify it.
5. If a source was unreachable, the answer says so.
The difference is not style. The second rubric is inspectable. A human reviewer can tell whether the agent followed it.
For developer workflows, rubrics should be:
| Property | Why It Matters |
|---|---|
| specific | vague criteria become vibes |
| versioned | teams need to know which rubric judged which run |
| task-scoped | a support rubric is not a coding rubric |
| evidence-linked | the judge should inspect the trace, not only the final answer |
| cheap enough | a rubric that doubles cost everywhere will get bypassed |
| sampled by humans | model-judged quality needs calibration |
That last point is the one teams skip.
Self-correction is useful. Self-certification is dangerous.
Where This Fits in the Agent Stack#
Rubrics sit between the agent harness and the eval platform.
At the harness level, a rubric can decide whether to loop:
draft -> rubric check -> revise -> rubric check -> final
At the eval-platform level, rubrics become the reusable criteria that compare candidate systems against baselines.
At the product level, rubrics become part of the user promise:
- this support answer must cite policy
- this code patch must include tests
- this data-agent answer must name the source table
- this research summary must separate claims from uncertainty
- this migration plan must include rollback
This is why rubrics belong next to long-running agent harnesses. A loop without a rubric tends to optimize for "keep going." A loop with a rubric can optimize for "stop when the output satisfies these criteria, or stop when it clearly does not."
That is a much safer loop.
The Counterargument#
The obvious critique is that a model grading a model can launder mistakes.
That critique is correct.
A rubric check can fail in several ways:
- the evaluator shares the same blind spot as the generator
- the rubric is too vague
- the final answer looks compliant but hides weak evidence
- the agent learns to satisfy the rubric wording instead of the user need
- the rubric check adds cost without improving acceptance rate
This is the same reliability cliff we discussed in the agent reliability cliff. Adding another agent step does not automatically improve the system. If that step has weak criteria or no external signal, it can create confidence without quality.
The fix is not to avoid rubrics. The fix is to bind them to evidence.
Use executable checks where possible:
- schema validation
- unit tests
- source-link checks
- required fields
- diff-size limits
- lint and typecheck
- policy allowlists
- replayable traces
Then use LLM rubric judges for the parts that are genuinely semantic: reasoning quality, user fit, clarity, missing caveats, and tradeoff coverage.
The Operational Pattern#
If you are adding rubrics to an agent this week, start small.
| Step | Action |
|---|---|
| 1 | Pick one workflow with repeat failures |
| 2 | Write a five-point rubric that a human reviewer already uses mentally |
| 3 | Save the rubric with a version ID |
| 4 | Run the agent with and without the rubric on the same task set |
| 5 | Compare accepted outcomes, cost, latency, and review time |
| 6 | Sample failures manually and adjust the rubric |
Do not measure only the rubric score. Measure whether the output is accepted faster.
That connects directly to the AI affordability cost model. A rubric that adds tokens but reduces retries and review time can be a net win. A rubric that adds tokens and mostly agrees with bad output is just ceremony.
My Take#
LangChain rubrics are interesting because they make a quiet but important claim: agent quality criteria should be explicit and reusable.
That is the right direction.
The mature agent stack will not be "prompt plus tools." It will be:
- prompt
- tools
- memory
- harness
- trace
- rubric
- baseline
- human calibration
Rubrics are not magic. They are a way to turn taste, policy, and task-specific quality into something an agent can inspect before it stops.
For teams building real agent workflows, that matters. The agent that can revise against a clear rubric is more useful than the agent that simply runs longer. The team that versions and samples those rubrics is safer than the team that trusts a self-grade.
Use rubrics to make the loop better.
Do not use them to avoid owning the loop.
FAQ#
What are LangChain rubrics for Deep Agents?#
LangChain rubrics let developers define criteria that Deep Agents can use to evaluate and improve their own outputs. They bring quality checks closer to the agent runtime instead of leaving all evaluation for offline dashboards.
Are rubric-graded agents safe to trust automatically?#
No. Rubrics help agents catch failures, but model-judged quality should still be sampled against human review and executable checks. A rubric is a control, not proof of correctness.
What makes a good agent rubric?#
A good rubric is specific, task-scoped, versioned, evidence-linked, and reviewable. It should name observable criteria rather than vague goals like "be helpful" or "write good code."
How do rubrics relate to LangSmith evals?#
LangSmith evals help teams compare agent behavior across datasets, experiments, and baselines. Rubrics can become the reusable criteria inside those evals and, in Deep Agents, part of the runtime correction loop.
Do rubrics make agents cheaper?#
Not automatically. Rubrics add evaluation work. They save money only when they reduce retries, review time, rejected outputs, or failed agent loops enough to offset the extra tokens and latency.
Continue Reading#
- LangSmith Fleet Turns Agent Ops Into On-Call Work
- StateAct Shows Computer-Use Agents Need Program State, Not Just Pixels
Sources#
Fetched June 23, 2026.
Get the next deep dive like this in your inbox
One email a week on LangChain and the rest of the AI dev stack. Free.
Read next on AI coding tools
Agent Evals Need Baseline Receipts
Agent evals need baseline receipts: Hex's data-agent lab compares candidates against stable production baselines, keeps evidence and judges changes by behavior.
8 min readThe Agent Reliability Cliff: Why Your 10-Step Chain Only Succeeds 20% of the Time
The agent reliability cliff: 85% per-step success compounds to about 20% over 10 steps. Why long chains collapse, and six patterns that fight the decay.
9 min readLong-Running Agents Need Harnesses, Not Hope
Long-running coding agents need a harness: task contracts, scoped workspaces, logs, checkpoints, verification gates, and cost limits to recover from failure.
9 min readNew here? Start with
Technical content at the intersection of AI and development. Building with AI agents, Claude Code, and modern dev tools - then showing you exactly how it works.








