The feedback loop is the product

I'm building a complex product that includes AI agents. I needed a way to test it to make sure it worked as expected. As I looked into how AI products are tested, I learned a new term: evals. It's not a term many of you have heard of, but that's going to change pretty soon.

Every business tries to improve and adapt: changing marketing messages, trying new projects, giving employees feedback, adjusting pricing, and so on. But the feedback loops that drive this improvement are messy and slow. It takes time to measure the effect of a price change in the market. Managers' messages to employees are imperfect. We don't capture the right data.

When we built traditional software, we knew how we worked, so testing it was relatively simple. But as any researcher will tell you, we don't really understand how generative AI and LLMs work. So when you use AI in a process or project, you need to feed it inputs, judge its outputs, and adjust.

When you close that loop, you get a self-improving organization.

What's an eval, anyway?

At its simplest, an eval (short for evaluation) tests whether an AI does what it's supposed to do.

Testing traditional software is easy: 2+2 = 4, and if it doesn't something is wrong.

AI isn't like that. Ask the same question twice and you'll get two different answers, both potentially valid (which is rather the point!) Ask an AI to draft an email and there's a nearly infinite number of responses that might be considered "good." Often, the results are what you wanted. Sometimes, they're nonsense. On rare occasions, they're company-ending bad stuff that is dangerous or deeply offensive.

So how do you make sure your AI delivers consistently good results?

Every AI application turns inputs (a prompt, retrieved context, user data, tool access) into outputs (a response, an action, a decision).

An eval checks the outputs against a definition of "good". It's a structured, repeatable set of judgement calls that help you understand (and improve) how an AI behaves.

An eval has three parts:

1. A test dataset: a set of inputs, often paired with reference answers that represent what "good" looks like.
2. The system under test: your full pipeline: prompts, model, retrieval, tools, all of it.
3. A grader: because AI outputs are always different, the thing that decides whether the output passes or fails needs judgement.

This is no different than an employer conducting performance reviews. Except that where those happen quarterly, this is a continuous process closer to an OODA loop than to HR.

The grader is where it gets interesting. We'll come back to that.

Evals are iterative, not one-shot

Evals are a continuous cycle: define what good looks like, feed it some inputs (the prompt, the skills, the data being retrieved, the tools the AI is using), measure your system against it, find where it fails, fix the inputs—and repeat.

Each trip around the cycle is different, which means you need to:

• Track and analyze what happened with each eval.
• Link the prompt you used to the outputs it produced, and the grading they received.
• Keep a copy of each version, and clear records of what changed, so you can reproduce it.

Managing your evals is like managing your code base: version control, pulls and commits, repositories and forks. Evals are your IP. There are a bunch of companies that make software to do this (LangSmith, Braintrust, Promptfoo, and Arize for example.)

Prompt, component, outcome

Evals test a system in three concentric loops, from narrow to broad:

Prompt evals

Does this specific prompt produce good outputs for a set of known inputs? This is the tightest loop. You change a word in your system prompt, run your test cases, and see if the scores move. This is where most people start (and it's necessary) but it only tells you that the prompt works in isolation.

Component evals

Does this combination of AI and tool chain do what I want? A modern AI does more than just respond with text. It uses tools, searches the web, launches a sub-agent, and writes to file folders. A prompt can be perfect and the system can still fail because a file was missing, or the name of an API changed.

Outcome evals

Does the system as a whole produce a desirable result? If the agent was supposed to book a vacation, did it do so? These are the hardest evals to build and the most expensive to run, often involving multiple layers of agents and interactions with human or synthetic operators, but they're the ones that tell you whether your product actually works.

The grader: judging what "good" is?

There are three different ways to decide if an output was correct:

• Code-based grading works when the answer is objective. Did the AI extract the correct date from a user message? Is the output formatted correctly? Did the math math? You write some code that checks, and it either passes or fails. If your AI says 2+2=5, that's bad.
• Human grading works for everything. A person reads the output and scores it. Was the tone right? Was the answer helpful? Was the reasoning sound? Humans are pretty judgy to begin with; the problem is that human grading doesn't scale: it's expensive, it's slow, and it's inconsistent because different humans will disagree with each other. So human grading is only used to spot check and verify the eval process is working.
• AI-as-judge grading lets you scale the evals. You give a second AI (the "grader") a set of criteria that define "good", and it grades the outputs. You can ask the judge-AI subjective questions like, "was the response empathetic?", "did the AI make things up?" or "was it polite?"

AI-as-judge is a real game-changer, because it closes the loop. Once you've built a system that can test itself by generating outputs, judging them automatically, and identifying failures, it becomes self-improving. If the judge AI concludes that the app isn't being polite, it can rewrite the skill. If the tone isn't right, it can tweak the prompt. If the AI keeps failing to get the right information, it can code the API differently.

Parallels with Lean Startup

In the first decade of the new millennium, startups were burning millions building products nobody wanted. The fix was to build the smallest thing, see if it works, and learn from what happens. This was called the Minimum Viable Product (MVP)—a term popularized by Eric Ries' The Lean Startup—and it forever changed how new businesses validate their ideas.

Fifteen years later, companies building AI products are making the same mistake: shipping agents and apps without any systematic way to know whether they work. If you're deploying AI without them, you're making the same mistake startups made before Lean: building things without knowing if they work, and having no way to get better systematically. The pattern is the same:

• Build: write the prompt, set up the pipeline, configure the agent.
• Measure: run your eval suite, get scores across your test cases.
• Learn: analyze the failures, identify patterns, go back to Build to adjust your inputs.

Just as vanity metrics (page views, registered users) misled startups into thinking they had traction, "it looked good when I tested it" tricks you into thinking your system works. Vibes aren't enough. Evals tell you what's actually happening across hundreds of cases, not the three you happened to try, and tracks what worked and what didn't so you can see what changed and how to fix it.

The analogy goes deeper. In Lean, the MVP wasn't "the smallest product." It was the smallest experiment that could test your riskiest assumption. In evals, the riskiest assumption isn't "does the model know things?" (it does). It's "does our system behave correctly in the situations that matter most to our users, customers, and employees?" The eval suite is the MVP: the smallest set of behaviors whose improvement you can automate and measure.

We learned fifteen years ago that build-it-and-ship doesn't work for products. We now know it doesn't work for AI either. Mature AI deployments start by defining what "good" means: Write the test cases. Create the library of test inputs. Set the grading criteria. Then build the simplest thing that can pass them. An AI MVP isn't the smallest model, or the cheapest deployment. It's the smallest set of core behaviors whose improvement you can automate. The eval suite becomes the product spec, the regression test, and the quality bar, all in one artifact.

Your AI processes need product managers now.

You need evals even if you don't build AI products

Evals aren't a technology tool, they're a management tool. Here are three specific examples:

The basis for the self-improving organization

In Lean, your measurement loop required real users and real time. You had to wait for people to show up and behave. In enterprises, you had to wait for quarterly results to come in or new hires to come up to speed. Cycle time was slow.

In evals, you can simulate users, generate test cases, and run hundreds of experiments in the time it takes to make coffee. The improvement loop tightens from days to minutes. Of course, you need to trust your LLM judge, which is weird because that means your judge needs evals. But things bootstrap from there, and once calibrated, the process, product, or organization can improve endlessly.

At Startupfest in 2025, I said that startups are moving from product/market fit to outcome/liability fit. You're not selling functionality, you're promising an outcome, and evals show you if you can deliver it.

Evals are the future of governance

If your AI gives bad medical advice, makes a discriminatory hiring decision, or hallucinates a contract term, the eval suite (or lack of one) becomes evidence. "Did you test for this failure mode?" is going to be a courtroom question, and the eval (or lack thereof) is the audit trail that shows whether or not you tried.

Evals are part of investor due diligence

Any investor doing due diligence in 2026 must look at the eval cycles on which the company's products and services rely. They show whether the company can adapt automatically to changes in the market. And they dictate whether the business can bootstrap itself, improving every time it gets a new model, new tools, or new data.

Evals keep you current and prevent model lock-in

As AI moves out of labs and into enterprises, evals become much more important. Getting them right and incorporating them into your business processes won't just help you move faster than everyone else, it'll let you keep building atop the best AI models.

When Microsoft ships a new version of Windows, your old code still runs. Backwards compatibility is a given. Apple switched chips from Intel to Apple Silicon and the transition is still underway five years later.

AI models don't work like software versions. When Anthropic releases a new Claude, or OpenAI drops a new Codex, or Google announces a new Gemini, there's no guarantee that your products and processes will work the same way. Claude Opus 4.6 might have broken things that worked in 4.5 because it behaved differently.

If you're stuck on an old model one because you have no way of knowing whether your product or process works correctly on the new one, you're not keeping up with the state of the art. Which means even if you don't change your product, you need to evaluate it as new models are released. Every new model release is only a performance boost if you can quickly verify that your business processes still work.

Without evals, every model change is a terrifying, weeks-long manual regression test. With evals, it's an afternoon. Build an eval cycle that automatically adjusts, and you can switch models within days. You can swap out some code and know within hours whether the swap helped. In that way, evals aren't just product testing, they're upgrade readiness and an antidote to lock-in.

(The model providers know this. They're forced to maintain multiple model versions simultaneously, because customers can't migrate, but they're going to end-of-life them soon.)

The bottom line

To reiterate:

• An eval is a structured, repeatable set of judgement calls that help you understand (and improve) how an AI behaves.
• An AI MVP is the smallest set of core behaviors whose improvement you can automate.
• You're not selling functionality, you're promising an outcome, and evals show you if you can deliver it.
• Once you've built a system that can test itself by generating outputs, judging them automatically, and identifying failures, it becomes self-improving.
• As a result, you're competing less on what you do and more on how well you can improve what you do.
• Evals are vital for governance, because they're an audit trail to prove, or defend against, negligence.

We've seen this movie before. This time, the feedback loop is faster. Build it right, and you've created a self-improving app. Ignore it, and you'll be stuck with earlier models and spiralling technical debt.

Sidenote: Strategies for doing this without going broke

Serious evals cost real money. Running an AI agent through a complex scenario over and over again costs tokens, plus more tokens for the AI that's judging the results, and at scale that adds up fast. My system runs 10 AI agents, controlled by 10 fake humans, through an 11-phase system, with a lot of back and forth. It takes around 4 hours to complete. I ran out of tokens on the highest tier of Claude Code and had to wait two days to continue.

The fix isn't to skip evals, it's to be smart about what you test and how.

Decompose your expensive tests. If your end-to-end agent evaluation takes hours and thousands of API calls (as mine does for the thing I'm building), don't run it on every change. Instead, extract the critical decision points—the moments where the agent chose an action, picked a tool, or generated a response—and test those in isolation. Twenty extracted decision points running in two minutes will catch most of the same bugs as a four-hour full simulation.

Tier your testing. Cheap component evals run on every change (just as unit tests do, part of your continuous deployment pipeline). Expensive end-to-end tests run nightly or weekly. Full simulations run before major releases. This is the same pyramid that software engineering figured out decades ago (unit test, then integration test, then end-to-end test), applied to AI. I have a ci/cd skill that takes 20 minutes to run and produces an 11-tab interactive report; I run it every couple of days. But I have 511 unit tests that run every time the software changes.

Turn on logging. I have incredibly verbose records of every simulation, even down to detailed timing measurements. It's essential for troubleshooting. It's how I found two agents were sharing the same folder, and one thought the other was trying to hack it via prompt injection.

Mine your past logs. If you've already run your system in production or simulation, you have a dataset. Every conversation transcript, every agent trace, every user interaction is a potential test case. You don't need to generate scenarios from scratch when you have real ones sitting in your logs.

Use cheaper models where you can. Your product needs the best model. Your simulated users, test harnesses, and grading judges often don't. A smaller, cheaper model playing the human side of a conversation can cut your simulation costs dramatically. If you're checking mechanical stuff like "can the AI read the file?" this is good; it's not so good for apps where the AI is doing a lot of reasoning, because behavior changes across models. I'm testing Claude Sonnet and Opus, alongside Codex and Gemini.

Start with 20 cases, not 200. You don't need a massive test suite on day one. Twenty cases drawn from real failures (the edge cases, the confusing inputs, the things that actually broke) will tell you more than 200 synthetic scenarios that don't reflect reality. Expand from there as you learn where the system is fragile.