Agent harness traces and evals are the real improvement loop

At a glance

What this is: Arize argues that the real path to better AI agents is not prompt tuning alone, but a harness built around traces, targeted evals, failed-span analysis, and controlled change review.

Why it matters: For IAM and AI security teams, that shifts governance from output inspection to lifecycle control over agent behaviour, evidence, and safe change deployment.

Context

AI agents are systems that make decisions and take actions through tools, context, and runtime logic, so their behaviour cannot be governed by prompt quality alone. The problem is not just whether the output looks plausible, but whether teams can explain the path the system took, evaluate the right behaviour, and change it safely when something goes wrong.

That makes the harness a governance surface in its own right. In AI agent programmes, traces, evals, tool sequencing, review gates, and stopping criteria become the control points that determine whether behaviour is observable and improvable, which is exactly where identity, access, and policy questions start to matter.

Key questions

Q: What breaks when teams cannot trace what an AI agent did?

A: Governance breaks first, because teams lose the evidence needed to decide whether the issue was behavior, identity, or control. Without replayable logs of prompts, tool use, data access, and escalation, incident response becomes speculation and accountability becomes weak. For autonomous systems, traceability is the control that makes every other control defensible.

Q: Why do evals need to be built from real agent traces?

A: Because evals should measure the behaviour that actually produced the outcome, not an abstract guess about what might matter. Traces show the decision path, so the evaluator can inspect the right span, score the right behaviour, and catch the failure mode that drives the final report. That makes improvement specific instead of speculative.

Q: What are the signs that an agent improvement loop is failing?

A: The main signs are either every run passing, which suggests the eval is too weak, or every run failing, which suggests the rubric is misaligned. Another warning sign is when teams keep changing prompts without being able to point to the span or decision that caused the error. That means the harness is not informative enough.

Q: How should teams govern prompts that drive agent tool use?

A: Treat those prompts as high-impact workflow controls, not just text templates. Teams should require ownership, controlled testing, replayable traces, and approval criteria that reflect the downstream actions the agent can take, especially when tools touch sensitive data or external systems.

Technical breakdown

Why the harness matters more than the prompt

An agent harness is the operational layer around the model: the tools it can call, the context it receives, the traces it emits, the evaluators it runs, and the review gates that decide what changes ship. A prompt can influence a response, but it cannot by itself make runtime behaviour inspectable or correctable. That matters because most failures in agent systems are not simple answer-quality issues. They are trajectory issues: wrong data fetched, missing context, poor tool choice, premature stopping, or a rubric that judged the wrong thing. The harness is what turns those hidden decisions into evidence.

Practical implication: Treat harness design as a control objective, not just an engineering convenience.

How traces expose agent failure paths

A trace is the record of what the agent actually did during a run: tool calls, intermediate outputs, model calls, and the sequence of decisions that produced the final answer. Without that record, teams can only inspect the output and guess at the cause of failure. With it, they can see whether the problem happened in data retrieval, scoring, synthesis, or evaluation. That is especially important in agent systems because a good-looking final report can still be built on bad intermediate judgments. Traces provide the chain of evidence needed to isolate the real defect instead of rewriting prompts blindly.

Practical implication: Instrument every agent run so failures can be replayed at the span level.

Why targeted evals must follow traces

Evals are most useful when they are derived from traced behaviour rather than abstract expectations. Instead of judging the whole output at once, a targeted eval can test the specific span where a failure occurred, such as whether the agent scored an issue correctly or chose the right tool. That creates a tighter feedback loop because the evaluation maps to an observable behaviour, not a vague quality label. But the evaluator itself can also be wrong, so teams need to critique the eval against real spans and decide whether the agent, the rubric, or both need revision. That is the engineering loop Arize is describing.

Practical implication: Build evals from real traces and review both false passes and false failures.

NHI Mgmt Group analysis

Harness observability is becoming a governance control, not a debugging feature. Agent programmes fail when teams can see the output but not the path that produced it. That leaves no defensible way to explain why a decision happened, whether the evaluator was aligned, or what changed between one run and the next. For agentic AI security, observability is therefore part of control design, not a post-hoc troubleshooting aid.

Agent improvement creates a new trust boundary between analysis and action. The moment traces and evals can be consumed programmatically, they become inputs to automated recommendations and potential change proposals. That is useful, but it also means the organisation must separate diagnosis from deployment. Review gates are not optional bureaucracy here; they are the mechanism that keeps learning systems from turning feedback into unreviewed production drift.

Trace quality is the named concept practitioners should operationalise. Trace quality is the degree to which runtime evidence is complete enough to explain tool use, context selection, scoring, and failure points. If traces are incomplete or trapped in dashboards, the improvement loop becomes guesswork and evals degrade into theatre. Practitioners should treat trace quality as a prerequisite for agent governance, not a reporting metric.

From our research library:

• According to PwC, 79% of organizations have already adopted AI agents to some degree.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Trace quality is now part of agent governance. Once agents rely on tools, context, and evaluators, the organisation needs evidence that explains each step, not just a final answer. If the trace cannot show why a decision happened, the improvement loop cannot support accountable change.

AI agent programmes should move review earlier in the lifecycle. The right control point is not after the output is shipped, but before prompt, tool, or evaluator changes are promoted into production. That is especially true where the agent can alter business priorities, customer responses, or internal decision support.

According to PwC, 79% of organizations have already adopted AI agents to some degree. As adoption spreads, the pressure shifts from experimentation to safe operability, which makes traceable harnesses and reviewable evals the real scaling constraint.

For practitioners

• Define a trace-first agent workflow Record tool calls, intermediate outputs, model calls, and stop decisions for every meaningful agent run so failures can be replayed at the span level.
• Tie each eval to one observable behaviour Start with one targeted evaluation, such as priority scoring or groundedness, and map it to a specific span rather than the full output.
• Separate diagnosis from deployment Require human review before any prompt, tool, routing, or evaluator change reaches production, especially when eval logic itself changes.
• Use failed spans to drive the next change Group failed evaluations by root cause, then decide whether the prompt, rubric, tool implementation, or data sources need adjustment.

Key takeaways

• The article’s core message is that durable agent improvement comes from the harness around the model, not from prompt tuning alone.
• Traces and targeted evals turn opaque agent behaviour into evidence that teams can inspect, challenge, and refine.
• For AI governance, the practical lesson is to control observation, evaluation, and change approval before scaling agent autonomy.

Key terms

• Agent Harness: The agent harness is the runtime layer that wraps a model and turns it into an acting system. It usually includes the loop, tools, context handling, permissions, hooks, and logs. In security terms, it is often the real place where privilege sits and where identity evidence must be governed.
• Trace: A trace is the recorded path an agent took during a run, including tool calls, intermediate outputs, and decision points. It lets teams reconstruct how the agent arrived at an outcome instead of guessing from the final answer alone.
• Targeted Eval: A targeted eval is a narrow test that checks one specific agent behaviour, usually at the span or step level. Rather than scoring the final answer only, it measures whether the agent made a correct decision, used the right tool, or followed the intended rubric.
• Review Gate: A review gate is a control point where a human must inspect and approve work before it continues or is committed. In agentic workflows, review gates are only effective if they happen early enough to constrain the agent's path, not just after the fact.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and workload identity for practitioners who need to control access, lifecycle, and review. It helps security and identity teams apply governance discipline to systems that act through non-human identities.