Written by Damilola Oladele.
Traditional tests, like unit tests, can catch some agent failures at the point where one function, tool, or service hands its output to the next. However, traditional tests miss trajectory-level failures. A trajectory is the full sequence of steps an agent takes to complete a task, so a trajectory-level failure unfolds across tool calls, state changes, retries, and recovery. You need an agent evaluation to catch trajectory-level failures before your users do.
For example, a team deploys a research and data analysis agent to production. Its job is to read research questions, query a data warehouse, retrieve internal documents, run analysis code, and publish summary reports to a shared workspace. Although the agent passed all traditional tests before deployment, the team recorded three production failures in the first week. The first failure is a state verification failure. The agent told a stakeholder that the quarterly analysis report had been published to the shared workspace. However, no report existed in the workspace. This means that there is a mismatch between the agent’s claim and reality. A state verification failure differs from a hallucination, which is a false statement in the response text. To confirm a state verification failure, the mismatch must be confirmed against the external state rather than the response text alone.
Note:Recent agent-evaluation research categorizes this same pattern as an outcome hallucination. In outcome hallucination, the agent asserts task completion despite trace evidence showing otherwise, a distinct failure class from ordinary hallucination or simply forgetting an existing state.
This check has its own failure mode: if it runs against an eventually consistent index, such as MongoDB Atlas Vector Search, where the vector index updates asynchronously after a write, a verification query run immediately after the write can return a false negative. “No report found” can mean the report doesn’t exist, or that the index hasn’t caught up yet. Evaluators that treat every miss as a state-verification failure will overcount on systems like this.
In the second failure, the agent made an incorrect tool call. Instead of querying the data warehouse for a revenue figure, it queried a web search tool and returned a confident answer based on the wrong source.
Finally, the agent got stuck in a planning loop. It retried the same failed warehouse query five times, thereby consuming unnecessary tokens and eventually timing out.
These three production failures described earlier could have been prevented through agent evaluation.
This guide explains what evaluation means for AI agents, the metrics that matter, and how Langfuse and LangSmith help you observe, measure, and improve agent behavior.
An evaluation measures how well an AI system performs a task. It applies one or more grading criteria to the system’s behavior and outcomes to determine whether it met the expected objective. Depending on the system, the evaluation may examine the final response, the intermediate reasoning process, tool usage, execution trace, and changes to the external state.
Generally, Large Language Model (LLM) applications generate a single response to a prompt, so evaluating the final response is often sufficient. Agentic systems, however, complete tasks by planning, calling tools, maintaining state, and making decisions over multiple steps. So, evaluating only the final response can miss failures that occur during execution.
There are two broad categories of evaluation:
Note:A turn is one interaction in the agent’s execution. It begins when the agent receives new information, such as a user prompt or tool result, and ends when the agent produces its next action or response.
The following are the performance dimensions that agent evaluations assess:
Note:No single dimension provides a complete picture of agent performance. For example, an agent with 95% task success but a 10-minute average completion time still frustrates users.
You should evaluate agents for the following reasons:
This section defines the metrics used to evaluate agent performance, explains the methods for measuring those metrics, and shows how to apply them at different levels of testing.
The following table summarizes the key metrics to track for each dimension of performance:
The self-aware failure-rate metric within the task success dimension deserves additional explanation. Self-aware failure rate measures the percentage of failed tasks in which the agent correctly reports uncertainty or requests escalation instead of pretending to have succeeded. For example, an agent that says, “I can’t access this warehouse table,” scores higher than one that fabricates a report. Some agent-benchmarking research uses the same term, self-aware failure rate, to describe exactly this distinction between a solid production agent and a brittle prototype.
While metrics define what you evaluate in AI agents, measurement methods define how you score an agent’s performance against those metrics. The following subsections describe the primary measurement methods for evaluating AI agents.
The first measurement method is rule-based checks, which are fast, cheap, and objective. They work well for validating expected outputs, tool call parameters, string matches, and execution counts. The main limitation of rule-based checks is their rigidity. They can mark a correct response as incorrect if it doesn’t match the expected pattern.
The second measurement method is LLM-as-judge, which is also known as model graders. Model graders evaluate open-ended outputs that are difficult to verify with rules alone. They are well-suited for questions such as, “Did the agent resolve the user’s request?”
One limitation of model graders is that, because they judge generated text, they require validation by human reviewers to maintain consistency.
Model graders can also reward fluent but unsupported answers. You can reduce this risk by including evidence in the evaluation rubric, such as tool outputs, retrieved documents, or application state. In the research and data analysis agent scenario, the grader should assess the warehouse query results and report status in addition to the final summary.
Human review is the most reliable way to evaluate nuance and domain-specific judgment. You can use subject-matter experts to check model graders, perform spot checks, compare alternative approaches through A/B testing, and review high-risk scenarios where automated methods may be unreliable. You should reserve human review for cases where automation is insufficient because human review can be time-consuming and expensive.
You can apply each measurement method at the following levels:
Langfuse and LangSmith are observability and evaluation platforms for AI agents. They capture execution traces, including prompts, responses, tool calls, latency, token usage, and cost, and let you attach evaluation scores to each execution.
The primary difference between Langfuse and LangSmith is the ecosystem.
Langfuse is an open-source, framework-agnostic platform. It commonly uses the @observe decorator to trace function execution and integrates with OpenTelemetry, allowing agent traces to appear alongside application traces. Also, self-hosted Langfuse stores traces in ClickHouse. You can run SQL queries against it for cross-run analytics, such as cost by model, latency percentiles, and tokens per session.
Self-hosted Langfuse has lower software costs. This deployment model gives you greater control over data residency, which can support compliance requirements such as the General Data Protection Regulation (GDPR), the Health Insurance Portability and Accountability Act (HIPAA), and internal IP policies. Actual compliance still depends on deployment and operational practices.
LangSmith is LangChain’s managed evaluation platform. When you use LangChain or LangGraph, tracing can be enabled through environment variables such as LANGSMITH_TRACING, LANGSMITH_API_KEY, and optionally LANGSMITH_PROJECT. LangSmith supports tracing outside the LangChain ecosystem through the @traceable decorator.
LangSmith also includes built-in evaluators and experiment tracking for structured evaluation workflows. LangSmith offers automation rules that route low-quality runs to human review and promote high-confidence runs into datasets. Unlike self-hosted Langfuse, LangSmith’s managed Software as a Service (SaaS) doesn’t expose a raw SQL-accessible trace store.
The following table compares how each platform supports several of the dimensions introduced earlier:
It’s recommended to compare Langfuse and LangSmith using the same workload before choosing a platform. For example, create three traces: one successful run, one failed report-state run, and one retry-loop run. Then score each trace in both platforms and compare how quickly they surface failures.
A Field Guide to Agentic Eval Frameworks: Langfuse, LangSmith, and What to Measure was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.