If you are used to the rhythm of traditional software engineering, you instinctively believe that writing clear requirements, getting the logic right, and covering everything with unit tests will lock quality in place like a safe. But once you put an LLM into a loop where it plans, calls tools, reads and writes memory, and interacts with an environment, quality is no longer a lock — it is more like an F1 car. It can still run, but only continuous telemetry and track-level evaluation can tell you whether it will fly off the guardrail at the next corner.
The core stance of the *Agent Quality* whitepaper is blunt: Agent quality is an architectural pillar, not the last testing step before launch. Agents rarely fail by crashing; they fail by 'plausibly drifting off course': hallucinations, bias, drift, unexpected policies... The API still returns 200 OK, while the user quietly loses trust.
This post walks through the whitepaper's main line — why old QA fails, how to evaluate, and how to turn evaluation engineering into a closed loop — from the four quality pillars to the Outside-In evaluation hierarchy, the three pillars of observability, and finally the most engineering-flavored conclusion: the Agent Quality Flywheel.
Chapter 1: Why Traditional QA Is Not Enough for Agents
The whitepaper uses a precise analogy: traditional software is a truck; an AI agent is an F1 car. A truck follows a fixed route and you ask 'does the engine start? is the route correct?'. An F1 race is decided by dynamic judgment: fuel strategy, braking points, tire management, reaction to surprises. An agent's quality is likewise not about whether it runs, but how it thinks and acts at every step.
Traditional QA is good at catching explicit errors (crashes, exceptions, deterministic computation bugs) but poor at catching agents' 'silent degradation'. An agent may output answers that 'look real' but are factually wrong; it may loop forever without crashing; it may violate business ethics without violating syntax. Worse, these behaviors are unstable, hard to reproduce, and strongly coupled to context/environment.
Typical failure modes listed in the whitepaper are all 'the system is alive, but already failing or misbehaving':
- Algorithmic bias: turning systematic bias in training data into decision rules, even amplifying it
- Factual hallucination: generating high-confidence fabricated facts without evidence
- Performance/concept drift: the real world changed, but the model still lives in yesterday
- Emergent unexpected behavior: exploiting rule loopholes, 'agent wars' with other bots, etc.
- Task success rate (binary or graded)
- User satisfaction (likes/CSAT)
- Overall quality (e.g., 'did it summarize all 10 articles?')
- Domain accuracy (medicine, law, finance)
- Nuanced judgment on tone, intent, ethical alignment
- Producing the Golden Set (without which automated evaluation loses its anchor)
- prompt/response
- tool calls (inputs/outputs/errors)
- state changes
- (within compliance limits) key intermediate steps
- System Metrics (vital signs): P50/P99 latency, error rate, tokens per task, cost, completion rate, tool call frequency
- Quality Metrics (decision quality): correctness, trajectory adherence, helpfulness, hallucination rate, safety compliance (usually requiring a golden set or LLM judge)
- Treat evaluation as an architectural pillar, not a closing test (leave telemetry hooks first, then talk about launch)
- Trajectory is the truth (the final answer is only the last sentence of the story)
- Humans are the final judges (automation for scale; humans for anchoring value and safety)
> Tip: Agent failures are usually 'judgment errors', not code bugs. You cannot debug a hallucination with breakpoints or eliminate bias with unit tests. What you need is to turn the 'judgment process' into an observable, evaluable, and feedable engineering object.
Chapter 2: From Model-Centric to System-Centric — Evaluate the Trajectory
The whitepaper breaks AI's evolution into five layers, each expanding the evaluation surface:
1. Traditional ML: Precision/Recall/F1 against a test set 2. Passive LLM: probabilistic outputs; human evaluation and model comparison appear 3. LLM + RAG: errors may come from retrieval or generation 4. Agentic systems: planning + multi-step reasoning + tool interaction + evolving memory → non-deterministic accumulation along the trajectory 5. Multi-agent systems: system-level emergent failures; cooperation and competition both complicate evaluation
The key conclusion is hard-line: Trajectory is the Truth. An agent's output is only the last link in a long chain. What you evaluate is not one sentence, but:
> Thought → Action → Observation → Thought → … → Final Answer
Once you accept 'the trajectory is the evaluation unit', everything else (Outside-In, Observability, Judge, Flywheel) follows naturally.
Chapter 3: The Four Pillars of Agent Quality
The whitepaper splits agent quality into four interrelated pillars — not slogans, but a way to put business value, user experience, engineering constraints, and safety bottom lines into one framework:
Effectiveness (goal achievement)
A black-box question: did the user's real intent get fulfilled? Not 'it wrote code' but 'the code produced the right insight'; not 'it found the product' but 'it drove conversion'.Efficiency (resources and cost)
An agent can succeed 'expensively': 25 steps, 5 failed tool calls, 3 self-corrections. Efficiency metrics track token cost, end-to-end latency, and trajectory length/complexity.Robustness (real-world resilience)
When APIs time out, page structures change, data is missing, or user prompts are vague: does it fail gracefully, retry, or ask for clarification — or fabricate and pretend to succeed?Safety & Alignment (the non-negotiable gate)
However effective, it must not cross the line: bias, privacy leaks, prompt injection, dangerous actions. The whitepaper defines this pillar as a 'non-negotiable gate'.Together, these four pillars imply one engineering requirement: you cannot reliably measure any of them by looking at the final answer alone. Without the trajectory you cannot count steps, locate failed tool calls, or verify safety policies fired at critical points.
Chapter 4: The Outside-In Evaluation Hierarchy
Do not obsess over component metrics from the start. Proceed by layers.
4.1 Outside-In: End-to-End Evaluation (Black Box)
Ask the most important question first: did it achieve the goal? Typical metrics:If the black box is at 100%, you can stop; if it fails, open the box.
4.2 Inside-Out: Trajectory Evaluation (Glass Box)
After a failure, decompose the trajectory segment by segment. The whitepaper offers a practical six-point diagnostic checklist:1. LLM planning/reasoning (Thought): going off-topic, loops, context pollution, hallucination 2. Tool selection and parameterization: wrong tool, missing parameters, type errors, malformed JSON 3. Understanding tool results (Observation): misread values, missed entities, not recognizing 404/error states 4. RAG performance: wrong retrieval, stale information, or the model ignoring retrieval results and fabricating anyway 5. Efficiency and robustness: excessive calls, redundant loops, unhandled exceptions 6. Multi-agent dynamics: communication misunderstanding, role drift, agents fighting each other
> Practical tip (ADK): interact in the ADK Web UI until you reach an 'ideal response', then save the current session as an Eval Case (including the final answer and tool trajectory), and use adk eval/pytest for regression testing. Every production failure can thus be 'frozen' into a permanent test case.
Chapter 5: Who Grades? — From Automated Metrics to LLM Judge to Humans
Evaluation is not just 'what to look at' but 'who arbitrates'. The whitepaper stresses a hybrid mechanism:
5.1 Automated Metrics: fast and reproducible, but shallow
ROUGE/BLEU, embedding similarity, and task benchmarks (e.g., TruthfulQA) serve as the first CI/CD gate: catching obvious regressions and monitoring trends — but they cannot replace deeper judgment.5.2 LLM-as-a-Judge: use a stronger model to evaluate a weaker one
Give the judge model the user question, candidate answers, reference answers (if any), and a scoring rubric. The whitepaper recommends pairwise (A/B comparison) over single 1–5 scoring, with win/loss/tie statistics being more robust.5.3 Agent-as-a-Judge: evaluate the 'process', not just the 'output'
To judge plan quality, tool sequence plausibility, and parameter correctness, the most effective approach is handing the execution trace to a dedicated Critic Agent for item-by-item audit: is the plan feasible, should the tool be called here, is the parameter structure compliant... This fits 'Trajectory is the Truth' perfectly.5.4 HITL: humans are not replaceable components
Human review is not perfectly objective either, but HITL is irreplaceable in three things:Real user feedback (likes/dislikes) must become an event-driven pipeline: a negative review should automatically package the context and trace into a review queue, not sleep in a log file.
Chapter 6: The Three Pillars of Observability
Another kitchen analogy: traditional software is an assembly-line cook; an agent is a chef on a 'mystery ingredient challenge'. You cannot just taste the dish — you must watch every step of choosing ingredients, revising the plan, and coping with missing sugar.
6.1 Logging: the agent's diary
Best practice is structured JSON logs recording:Emphasize the 'verbosity vs performance' trade-off: INFO by default in production, DEBUG in development; structured logs for filtering and querying.
6.2 Tracing: chaining logs into causal links
A trace chains spans so you can see at a glance: user request → RAG failure → tool received empty input → LLM misled by wrong output → final fabricated answer. OpenTelemetry/Cloud Trace trace_ids make this scalable.6.3 Metrics: aggregating evidence into a health report
The whitepaper splits metrics into two classes:Operational practices: separate dashboards for system health and quality metrics; PII scrubbing on production logs; dynamic sampling (e.g., sample 10% of successful requests, 100% of errors) to balance granularity and cost.
Chapter 7: The Agent Quality Flywheel
The whitepaper welds everything into a closed loop: define goals → enable visibility → evaluate the process → build the feedback loop:
1. Define Quality: set direction with the four pillars 2. Instrument for Visibility: collect evidence with logs + traces 3. Evaluate the Process: grade evidence with Outside-In + Judges + HITL 4. Architect the Feedback Loop: automatically convert production failures into regression cases, accumulating into the Golden Eval Set
The flywheel's power is that it turns 'incident retrospectives' from a human ritual into an engineering mechanism — every failure becomes the system's next immune memory, giving quality improvement momentum.
The whitepaper states three principles for 'trustworthy agents' like an engineering manifesto: