Evaluating Agent Behavior: Outcomes, Trajectories and Production Feedback
How to judge agentic systems beyond the final answer: map LangChain, LangGraph and LangSmith to roles, score trajectories and context, and feed production failures into evals.
This article is published in English.
Sources: Building Better Agentic AI Systems: What I Learned About Deep Agents, LangSmith Engine & Evals
Getting an AI agent to work in a demo takes an afternoon with today's models and frameworks. The difficult part begins when that agent sits inside a real product: it picks the wrong tool, receives thin context, takes a route nobody planned, or returns an answer that sounds right and is not. This article looks at the engineering lifecycle that makes such systems reliable, with a focus on evaluation: what to measure, at which level, and how to turn every production failure into a check that keeps it from coming back. The examples use the LangChain ecosystem (LangChain, LangGraph, LangSmith and Deep Agents), but the ideas carry over to any stack.
From a single LLM call to an agentic system
A basic LLM feature is easy to picture: a request goes in, one model call happens, and a response comes out.
User → Prompt → LLM → Response
An agent is a different animal. Given a goal, it may split the work into tasks, retrieve documents, call APIs, run tools, keep state, hand part of the job to another agent, examine intermediate results, recover from errors and then choose its next move. A simplified view of that control flow:
USER GOAL
│
▼
AGENT
│
PLAN
│
┌──────────────┼──────────────┐
│ │ │
▼ ▼ ▼
TOOLS MEMORY SUBAGENT
│ │ │
└──────────────┼──────────────┘
│
▼
DECIDE / ACT
│
More work needed?
↙ ↘
YES NO
│ │
└── LOOP ▼
RESULT
Notice the loop at the bottom: the agent keeps deciding whether more work is needed, and every iteration can touch tools, memory or subagents. At that point you are no longer shipping a model response; you are running a system. This matters for quality because the final answer is only as good as the chain of decisions that produced it. A correct model with a bad retrieval step, or a good plan executed with the wrong tool, still produces a bad outcome.
Assigning roles: LangChain, LangGraph and LangSmith
A practical way to keep the three main LangChain products straight is to tie each to the engineering question it answers.
- LangChain supplies capabilities around the model: model integrations, tools, retrieval and connectors to external data. Its question is: what does the application need to be able to do?
- LangGraph handles orchestration once workflows become agentic, with state, conditional branches, loops, tool calls, human approval steps and multi-agent coordination. Its question is: how should the workflow run?
- LangSmith covers what happens after the system is live: which tools were called, what context the model saw, where latency grew, which step broke, why a decision was made, and whether the new version actually beats the old one. Its question is: what really happened, and was it good?
Stacked together, the flow runs from a business goal through capabilities and orchestration to a result, which is then observed and evaluated so the team can learn from it.
BUSINESS GOAL
│
▼
LANGCHAIN
Models • Tools • Data
│
▼
LANGGRAPH
State • Flow • Decisions
│
▼
AGENT SYSTEM
│
▼
RESULT
│
▼
LANGSMITH
Observe • Trace • Eval
│
▼
LEARN
The last arrow is the important one. Observation is not an end state; it feeds learning. If the split between LangChain and LangGraph is still fuzzy, our comparison of chains and stateful graphs covers it in depth.
Using agents to improve agents: LangSmith Engine
Tracing tells you precisely what an agent did, but a trace on its own fixes nothing. Somebody still has to read it, work out what went wrong, check whether the same failure shows up elsewhere, find the root cause, change the system and confirm the change did not break something else. That is manageable for a handful of runs and hopeless across thousands of production traces.
LangSmith Engine, a newer LangSmith capability at the time of writing, applies an agent to that analysis. It scans production traces for recurring patterns and failures, clusters related problems, helps diagnose them and proposes improvements. Crucially, the failures it finds can be pushed into evaluation, so an issue discovered today becomes an explicit check tomorrow. Conceptually the pipeline looks like this:
PRODUCTION AGENT
│
▼
TRACES
│
▼
LANGSMITH ENGINE
│
▼
Detect Patterns
│
▼
Diagnose Issues
│
▼
Suggest Improvement
│
▼
Add Evals
│
▼
Regression Testing
│
▼
Review / Deploy
│
└────────► Observe Again
Each stage narrows the problem: raw traces become patterns, patterns become diagnoses, diagnoses become candidate fixes, and fixes are gated by new evals and regression tests before a human reviews and deploys them. Then the cycle restarts with fresh traces.
The shift here is in how traces are treated. Instead of being something you open only during an incident, they become the raw material of continuous improvement. That is exactly how mature quality engineering already works in conventional software: a production bug should not end with a patch but with a test that stops the same class of defect from silently returning. Automated diagnosis does not remove the need for review, though. Proposed fixes to prompts or tool definitions can have side effects, which is why the review and regression stages stay in the loop.
Deep Agents for long-horizon tasks
Some requests hide a lot of work. Consider a quality-engineering request of this kind. Given a new product requirement, the agent must review the related docs, flag the riskiest user flows, draft test scenarios for them, dig into the code that implements those flows, and write up its findings.
To complete it, an agent has to plan, read files, retrieve knowledge, call tools, possibly run code, hold intermediate findings, delegate specialized pieces, and remember what it has already learned. The shape of that work:
Understand Goal
│
▼
Create Plan
│
┌─────────────┼─────────────┐
│ │ │
▼ ▼ ▼
Read Files Use Tools Search Knowledge
│ │ │
└─────────────┼─────────────┘
│
Delegate Work
│
▼
SUBAGENTS
│
▼
Combine Findings
│
▼
RESULT
Deep Agents is LangChain's agent harness aimed at this kind of longer-horizon work. It bundles planning, tools, file handling, context management, skills, memory and subagents, so you do not have to assemble each of those yourself.
The interesting part is not that the agent can do more, but how the autonomy is structured. Handing an agent twenty tools does not make it better; it often makes tool selection worse. Splitting every task across five subagents does not automatically improve the architecture either, because each handoff costs tokens and can lose context. The more capable the building blocks become, the more the design decisions around them matter. A useful default is to add a subagent only when a sub-task needs an isolated context or a different toolset, and to keep the tool list for each agent as small as the task allows.
Operating agents is a separate problem: Managed Deep Agents
Building a capable agent and running it reliably in production are two distinct engineering jobs. A long-running agent may need to survive interruptions, keep its state, work with files, execute code safely, stream progress to the user interface, retain memory, and emit enough telemetry for engineers to reconstruct what happened.
Managed Deep Agents, a hosted offering in the same ecosystem at the time of writing, targets that operational layer. The relationship between the two can be drawn as behavior on top and runtime infrastructure underneath:
DEEP AGENT
Planning • Tools • Files • Subagents
│
▼
Agent Behavior
│
▼
MANAGED DEEP AGENTS Durable Execution
Persistence
Sandboxes
Memory
Streaming
Identity
Tracing / Evaluation
The agent defines behavior through planning, tools, files and subagents. The managed layer provides durable execution, persistence, sandboxes, memory, streaming, identity, and tracing with evaluation. The general lesson applies whether you use a managed service or run your own: model intelligence is one component of a production AI architecture, and the infrastructure around it deserves equal attention. Our comparison of runtime harnesses and composed frameworks explores the build-versus-adopt trade-off.
Why agents break traditional testing
Conventional testing thrives on determinism. Feed a function a known input, get an output, assert on it.
Input → Function → Output → Assertion
Call an API with a fixed request and you can check the status code, response schema, payload, headers and business rules. Agents do not fit this mold. Ask one to investigate a production incident and find the probable root cause. On one run it reads logs first and then queries a database; on another it checks documentation, calls an API and only then reads logs. The paths differ, yet both might reach a sound conclusion.
The reverse is also possible and more dangerous: a final answer that looks right even though the agent relied on an unreliable source, used an inappropriate tool, or reached the correct conclusion for the wrong reasons. An exact-match assertion on the output cannot distinguish these cases. That is the gap evaluations fill.
What an eval measures
A workable definition: an eval scores how well an AI system performed against the standards that are important for one particular job. The criteria come from the task, not from the framework.
Take an agent that generates test scenarios from a requirement. Knowing that it returned ten test cases in valid JSON tells you almost nothing. The meaningful signals are about quality:
GENERATED TESTS
│
▼
EVALUATE
│
┌────────────────┼────────────────┐
│ │ │
Coverage Correctness Relevance
│ │ │
├──────── Hallucination ──────────┤
│ │
└──────────── Duplication ─────────┘
│
▼
QUALITY SIGNAL
In practice those dimensions become concrete questions:
- Do the tests actually cover the requirement?
- Is each one relevant to it?
- Did the agent invent behavior the product does not have?
- Did it skip an important negative or edge-case scenario?
- Are several of the ten effectively duplicates?
Each question can become a scorer: some are deterministic (duplicate detection via normalized text or embeddings), some need a reference dataset (coverage against known requirements), and some typically need an LLM-as-judge or human labels (hallucinated functionality). Structural checks like schema validity are still worth running, but as a baseline rather than the definition of success.
Three evaluation surfaces: response, step and trajectory
With agents you do not have to evaluate only the final output. There are at least three useful targets:
- The final response: is the answer correct, complete and relevant?
- A single step: for example, did the agent choose the right tool for this sub-problem, with sensible arguments?
- The trajectory: the whole sequence of actions taken to reach the goal.
Here is a typical trajectory for a question-answering agent:
User Goal
│
▼
Agent
│
├── Search Documentation
│
├── Query Database
│
├── Call API
│
└── Generate Answer
The final answer is just the last node. For many applications the route matters as much as the destination, for example whether the agent consulted documentation before querying production data, or whether it made an API call it had no reason to make. Trajectory evaluation becomes essential once agents can change data, open tickets, run code, trigger workflows or act inside enterprise systems, because a harmful intermediate action is a failure even if the final message reads well. Trajectory checks can be strict (an exact expected sequence), lenient (required steps present in any order, forbidden steps absent) or judged by a model; lenient checks are usually the right starting point given the path variance described above.
Offline and online evals as one loop
Evaluation splits naturally into two modes that map onto familiar software practice.
Offline: gate releases on known cases
Offline evaluation runs against curated datasets and scenarios before a release. You execute representative cases against the candidate agent version, score them, compare against the current version and decide whether to ship.
Known Dataset
│
▼
Agent Version
│
▼
Run Evals
│
▼
Compare Results
│
▼
Release Decision
This is the agent equivalent of a regression suite in CI. Because model outputs vary between runs, it helps to run each case more than once and compare score distributions rather than single results.
Online: learn from real traffic
Online evaluation scores what happens in production, and production is where the surprises live. Users ask things nobody anticipated, external tools fail, context arrives incomplete, data changes underneath you, and agents take trajectories no dataset contains. Scoring a sample of live traces surfaces these cases.
Closing the loop
The two modes become far more valuable when connected: every meaningful production failure found online is added to the offline dataset, so the next release is tested against it.
OFFLINE EVALS
│
▼
BUILD
│
▼
DEPLOY
│
▼
PRODUCTION TRACES
│
▼
ONLINE EVALS
│
▼
DISCOVER FAILURE
│
▼
ADD FAILURE TO DATASET
│
└────────► OFFLINE EVALS
Over time the offline suite stops reflecting what the team imagined users would do and starts reflecting what they actually do. Be deliberate about privacy when copying production inputs into datasets; redact or synthesize sensitive fields before they become permanent test data.
Agent behavior as a new quality surface
None of this replaces traditional testing. UI, API, integration, data validation, performance and security testing remain necessary for any reliable product. Agentic systems add another layer on top: the quality of the agent's behavior. That layer raises its own questions:
- Was the tool it picked the right one?
- Was its context on-topic and backed by real sources?
- Did memory improve the decision, or inject stale information?
- Was the subagent actually needed?
- When a tool errored, did it recover sensibly?
- Did it spin in loops without progress?
- Did it achieve what the user wanted?
- How much latency and cost did its trajectory add?
Organized as a model, these questions look quite different from the classic test pyramid:
AGENT QUALITY
│
┌─────────────────┼─────────────────┐
│ │ │
OUTCOME TRAJECTORY CONTEXT
QUALITY QUALITY QUALITY
│ │ │
▼ ▼ ▼
Correctness Tool Usage Groundedness
Relevance Decisions Relevance
Completeness Efficiency Freshness
│
┌────────┴────────┐
│ │
MEMORY RECOVERY
│ │
▼ ▼
Accuracy Failure Handling
Relevance Retry Behavior
Outcome quality covers correctness, relevance and completeness. Trajectory quality covers tool usage, decisions and efficiency, and branches into memory (accuracy and relevance of what is recalled) and recovery (failure handling and retry behavior). Context quality covers groundedness, relevance and freshness. Each leaf can map to one or more evaluators, and together they give a far richer picture than a pass/fail on the final answer. Building this out calls for new practices around agent testing, observability, trajectory evaluation, AI regression suites, production scoring and continuous improvement, which is where quality engineers and AI engineers increasingly overlap. For the safety side of the same problem, see our guide to LangChain guardrails and middleware.
Practical changes for your own agent projects
The lesson from all this is not to adopt every new feature. It is closer to the opposite: be more deliberate about architecture.
- Define evaluation criteria while designing the agent, not after it ships.
- Treat observability as part of the initial architecture rather than a later add-on.
- Route production traces back to engineering as feedback, not just incident evidence.
- Make sure every significant production failure ends up covered by a future eval.
- Match complexity to the problem. Sometimes a simple agent is enough; sometimes LangGraph orchestration is justified; sometimes a task truly benefits from subagents, persistent context or a full agent harness.
The technology should follow the problem, never the other way around.
The improvement loop
Frameworks will come and go; the durable idea is a loop.
LEARN
│
▼
BUILD
│
▼
OBSERVE
│
▼
EVALUATE
│
▼
IMPROVE
│
└──────────► LEARN AGAIN
You learn a concept and build with it. Building exposes what you did not understand. Running it exposes problems you did not foresee. Evaluation replaces assumptions with evidence, evidence drives improvement, and improvement usually reveals the next thing to learn.
Key takeaways
- An agent is a system of decisions; judge the decisions, not just the final text.
- Give each tool a clear job: LangChain for capabilities, LangGraph for orchestration, LangSmith for observation and evaluation.
- Evaluate at three levels, response, step and trajectory, and prefer lenient trajectory checks when valid paths vary.
- Connect online and offline evals so production failures become regression cases.
- Add agent autonomy, tools and subagents only where the task demands them, and let measurements confirm the choice.
Models, frameworks and hosted products in this space change quickly, so check current documentation for features such as LangSmith Engine and Managed Deep Agents. The discipline of observing, measuring and feeding lessons back into the system is what will keep your agents trustworthy as everything around them evolves.