Most teams approve agents on subjective review. Here's the structured scoring framework — 11 measurable dimensions across five families — that turns "looks good" into a governance decision you can defend.
'Looks good' is not an evaluation framework. Here are the 11 dimensions every AI agent should be scored on before production — and how each one is actually measured, not guessed at.
At the quarterly AI review, someone asks whether the customer support agent is ready for production. The product manager says the outputs look good. The QA lead says they tested 50 scenarios and found no issues. The CISO says to test more. Nobody can define what "ready" actually means. The meeting ends with a decision to run another two weeks of review.
This is how most enterprise AI agent deployment decisions get made — by subjective consensus, not measurable criteria. There is no defined pass threshold, no scorecard an auditor could examine six months later, and no mechanism to detect whether the agent has drifted from its original quality baseline after deployment. The decision to grant an AI agent more autonomy — to let it execute refunds, close tickets, or schedule follow-ups without a human in the loop — is one of the highest-stakes software decisions a team makes. And it is almost universally made with the same rigor as "let's ship it and see."
This post defines the 11 dimensions every AI agent should be scored on, explains how each is actually measured using validated techniques, and shows how a composite score structure creates the governance mechanism that turns "looks good" into a defensible production decision. We cover the full scoring model, the right measurement technique per dimension, and how Trust Certify, Trust Runtime, and Trust Audit implement this across the agent lifecycle.
Traditional software ships when tests pass. A CI pipeline runs a defined suite; if all green, the deployment proceeds. The threshold is binary, the criteria are objective, and any engineer can reproduce the result. That model breaks completely for AI agents.
An AI agent's behavior is probabilistic, context-dependent, and multidimensional. A response that is accurate might still be incoherent. A response that is coherent might cite a fact the agent fabricated. A tool call that looks right might be invoked with arguments that violate a business policy nobody thought to test. These failure modes do not appear in a binary test suite — they emerge in the interaction of multiple quality signals that need to be evaluated simultaneously.
AI agents fail creatively. A traditional application has a finite set of failure modes. An AI agent has a nearly infinite one. The only way to manage that complexity is to measure it systematically — across every relevant dimension, on every call, with a scoring model that aggregates the signals into a decision.
The second problem with subjective review is that it has no memory. If an agent's behavior drifts after a model update, a prompt revision, or a change in the documents it retrieves, a human reviewer will not notice unless they happen to test the specific scenario where drift occurred. A scoring system running on every call catches drift before a human does — because it is looking at every call, not a curated sample.
The 11 dimensions are organized into five functional families. Each family covers a distinct aspect of agent trustworthiness. None is optional for a production agent — an agent that scores 100 on Quality and 0 on Safety is not a trustworthy agent.
This is where evaluation systems divide into those that work and those that don't. The wrong answer is to put a single LLM judge on every dimension and call it done. LLM judges are slow, non-deterministic, expensive per call, and have known biases toward longer outputs and their own prior generations. The right answer is to use the measurement technique that is appropriate for each dimension — deterministic, ML classifier, or LLM-as-judge — and reserve the expensive approach for the cases where it is genuinely necessary.
Decompose the answer into atomic claims, then verify each claim against retrieved context: score = supported_claims / total_claims. Deterministic baseline uses lexical overlap; LLM-upgradeable to full RAGAS semantic verification.
Generate the questions the answer would answer, then measure cosine similarity to the actual question. An answer that would answer a different question is penalized — even if it is factually accurate and well-written.
LLM-as-judge with a chain-of-thought rubric. The judge scores logical flow, internal consistency, and narrative continuity across turns. Requires an LLM judge but produces reliable, human-interpretable explanations for failures.
Match tool calls against expected name, arguments, and invocation order. Includes irrelevance detection — a tool call that should not have been made is a failure even if it returned a valid result.
Input perturbation: typo → synonym → paraphrase → semantic shift. Score = output invariance across perturbation levels. This is an offline, multi-run evaluation — it cannot be done from a single call, but must be run against every prompt change or model update.
Three-layer detection: toxicity classifiers (Detoxify), PII detectors (Presidio for SSNs, API keys, payment card numbers via Luhn validation), and safety-judge models (Llama Guard for harmful content). Each layer catches a different category of safety failure.
The underlying pattern: some dimensions are deterministic or statistical, some require ML classifiers, and some genuinely need an LLM judge. A governance-grade evaluation layer uses the right method for each — not one LLM for everything. Using an LLM to evaluate latency is wasteful. Using a string match to evaluate coherence misses the point.
Individual dimension scores are useful for debugging — they tell you exactly which aspect of agent behavior failed and why. The composite score is useful for governance — it tells you whether the agent clears the bar to operate at a given level of autonomy.
Each dimension carries a weight that reflects its importance for the agent's specific use case and risk context. Safety and Faithfulness are weighted higher for agents that handle sensitive data or make consequential decisions. Latency and Cost are weighted higher for agents in high-volume, cost-sensitive pipelines. The resulting composite is a single number from 0 to 100 that encodes the full quality surface of one agent execution.
Don't use a single composite threshold across all your agents. A customer support agent and a payment execution agent have fundamentally different risk profiles. Define per-agent-type thresholds: what score enables unsupervised operation, what score triggers human review, and what score forces a block regardless of business pressure.
The composite score gates autonomy promotion. This is the structural link between measurement and governance: you cannot grant an agent more autonomy unless it has demonstrated it meets the measurable criteria for that autonomy level. This transforms the deployment review from "does this feel ready?" to "does it meet the defined threshold?"
Note that the payment agent requires both a high composite and a specific Faithfulness floor — and mandates human-in-loop regardless of score. This is the correct model for high-stakes agents: the composite score governs routine operations, while explicit hard constraints handle the highest-consequence scenarios where no score, however high, eliminates the need for human review.
A common mistake is building an evaluation layer that runs an LLM judge on every request. In testing, this looks thorough. In production, it collapses. LLM judges add 800ms–5 seconds of latency per call, cost money on every inference, produce non-deterministic outputs across identical inputs, and cannot explain their reasoning in an auditable way. When an LLM judge says a response "feels off," that is not a reason you can put in an incident report or regulatory filing.
The viable architecture is deterministic-first, LLM-upgradeable. The baseline implementation uses statistical and rule-based methods for each dimension — 1–5ms per check, free, reproducible, and fully explainable. For dimensions where LLM-grade precision is necessary (Faithfulness in a RAG pipeline, Brand & UX for a high-stakes customer-facing agent), you register an LLM judge that upgrades that specific dimension without changing anything else. The result: 9 of 11 dimensions resolve in under 5ms total, LLM judges run only on the 1–2 dimensions where they add genuine value, and every failure produces a concrete, auditable reason — the exact claim that could not be grounded, the exact tool that was called out of order, the exact PII pattern that was detected.
What does a real failure look like in practice? Here is a decision log from four live agent calls:
The clean answer sails through in under 20ms. The SSN leak, the jailbreak attempt, and the low-faithfulness payment response are each stopped with a specific, reproducible reason. No "the model felt off." Every decision can be audited, replicated, and explained to a regulator.
When running Robustness evaluation offline, test every prompt template change — not just model updates. A prompt that routes differently under paraphrase is as broken as a model that does. Most teams test model updates and forget that prompt engineering is equally capable of introducing robustness regressions.
Most evaluation frameworks — RAGAS, DeepEval, TruLens, Galileo — are designed for offline benchmark runs. You curate a test set, configure the evaluation pipeline, run it against a snapshot of your model and prompts, and get a report. This is genuinely useful for pre-deployment validation and regression detection between model versions.
What these frameworks do not do: score every production call, return a gate decision synchronously before the output is released, or produce audit records as a byproduct of normal operation. They are designed for evaluation cycles, not governance infrastructure. The distinction matters because agent failures do not happen in your test set — they happen in production, with real users, in scenarios your test set never covered.
Eval frameworks and runtime governance are complementary, not competitive. Use eval frameworks for comprehensive pre-deployment validation and regression testing between model versions. Use runtime governance for inline scoring of every production call, synchronous gate decisions, and audit records that regulators and boards can inspect. The failure to distinguish these two jobs is why teams think they have evaluation covered when they actually only have the offline half of it.
The practical implication for teams: zero-config scoring of 9 of 11 dimensions from the call envelope means there is no reason not to score every production call. The call already carries the agent ID, request, tool execution trace, output, latency, and token count — 9 dimensions score from that data with no additional instrumentation. Faithfulness needs the retrieved context; Robustness runs offline. Everything else is already there, already structured, already available. The only choice is whether to compute the scores or discard that information.
The question every team asks after seeing the 11-dimension model is: where do I start? The honest answer is that your initial thresholds are educated guesses that you will adjust based on production data. Start conservative, measure the false positive rate (valid outputs that get escalated or blocked), and tighten or loosen specific dimension floors based on what the data shows.
A practical starting framework for a customer-facing support agent: Safety ≥ 95 (hard floor — do not negotiate this), Faithfulness ≥ 80 (escalate for human review below this), Tool-Use ≥ 90 (block on fabricated tool calls regardless of composite), composite ≥ 80 for unsupervised operation. Run this in shadow mode for two weeks — compute every decision but don't block — and review the escalation queue. If 40% of escalations are false positives (human reviewers approve them), raise the Faithfulness floor. If Safety escalations are all genuine, keep that floor or raise it.
For high-stakes agents (payment, records modification, scheduling with external consequences), start with composite ≥ 95, Safety ≥ 99, Faithfulness ≥ 90, and mandatory human-in-loop for any action above a defined impact threshold regardless of score. Build toward autonomous operation by accumulating evidence, not by lowering the bar.
Production readiness is not a one-time certification. An agent that scores 95 on launch day may score 82 six weeks later — because the documents it retrieves have changed, a new user population is probing it in ways that weren't in the test set, or an upstream data source has degraded. Score drift is real, it is common, and it is invisible without continuous monitoring.
Track composite score as a time-series metric, not just a one-time gate. Set alert thresholds on rolling averages: if the 7-day average composite drops below the certification score by more than 5 points, trigger a re-evaluation. Track dimension-level drift separately — a drop in Faithfulness with stable Safety and Coherence usually points to a retrieval degradation problem, not a model problem. A drop in Tool-Use often signals that an API schema changed and the agent is now calling tools with stale argument formats.
AgentTrust OS implements the 11-dimension evaluation framework across the full agent lifecycle — from pre-production certification through every live call to long-term audit reporting.
AgentTrust OS certifies agents on all 11 dimensions — pre-production, at runtime, and across every audit record.
Start Free →