Eighteen months ago, “running evals” at most AI teams meant a Google Sheet, a junior engineer, and a vague sense of dread before each model upgrade. That’s no longer the case. The evaluation tooling space has quietly become one of the most active categories in applied AI, and as of May 2026, it’s possible to map the field without hand-waving.

The shift is partly because the cost of getting it wrong went up. When a coding agent ships bad PRs at 3am, or a customer-support bot starts confidently misquoting refund policy, the blast radius scales with the autonomy you’ve given the system. Teams figured out — usually after an embarrassing incident — that they needed something more rigorous than vibes.

What’s actually in the stack now

The mature evaluation stack has settled into roughly four layers, and they aren’t always supplied by the same vendor.

The first is trace capture and observability. Tools like Langfuse, Arize Phoenix, and Braintrust have made it normal to log every LLM call with inputs, outputs, latency, token counts, and metadata. This part is largely solved. Most teams I talk to have one of these wired in within a week of starting a serious project.

The second is dataset curation. This is messier. Synthetic test set generation has gotten better — Anthropic’s published guidance on building eval sets from production traffic is a useful baseline — but the bottleneck is still humans labeling edge cases. The teams doing this well have a small group of domain experts spending two to four hours a week reviewing flagged outputs. Nobody’s automated their way out of this yet.

The third is scoring. LLM-as-judge has become the default for open-ended tasks, with all the well-documented problems: position bias, length bias, and the embarrassing tendency of judges to prefer outputs from models in the same family. The current best practice is multi-judge ensembles plus periodic calibration against human ratings, but it’s expensive. Inference costs for evals can easily exceed inference costs for the actual product if you’re not careful.

The fourth is regression detection. This is where I think the most interesting work is happening. Teams want to know whether the new model version, the new prompt, or the new RAG configuration broke something subtle. The answer used to be “ship it and watch the dashboards.” Now there are pre-deployment gates that block PRs if eval scores drop below thresholds on critical task categories.

Where the real disagreements are

Two camps have emerged, and they don’t agree on much.

The first camp argues that evals should be task-specific and small. A few hundred carefully curated examples, scored with deterministic checks where possible, run in seconds. Their argument: big benchmarks are gameable, and what you actually want is a guard rail that catches the failure modes specific to your application. This is the camp most production teams end up in.

The second camp wants broad capability evaluations — running models against thousands of held-out examples across reasoning, code, math, retrieval, and tool use. This is closer to what the labs do internally and what shows up on public leaderboards. It’s useful for model selection but overkill for most product decisions.

Mid-2026, I see teams running both: a tight task-specific suite that gates deploys, plus a quarterly capability sweep when they’re considering a model swap.

The honest gaps

Three things are still genuinely hard.

Long-horizon agent evaluation is one. When an agent runs for thirty minutes and makes forty tool calls, scoring “did it succeed” is easy but scoring “did it succeed efficiently and without doing anything weird along the way” is not. The state of the art here is still essentially trajectory replay plus human review.

Multimodal evals are another. Text evals are mature. Vision evals are getting there. Audio and video evals are mostly bespoke.

And finally, cost-aware evaluation is underdeveloped. Most eval frameworks score quality but ignore that two models with similar quality might differ 10x on price. A few tools — Helicone has been pushing on this, and there are smaller projects from a Sydney-based firm and others working on cost-quality Pareto curves — are starting to make this first-class. It still feels early.

What to do about it

If you’re building anything where LLM output goes to a customer or triggers a real action, the tooling is finally good enough that there’s no excuse not to have an eval suite. Start with maybe 50 examples that represent the failure modes you actually care about. Wire up trace capture so you can grow that set from real traffic. Pick one judge model and one scoring rubric and commit to it for a quarter before changing anything.

The teams that win in 2026 won’t be the ones with the best model. They’ll be the ones who can tell, within an hour, whether a change made things better or worse.