Introduction
Prompt Engineering gave way to Context Engineering, which governs what the model sees. Context Engineering gave way to Harness Engineering, which governs the operating environment the model acts within.Both disciplines are about building the system.This article addresses the question that determines whether any of it can be trusted in production: how do you know the agent is working?
It is not enough to know that an agent produced a correct answer. You must be able to demonstrate how it arrived there, prove it followed the required process, and reconstruct the decision months later when someone asks. That capability is built from two connected disciplines, Observability and Evaluation, and neither is optional once agents take consequential actions.
The silent failure problem
Traditional quality checks fail on agents for a specific reason. Consider an agent asked to find a flight that returns the correct flight number and price. A user rates the interaction five stars. Pass and fail scoring records a success. What the metrics did not capture is that the agent made three unnecessary API calls and hallucinated an intermediate price check along the way. The answer was right. The process was not.
This is the silent failure problem. Agents return plausible answers while making unnecessary calls, fabricating intermediate facts, or following unsafe reasoning paths, and binary outcome metrics catch none of it. Two agents can produce identical correct answers while one wastes tokens on an irrelevant tool and a duplicate call. Output-only evaluation rates them equally.
The scale of the consequence is documented. Analysis of adoption finds that while a large majority of organizations have deployed AI agents, most cannot trace failures through multi-step workflows or measure quality systematically. Evaluation gaps are among the systematic failures driving projected cancellations of nearly half of agentic AI projects.
Trajectory evaluation versus outcome evaluation
The response to silent failure is to evaluate the path, not only the destination.
Outcome Metrics
Measure final task completion and output quality. They validate whether the agent achieves the business goal, and they remain necessary.
Trajectory Metrics
Evaluate the complete reasoning and execution path, including intermediate steps, tool selections, and decision sequences. They expose reasoning failures and enable debugging and process improvement by showing how the agent works, typically scored across dimensions such as grounding and context use, experience quality, and security and safety.
Trajectory evaluation carries real overhead. It requires building reference trajectories, maintaining evaluator infrastructure, and paying for the evaluation calls themselves, so it is not always warranted. The decision is not binary. Many teams begin with outcome evaluation, add trajectory checks on their most critical workflows, and expand coverage as production failures reveal what outcome metrics alone cannot explain.
One category of organization should not treat it as optional. In regulated and high-stakes domains, including finance, healthcare, and legal, institutions often need to demonstrate that the agent followed a specific protocol, not merely that it produced the right answer. Trajectory evaluation is what produces that evidence.
LLM as a judge, and its limits
Manual review does not scale. An agent processing thousands of interactions daily cannot have a human inspect each one, which is why using a stronger model to score agent outputs against a rubric has become the practical default for trajectory evaluation.
It is also imperfect, and practitioners should be candid about that. Documented weaknesses include systematic biases such as position bias, length or verbosity bias, self-enhancement bias, and agreeableness bias. Error rates can exceed fifty percent on complex evaluation tasks, and agreement with domain experts in specialized fields sits in the range of roughly sixty-four to sixty-eight percent. A single evaluator model may produce a plausible score without genuinely understanding domain policy, operational risk, or the required tool sequence.
The mitigations are known. Design judge prompts with explicit rubrics, few-shot examples, and structured outputs that require evidence before scoring, because vague criteria are precisely what produce position and verbosity bias. Use multiple judge passes, calibrate against human-labeled examples, and validate reliability statistically across independent runs. The point is not to abandon automated judging but to treat the judge as a measuring instrument that itself requires calibration.
The technique is also evolving. Agent as a judge extends the idea by using an agent, rather than a single model call, to examine the full trajectory. In one code evaluation study, the agent judge diverged from the human majority vote only a fraction of a percent of the time, while a standard single judge seeing only final outputs disagreed roughly a third of the time. For long-horizon agents, a basic judge simply cannot fit the entire trajectory into its context window or verify stateful changes against systems of record, which is the gap agentic evaluation is designed to close.
Observability: seeing the decision path
Evaluation answers whether the agent performed well. Observability is what makes that question answerable at all.
Agent observability is the practice of capturing every step an agent takes during execution, including tool selection, tool arguments, model responses, memory reads and writes, state transitions, and decision branches, producing a structured trace that lets you reconstruct what the agent did, in what order, and with what inputs and outputs at each step.
It sits one layer above traditional monitoring. Conventional infrastructure tooling captures request rates, latency percentiles, and span counts. Application logging captures developer-defined events. Agent observability captures semantic behavior: which tool the agent chose, what arguments it passed, what came back, and how the next reasoning step changed in response. Stated simply, ordinary monitoring observes outputs, while agent observability explains the chain of decisions that produced the outcome.
A common objection is instrumentation overhead, and it is largely overstated. In-process tracing adds single-digit millisecond overhead per span in most frameworks. The teams that resist instrumenting are frequently the same teams that spend two days debugging a production failure a good trace would have resolved in twenty minutes.
The feedback loop
The value of the two disciplines together is greater than either alone, because they form a flywheel. Production traces that fail an automated scorer are converted into evaluation cases. The evaluation suite grows from real user behavior rather than from imagined test scenarios. Failures flow into annotation queues for expert review and then become regression tests that prevent the same defect from recurring.
Mature teams extend this into release control, running evaluations automatically on every change and blocking deployment when quality drops below a configured threshold. This is the point at which agent quality stops being a matter of judgment and becomes an engineering gate.
Why this is a governance discipline
For financial institutions, evaluation and observability are the mechanisms that convert AI governance policy into evidence.
Auditability
Structured traces are the record that allows an institution to reconstruct why an agent did what it did. Without harness-level instrumentation, that reconstruction is not possible, and it is the first thing an examiner or internal audit function will request.
Protocol Adherence
Trajectory evaluation demonstrates that a required sequence was followed, which is distinct from and stricter than demonstrating a correct result.
Continuous Assurance
A single correct run does not establish reliability. Quality must be measured across runs, query types, data domains, and time periods to detect degradation patterns. Evaluation probes embedded in live workflows can assess factual grounding, completeness, and sufficiency during inference rather than only in pre-deployment suites, producing machine-readable verdicts with rationale for audit purposes.
Human Oversight
For high-risk systems, EU AI Act Article 14 mandates human oversight interfaces with verified confirmation steps, and human-in-the-loop checkpoints for high-stakes decisions are standard practice in reliable deployments regardless of jurisdiction.
Agent Sprawl
As deployment accelerates, organizations routinely discover agents stood up by individual teams without central registration, governance, or monitoring. These shadow agents access production data, make decisions with business consequences, and accumulate cost with no visibility into their behavior. An observability layer paired with an ownership registry is the control that surfaces them.
Where to start
A practical sequence for an institution beginning this work. Instrument tracing on critical agent paths first and attach business metadata from day one so traces can be filtered by product, client segment, or process. Wire up at least one automated evaluation check before going to production. Begin with outcome evaluation, then layer trajectory evaluation onto the workflows with the highest consequence. Calibrate any automated judge against a human-labeled sample before trusting its scores. Expand governance, anomaly detection, and release gating incrementally. The trace foundation, however, needs to be present from the start, because it cannot be reconstructed retrospectively.
Conclusion
An AI agent’s reliability cannot be established by its final answer alone. Observability makes its execution path visible, while evaluation tests whether its actions and results meet defined expectations. Together, they connect system design with operational accountability. For organizations deploying agents in consequential workflows, that means building traceability into the architecture, calibrating evaluators against expert judgment, and using production failures to strengthen future tests. The goal is evidence that the system performs consistently and follows the required process.
Build the trace foundation early, evaluate both the outcome and the path, and treat automated judges as instruments that need calibration. Context engineering shapes what an agent sees. Harness engineering shapes what it can do. Observability and evaluation provide the evidence needed to assess whether it worked. That evidence is what makes reliability measurable, failures diagnosable, and human oversight actionable.
Explore more: Start Here · Topics · Archive · About