Same input, different output
Run an agent twice and you may get two answers. Repeated runs show whether it is reliably right.
An agent you have not measured is a guess. One you stop watching drifts.
Botminds tests any agent, workflow or mesh against golden datasets of thousands of cases, runs them side by side with repeats to catch inconsistency, flags a change that makes things worse, fits each field’s confidence to reviewed outcomes so a stated 90% tracks how often it is right, watches every live run for cost and failures, tracks audited outcomes continuously, and reports input drift against a reference window.
AI agent evaluation is measuring whether an agent does its job correctly and consistently — before a change goes live and while it runs. It means running the agent on a golden dataset of cases with known answers, scoring each output with exact rules and, where text must be read, an LLM judge, repeating runs to test consistency, and comparing with a baseline. Live observability then shows what tests cannot: real traffic, real cost, real failures.
A unit test asks one question with one right answer and gets the same result every time. An agent breaks all three assumptions, so evaluation is built for that.
Run an agent twice and you may get two answers. Repeated runs show whether it is reliably right.
“Acme Corp.” and “ACME Corporation” are one supplier. Scoring needs a rule per field, not string equality.
A five-point drop and run-to-run noise look alike. A verdict needs a confidence interval.
Suppliers change layouts; model versions change. An agent that passed in March can drift by June.
LLM evaluation vs AI agent evaluation. LLM evaluation scores a model on general benchmarks. AI agent evaluation scores your agent — instructions, tools, data and model together — on your cases. The first helps you pick a model; the second tells you if your process works.
A golden dataset is a set of real cases with the answers a careful person would give. Everything else depends on it, so it is built like an asset: versioned, reviewed, and shaped to the job.
record: invoice-0142 review: verified
documents: [invoice-0142.pdf]
expected:
supplier "Northwind Traders" fuzzy ≥ 0.85
invoice_date 2026-03-14 date
total 18,240.50 numeric ± 0.5% critical
currency "EUR" exact critical
po_number "PO-77310" exact
line_items [12 rows] listDocuments with expected fields, packages with cross-document rules, questions with answers, and conversation scenarios.
Exact, fuzzy, numeric with a tolerance, date or list — a right answer written differently still scores right.
The fields that must never be wrong weigh double and get their own accuracy.
Every edit is a new version; each case is verified before it becomes the answer key.
An average accuracy hides the two things customers notice: the field that is wrong when it matters, and the case that is right only some of the time. The scorecard reports both.
Per field and overall, with precision, recall and F1 — so you know which field is weak.
Accuracy on the fields that must never be wrong, on its own line.
A case counts when every repeated run passes — the number a customer feels.
Schema breaks, plus time per case, and model cost per case for agents: a better score at triple the cost is a trade-off.
Is this summary faithful, does this answer cover the key facts, is this reply grounded in the source? An LLM judge can read them. It can also be lenient and inconsistent, so it works inside firm rules.
Every field a rule can score is scored by the rule.
The judge returns a binary verdict — supported or not — which holds steadier than a score out of ten.
Pick one from a different model family than the agent, so it never marks its own homework.
The scorecard says which judge was used, and shows a fallback as a fallback.
Does the answer state each fact the case expects?
Is each claim supported by the source documents?
For assistants, checked by rules on every turn: did it say what it must, avoid what it must not, and ask before changing anything?
A gate that fails a change on every dip gets switched off within a week; one that never fails a change is decoration. The Botminds gate compares a change with a pinned baseline, case by case, and flags what the evidence supports.
And the floor. A comparison says “no worse than before”. The floor says “good enough”: a score under the pass mark you set fails on its own, so an agent that was always weak is caught too.
Pick a good run as the baseline. Every later run is compared with it, case by case.
Off; advisory, which reports; and enforce, which marks a worse change as failing and says why.
Each run reports the smallest change it could detect, so you know when more cases will sharpen it.
An automation ties a target, a dataset, a judge, repeats and a gate together, and runs on every publish or on a schedule — so evaluation happens without anyone remembering to start it.
target agent: invoice-extractor
dataset invoices-golden (version 7)
judge your choice — a different model family
repeats k = 3
schedule on every publish
gate enforce · floor 0.90An agent, a workflow or a whole mesh, scored on the same dataset shapes.
Publishing an agent saves the change and starts its evaluations; an enforced gate flags a worse change with the reason.
Nightly or weekly runs catch drift when nothing in your project changed but the world did.
A run that stopped early is marked, so it is compared as what it is.
Every extracted field carries a confidence. Raw model confidence is usually too high. Botminds fits a calibration curve per field from reviewed outcomes, and then lets confidence send work straight through at a precision you set.
raw confidencecalibratedwhere it should bean illustration, not a measurement
A simple curve while outcomes are few; a finer one as they grow.
A curve is accepted when, on outcomes it was not fitted on, calibration error falls and overall error holds.
Set the precision you need: this field may skip review at 99%.
A neutral audit sample of straight-through work is still reviewed.
The platform finds the confidence bar whose precision clears 99% with 95% confidence.
Above the bar, the field skips review; below it, a person checks.
If audited errors climb, the field returns to review on its own.
Tests cover the cases you thought of; production brings the rest. LLM observability on Botminds records every request, every model call’s cost and every failure — and the Action Center turns them into a short list of things a person should do.
What needs me today?
Three items. Invoice intake has 41 documents waiting at extraction since 10:20 — the model provider’s rate limit, not your settings. Model spend for the claims project is 2.3× its usual Tuesday. And a reviewer queue in onboarding has had nobody claim it for six hours.
Why is claims spend up?
One agent, Claims summariser, moved to a larger model yesterday at 16:05; each call costs about four times more. Volume is normal. Shall I show the change and who made it?
Evaluation on Botminds runs at enterprise scale: golden datasets of thousands of cases, run side by side and repeated, on every publish of an agent and nightly, weekly or on demand for workflows and meshes — and continuous monitoring of production on the same scaled-out platform, on Azure, AWS, Google Cloud or on-premises.
Add each failure found live to the dataset, so the answer key keeps pace with the work.
Cases run side by side; each is repeated to measure consistency.
Set an agent’s evaluations to run on every publish; workflows and meshes are measured nightly, weekly or on demand against their baselines.
Traces, cost, exceptions and audited outcomes are watched continuously, and input drift is reported against a reference window.
Three kinds of tool get called “evaluation”. They answer different questions, and an enterprise running agents needs all three answers, joined up.
| LLM benchmark | Observability tool | Botminds evaluation & observability | |
|---|---|---|---|
| Question it answers | Which model is smarter in general? | What happened in production? | Is my agent right, consistently, and still right today? |
| Test cases | Public datasets | None | Your golden datasets, versioned and reviewed |
| Consistency | One score | Outside its scope | pass^k over repeated runs |
| Is a change worse? | Outside its scope | After the fact | Case-by-case comparison with a baseline: on publish for agents, on a schedule for workflows and meshes |
| Confidence | Outside its scope | Outside its scope | Calibrated per field; straight-through at a certified precision |
| Live failures and cost | — | Yes | Yes, with causes, owners and Piper |
| Setup | Download a leaderboard | Instrument your code | Built into every agent, workflow and mesh |
Measured, or it did not happen. Every number on these pages marked measured names the record it came from — see the scale results in agent mesh. The same rule applies to your agents.
More from the platform: the full architecture, and how security works at Botminds.
AI agent evaluation measures whether an agent does its job correctly and consistently, before a change goes live and while it runs. It uses golden datasets with known answers, rule-based scoring and LLM judges, repeated runs, and comparison against a baseline.
Build a golden dataset of real cases with verified answers; run the agent on it several times; score each field with the right match rule and use a judge where text must be read; compare with a pinned baseline; and set a gate that flags a real drop or a score under your floor on every publish.
A golden dataset is a versioned set of real inputs with the answers a careful person would give, used as the answer key. Good ones cover common formats and known edge cases, mark the fields that must never be wrong, and are reviewed before use.
Ground truth is the true answer for one case. A golden dataset is a curated, frozen collection of such cases, chosen to test what matters and versioned so that two runs are compared on exactly the same questions.
It is far steadier inside firm rules: Botminds scores everything a rule can score with the rule, asks the judge for yes-or-no verdicts, lets you choose a judge from a different model family than the agent, and names the judge on every scorecard.
pass^k is the share of test cases an agent gets right on every one of k repeated runs. Unlike average accuracy, it exposes cases that are right only some of the time — the ones behind “it worked yesterday” complaints.
Field accuracy with precision and recall, accuracy on critical fields, pass^k for consistency, schema breaks, time per case, and model cost per case for agents. For assistants: whether replies cover key facts, stay grounded and ask before changing anything.
On Botminds, golden datasets grow to thousands of cases, cases run in parallel with repeats, and you set an agent’s evaluations to run on every publish; workflows and meshes are measured nightly, weekly or on demand against their baselines — while production runs are monitored continuously for cost, failures and audited outcomes.
Seeing what agents do in production: a trace of each request, the cost of each model call, failures grouped by cause, queues and jobs, and drift in inputs and quality. On Botminds it feeds an Action Center that says who should act, and Piper answers questions about it in plain words.
Run evaluations on a schedule even when nothing changed, compare input distributions with a reference window, and watch audited outcomes on fields that skip review. On Botminds, a climb in audited errors sends a straight-through field back to review automatically.
Give us real cases. We’ll build the golden dataset, run your agent on it with repeats, and show you the scorecard, the weak fields and the calibrated confidence.