← All speakers

Bio, Work & Ideas

Aparna Dhinakaran

Conference affiliation: CPO · Arize · 2026

On this page

Aparna Dhinakaran is the cofounder and chief product officer of Arize AI, where she builds tools that reveal how artificial-intelligence systems behave in production and why they fail. Her work spans AI observability, application-specific evaluation, and software agents that learn from their mistakes.

From production machine learning to Arize

Dhinakaran studied electrical engineering and computer science at the University of California, Berkeley, conducted research with Berkeley AI Research, and later entered Cornell University’s computer-vision doctoral program before taking a leave of absence. She worked at Apple and TubeMogul, then helped build machine-learning infrastructure at Uber, including its Michelangelo platform.

She subsequently led Monitor ML, a Y Combinator-backed machine-learning monitoring startup. When Arize acquired its team in 2020, she became the company’s cofounder and chief product officer. In her writing on opaque automated decisions, she connected model transparency to accountability in lending, insurance, hiring, and fraud detection.

As predictive models gave way to language models and agents, Arize expanded into tracing, evaluation, and experimentation. Its organization-owned open-source project Arize Phoenix helps developers inspect application behavior, assemble evaluation datasets, and test improvements. Dhinakaran and chief executive Jason Lopatecki announced the company’s $70 million Series C in 2025.

How she approaches reliable AI

  • Evaluate the application, not the leaderboard. A highly ranked model can still route a shopping question to the wrong function or pass incorrect arguments to the right tool. Dhinakaran evaluates routing, retrieval, tool selection, and parameter extraction separately, using production traces to create datasets and experiments.
  • Make evaluations explain their judgments. Binary labels and numerical scores rarely tell engineers what to fix; her experiments also found that substantially different document-error rates could receive similarly extreme grades. Explanations distinguish misunderstood intent, irrelevant retrieval, incorrect tool arguments, and other actionable failure modes.
  • Inspect the entire agent trajectory. Reliable agents must select appropriate tools, execute them in a sensible order, retain conversational context, and finish without unnecessary loops. Her agent-evaluation framework also addresses voice-specific challenges, including transcription accuracy, speech quality, and conversational continuity. She argues that evaluation prompts require their own improvement loop because faulty judges can misclassify successful interactions.
  • Use prompt learning to preserve useful feedback. Working with Claude Code and Cline, Dhinakaran’s team combined software-engineering tasks, unit tests, and explanatory model judgments to generate persistent CLAUDE.md instructions or Cline rules. This prompt-learning approach improves agent behavior without changing model weights.
  • Deploy adaptive agent judges. Fixed rubrics struggle when agents generate interfaces dynamically, pursue long-horizon tasks, or repeatedly revisit tools. Arize’s Signal investigates production traces for inefficient trajectories and unexpected failure patterns, complementing deterministic tests and conventional model-based judges. Her work on self-improving agent systems links investigation, experimentation, evaluation, and repair.

These ideas depend on dependable infrastructure: her OpenTelemetry analysis examines immutable spans, delayed evaluation results, dropped attributes, and streamed responses. She has also credited Phoenix’s open-source lead and small engineering team, emphasizing that exceptional engineers build systems whose impact compounds.

Read the topics behind these talks

5 conference talks

Key ideas

Scroll to read ↓

Agent evaluation starts with individual tool calls, expands to trajectories and conversations, and closes the loop by checking whether the evaluators themselves are right.

  • When a spreadsheet cannot tell you what improved
    0:34 ↗
  • Separate tool selection from argument correctness
    3:13 ↗
  • Start with the paths that need attention
    4:15 ↗
  • Follow a failed answer down to its arguments
    7:05 ↗
  • Correct calls can still form a bad trajectory
    8:40 ↗
  • Carry context across the conversation
    10:25 ↗
  • Improve the evaluator alongside the agent
    11:40 ↗

Key ideas

Scroll to read ↓

A production agent needs checks for routing, tool arguments, skill execution, and the path to completion; voice adds audio quality and conversation behavior to that list.

  • What does it mean for a voice travel agent to work?
    0:44 ↗
  • Separate routing, execution, and memory
    2:51 ↗
  • Follow a latency question through the trace
    5:43 ↗
  • Check the selected skill and its arguments
    7:42 ↗
  • Evaluate the work inside a skill
    9:30 ↗
  • Measure whether execution converges
    10:09 ↗
  • Evaluate the audio the user experiences
    11:24 ↗
  • Use distributed evaluations to locate failures
    13:14 ↗

Key ideas

Scroll to read ↓

Evaluate the decisions inside an LLM application, turn explained failures into regression cases, and test whether judge scores and model benchmarks measure the behavior you need.

  • Is the model good, or is the application working?
    0:17 ↗
  • Evaluate the route before the response
    2:15 ↗
  • A promotions request takes the wrong branch
    5:50 ↗
  • Turn a trace failure into an experiment
    7:46 ↗
  • Carry evaluation through the application lifecycle
    9:25 ↗
  • A numerical score may hide the difference you need
    11:22 ↗
  • Retrieval depends on context length and placement
    13:41 ↗
  • Finding the fact is only the first task
    16:08 ↗

Key ideas

Scroll to read ↓

As agents gain tools, memory and longer trajectories, evaluation must examine how they work—not just whether their final answers satisfy a rubric.

  • What do production evaluations actually catch?
    0:35 ↗
  • The evaluation target changed
    2:00 ↗
  • Alyx: more capability, new failure modes
    2:47 ↗
  • Three complementary evaluation methods
    3:54 ↗
  • Signal: from traces to proposed fixes
    4:35 ↗

Key ideas

Scroll to read ↓

Coding agents can retain lessons from failed attempts in their instructions. Aparna Dhinakaran traces a loop from patches and tests to diagnostic feedback and revised rules.

  • What goes into a successful coding agent?
    0:35 ↗
  • A grade tells you less than an explanation
    2:14 ↗
  • Start with the model and instructions already in place
    3:55 ↗
  • Turn test outcomes into diagnoses
    5:29 ↗
  • Convert diagnoses into persistent rules
    7:36 ↗
  • Rerun the agents with learned instructions
    8:29 ↗
  • The quality of the explanation determines what can be learned
    9:00 ↗

References