The data flywheel for continuously improving agents

Chapter 9 · 14:41–17:31

Evals tell you whether an agent's result meets your standard. Observability helps you see why the run produced that result. Together, they support a repeatable improvement loop: run the agent, collect and curate traces, experiment, and feed the resulting changes back into the agent.

From one run to a learning system

A useful agent is not finished when it produces its first successful answer. The harder engineering problem is improving it as the team sees more real tasks and more failures.

The speaker presents this as a data flywheel. The cycle is:

1. Build and run an agent. Let it perform real or benchmarked tasks.
2. Collect traces. Keep records of its steps, model interactions, tool calls, and resulting behavior.
3. Curate the traces. Select and organize useful runs for later experiments.
4. Get feedback. Learn which runs were useful or failed, from users or evaluators.
5. Experiment. Try a change against the curated data.
6. Feed the change back. Update the harness, model, or context and run the cycle again.

The point is not that every turn automatically makes the system better. Each cycle gives the team evidence for deciding what to change next.

Click to enlarge

At about 14:59, the presentation slide shows a sequence from running a first agent, through collecting and curating traces, to experimenting on the resulting data. It supports the flywheel's first stages; the talk supplies the broader interpretation that experiments feed future agent changes.

What trace curation adds

A trace is the record of an agent run. It can contain messages exchanged with the model, tools that ran, observations returned by those tools, and context accumulated over time.

Collection alone is not the same as learning. A system may produce many traces, but those traces still need to be useful for an experiment. Curation means selecting or organizing the data that the team wants to inspect or test. A team might, for example, bring together traces associated with a recurring failure or a particular task type.

The source does not specify a complete labeling process for this curation. It does establish curation's role: raw run history becomes data that can support an investigation and a comparison of a proposed change.

This is where observability connects to evaluation. An eval can show that a task received a poor result. A trace can help show whether the cause was a model response, missing context, an unhelpful tool result, or another part of the harness. Curated traces then give the team concrete cases against which to test a fix.

Two ways to obtain feedback

The speaker describes two broad feedback sources.

Feedback from the environment or the user

Some feedback comes from what happens around the agent. A task may pass or fail in its environment. A user may accept an answer, revise it, abandon the interaction, or take another action that indicates whether the result helped.

Useful user feedback does not require an explicit thumbs-up or thumbs-down button. The user experience (UX) can be designed so that people naturally reveal useful signals while they work. A carefully presented result may encourage a user to correct it, choose among alternatives, or continue with the answer. Those actions can become evidence about the quality of the run.

This gives two different patterns:

• Explicit feedback asks the user to rate the result directly.
• Behavioral or implicit feedback learns from what the user does in the product.

The second kind may fit the workflow better, although interpreting behavior requires care. A user changing an answer can indicate a problem, but the action does not by itself explain every reason for the change.

Synthetic feedback from online evaluators

The other source is synthetic feedback. An evaluator examines traces and produces a judgment or signal. The evaluator may be a strong language model, a smaller fine-tuned model, a prompted off-the-shelf model, or code. The appropriate choice depends on what the test needs to check.

An online evaluator operates over traces as they arrive from ongoing use. It is separate from the agent being evaluated. The agent performs the task; the evaluator judges some aspect of the resulting run.

Code may be enough to check a deterministic condition. A unit test may check whether an expected behavior occurred. A language model or another agent may help when the test requires judging a more flexible response. The benchmark or product team defines what the evaluator should measure and how its output becomes feedback.

There is a practical tradeoff. Sending every trace to a strong model may produce more capable judgments, but it can be expensive and slow. Smaller models, prompted models, or code can reduce cost and increase speed when they are adequate for the test. Evaluator quality, latency, and cost therefore become part of the improvement-loop design.

Three places where improvement can happen

The flywheel does not only train or fine-tune the underlying model. The speaker identifies three intervention points in an agent:

Intervention	What changes	Typical question
Harness engineering	The orchestration around the model: the loop, tools, gates, or other execution behavior	Did the system supply context and invoke tools in the right way?
Model fine-tuning	The model's learned behavior	Would a model adapted to these examples respond more effectively?
Context and memory updates	The information made available to later runs	Should the agent remember a fact, decision, or prior result?

These are different fixes for different failure patterns. If the agent repeatedly calls a tool at the wrong point, changing the harness may be the right experiment. If it needs a behavior that is not reliably produced, model fine-tuning may be worth testing. If it lacks information that the organization has already learned, updating memory or other context may help.

The same observed failure can motivate more than one hypothesis. The purpose of the trace and the eval is to make those hypotheses testable instead of treating every bad result as proof that the model must change.

Why automation matters

The speaker describes this end-to-end process as tricky and time-consuming. Someone must inspect traces, identify patterns, decide which examples matter, choose an evaluator, and test possible changes. As the number of runs grows, doing all of this manually becomes a bottleneck.

That difficulty leads into the next section's Engine demonstration. Engine is presented as an attempt to automate parts of the flywheel. The conceptual process remains straightforward—run, inspect, find a pattern, make a change, and test again—but automation can help the team perform it at a useful scale.

The important mental model is not “collect data and the agent improves.” It is:

Use traces and feedback to form a hypothesis, run an experiment, and measure whether a change improves the system.

That hypothesis may concern the harness, the model, or the context. The data flywheel is valuable because it keeps all three possibilities open while connecting them to evidence from actual agent behavior.