Evaluating Agent Trajectories: Stopping Multi-Step AI Workflows from Hallucinating in Production

An unmonitored AI agent enters an error loop at 2:00 AM. Tasked with updating a CRM record, it hallucinates a parameter in its API call. The CRM returns a standard 400 Bad Request error. Instead of stopping, the agent reads the error, guesses a different incorrect parameter, and tries again. Because the entire history of this failure is appended to the agent's context window with every retry, the token payload grows exponentially. By the time a hard timeout kills the process thirty steps later, a task that should have cost fractions of a cent has burned through your API budget.

For US and Gulf region enterprise buyers and SaaS founders scaling their operations, this is not just a technical glitch—it is a direct hit to gross margins and operational stability. Agent trajectory evaluation is how you stop multi-step AI workflows from hallucinating actions, violating compliance boundaries, and burning capital. Across the industry, most enterprise AI projects stall in pilot purgatory because teams build agents that work beautifully on the happy path during a demo, but fail unpredictably when handed real, messy data. They accumulate AI technical debt—tangled prompt chains and unmonitored agents—that we call AI spaghetti.

Verel Systems takes AI from spaghetti to production. Building production-grade agentic systems requires abandoning the idea that you can evaluate an AI by simply reading its final answer. To protect your bottom line and guarantee service-level agreements (SLAs), you must evaluate the trajectory: the exact sequence of decisions, tool calls, and state changes the agent made to get there.

The Financial Cost of Multi-Step Hallucinations

When a basic Retrieval-Augmented Generation (RAG) system fails, the financial exposure is relatively contained. The system retrieves the wrong document, generates a poor answer, and returns it to the user. The transaction ends.

When an autonomous agent fails, the financial risk cascades. Agents are designed to act in loops: they observe a state, reason about what to do next, execute an action (like querying a database or calling a web API), and observe the result. If the reasoning step is flawed, the agent takes a wrong action. If the system lacks trajectory evaluation, the agent will often try to "fix" its own mistake, leading to recursive loops that drain your API budgets while degrading the customer experience.

The financial math behind these loops destroys unit economics. Consider a customer support agent processing a ticket. A successful trajectory looks like this:

1. ▸Read ticket (500 input tokens)
2. ▸Call search_knowledge_base (1,000 input tokens, 50 output tokens)
3. ▸Read retrieved docs (2,000 input tokens)
4. ▸Draft reply (500 input tokens, 200 output tokens)

At standard frontier model pricing (roughly $5.00 per 1M input tokens and $15.00 per 1M output tokens), this successful run costs approximately $0.02.

Now consider an error loop trajectory where the agent struggles with tool use in production (calling search_docs instead of search_knowledge_base). The system returns an error. The agent retries. With every retry, the previous errors are appended to the context window so the model knows what it has already attempted.

• ▸Run 1 context: 1,500 tokens
• ▸Run 2 context: 2,000 tokens
• ▸Run 3 context: 2,500 tokens
• ▸Run 4 context: 3,000 tokens
• ▸Run 5 context: 3,500 tokens

Before a standard system-level timeout stops the process, the agent has consumed over 12,500 tokens just reading its own failure history, costing roughly $0.06 in input tokens alone. This effectively multiplies the base cost by 3x. When factoring in the wasted output tokens and the compute time of the backend systems being hammered by malformed API requests, unmonitored autonomous agents can easily multiply task costs due to recursive error loops.

Quantifying the Business Impact: If your platform processes 10,000 automated workflows a day, a modest 15% error loop rate that hits a 30-step timeout turns a predictable $200 daily API bill into an $800+ daily liability. Over a single quarter, this translates to $54,000 in wasted API spend alone. More critically, it represents 1,500 failed workflows daily that require manual engineering triage—costing an estimated $12,000 per month in developer overhead and risking severe customer churn due to breached SLAs.

Why Standard RAG Metrics Fail Autonomous Agents

Most engineering teams attempt to evaluate their new agents using the same metrics they used for their earlier text-generation pipelines. They use frameworks like RAGAS to measure context recall, answer relevancy, and faithfulness.

While these metrics are helpful for static search pipelines, relying on them for autonomous agents introduces significant business risk. Standard RAG evaluation routinely misses multi-step agent reasoning and tool-use errors because it only grades the final output, leaving your business exposed to silent failures and compliance violations.

The reason for this blind spot is architectural. RAG metrics are designed for a static, two-step pipeline: retrieve data, then generate text. They evaluate the relationship between the user's prompt, the retrieved text, and the final output.

Agents do not have static pipelines. An agent dynamically decides its own control flow. It might decide to search the web, then write a Python script, execute it, read the output, and then query an internal SQL database. If you only evaluate the final answer against the initial prompt, you are ignoring the entire execution path—and the associated security, regulatory, and financial risks.

Consider a scenario where an agent is asked: "What is the total revenue for Q3?" The agent should call a query_financial_db tool. Instead, it hallucinates and calls a web_search tool, searching the public internet for your private company's Q3 revenue. Finding nothing, it replies: "I do not have access to the Q3 revenue data."

If you run a standard RAG evaluation on this output, the metric for "faithfulness" might score a perfect 100%. The final answer ("I do not have access") is technically faithful to the retrieved context (a blank web search result). The RAG evaluator sees a system working as intended. The business reality is that the agent failed completely because it chose the wrong tool—and potentially leaked intent or metadata to public search engines.

To catch these failures and protect proprietary enterprise data, you must evaluate the trajectory. You must assert that for a financial query, the query_financial_db tool was invoked, that the parameters passed to it were valid SQL, and that the agent did not attempt to route private data to a public search endpoint.

What Good Looks Like: Evaluating Agent Trajectories

Building for production means shifting your observability strategy from black-box testing to white-box tracing. This shift directly translates to lower operational risk, faster debugging cycles, and predictable system behavior. You need to see inside the loop.

A trajectory is the complete, ordered sequence of states an agent transitions through during execution. It includes the user input, the system prompts, the model's intermediate reasoning (often called "Chain of Thought"), the specific tools invoked, the exact JSON payload passed to those tools, the latency of the tool execution, and the final output.

Evaluating this trajectory requires specialized infrastructure. Tracking frameworks like Weave and Langfuse can isolate specific tool-call failures within complex LangGraph states, allowing your engineering team to identify bottlenecks before they impact customer-facing systems.

When Verel builds production systems, we instrument the agent graph so that every node transition emits a trace. If a multi-agent system fails, we do not just see a generic "Task Failed" error. We see exactly where the breakdown occurred.

For example, a trace might reveal:

1. ▸Node: Analyze_Request (Success, 400ms)
2. ▸Node: Select_Tool (Success, 800ms) - Selected update_inventory
3. ▸Node: Format_Parameters (Failure, 1200ms) - Passed string "five" instead of integer 5.
4. ▸Node: Execute_Tool (Error, 100ms) - API rejected payload.

By isolating the failure to the Format_Parameters step, you stop guessing why the agent is failing. You can immediately implement a deterministic fix—such as adding a strict JSON schema validation step before the tool execution node, forcing the LLM to output the correct data type.

This level of precision is what separates a fragile prototype from a resilient enterprise system. Demos rely on the LLM "getting it right" most of the time. Production systems assume the LLM will eventually get it wrong, and they use trajectory evaluation to catch the error before it impacts the business.

To transition your AI initiatives from unpredictable prototypes to stable, high-ROI business assets, you need an engineering partner who designs for observability and cost control from day one.

The Financial Impact of Trajectory Evaluation

Investing in trajectory evaluation infrastructure requires upfront engineering effort. To justify this capital expenditure to business stakeholders, you must compare the operational reality of unmonitored agents against production-grade systems.

The primary business value of trajectory evaluation is risk mitigation and cost containment. When an agent has access to write data (updating records, sending emails, processing refunds), a silent failure is unacceptable. If an agent refunds the wrong customer because it misread a database ID in step two of a five-step process, standard final-answer evaluation will not save you. Trajectory tracing provides the audit log required to prove exactly why the system took an action, which is a non-negotiable requirement for deployment in regulated environments like finance, healthcare, or enterprise SaaS.

Implementing Trajectory Guardrails in Production

Building this infrastructure requires moving away from simple linear prompt chains and adopting stateful multi-agent systems. We use LangGraph because it allows us to model the agent's workflow as a deterministic state machine, giving business leaders complete control over the operational boundaries of their AI.

In a stateful graph, the "state" is a shared dictionary that gets updated as the execution moves from node to node. Trajectory evaluation involves writing programmatic assertions against this state dictionary at critical transitions.

For a business, the validation code below functions as an automated financial and operational circuit breaker. Instead of allowing an LLM to repeatedly query an expensive enterprise database or external API with invalid parameters, we intercept the execution using deterministic validation. This prevents both database performance degradation and compounding API costs before they occur.

def validate_tool_parameters(state: AgentState):
    """
    Circuit breaker: Ensure the LLM provided valid parameters 
    before making the expensive/risky API call.
    """
    tool_calls = state.get("pending_tool_calls", [])
    
    for call in tool_calls:
        if call.name == "update_crm":
            # Deterministic check, not an LLM check
            if not isinstance(call.args.get("customer_id"), int):
                return {"error": "customer_id must be an integer", "next_node": "recovery"}
                
    return {"next_node": "execute"}

This is not artificial intelligence; it is standard software engineering applied to AI workflows. If the validation fails, the graph does not enter a recursive error loop. It routes to a deterministic recovery node, which might format a highly specific error prompt to force the LLM to correct the data type, or it might simply escalate the task to a human operator.

We integrate this state management with observability tools. Every time the validate_tool_parameters function trips, a flag is raised in Weave or Langfuse. Over a week of production traffic, you can query these traces to see exactly which tools the model struggles to format correctly. If your traces show the model frequently fails to format the update_crm tool, you have actionable data. You can rewrite the tool's description in the system prompt, simplify the JSON schema, or switch to a model family with stronger instruction-following capabilities, protecting your margins and ensuring system reliability.

Frequently Asked Questions

Does trajectory evaluation slow down the agent in production? No, tracing and state validation add negligible latency (typically a few milliseconds for standard Python execution). The evaluation of the traces—such as using an LLM-as-a-judge to grade the quality of the reasoning steps—is done asynchronously after the run is complete. The inline circuit breakers are simple deterministic Python functions, not LLM calls, so they do not impact user-facing speed.

What is the ROI of implementing trajectory evaluation versus the cost of building it? For an enterprise or high-growth SaaS platform processing 10,000+ runs per day, trajectory evaluation typically pays for itself within the first 60 to 90 days. The upfront cost of building stateful guardrails is offset by a 70–90% reduction in wasted API token spend, a dramatic reduction in developer support hours spent debugging black-box failures, and the prevention of catastrophic silent errors that cause customer churn.

Can we use LLMs to evaluate the trajectory? Yes, but only asynchronously. Running an LLM to check another LLM's work at every step significantly increases your latency and costs. In production, you use deterministic checks (schema validation, type checking, string matching) inline to control the graph flow. You use LLM-as-a-judge offline on your trace data (via Langfuse or Weave) to score the overall logic and identify areas for prompt improvement.

How do we fix an agent that constantly hallucinates tool parameters? First, check your tool schemas. Most parameter hallucinations happen because the JSON schema provided to the model is too complex or lacks clear descriptions. Simplify the schema. If the error persists, implement a retry node in your LangGraph architecture that catches the specific validation error and returns it to the model with strict formatting instructions. Limit this to exactly one retry to prevent infinite loops.

What is the difference between tracing and evaluation? Tracing is the collection of data: recording every step, prompt, and tool call the agent made. Evaluation is the scoring of that data: asserting whether the path taken was correct, efficient, and safe. You cannot evaluate a multi-step agent without first tracing its trajectory.

Relying on final-answer metrics for autonomous agents is a guarantee of future failure. If your AI initiatives are stuck because the agents cannot reliably handle edge cases without looping or hallucinating actions, the problem is not the model. The problem is the lack of trajectory observability. Stop treating your agents like black boxes, implement stateful guardrails, and track every step of the execution path.