If 2024 was the year teams realised they couldn’t ship LLM features without evaluation, 2025 was the year they tried various tools and frameworks, and 2026 is the year the picture has settled. Most production AI teams now have some kind of formal evaluation discipline. The frameworks they use, the metrics they track, and the workflows around them have started to converge.

Here’s an honest look at where the evaluation conversation actually sits in May 2026.

The frameworks people are actually running

The evaluation tooling market has consolidated meaningfully. The names that come up most often in production teams now:

Braintrust has become a default for many engineering-led teams. The combination of tracing, evaluation, and a pretty good experimentation interface has won a lot of mid-market and enterprise accounts. Teams I talk to like that it doesn’t try to be a full ML platform - it’s specifically for LLM evaluation and gets that job done.

LangSmith is sticky in the LangChain ecosystem and has a strong showing in early-stage teams that started with LangChain and grew into needing better evals. The tighter integration with LangGraph in particular makes it the default for agent-heavy applications.

Arize Phoenix (open source) shows up in larger enterprises that want to self-host their evaluation infrastructure. The OpenTelemetry-based approach gives it good interoperability with broader observability stacks.

Weights & Biases still has a presence, especially in teams with traditional ML alongside LLM work. The story for pure LLM evaluation isn’t as sharp as the dedicated tools but the unified ML/LLM platform argument resonates with some larger orgs.

Custom-built solutions are still common, particularly in larger tech companies and organisations with specialised needs. The build-versus-buy calculation has shifted toward buy as the commercial offerings have matured, but custom is still the right call for teams with very specific evaluation requirements.

The metrics that actually matter

The evaluation metrics conversation has become more sophisticated. The teams shipping good production AI are running multiple categories of evaluation:

Reference-based metrics for tasks where there’s a clear right answer. Exact match, F1, BLEU/ROUGE for older NLP tasks. These are reliable but only useful for narrow problem types.

LLM-as-judge metrics for open-ended tasks where you can’t easily define a single right answer. The teams doing this well are careful about judge model selection (GPT-4-class judges for high-stakes evaluation), prompt engineering for the judge, and calibration against human ratings.

Pairwise comparison has become more popular for ongoing model comparison. Asking the judge “is response A or response B better” produces more reliable signals than asking for absolute scores.

Production proxy metrics like task completion rate, user thumb up/down, follow-up question rate, and abandonment - these are slower to gather but more authoritative than offline evals because they reflect real usage.

The pattern in 2026 is to run all of these in combination. Offline evals catch regressions before deployment. Production metrics validate that the offline signal predicts real-world quality. Pairwise comparison drives ongoing model selection.

The dataset problem hasn’t gone away

The single biggest predictor of evaluation quality remains dataset quality. Teams with rich, well-curated evaluation datasets get useful signal from their evals. Teams with thin or stale datasets get noise.

Building good evaluation datasets is unglamorous work. The patterns I see working:

• Mining real production traffic for evaluation cases (with proper consent and anonymisation)
• Synthetic data generation for edge cases the production traffic doesn’t cover
• Adversarial test cases written by humans who know the failure modes
• Regular dataset refresh cycles - quarterly is a reasonable cadence

The teams that treat evaluation datasets as a first-class engineering artifact - versioned, reviewed, documented - get much more durable value from their eval frameworks than teams that treat datasets as ad-hoc collections.

The agent evaluation problem

Standard LLM evaluation patterns break down somewhat for agent systems. When an agent can take multiple steps, call tools, and produce different valid trajectories to the same outcome, you can’t just compare a final output to a reference answer.

The patterns emerging for agent evaluation:

Trajectory evaluation - did the agent make sensible decisions at each step, regardless of whether the path was the same as a reference?

Outcome evaluation - did the agent achieve the user’s goal, even if it took a different path?

Tool-use accuracy - when the agent called a tool, did it call the right tool with the right arguments?

Cost and latency tracking - agents can be expensive. Tracking these in evaluation prevents nasty surprises.

This is still an actively-evolving area. The frameworks I mentioned earlier all support some variation on these patterns now, but the maturity is uneven. Custom evaluation tooling is more common for serious agent systems than for chat-style applications.

What’s broken about most evaluation programs

A few common failure modes I see in teams that have set up evaluation but aren’t getting much value from it.

Evaluating in isolation from production. If your offline evals say the new model is better but production metrics say users prefer the old one, your evals aren’t measuring what matters. This is a bigger problem than most teams admit.

Optimising for the eval rather than the user. Goodhart’s law applies. If you’re tuning prompts to maximise eval scores without correlating that to user outcomes, you’ll end up with a model that aces evals and disappoints users.

Evaluation theatre. Some teams stand up evaluation infrastructure and produce reports, but never actually act on the signal. The team ships whatever the engineers want to ship, regardless of what the evals show. This is worse than not having evaluation at all because it creates false confidence.

No human in the loop. Pure automated evaluation, even with LLM judges, drifts from human preference over time. The teams getting durable value have humans periodically reviewing eval outputs and recalibrating.

The takeaway

AI evaluation in 2026 is no longer optional for teams shipping production LLM features. The tooling has matured enough that there’s no good excuse for not having it. The metrics conversation has become more sophisticated. The hardest problems - dataset quality, agent evaluation, connecting offline to production signal - are well-known but not fully solved.

Teams getting this right treat evaluation as a discipline, not a tool purchase. They invest in datasets. They run offline and production evals together. They listen to what the data says.

The teams that don’t are the ones shipping AI features that quietly underperform and eventually erode trust. That’s a worse outcome than not shipping the feature at all.