AI Engineer · Published 2026-09-26

How We Built an Agent That Improves Itself — Zubin Aysola, Weights & Biases

privateReview: unreviewedConfidence: high
agentsObservabilityevaluationflywheeltracingagent-harnessllm-evaluationhill-climbingproduction-feedback-looptrain-serve-skewexecution-engine
Open on YouTube ↗

Summary

Overview

  • Speaker: Zubin Aysola
  • Channel: AI Engineer
  • Main topic: Building and evaluating self-improving AI software agents using W&B Weave and CoreWeave ARIA.
  • Purpose: Explain the methodology of evaluating, tracing, and self-improving AI software agents by treating research and production code as identical. Zubin Aysola from Weights & Biases presents a deep dive into how they evaluate and build ARIA, their self-improving AI research and iteration agent. The talk covers the covariation between benchmarks, evaluations, and agent configuration, introducing W&B Weave as an observability and evaluation framework that enables a closed-loop flywheel where every production error or success becomes a test case and fix.

Topic Map

Introduction to Agent Harnesses and Evaluation

  • Explanation: Zubin introduces himself, his work at Weights & Biases on the ARIA agent, and the challenges of agentic harnesses across different benchmarks.
  • Key claims:
    • Benchmarks, evaluations, and agents are covariant; changing one affects all others.
    • Packaging agents with different tool calls and frameworks leads to varied benchmark performance.
  • Examples:
    • Terminal-Bench 2.0 scores comparing different agent harnesses across base models.
  • Terminology:
    • Agent Harness
    • Terminal-Bench 2.0
    • Covariance
  • Why it matters: Understanding how packaging and tooling affect agent performance is critical for reliable agent deployment.

Introducing W&B Weave and CoreWeave ARIA

  • Explanation: Overview of W&B Weave as an observability platform for agents and ARIA as a self-improving AI research agent.
  • Key claims:
    • Weave provides observability for both production and offline tracing.
    • ARIA uses offline hill-climbing to self-improve by running evaluations against codebases.
  • Examples:
    • Live demo showing ARIA analyzing production traces, writing evaluation tasks, and hill-climbing.
  • Terminology:
    • W&B Weave
    • ARIA
    • Observability platform
    • Hill-climbing
  • Why it matters: Unified observability bridges the gap between production logs and offline development sandboxes.

The Flywheel: Research and Production Are the Same Code

  • Explanation: Details on how the codebase between production and research remains identical through automated sync jobs.
  • Key claims:
    • Research and production code should be identical to prevent drift during iterative improvements.
    • A four-hour sync job keeps research and production environments aligned.
  • Examples:
    • wandb/core repository synced with WandBAgentFactory via scheduled jobs.
  • Terminology:
    • WandBAgentFactory
    • Sync job
    • Code drift
  • Why it matters: Eliminates code drift between what runs in production and what is tested offline.

The Execution Engine: Six Phases per Record

  • Explanation: Breaking down the evaluation architecture into distinct phases: Hydrate, Setup, Rehydrate, Run, Score, and Teardown.
  • Key claims:
  • Examples:
    • Execution pipeline showing run lane and setup lane running independently.
  • Terminology:
    • Hydrate
    • Setup
    • Rehydrate
    • Run
    • Score
    • Teardown
  • Why it matters: Structured execution phases enable reliable, parallelized evaluation of agent trajectories.

Key Points

Benchmarks and Agents Are Covariant

  • Explanation: Any change to the evaluation dataset, harness, or reward model impacts all other parts of the agent system.
  • Evidence: Observed differences in Terminal-Bench 2.0 scores across different harness configurations.
  • Practical implication: Engineers must measure agent performance in both production and offline simulation environments simultaneously.

Research and Production Code Unification

  • Explanation: Using identical codebases for production agents and offline research environments prevents drift.
  • Evidence:
  • Practical implication: Ensures that improvements discovered during offline research directly translate to production capabilities.

Every Production Miss Becomes a Test and a Fix

  • Explanation: Production errors are captured as traces, turned into evaluation tasks, and fed back into the agent iteration loop.
  • Evidence: ARIA live demo logging a production error trace and creating a new hill-climbing evaluation task.
  • Practical implication: Creates a continuous self-improvement flywheel without relying solely on manual prompt engineering.

Frameworks, Models & Processes

W&B Agent Flywheel

  • How it works: Production traces are logged via Weave, analyzed for failures, converted into evaluation tasks, benchmarked against candidate agent variants, and deployed via PR.
  • Components:
    • Production miss
    • Diagnose and propose
    • Iterate the candidate
    • Benchmark vs baseline
    • PR into wandb/core
  • When to use: When developing and scaling autonomous software engineering agents in production.

Agent Execution Engine Phases

  • How it works: Executes evaluation records through six discrete phases separated into independent lanes for running and setup.
  • Components:
    • Hydrate
    • Setup
    • Rehydrate
    • Run
    • Score
    • Teardown
  • When to use: When building robust simulation and offline evaluation harnesses for LLM agents.

Examples & Case Studies

ARIA encountered an attribute error in production due to an uncalled logging method.

  • Illustrates: How production errors are automatically captured and turned into evaluation tasks.
  • Lesson: Production failures provide the highest-fidelity test cases for agent self-improvement.

Zubin triggered ARIA live to take a production trace, log it into offline evaluations, and run candidate agent variants.

  • Illustrates: End-to-end closed-loop agent iteration using W&B Weave.
  • Lesson: Agents can autonomously diagnose their own SDK bugs and propose code fixes.

Actionable Takeaways

  • Immediate:
    • Use W&B Weave for unified agent observability across production and offline environments.
    • Structure evaluation pipelines into clear phases (Hydrate, Setup, Rehydrate, Run, Score, Teardown).
  • Strategic:
    • Treat research code and production code as the exact same codebase to eliminate drift.
    • Build a flywheel where every production failure becomes a benchmark test case.
  • Questions to investigate:
    • How do different tool-use call configurations impact agent success rates across diverse tasks?
    • What are the best practices for scaling parallel evaluation sandboxes cost-effectively?

Claims Worth Verifying

  • Benchmarks, evaluations, and agents are covariant. (theoretical)
  • W&B Weave provides complete observability for both production and offline tracing of agents. (technical)

Notable Quotes

"Benchmarks, evaluations, and the agents and how you configure them are all covariant." "Every production miss becomes a test — then a fix."

Compressed Summary

  • Agents, benchmarks, and evaluations are covariant systems.
  • W&B Weave provides end-to-end observability for production and offline agent traces.
  • Research and production code share an identical codebase synced every four hours.
  • The evaluation engine operates across six phases: hydrate, setup, rehydrate, run, score, and teardown.
  • Production failures become automated evaluation tasks in a continuous self-improvement flywheel.
  • Keywords: agents, observability, evaluation, flywheel, tracing
  • Core insight: Synchronizing research and production codebases while feeding production failures back into automated evaluation loops creates a powerful self-improving agent flywheel.

Core insights

6
Mental Modelmedium noveltymoderate evidence

Agent capability is not a property of the model alone: benchmark, evaluation set, agent configuration, and harness (tool calls, packaging, framework) form a coupled system, so scores only mean something relative to a specific harness configuration. Terminal-Bench 2.0 scores are compared across different harnesses on the same base models.

Why it matters

Model-selection decisions made on leaderboard numbers can be invalid for your own harness; you must re-measure whenever you change packaging or tool wiring, and you cannot port a benchmark result across harnesses.

Generalization

Any platform that reports a single 'agent performance' number while varying the scaffolding around a fixed model is reporting a confounded metric; harness configuration should be versioned and reported alongside scores.

Benchmarks, evaluations, and the agents and how you configure them are all covariant.
Open source video
Terminal-Bench 2.0 scores comparing different agent harnesses across base models.
Open source video
Packaging agents with different tool calls and frameworks leads to varied benchmark performance.
Open source video
Architecturehigh noveltystrong evidence

The offline research environment runs the exact same codebase as production, kept aligned by a scheduled four-hour sync job between wandb/core and WandBAgentFactory, rather than a forked sandbox or notebook reproduction.

Why it matters

This is the agent-era analogue of eliminating train/serve skew: improvements found offline are guaranteed representable in production, removing the reimplementation step where gains typically evaporate.

Generalization

Any system that iterates on a deployed agent should make the evaluation target a deployable artifact of the same repository, with an explicit sync contract, instead of a parallel evaluation copy.

Research and production code should be identical to prevent drift during iterative improvements.
Open source video
A four-hour sync job keeps research and production environments aligned.
Open source video
wandb/core repository synced with WandBAgentFactory via scheduled jobs.
Open source video
Mechanismhigh noveltystrong evidence

The self-improvement loop terminates at a code change (a PR into wandb/core) after the candidate variant is benchmarked against a baseline — the agent diagnoses and proposes, but the merge is the deployment gate. The loop is: production miss -> diagnose and propose -> iterate candidate -> benchmark vs baseline -> PR.

Why it matters

This places a reviewable, revertible artifact at the boundary of autonomous self-modification, which is the practical answer to letting an agent edit the code that runs it.

Generalization

Self-improving systems should be designed so the agent's output is a diff that must beat a measured baseline, not an in-place mutation of the running policy.

Production traces are logged via Weave, analyzed for failures, converted into evaluation tasks, benchmarked against candidate agent variants, and deployed via PR.
Open source video
Every production miss becomes a test — then a fix.
Open source video
Mechanismmedium noveltymoderate evidence

Evaluation records execute through six discrete phases (Hydrate, Setup, Rehydrate, Run, Score, Teardown) split into two independently running lanes for run and setup, rather than as a single monolithic run step.

Why it matters

Separating record hydration from environment rehydration and letting setup/run lanes advance independently is what allows parallelized, partially overlapping sandbox execution and presumably resumption; it defines where per-record state, environment state, and scoring responsibility live.

Generalization

Evaluation harnesses for agents benefit from the same decomposition as durable/distributed job runners: separate record materialization, environment provisioning, reattachment, execution, scoring, and teardown so each can be retried, parallelized, or overlapped.

Executes evaluation records through six discrete phases separated into independent lanes for running and setup.
Open source video
Execution pipeline showing run lane and setup lane running independently.
Open source video
Hydrate
Open source video
Rehydrate
Open source video
Empirical Resultmedium noveltymoderate evidence

The agent's highest-fidelity test cases are its own production failures: ARIA hit an attribute error in production from an uncalled logging method, and that trace was turned into an offline evaluation task and a candidate fix.

Why it matters

It demonstrates a working feedback path where the agent debugs its own SDK/instrumentation — the agent and the observability layer it runs on are in the same improvement loop.

Generalization

Production error traces are a cheaper and more representative eval-corpus source than hand-authored tasks, but only for the failure distribution actually observed in production.

ARIA encountered an attribute error in production due to an uncalled logging method.
Open source video
Production failures provide the highest-fidelity test cases for agent self-improvement.
Open source video
Agents can autonomously diagnose their own SDK bugs and propose code fixes.
Open source video
Practicemedium noveltymoderate evidence

The same tracing substrate serves both production observability and offline evaluation, so a production trace can be consumed directly as an evaluation input without a translation layer, and ARIA improves by offline hill-climbing over evaluations.

Why it matters

Collapsing observability and evaluation into one schema removes the export/reformat pipeline that normally separates APM-style traces from eval datasets, and it constrains the search to a greedy local one (hill-climbing) rather than anything global.

Generalization

Design trace schemas so they are directly executable as eval records; then production traffic is a continuously growing evaluation set for free.

Weave provides observability for both production and offline tracing.
Open source video
ARIA uses offline hill-climbing to self-improve by running evaluations against codebases.
Open source video

Deep dives

5

Variance decomposition of agent benchmark scores: harness vs base model

Research question

What fraction of variance in agent benchmark scores is attributable to harness configuration (tool calls, packaging, framework) versus base-model choice, and can a reporting protocol make scores portable across harness configurations?

Why

If harness configuration dominates or interacts heavily with model choice, model-selection decisions made from single reported scores are invalid for your own harness, and every packaging change invalidates previously collected evaluation results.

Benchmarks, evaluations, and the agents and how you configure them are all covariant.
Open source video
Packaging agents with different tool calls and frameworks leads to varied benchmark performance.
Open source video
Terminal-Bench 2.0 scores comparing different agent harnesses across base models.
Open source video
Source video

Baseline integrity under repeated hill-climbing

Research question

Does repeatedly hill-climbing candidate agent variants against a fixed baseline benchmark produce measurable benchmark overfitting, and what baseline freezing or refresh policy keeps the flywheel's deployment gate honest?

Why

The self-improvement loop's safety and credibility depend entirely on the baseline comparison holding; if the candidate co-evolves with the baseline, the deployment gate stops discriminating real improvements from benchmark fitting.

Production traces are logged via Weave, analyzed for failures, converted into evaluation tasks, benchmarked against candidate agent variants, and deployed via PR.
Open source video
Every production miss becomes a test — then a fix.
Open source video
ARIA uses offline hill-climbing to self-improve by running evaluations against codebases.
Open source video
Source video

Generalization of production-mined eval tasks beyond the observed failure distribution

Research question

Do gains from eval-driven hill-climbing over production-mined failure traces transfer to failure modes absent from the production traces the tasks were mined from, or do they overfit the current failure distribution?

Why

If production traces are the eval corpus, the improvement loop can only see failure modes that already occurred, so held-out measurement is required to know whether the loop improves the agent or merely fits its recent incidents.

ARIA uses offline hill-climbing to self-improve by running evaluations against codebases.
Open source video
Production failures provide the highest-fidelity test cases for agent self-improvement.
Open source video
Production traces are logged via Weave, analyzed for failures, converted into evaluation tasks, benchmarked against candidate agent variants, and deployed via PR.
Open source video
Source video

Two-lane execution engines for agent evaluation: setup/run overlap, retries, and resumption

Research question

Does splitting evaluation records into Hydrate, Setup, Rehydrate, Run, Score, Teardown with independently advancing run and setup lanes reduce wall-clock and dollar cost while preserving retryability and resumption, and where should per-record versus environment state live?

Why

The decomposition defines where state, environment provisioning, and scoring responsibility live; getting it wrong makes parallel sandbox execution expensive, non-resumable, or incorrectly scored.

Executes evaluation records through six discrete phases separated into independent lanes for running and setup.
Open source video
Execution pipeline showing run lane and setup lane running independently.
Open source video
The execution architecture into distinct phases: Hydrate, Setup, Rehydrate, Run, Score, and Teardown.
Open source video
Source video

Sync-window divergence between research and production codebases

Research question

What divergence accumulates between research and production environments within a four-hour sync window, and does it produce false evaluation signals that mislead the improvement loop?

Why

Unifying the codebase removes the reimplementation gap but bounds alignment to the sync interval; if evaluations run on a stale or divergent revision, offline gains may not represent production behavior.

A four-hour sync job keeps research and production environments aligned.
Open source video
wandb/core repository synced with WandBAgentFactory via scheduled jobs.
Open source video
Research and production code should be identical to prevent drift during iterative improvements.
Open source video
Source video

Article ideas

4

Your Agent Benchmark Number Is a Harness Number

Reported agent benchmark scores are configuration-dependent measurements, so comparing models across different harnesses is not a model comparison; harness configuration must be versioned and reported as part of the score or the comparison is confounded.

Angle

Treat agent scores like instrument readings with a calibration record, and show what breaks when the calibration is omitted—including invalidated evaluation results after any packaging or tool-wiring change.

Source video

Self-Improving Agents Should Ship Pull Requests, Not Policy Updates

The practical answer to letting an agent edit the code that runs it is to require its output to be a reviewable, revertible diff that must beat a measured baseline, not an in-place mutation of the running policy.

Angle

Frame code review plus baseline comparison as the safety boundary of autonomous self-modification, reusing existing CI gating rather than inventing a new approval mechanism.

Source video

Train/Serve Skew Never Left: Repo Unification as the Agent-Era Fix

Agent iteration exhibits the same skew failure mode as ML serving, and the mitigation is to make the evaluation target a deployable artifact of the same repository with an explicit sync contract rather than a parallel evaluation copy.

Angle

Map the four-hour sync job between wandb/core and WandBAgentFactory onto the classic train/serve skew argument, and examine the new cost: research velocity becomes coupled to production code structure.

Source video

Production Traces Are the Eval Set—If You Design the Schema That Way

Collapsing observability and evaluation into one trace schema removes the export-and-reformat pipeline and makes production traffic a continuously growing evaluation set, but constrains improvement to a greedy search over the observed failure distribution.

Angle

Show the engineering consequence of making trace schemas directly executable as eval records, and name the bias that follows from mining test cases only from incidents that already happened.

Source video

Project ideas

4

Harness Variance Ledger

beyond-evals

A factorial sweep of base models by tool-call configurations by packaging frameworks will show that harness configuration explains a non-trivial share of benchmark-score variance, so single reported scores are not portable across harnesses.

Proof of concept

Build a runner that executes the same terminal-style task suite across a grid of base models, tool-call sets, and packaging frameworks, recording each score with a versioned harness configuration hash.

Measurement

Variance decomposition of scores into base-model, harness, and interaction components, plus the rank-order stability of models across harness configurations.

Source video

Baseline Integrity Guard

beyond-evals

Repeated hill-climbing against a fixed baseline will produce measurable benchmark overfitting, detectable as a divergence between gains on the mined task set and gains on a held-out task set.

Proof of concept

Freeze a baseline, run N rounds of candidate improvement against tasks mined from production traces, and evaluate every accepted candidate on a disjoint held-out set collected before the loop begins.

Measurement

Per-round gap between baseline-task gain and held-out-task gain, acceptance rate of candidates, and regression rate on unobserved failure categories.

Source video

Two-Lane Eval Engine Instrumentation

gatehouse

Overlapping setup with run in independently advancing lanes reduces wall-clock and dollar cost per evaluation record without increasing scoring error or reducing resumability.

Proof of concept

Instrument a Hydrate/Setup/Rehydrate/Run/Score/Teardown pipeline to timestamp and cost each phase and each lane, then compare sequential versus overlapped setup/run execution on the same record set.

Measurement

Setup-lane versus run-lane time and cost, wall-clock and dollar cost per record, retry and resumption success rate, and scoring correctness versus a sequential control.

Source video

Sync-Window Divergence Probe

movement-lab

Divergence between research and production codebases within a four-hour sync window is large enough to produce false evaluation signals that mislead candidate selection.

Proof of concept

Run identical evaluation records against the research revision and the production revision at multiple points inside a sync window, and compare scores and failure attributions.

Measurement

Score delta between research and production revisions per record, frequency of divergent verdicts, and whether candidates selected on divergent revisions fail baseline comparison after sync.

Source video

Architectural implications

3

Production traces and offline evaluation records are the same artifact type, handled by one observability system.

Before

Production logging/APM and the offline eval harness are separate systems with an export-and-reformat step between them.

After

One trace schema that both production instrumentation and the evaluation engine consume, so a production trace is directly replayable as an eval record.

Consequence

The trace schema becomes a load-bearing interface; changing it changes both observability and the eval corpus, and any production event is a candidate test case with no manual curation.

Source video

The research environment is the production codebase synced on a schedule, not a fork.

Before

Offline research happens in a sandbox or notebook that diverges from deployed code; promising results are reimplemented before shipping.

After

wandb/core and WandBAgentFactory stay aligned via a four-hour sync job, so experiments run the shipped code path.

Consequence

No reimplementation gap, but research iteration velocity becomes coupled to production code structure and bounded by the sync window.

Source video

The agent's improvement output is a PR into wandb/core gated on beating a baseline, not a live policy update.

Before

Improvements are made as manual prompt/config edits deployed directly into the running agent.

After

Candidate variants are benchmarked against a baseline and land as code changes through review.

Consequence

Autonomous self-modification stays auditable and revertible, and the baseline benchmark becomes a permanent piece of infrastructure that must itself be maintained.

Source video

Tradeoffs and failure modes

4

Identical research and production codebase

Benefit

Eliminates code drift so offline gains translate directly to production.

Cost or risk

Research experimentation is constrained by production code structure, and the four-hour sync job leaves a bounded window in which research and production are known to differ.

A four-hour sync job keeps research and production environments aligned.
Open source video
Source video

Offline hill-climbing as the improvement search

Benefit

Cheap, evaluation-grounded, and does not require gradient access to the model.

Cost or risk

Greedy local search can plateau, and iterating against tests mined from observed production traces risks fitting the agent to its current failure distribution and regressing on unobserved behavior.

ARIA uses offline hill-climbing to self-improve by running evaluations against codebases.
Open source video
Source video

Agent diagnosing and patching its own code

Benefit

Production failures become fixes with no human-authored reproduction step.

Cost or risk

An agent that proposes changes to the code that runs and instruments it can introduce regressions or game the baseline benchmark; safety depends entirely on the baseline comparison and PR review holding.

Agents can autonomously diagnose their own SDK bugs and propose code fixes.
Open source video
Source video

Harness/config covariance

Benefit

Acknowledges that tool-call and packaging choices are first-class performance levers.

Cost or risk

Reported benchmark numbers lose comparability across configurations, so any config change invalidates previously collected evaluation results.

Benchmarks, evaluations, and the agents and how you configure them are all covariant.
Open source video
Source video

Open questions

4

Do gains from eval-driven hill-climbing transfer to failure modes not present in the production traces the eval tasks were mined from?

Why unresolved

The summary reports the loop mechanism and a live demo but no held-out measurement of generalization to unseen failures.

Research direction

Build a held-out eval set disjoint from production-derived tasks and measure gain transfer and regression on unobserved categories.

Source video

What is the magnitude of the harness/config effect relative to base-model choice on benchmarks like Terminal-Bench 2.0?

Why unresolved

The talk shows comparative harness scores across base models but the summary provides no quantified effect size.

Research direction

Run a factorial sweep of base models x tool-call configurations x packaging frameworks and decompose variance.

Source video

What are the best practices for scaling parallel evaluation sandboxes cost-effectively?

Why unresolved

The summary lists it as an open question and gives no cost, concurrency, or isolation data for the run/setup lanes.

Research direction

Instrument the six-phase engine to measure setup-vs-run lane time and cost, and test whether overlapping setup with run reduces wall-clock and dollar cost.

Source video

How is the baseline in 'benchmark vs baseline' maintained and protected as the agent iterates against it?

Why unresolved

The flywheel names the baseline comparison step but the summary never describes how the baseline is versioned, refreshed, or kept from co-evolving with the candidate.

Research direction

Define baseline freezing/refresh policy and measure whether repeated hill-climbing against a fixed baseline produces benchmark overfitting.

Source video

Key claims

7
causalVerification needed

Benchmarks, evaluations, and agent configuration are covariant — changing one changes the others.

Evidence

Benchmarks, evaluations, and the agents and how you configure them are all covariant.

Question

What fraction of variance in terminal-bench-style scores is attributable to harness/tool configuration versus base model?

Source video
causalVerification needed

Research and production code must be identical to prevent drift during iterative improvement.

Evidence

Research and production code should be identical to prevent drift during iterative improvements.

Question

Does codebase unification measurably increase the rate at which offline gains survive to production?

Source video
factualVerification needed

A four-hour sync job is what keeps research and production environments aligned.

Evidence

A four-hour sync job keeps research and production environments aligned.

Question

What is the observed divergence between the two environments within a sync window, and does it produce false evaluation signals?

Source video
factualVerification needed

The flywheel logs production traces via Weave, converts failures into evaluation tasks, benchmarks candidate variants, and deploys via PR.

Evidence

Production traces are logged via Weave, analyzed for failures, converted into evaluation tasks, benchmarked against candidate agent variants, and deployed via PR.

Question

What percentage of proposed candidates actually beat baseline, and what is the end-to-end latency of one flywheel turn?

Source video
opinionVerification needed

The agent's highest-fidelity test cases come from its own production failures.

Evidence

Production failures provide the highest-fidelity test cases for agent self-improvement.

Question

Do production-mined tasks yield higher fix rates or broader coverage than hand-authored or synthetic eval tasks?

Source video
factualVerification needed

ARIA self-improves via offline hill-climbing over evaluations run against codebases.

Evidence

ARIA uses offline hill-climbing to self-improve by running evaluations against codebases.

Question

How many hill-climbing iterations are required per accepted improvement, and where does the search plateau?

Source video
factualVerification needed

Weave provides observability covering both production and offline tracing.

Evidence

Weave provides observability for both production and offline tracing.

Question

Can production traces be replayed directly as evaluation records without lossy transformation?

Source video

Connections

5