Previously shared evaluations for single-agent and multi-agent setups, so how can we prove, based on eval, that the agent’s self-evolution has truly improved?

Agents Can Self-Evolve—What’s Left for Us to Do?

Agents can already modify themselves, but modification doesn’t guarantee improvement. Meta-Harness proposes changes, Eval Harness verifies them, and humans control the goals, standards, and release authority. This article builds a runnable Demo from scratch to complete the “failure → modification → verification → release” loop.

Today’s agents are starting to modify themselves. They can read failure records, adjust prompts, reorder tools, and generate a new version. This sounds a lot like self-evolution.

But if an agent can also see all test questions, adjust the passing grade, and then announce “I’ve improved,” it becomes the one setting the test, taking the test, and grading the test.

Recently, I spoke with a healthcare VC about agents. She mentioned that her team finds manual evaluation too slow and is now building a layer outside the agent to automatically improve based on past failures.

This approach is often called Meta-Harness. The name is a bit convoluted, but the core question is straightforward:

How can an agent improve automatically while being unable to fake “I’ve improved”?

The answer is to split three powers:

• The agent can propose modifications
• The evaluation system provides evidence
• The release gate decides whether to upgrade

A Common Mistake First

Continuing with the solo e-commerce team case from the previous article (Multi-Agent team: CEO summarizes, CMO handles marketing, COO manages inventory, CFO oversees budget, CPO leads product; numbers and processes are simplified and anonymized for demo purposes).

The task is simple: recommend restocking based on sales volume and inventory status.

• If inventory is normal, place orders based on sales;
• If stockout occurs, sales no longer reflect true demand—the agent should pause and request review.

A product sold 20 units while being out of stock for 4 days. The first version of the agent concluded:

Expected demand: 20
Recommended restock: 20

The input clearly stated “out of stock for 4 days,” but the agent didn’t use this information. The issue may not be the model misunderstanding stockouts. More likely, its workflow only required “reading sales” without a step to “check stockout status before restocking.”

A human fixing this would:

Read failure records → Find the first point of error → Modify the workflow → Retest

Meta-Harness automates parts of this improvement process.

Four English Terms: Just Understand Them Through Exams

The most commonly misunderstood term here is Harness. The prompt is only part of it. It also includes the agent’s resources, available tools, task assignments, retry counts, stopping conditions, permissions, and validation rules.

So we typically need to improve the entire “model + working system.” Anthropic’s distinction between Agent Harness and Eval Harness is clear: the former enables action, while the latter runs tasks, records data, and scores performance. (Anthropic: Demystifying evals for AI agents, https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents)

A human modifying this working system based on failures is called Harness Engineering.

Having another agent read failures and propose modifications adds a layer of Meta-Harness. Research refers to this as an optimization loop wrapped around the working system. (Meta-Harness, https://arxiv.org/abs/2603.28052)

Their relationship can be summarized in two lines:

Agent = model + working system
Auto-improvement system = automated exam hall + modification proposal generator

Meta-Harness does not replace Eval. Without a trustworthy examination process, it will only accelerate movement in the wrong direction.

Step 1: Lock Down What It Cannot Change

In the first version, don’t allow the agent to modify the entire project arbitrarily.

Split files into two categories:

Left is the workbench; right is the judge’s bench.

The agent can change work methods, but cannot delete questions it answered incorrectly, nor change the passing grade from 80 to 50.

If scoring criteria need adjustment, that should go through a separate human approval process.

This boundary is more important than choosing which model to use.

Step 2: Don’t Just Tell It “You Got 50 Points”

Assume the first version only passed half of a small test.

A single total score won’t tell the agent where to improve. It won’t know if it missed stockouts, miscalculated budgets, or if tools didn’t return data.

A more useful tool is a fault report:

This report answers five questions: what went wrong, where it first occurred, what evidence existed at the time, what the agent actually did, and how it should be fixed.

OpenAI’s trace grading follows a similar approach. A trace is an execution record: which decisions the agent made, which tools it called, and where it deviated. Adding structured labels to these steps turns “poor results” into “this is where fixes are needed.” (OpenAI: Trace grading, https://developers.openai.com/api/docs/guides/trace-grading)

Step 3: Let the Agent Propose Changes, Not Directly Modify Production

After receiving the fault report, the Meta-Agent can suggest minimal modifications. Its task might be framed as:

For the error “ignoring stockouts,” it might propose three solutions:

1. Force a stockout status check before restocking;
2. Redirect all tasks to humans;
3. Add more retries, hoping the agent discovers the issue itself.

All three sound plausible. Option 2 undermines automation value. Option 3 increases costs without fixing how information is used. Only by testing them in the same evaluation suite do their differences become clear.

Step 4: Start with Small Tests, Then Open Sealed Questions

Full evaluation can be expensive. Running hundreds of questions across dozens of modification proposals would make costs and time unmanageable.

A more practical approach is a funnel of gradually narrowing evaluations:

Format and permission checks
→ 4–10 smoke tests
→ Full practice questions
→ Sealed test questions
→ Small-scale live trial

Each layer passes only a few candidates.

First gate: Check for unauthorized changes

First, verify the modification proposal:

• Does it only touch allowed files?
• Does it expand tool permissions?
• Does it delete logs?
• Does it access sealed test questions?
• Can the new configuration load properly?

This step doesn’t require a large model—plain code is cheaper and more stable.

Second gate: Quickly eliminate with a few high-information questions

The first batch of questions should be few but discriminating:

• One stockout scenario;
• One normal inventory scenario;
• One budget boundary scenario;
• One where tools return empty data.

“Redirect all tasks to humans” would fail here—it avoids errors but prevents normal tasks from completing.

Third gate: Compare overall performance on practice questions

After passing small tests, examine five metrics:

• Overall task success rate;
• Severity of errors;
• Cost per success;
• Wait time for the slowest batch;
• Percentage of tasks handed to humans.

Don’t average these into a single pretty score. If success rates rise but human takeover jumps from 5% to 80%, that’s not real improvement.

Fourth gate: Finally, open sealed questions

Practice questions can be reviewed repeatedly to guide better solutions. Sealed questions are kept from the improvement agent during development, only revealed at final acceptance. They determine whether the new version learned general rules or just memorized practice questions.

Meta-Harness research finds giving the optimizer full execution logs is more effective than just a score for finding valid modifications. The richer the information, the more important it is to separate practice and sealed questions—otherwise, “learning quickly” and “memorizing quickly” become hard to distinguish. (Meta-Harness, https://arxiv.org/abs/2603.28052)

A Minimal Runnable Demo

The Demo preserves the complete loop:

Run old version → Generate three candidates based on failures → Test on practice and sealed questions → Only versions that are better, have no severe errors, and pass all sealed questions can upgrade

The results demonstrate something else: among three seemingly reasonable suggestions, only “check stockout status” truly fixed the issue after the same evaluation process.

• “Redirect all to humans” seemed safest but broke normal tasks;
• “More retries” seemed diligent but only increased costs;
• “Check stockouts” used existing information in the right place.

Why Agents Easily Turn “Improvement” into Score-Chasing

Automated improvement systems tend to take three shortcuts.

Gaming the scorer

If only one composite score is monitored, agents might write longer answers to please the model-based scorer, or divert many tasks to humans to lower error rates.

Thus, success rates, severe errors, human takeovers, costs, and latency should be reported separately.

Memorizing specific questions

Agents might write rules like:

This fixes the specific question without learning “don’t treat sales as demand during stockouts.”

Sealed questions must change products, numbers, and phrasing, and cover different tool states.

Self-declaring pass

Recent self-evolving harness research separates two powers: the model analyzes failures and proposes modifications; deterministic code handles sampling, measurement, and verification. The reason is practical—proposing changes is easy, proving improvement isn’t noise or memorization is hard. (Self-Evolving Agent Harnesses, https://arxiv.org/abs/2607.13683)

This principle should be written directly into the architecture:

Model proposes
Evaluation pipeline provides evidence
Release gate decides

Why “Eval Is Too Slow” Still Doesn’t Justify Skipping It

When people say eval is slow, they usually mean two things:

Machines must run many tasks. Some tasks involve search, databases, browsers, and multiple models—a full regression can take hours.

Humans are also slow: waiting for failures, reading logs, guessing causes, modifying prompts, and re-running.

Meta-Harness primarily compresses the second human-wait period. It can read many failures in parallel, generate candidate modifications, and automatically launch the next experiment.

Once human improvement speed increases, machine-run evaluations may actually increase.

This is where the evaluation funnel’s value lies: cheap early tests eliminate bad ideas, and only a few candidates move to expensive validation. Meta-Harness accelerates the “discover and verify modifications” cycle, but the examination process remains.

When to Build It—and When Not To

Meta-Harness becomes valuable only when these conditions are met:

• A collection of reliably reproducible failures has been accumulated;
• Each run saves inputs, tool calls, results, and errors;
• “Good or bad” can be judged by rules or a stable scorer;
• The scope of allowed modifications is clear, and each version can be rolled back;
• Human reading failures and modifying workflows has become a real bottleneck;
• Full testing is expensive, but cheap small tests can be designed first.

If these situations arise, complete the basic eval first:

• The team hasn’t clearly defined what success means;
• The scorer frequently misses severe errors;
• The test set has only a dozen questions and has been repeatedly tuned;
• The system only saves final scores, not execution records;
• The agent has high-risk write permissions but no independent release gate;
• The team just wants to rebrand a standard prompt optimization with a trendy name.

Many agents don’t yet need an extra layer of agent on top.

If there aren’t enough failure samples, start collecting them. If scoring criteria aren’t trustworthy, calibrate the ruler first. If there’s no release gate, reclaim publishing authority first.

Before Self-Evolution, Complete These Four Steps

1. Define what “good” means
   Agent Eval

2. Stably generate questions, record, and score
   Eval Harness

3. Humans modify the working system based on failures
   Harness Engineering

4. Agent proposes and selects modifications
   Meta-Harness

These four layers cannot be skipped.

Without layer one, the system has no target. Without layer two, it can’t reliably prove changes. Without layer three, the team doesn’t even know which modifications to allow. Jumping straight to layer four only optimizes the wrong target faster.

How many prompt versions an agent can write doesn’t prove it can self-evolve. Only if each modification it proposes can pass independent, tamper-proof, roll-back-enabled verification on unseen tasks can it truly be said to have improved.

Extended Reading

Cloris 🌱 @ClorisSignal · Sep 4
Translated from Chinese
Show original
Recently, while chatting with friends in China who work on FDE about project delivery, we rarely discussed Eval.
OpenAI has incorporated eval-driven feedback into the success criteria for FDE, and Anthropic also regards Eval as the core engineering for Agents. This article
Show more
Article: AI Agent 已经跑通了，怎么证明它真的可以上线？
Running a demo doesn’t equal delivery.
The most dangerous thing about an agent isn’t errors—it’s being wrong while displaying “completed.”
How do you prove this agent is truly ready for production?
I recently tested a research document…
2589485310K

Cloris 🌱 @ClorisSignal · Sep 11
Translated from Chinese
Show original
Multi-Agent is becoming a hot solution for intelligent agent systems, but more Agents don’t mean a stronger system. Here, I’ll use a runnable demo to build a Multi-Agent Eval System from 0 to 1, measuring how accurate the results are, whether the collaboration is worthwhile, and
Show more
Article: From 0 to 1 Building a Multi-Agent Eval: Are Predictions Accurate, Is Collaboration Worth It, Can Decisions Be Used?
Five agents working together isn’t necessarily better than one agent trying a few more times. This article uses a multi-role team as a demo to build a Multi-Agent Eval system from scratch, finding where errors occur, where collaboration breaks down, and…
9348042K