How Uber is making evals the operating system for production AI agents with Arize

Problem

As Uber moved AI agents, including voice agents, toward production, high eval scores sometimes masked failures in real customer interactions. Engineering-focused evaluation tools also made it difficult for PMs and designers to help define and assess agent quality.

Solution

Uber uses Arize AX to connect evaluation results with agent traces, helping teams identify missed failures and refine evaluators. A shared UI and Arize Skills bring engineers, PMs, and designers into the evaluation workflow.

Results

Uber expanded evaluation ownership beyond engineering, enabling PMs and designers to help identify failures, refine quality criteria, and improve agents. With evals built into development, teams are establishing the foundation to move confidently from limited launches toward broader production rollouts.

When teams first start building AI agents, evals can feel like a launch checklist item: define the evaluator, get a passing score, ship the feature. Aayush Agrawal, AI product lead at Uber, has seen why that is not enough.

In one review with product managers working on production-level agents, teams were reporting eval scores above 90. But when they opened the actual traces and looked at what the agents were saying turn after turn, the picture changed. “I could see the color in their face when they were reporting a 90-plus eval score, but when they actually saw the real traces, one after another, they saw that their eval scores were not representative of what was actually happening,” Aayush says.

For Uber, the lesson was clear: evals are not a rubber stamp. They are part of the development loop. And as agents become more autonomous, longer-running, and more embedded in customer workflows, the teams building them need to understand not just whether an agent passed an eval, but why it behaved the way it did.

That shift has changed how Uber thinks about instrumentation, experimentation, and the role of product, design, operations, and engineering in building reliable AI systems. Learn more from Uber’s talk at Observe.

The challenge: high eval scores did not always match real user behavior

Agent quality is difficult to judge from aggregate scores alone.

A score can say that a system is passing and a dashboard can show that performance is trending in the right direction. But production traces tell a more specific story: what the user said, what the agent understood, what it did next, and where the interaction drifted away from the intended path. That gap becomes especially important for voice agents.

In the real world, users do not interact with agents in clean, isolated prompts. They talk over background noise. They change topics. Other people in the car or room speak at the same time. Children interrupt. The agent may hear something that was not meant for it at all.

Aayush described one example: a rider was trying to book a ride to SFO, while their kids were talking about wanting pizza. The voice agent picked up the pizza conversation and redirected the family toward a pizza place.

That kind of failure is easy to miss in a test set and hard to diagnose from a score alone. It is also exactly the kind of real-world behavior that matters once an agent is interacting with customers.

The issue was not that evals were unimportant. It was that evals needed to be treated as living systems: continuously inspected, questioned, updated, and connected back to the traces they were meant to represent.

The shift: invest in instrumentation before production, not after

For Aayush, one of the biggest lessons from working with agent teams is that eval work needs to start while teams are still experimenting. Waiting until production is too late. “When you’re in experiment,” Aayush says, “that is the time to invest in instrumentation and setting up the right evals. It’s not something to wait for when you’re in production.”

The reason is simple: the experimental phase is when teams learn what their agent actually does. That is when they discover edge cases, clarify success criteria, refine datasets, and pressure-test evaluator definitions.

Those learnings compound later. By the time a team is moving from a small launch to a broader rollout, the quality of its eval foundation determines how quickly it can learn from production traffic. Aayush continues: “The learnings that you can gain in experimental phase are so important when you move in production… that will help you move from 1% launch to 100% launch.”

At Uber, that meant helping teams iterate on the basics early: datasets, evaluator definitions, trace review workflows, and the insights teams needed on day one. The goal was to make evals part of how agents were built from the beginning.

The process change: evals moved beyond engineering

Uber’s previous eval platform was highly engineering focused. That created a collaboration problem. Engineering teams could work with evals, but product managers, operations teams, and designers often felt outside the process.

They were close to the user experience and often understood the product intent deeply, but the tooling did not make it easy for them to inspect, update, or participate in the eval lifecycle. That mattered because agent quality is not just a model problem, but a product problem too. A good evaluator needs to encode what “good” means for the user, the business, and the context of the interaction.

PMs and designers often have crucial judgment about the difference between a technically valid answer and a useful customer experience.

That changed who could participate. Instead of evals living only in engineering workflows, cross-functional teams could inspect traces, understand evaluator behavior, and contribute to improving the system. PMs and designers could see what agents were doing, understand where evals were missing important behavior, and help update the criteria used to judge quality.

Arize’s role: make traces and evals usable by the whole agent team

Arize AX gave Uber a shared place across teams to inspect agent behavior and reason about eval quality.

The value was that multiple teams across engineering, PM, and design, could connect those outputs to the underlying traces and ask whether the evals were actually measuring the right thing.

That distinction is important. An eval score can create false confidence if teams do not inspect the examples underneath it. But when teams can review trace after trace, they can see whether the evaluator is aligned with the behavior they care about. That workflow helped teams identify when an eval was too shallow, when a dataset was missing real-world examples, or when an agent was passing the test while still producing poor customer outcomes. Aayush also called out the importance of meeting technical teams where they work.

Arize skills helped teams interact with eval workflows from the integrated development environment (IDE) using natural language, reducing the need for every user to understand every underlying eval concept before they could participate.

“The skills that Arize built really help teams live right in their IDE and have an experience where they could just write natural language and understand the entire lifecycle… without having to understand any of the eval concepts,” he says. The result was a more accessible eval workflow: technical enough for engineering teams, but understandable enough for product and design teams to help shape the quality bar.

The lesson: eval tooling only works when teams lean in

Aayush is clear that tooling alone does not make agents reliable. A platform can expose traces, make evals easier to inspect, and give teams workflows for updating datasets and evaluator definitions.

But teams still have to do the work. They have to instrument their agents, review traces, and update evals when real-world behavior reveals gaps. Moreover, they have to use those insights to improve the next version of the agent.

“Eval tooling is only as good as the work that the teams put in to actually make it work,” Aayush says. That’s why he sees evals as an operating discipline, not a one-time setup step. Teams that treated evals like a rubber stamp learned that passing scores did not guarantee good customer experiences. Teams that invested in evals as seriously as they invested in the agents themselves were able to build better feedback loops.

He explains: “What I’ve seen teams do is come back, realize that this is an investment worth making, and put in the work to spend as much time with their evals as they spend with their agents.”

For Uber, that foundation matters because AI agents are becoming more complex. Long-running coding agents, multi-step workflows, voice agents, and autonomous systems all create traces that are more complicated than a single prompt and response. As the shape of agents changes, the shape of observability has to change with it.

What comes next: evals as the engine for agent iteration

Over the past year, Aayush says Uber has focused on building the foundation for safe, reliable, scalable agents with evals as a default. The next step is more ambitious: making evals the engine that drives agent development. That means evals are not just used to check whether an agent is ready to launch. They become part of the loop that determines how quickly the team learns, how confidently it can expand rollout, and how effectively it can incorporate feedback from real users.

“Where we’re going next is making eval the engine,” Aayush says. “Evals are going to be the thing that drives agent building and the next iterations of the agent loop.” In that world, the question is no longer just, “What agent did you ship?” It becomes: how fast can the team learn from what customers are telling them, update the system, and safely expand the agent’s role?

For Uber, that is the promise of a stronger eval culture: not a dashboard that says the agent passed, but a system that helps teams understand, improve, and scale agent behavior in production.