← All speakers
  • Ship Real Agents: companion slides ↗

    Slides explicitly identified as the companion material for Voss’s workshop, including setup instructions, a learner-notebook link, evaluator examples, and experiments.

    slides.com · Source ↗
  • LLM Evaluation Basics ↗

    Arize University course explicitly led by Voss, covering tracing, deterministic checks, LLM judges, clear criteria, and incremental evaluation.

    courses.arize.com · Source ↗
  • Arize AX | How to Observe, Evaluate, and Improve AI Agents ↗

    Hands-on course series attributed to Voss, using a financial-analysis agent to teach tracing, evaluation, calibration, experiments, monitoring, and feedback loops.

    courses.arize.com · Source ↗
  • stuff-everybody-knows ↗

    Repository under Voss’s verified GitHub account, described as a guide to the rest of a web-development career. Retained profile evidence establishes account ownership, but not sole authorship or the biography’s teaching start date.

    github.com · Source ↗
  • domain-name-generator ↗

    Repository under Voss’s verified account for a web application combining random word generation with the Namecheap API to find domain names; sole authorship is not established.

    github.com · Source ↗
  • zeitgeist ↗

    Repository under Voss’s verified account, described as a small application that summarizes a social-media feed; sole authorship is not established.

    github.com · Source ↗

Bio, Work & Ideas

Laurie Voss

Conference affiliation: Arize · 2026

On this page

Laurie Voss is the co-founder of npm, Inc. and the head of developer relations at Arize AI. After helping build infrastructure for the JavaScript ecosystem, he now concentrates on making AI agents observable, testable, and reliable.

From web development to AI infrastructure

Voss identifies himself as a web developer on his GitHub profile and as an npm, Inc. co-founder on his personal site. In his evaluation workshop, he describes his transition from speaking about JavaScript to thinking about how to test AI systems and make them work.

His verified GitHub account includes Stuff Everybody Knows Except You, described as a guide to the rest of a web-development career. His personal site discusses exploring AI, ML, and LLM opportunities after leaving Netlify. His retained conference recording credits also identify a LlamaIndex affiliation before his Arize presentations. At Arize AI, his evaluation teaching focuses on tracing, deterministic checks, LLM judges, calibration, and measured improvements to agents.

How Voss thinks about dependable AI

  • Agents should solve concrete software problems. His hands-on evaluation workshop uses a financial-analysis agent that researches companies and writes reports. He distinguishes a report that merely summarizes financial information from one that supports an investment decision through forward-looking analysis and an actionable recommendation. Tests should enforce the required outcome and meaningful constraints without prescribing incidental tool sequences, since an agent may find a faster valid route.
  • Answers need the right evidence. The workshop separates research from report writing so that an evaluator can compare the final answer with the research supplied. Voss prioritizes fixing stale knowledge, wrong sources, and missing evidence: prompt engineering cannot recover facts the system never receives.
  • Agent evaluation starts with understanding failure. Voss combines execution traces, inexpensive deterministic checks, human-labeled examples, and LLM-as-a-judge rubrics. His hands-on evaluation workshop demonstrates why a superficially plausible financial report can still concern the wrong company, omit an investment recommendation, or be delivered incorrectly.
  • Evaluators need their own safeguards. Generic correctness checks can fail when a judging model lacks current information; a faithfulness evaluation instead tests whether an answer reflects the research supplied. Voss recommends checking automated judgments against labeled examples, watching for bias, and avoiding tests so prescriptive that they reject better solutions.
  • Capability and regression evaluations serve different purposes. Capability tests define behaviors an agent has yet to master; regression tests preserve behaviors that already work. Voss prioritizes better data before prompt changes, model selection, or parameter tuning, and regards fully automated optimization as promising but immature.

Voss also treats developer relations as engineering and product work, emphasizing documentation, useful open-source software, education, and actionable product feedback. His writing examines how AI-assisted development can weaken the junior-engineer apprenticeship pipeline and how autonomous agents complicate legal accountability for security breaches.

Read the topics behind these talks

3 conference talks

Key ideas

Scroll to read ↓

Build agents around messy inputs, selective retrieval, and explicit control flow, then combine chaining, routing, parallel work, and feedback to handle more demanding tasks.

  • Getting from documents to an application
    0:16 ↗
  • Use agent flexibility where the inputs are messy
    2:55 ↗
  • Retrieve the context the model needs
    5:36 ↗
  • Give retrieval a control loop
    7:12 ↗
  • Start with a chain, then add routing
    8:47 ↗
  • Run independent work in parallel
    10:21 ↗
  • Let an orchestrator determine the subtasks
    12:24 ↗
  • Evaluate against the original goal, then revise
    13:08 ↗
  • Compose workflows and hand control between agents
    13:56 ↗

Key ideas

Scroll to read ↓

A financial-analysis agent becomes a practical test bed for tracing failures, calibrating LLM judges and measuring whether prompt changes actually improve the application.

  • Your agent runs. How do you know it works?
    0:40 ↗
  • Tests need evidence of what happened
    5:50 ↗
  • Use code, models and humans for different jobs
    10:27 ↗
  • Catch cascading failures without prescribing every step
    15:04 ↗
  • Make a failing score actionable
    18:43 ↗
  • Instrument the notebook and connect the agent turns
    22:04 ↗
  • Build a varied set of traces before writing checks
    33:24 ↗
  • The research worked; the report went to the wrong destination
    42:52 ↗
  • Start with a deterministic ticker check
    48:45 ↗
  • Correctness and faithfulness answer different questions
    55:24 ↗
  • Define what makes a financial report actionable
    1:04:35 ↗
  • Version the judge and keep its dimensions separate
    1:15:16 ↗
  • Calibrate against explicit human judgments
    1:17:27 ↗
  • Measure which mistakes the judge makes
    1:22:17 ↗
  • Audit preferences and failures that do not seem fair
    1:28:23 ↗
  • Turn failures into a controlled improvement loop
    1:32:03 ↗
  • A release decision needs uncertainty, not just a pass rate
    1:40:29 ↗
  • Improve the data before tuning the model
    1:42:06 ↗
  • Evaluate production cost and repeated success
    1:46:01 ↗
  • Start small, then decide where evaluations run
    1:50:16 ↗
  • Choose the scope and cost of an evaluation
    1:54:12 ↗
  • Stabilize each layer and widen validation before shipping
    1:59:47 ↗

Key ideas

Scroll to read ↓

Laurie Voss reruns IFScale and finds a roughly tenfold increase in simultaneous keyword constraints over a year. Longer skills become plausible, while four different failure patterns explain why outputs still need checking.

  • IFScale measures exact-word inclusion in a business report. Its results demonstrate constraint tracking, rather than reliable reasoning over equally large real skills files.
    3:11 ↗
  • The original ceiling near two hundred to three hundred requirements moved into the thousands in the newer tested versions. GPT-5.5 reached ninety-nine percent accuracy at five thousand rules.
    5:42 ↗
  • Omissions, API refusals, exhausted reasoning budgets and late abandonment require different detection. Fluent prose can still be an incomplete deliverable.
    9:12 ↗
  • Reconsider fragmentation imposed by an old capacity limit, while measuring cost, latency and compliance. Wording and order can still change whether the instructions are followed.
    14:15 ↗

References