Private evals, observability, and the learning loop

Chapter 6 · 09:08–10:32

The central idea in this section is simple: a team can improve an agent more deliberately when it can both measure the result and understand how the result was produced. The speaker presents private evaluations and observability as the two tools that provide those capabilities.

Evals and observability answer different questions

An evaluation, or eval, judges an agent's performance against a standard. It answers:

Did this run meet the level of quality we need?

Observability exposes what happened inside the run. It helps a builder inspect the agent's behavior and the information it used. It answers questions such as:

• What entered the model's context?
• How did that context accumulate during the run?
• Which steps and tools ran?
• What traces, feedback, and decisions were produced?

These tools are complementary. An eval can show that a run failed, but the score alone may not explain the cause. Observability can show the sequence and evidence behind the result, but it does not define what a successful run should look like. A team needs both a standard for judging quality and a view of the path that led to the outcome.

A private eval defines “good” for the organization

Generic model claims or public benchmarks do not necessarily describe success for a particular company. A mission-critical agent has to work on that organization's tasks, with its constraints and expectations. The speaker therefore emphasizes a private eval: a benchmark built around the work the organization actually cares about.

In this context, “private” does not merely mean that the benchmark is hidden. It means that the organization owns the examples and the judgment of quality. The eval makes the local standard explicit: these are the tasks, and this is what the organization considers good enough. The section does not provide a formal scoring formula, so the important point is the ownership of the standard rather than a particular metric.

The speaker attributes a set of organizational principles to an article by Satya. The exact quotation is not available in the supplied source, but the practical message is clear: useful organizational advantage comes from retaining the knowledge created while the system operates. That knowledge includes:

• Memory of information that should help future runs.
• Traces of what agents actually did.
• Feedback about those runs.
• Decisions made while interpreting results and choosing changes.
• Institutional context about how the organization works and what it values.

Together, these items form a kind of institutional memory. They prevent every new experiment from starting with only the model's general capabilities and a blank record of past work.

Click to enlarge

Source visual at 09:44: A slide presents three principles for building organizational advantage around AI investments.

The slide supports the speaker's three-part list and makes its sequence visible. It does not supply formal metric definitions, so it should be read as a summary of the organizational principles, not as a complete evaluation specification.

The learning loop is a controlled hill climb

Once a private eval exists and runs are observable, improvement becomes a repeated loop:

flowchart LR
    A[Run the agent] --> B[Measure with the private eval]
    B --> C[Inspect traces and feedback]
    C --> D[Choose a change]
    D --> E[Run the benchmark again]
    E --> B

The speaker describes this as a continuous learning loop or a hill-climbing machine. The metaphor means that the team repeatedly measures its current position and tests changes that might move performance upward. It is not a promise that every change will help. A change can fail, help one part of the benchmark while hurting another, or reveal that the team needs a better diagnosis. The eval supplies the comparison, and observability supplies clues about what to change next.

The possible improvement target is not limited to the model. The loop can lead to a change in any of the three parts of the agent system:

1. The model can be changed or improved.
2. The context can be changed, including the memory made available to later runs.
3. The harness can be changed so it assembles information or runs the workflow differently.

This is why the loop matters to harness design. A low score does not automatically mean “replace the model.” The traces may instead show that the model received poor context, or that the harness did not support the task well. The team can then test the appropriate intervention and use the private eval to compare it with the previous version.

The practical mental model

Think of the eval as the measuring stick and observability as the record of the experiment:

• Without the measuring stick, the team can inspect many traces but cannot agree on whether a change is better.
• Without the experiment record, the team can see a score change but may not know why it happened.
• With both, the team can preserve what it learned and make the next experiment more informed.

The section's conclusion leads directly to Harbor, which the speaker presents as a concrete benchmark runner for this motivation. The conceptual order comes first: define quality for the organization, retain evidence from runs, and use that evidence to improve the model, context, or harness.