How Uber evaluates AI agents at production scale

At Arize:Observe 2026, Aayush Agrawal, a senior AI product manager at Uber, shared a story during his talk.

A mother asks an Uber voice agent to book a ride to San Francisco International Airport. In the background, her child says, “I want pizza too.” The agent hears both requests. Instead of treating the child’s comment as ambient conversation, it begins rerouting the ride toward a nearby pizza restaurant.

The incident had slipped through the team’s offline evaluations. Production caught it indirectly, after the average session length jumped from four or five conversational turns to as many as 20. A conversational designer followed the traces, found the failure, and changed how the agent handled requests unrelated to booking.

For Agrawal, the pizza detour signaled more than a memorable edge case. It exposed a structural weakness in how teams approach agent evaluation. Most teams know they need evals. Many already have the platforms, judges, datasets, and dashboards required to run them. Far fewer have built an evaluation system that consistently turns production behavior into new tests, product decisions, and better agents.

So, Uber’s agent platform team spent more than a year studying that gap. Its conclusion became the central thesis of Agrawal’s talk: the hardest part of evals isn’t the tooling. Instead, it’s designing the defaults, ownership models, and feedback loops that make evaluation part of everyday product development.

At Uber’s scale, that work carries real consequences. When an agent fails, someone may miss a ride, lose income, or have an order disrupted. Evaluation therefore has to do more than produce a score before launch. It must help teams understand what their agents are doing in production, learn from behavior they never anticipated, and decide what to build next.

Why production AI agent evals become a checkbox

Uber’s agent platform supports teams with dramatically different levels of technical maturity.

An operations team might be building its first personal productivity agent; an infrastructure group might create an agent for debugging pipeline failures; or a consumer product team might have dedicated engineers, designers, and researchers building an agent that books rides.

These teams share two priorities: speed and quality. Their paths toward those goals look very different.

To support them, Uber built a broad agent platform that included model access, AI guardrails, reusable skills and agents, code-first SDKs, managed deployment, low-code building tools, and an evaluation platform. Yet even with those capabilities available, teams repeatedly followed the same pattern: they built the agent first and postponed evaluation.

This rarely came from indifference toward product quality. Teams were trying to prove that an agent could work, find a viable product experience, and ship quickly. During that phase, evaluation could feel like an additional system to design before the product itself had fully been developed.

Installing more tools did little to change that behavior. Teams already had tools. Instead, they needed an evaluation workflow that required fewer decisions and delivered useful feedback sooner. That insight led Uber toward a different platform strategy: make the practices associated with reliable agent evaluation part of the default development path.

Start AI agent evaluation with complete tracing

Many agent teams begin with logs that capture a user’s input and the agent’s final response. That record can be useful for simple applications, but often leaves out the part developers need when something goes wrong: the trajectory.

A production agent may call several tools, retrieve documents, update its plan, retry an action, and generate intermediate outputs before responding. When the final answer fails, input and output logs cannot show which decision created the problem.

Uber found that teams often added fuller observability only after an agent had entered production. When a real incident occurred, developers had to reconstruct the behavior from fragmented logs or incomplete records. So, the platform team changed tracing from an optional integration into an automatic part of deployment.

Agents deployed through Uber’s managed agent system received tracing in every environment from the beginning. The deployment process also provisioned the appropriate Arize environment and permissions. Teams using the code-first SDK could enable tracing through a small configuration change.

This default served two purposes. It gave developers the evidence required for debugging, and it created the production data needed for meaningful evaluations later.

That second purpose matters because production traces reveal more than whether an agent succeeded. They show what users ask for, how the agent interprets those requests, which paths consume the most time, where tools disagree with generated answers, and which behaviors the original test set failed to anticipate.

With that record, teams at Uber could begin evaluating the agent their users actually experience. That is the core job of an agent observability platform: connect what happened in production to the next round of evaluation and improvement.

Automate the path from traces to useful signals

Tracing solves the visibility problem, but can introduce a second problem: teams now have a large volume of behavioral data and no clear process for converting it into insight.

A developer may need to decide:

• Which traces should become evaluation examples?
• Which evaluators are appropriate for this agent?
• How often should those evaluators run?
• Which thresholds indicate a meaningful regression?
• Where should the results appear?
• Who is expected to respond?

Each decision adds friction, but together, they can turn evaluation into a small internal platform project.

Uber reduced that burden by using information it already possessed. The platform had the agent’s configuration, its production traces, and contextual information about its intended behavior. From those inputs, it could create evaluators tailored to the agent, run them continuously, and deliver relevant alerts through tools such as Slack.

One team, for example, received an alert showing that the agent contradicted tool outputs in roughly 30 percent of evaluated cases. Team members did not need to understand the LLM-as-a-judge technique behind the alert before recognizing the product problem. The result was concrete enough to investigate immediately.

This approach helped solve the cold-start problem for teams that had never designed an evaluation suite. Instead of asking them to anticipate every relevant failure before launch, the platform used early agent behavior to give them a practical starting point.

Developers still needed to inspect and refine the resulting evaluations. Automation lowered the cost of reaching the point where that refinement became worthwhile.

Build evaluation datasets from production failures

Evaluation datasets have an uncomfortable lifecycle. Teams may struggle to create the first one, then struggle just as much to keep it relevant.

A dataset assembled before launch reflects assumptions about how users will behave. Once the agent reaches production, those assumptions begin to age. New user intents appear, model behavior changes, tools evolve, and the product itself gains capabilities.

Uber designed different defaults for teams at different stages:

The principle behind each workflow is the same: production should continuously improve the next round of offline evaluation.

This is especially important for multi-turn agents. A generic user simulator can generate plausible conversations while missing the constraints, habits, and interruptions found in the actual product. By combining agent context with real traces, teams can create simulations that better resemble the conversations their agent needs to handle.

The result is a feedback loop between online behavior and offline testing. Production exposes a weakness, a human reviews it, the example enters the evaluation dataset, and future versions of the agent have to demonstrate that they can handle it.

A dataset that remains untouched for months may continue producing a reassuring score. But that score becomes less and less meaningful as the product moves away from what’s defined by the test cases.

Make AI agent evaluation a cross-functional workflow

Traditional software testing often sits primarily with engineering. Agent evaluation depends on a wider set of expertise.

An engineer can determine whether a tool call completed successfully. A conversational designer may be better equipped to judge whether the agent handled an interruption naturally. An operations specialist may know which edge cases create real downstream costs. A product manager may understand whether an answer supports the intended customer experience.

At Uber, much of the subject-matter expertise required to evaluate an agent lived with the people closest to the user. The evaluation interfaces, however, had originally been designed around engineering workflows.

The platform team began making evals accessible through user interfaces that allowed product, design, and operations teams to inspect evaluators, review examples, and participate in maintaining evaluation criteria. Engineers no longer had to translate every judgment into an evaluation rule on someone else’s behalf.

The rise of coding agents created another interface for this work. Uber began developing skills that allowed team members to ask a coding agent about traces, investigate failures, and manage parts of the evaluation lifecycle through natural-language instructions.

This broadened participation without removing engineering rigor. Developers still owned instrumentation, integrations, and system behavior. Subject-matter experts could contribute directly to defining what good behavior looked like.

The voice-booking incident illustrates the value of that arrangement. A conversational designer identified the production failure and incorporated what the team learned into its weekly evaluator and dataset updates. The person with the most relevant understanding of the interaction could act on the evidence directly.

Measure eval quality by the decisions it changes

After Uber improved tracing, automated evaluator creation, simplified dataset management, and expanded access, one problem remained: product quality was not improving as much as expected. Teams were still treating evaluation as a launch gate.

The dominant question was whether an agent had reached a particular score. Once the result crossed the required threshold, the team could ship. Over time, this encouraged teams to optimize their datasets and evaluators around the target number.

But that meant a passing score could quietly signal the agent had learned to satisfy the test suite. It did not necessarily show that the evaluation system was teaching the team anything new about the product.

Uber began asking a more demanding set of questions (the same kinds of questions raised by practitioners like Hamel Husain) when evaluating whether an eval suite is actually useful:

• Do you trust what your evals are telling you? A polished dashboard has little value when the team doubts the evaluator’s judgments.
• Would an evaluation regression stop a release? When a team would ignore a decline and ship anyway, the evaluator may be measuring behavior that nobody considers important.
• Which product decision changed because of an evaluation result? Useful evals influence the roadmap, prompt a design change, reveal a missing capability, or alter how an agent is built.
• When was the dataset last updated? A dataset that no longer reflects production behavior can generate dangerously misplaced confidence.
• How quickly can the team test a new model or system change? When evaluating a model release requires weeks of preparation, the evaluation system cannot support the pace of agent development.

These questions changed the conversation. They shifted attention from the existence of an evaluation score toward the quality of the learning process around it.

The platform team did not arrive at them during a single whiteboard session. It held detailed discussions with agent teams about ownership, accountability, and the practical work required to maintain evals. It also compared approaches with evaluation practitioners at other organizations.

Some of those conversations were uncomfortable because they exposed cases where evaluation existed largely for procedural reasons. That discomfort was productive. It helped distinguish an evaluation suite that certified a launch from one that improved the product.

Production metrics can reveal failures your evaluators miss

The voice-booking failure also shows why evaluation systems need more than direct quality scores. The team’s offline evaluators had not included a scenario in which a child made an unrelated request in the background. The production system still exposed the problem because the agent’s behavioral metrics changed dramatically.

Average turns per session became a proxy for confusion. When conversations expanded from a typical four or five turns to 15 or 20, the spike indicated that the agent was struggling even before the team knew why.

This suggests a broader evaluation strategy. Agent quality signals can include:

• Task completion and outcome accuracy
• Tool selection and tool-result consistency
• Conversation length
• Repeated actions or retries
• Escalation frequency
• Latency and token usage
• User corrections
• Abandonment
• Unexpected changes in agent trajectories

None of these metrics independently explains the failure. Together with complete traces, they can identify where to investigate. Different production agent patterns also need different criteria; conversation-length spikes matter more for multi-turn assistants than for single-shot task agents.

The important design choice is to connect the alert to the evidence. A spike in session length should lead the team to the relevant traces, which should then support an investigation, an evaluator update, and a new dataset example.

Using evals to power a continuous agent improvement loop

Uber’s longer-term vision extends beyond alerting teams when an agent regresses. It points toward the same shift discussed throughout Observe: from human-operated agent development to systematic agent improvement.

The traces generated by a production agent contain evidence about user needs, failure patterns, and system behavior. An evaluation system can organize that evidence, identify recurring problems, and suggest how the agent should change.

The improvement loop described by the platform team looks like this:

In this model, evals become the engine connecting production evidence to the next version of the agent. Uber has started building an eval copilot around this idea. The system can draw from several sources of context, including the agent configuration, product documents, architectural documents, production traces, and previous evaluation results.

Given that context, the copilot could identify a group of related failures, recommend changes to the evaluation suite, propose an agent modification, run the candidate against offline tests, and present the comparison to the builder. That direction aligns with the broader industry move toward self-improving agent factories, where observability, evals, and experimentation form one continuous loop.

Human review remains central. The system assembles the evidence and reduces the labor required to produce a credible candidate. The agent builder decides whether the proposed change improves the product.

That workflow could dramatically shorten the distance between discovering a production problem and shipping a verified fix. It also gives evaluations a proactive role. Instead of waiting for a customer complaint or a public incident, the system can identify emerging patterns while the team still has time to intervene.

The best evals should inform what developers build next

Uber’s experience traces an evolution that many agent teams are now beginning.

Evaluations start as an afterthought. Platform defaults make them easier to adopt. Production data makes them more representative. Cross-functional ownership improves their judgment. Better questions connect the results to product development.

The platform team’s central lesson is that reliable evaluation workflows should emerge naturally from the way agents are built and operated. Tracing should begin with the first deployment, evaluators should draw from agent context, datasets should absorb reviewed production failures, and the people closest to the customer should be able to participate.

Once those pieces are in place, an eval score becomes only one output of a much richer system. The more important output is a decision: which failure to fix, which behavior to redesign, which model to test, which dataset to update, or which version of the agent to ship.

An evaluation system earns its place in the stack when it consistently changes what the team builds next.