Three Guarantees for an Evolving Agent Harness: An Overview

Why People Wanted It

An agent harness can preserve instructions, skills, and feedback across tasks. That gives later revisions a history to learn from—but also a history to overfit, overwrite, or repeatedly inspect during validation.

The real question was never just whether the next score improved. Did performance generalize beyond the tasks used to construct the harness? Did older capabilities survive? And was the proposed replacement evaluated independently of its construction?

This page is the overview. Each mechanism has its own standalone page, because each has different assumptions and a different conclusion.

The Core Move

Separate sensitivity to training history, accumulated historical regression, and the decision to deploy a candidate.

Write $H$ for the deployed harness and $\ell(H,z)\in[0,1]$ for its loss on task $z$, averaged over execution randomness. Lower loss is better. A task distribution describes which tasks are sampled; its risk is the harness's average loss on those draws:

$$R(H)=\mathbb{E}_{z\sim\mathcal D}[\ell(H,z)].$$

The checks below concern different relationships between this population risk, observed task losses, and revisions over time. They are not interchangeable certificates.

Quiz

Which guarantee requires an explicit assumption about how much each later update may worsen risk on an earlier task distribution?

The replace-one expected generalization bound

The fresh-validation admission bound

The accumulated-retention bound

$ check

Why Generalization Is About the Whole Revision Path

For readers going beyond the basic distinction, the important technical boundary is what gets rerun in a replacement experiment.

Replace one training task with an independent draw, then rerun all downstream updates using coupled randomness: corresponding runs share their auxiliary random choices. Feedback, archives, and selection must be rerun too. Compare the resulting harnesses on the original sampled task.

The resulting average sensitivity controls the magnitude of an expected generalization gap under independent task sampling and replace-one exchangeability. It does not bound the gap in every run, and a small code edit does not establish small sensitivity.

Replace-One Stability and Expected Generalization develops the replacement construction and its bound. The question left open is retention: what if later revisions consistently hurt an earlier task group?

Why Retention Requires a Separate Budget

For readers going beyond the basic distinction, retention adds an assumption about each later transition—not another interpretation of stability.

Let $R_s$ mean risk on the task distribution from round $s$. If every later update may increase that risk by at most its assigned allowance, the total increase is bounded by the sum of those allowances. This follows because consecutive risk differences cancel when added.

These are historical-risk assumptions, not automatically enforced limits. Checking them requires groupwise uncertainty control for the deployed composition, including merged edits and shared routers. An improvement averaged across historical groups does not establish that each group stayed within budget.

Retention Through Accumulated Regression Budgets derives the bound and separates it from original-round generalization. The question left open is admission: how do we test the next candidate without evaluating it on tasks that shaped it?

Why Admission Requires a Fresh Comparison

For readers going beyond the basic distinction, the key admission condition is independence conditional on the prior history.

Fix the candidates, then draw new independent validation tasks from the uniform mixture of historical task distributions. Evaluate each candidate and the current harness on the same tasks. Estimate the candidate's loss increase and add an uncertainty margin accounting for all candidates and rounds. Accept only a negative upper bound.

The pairing defines a direct loss difference on each task. Freshness prevents candidate construction from adapting to the validation draw. Neither keeping a reused set secret nor correcting for the number of comparisons restores that independence.

Fresh Validation for Harness Admission gives the confidence bound and its deployment rule. Its remaining question is scope: improvement on this historical mixture says nothing by itself about arbitrary future workloads or every historical group.

Minimal Causal Code

This schematic PyTorch loop shows only the admission decision, not a trainer or a stability estimator. propose must fix at most K candidates before draw_fresh samples independent tasks from the historical mixture. loss returns a tensor of bounded, execution-averaged task losses. The deployed state changes only after the comparisons.

import math
import torch

def evolve(state, propose, draw_fresh, loss, T, K, m, delta):
    margin = math.sqrt(2 * math.log(K * T / delta) / m)
    for k in range(1, T + 1):
        candidates = list(propose(state, k))
        assert len(candidates) <= K
        tasks = draw_fresh(k, m)
        with torch.no_grad():
            baseline = loss(state, tasks)
            upper_bounds = [
                (loss(candidate, tasks) - baseline).mean().item()
                + margin
                for candidate in candidates
            ]
        if upper_bounds:
            best = min(range(len(candidates)), key=upper_bounds.__getitem__)
            if upper_bounds[best] < 0:
                state = candidates[best]  # visible deployment update
    return state

What You Gain, and What You Lose

You gain a map of three different obligations: control sensitivity to training tasks, bound later damage to earlier groups, and independently assess proposed replacements.

You do not gain an unconditional guarantee. Stability needs the stated task-sampling assumptions. Retention needs separately justified historical-risk budgets. Admission consumes fresh validation data and certifies the historical mixture, not arbitrary future distributions.

The effective sample size counts independent tasks, not repeated executions of the same task. Correlated sessions need grouping or dependence-aware analysis. Without a justified evaluator-to-target discrepancy bound, validation certifies evaluator-defined loss only.

Quiz

A candidate is modified after inspecting its validation tasks. What is required before using the stated admission guarantee for that modified candidate?

A new independent validation sample

More execution rollouts on the same tasks

A larger confidence adjustment on the same inspected sample

$ check