Why Self‑Evaluating Agents Fail and How to Build Reliable Multi‑Agent Systems

In many practical setups a natural design is to let an Agent complete a task and then have it self‑check; intuition suggests this adds a safety net, but in reality models often give themselves high scores even when the result is barely usable or contains obvious defects.

This phenomenon is especially pronounced for subjective tasks such as UI design, interaction experience, or creative content, where the output may appear fine at a glance but hides hard bugs like unresponsive buttons, broken logic, or inconsistent states when actually used.

The root cause lies not in model capability but in task structure:

When generation and evaluation share the same Agent, the same preference system performs two roles.

The model tends to rationalise its existing result rather than actively overturn it.

For subjective problems, lacking external standards causes self‑consistency to be mistaken for correctness.

Consequently, self‑evaluation is more a continuation of the first judgment than an independent second assessment; it inherits the previous generation’s biases, assumptions, and blind spots. A more reliable principle is to separate generation from evaluation, using an independent role to calibrate results.

The article introduces a three‑stage structure: Planner: converts a natural‑language requirement into a structured specification. Generator: implements the specification. Evaluator: independently verifies whether the result meets the specification.

This decomposition turns a monolithic problem (e.g., building a game editor) into three distinct sub‑problems: defining what counts as “complete,” constructing the solution, and validating correctness. Each sub‑problem can be individually optimised, constrained, and tuned, shifting complexity from a single Agent to multiple manageable components.

Introducing an independent Evaluator alone is insufficient if the input remains vague; without clear acceptance criteria the evaluator can only judge an ill‑defined goal. The article therefore proposes three layers of improvement:

Move from passive observation to operational verification: instead of inspecting screenshots or code snippets, the evaluator performs real interactions such as automated button clicks, API calls, or database state checks, exposing hidden issues that only appear at the behaviour level.

Translate subjective judgments into concrete acceptance standards: break vague goals (e.g., “the UI looks good”) into measurable checks like contrast ratios or drag‑and‑drop coverage, making the task engineering‑friendly and objectively assessable.

Shift from model‑level training to prompt engineering: analyse evaluation logs to identify systematic bias, then craft prompts that constrain and correct the evaluator’s reasoning, effectively calibrating the judgment framework without costly fine‑tuning.

The core principle emerging from this methodology is to make subjective decisions scoreable by defining concrete standards, while recognising that the harder problem is defining what counts as “good.” Evaluation systems themselves require continuous tuning, just like generation systems, as task shapes, model abilities, and data feedback evolve.

When model capabilities improve, the previously necessary complex pipelines may become burdensome. Early models with limited context required multi‑round structures, state management, and negotiation mechanisms; newer models with stronger context compression and continuous reasoning can drop many of these layers, simplifying to single‑round evaluation, removing contract‑style negotiations, and streamlining Agent interactions.

Thus, system design is not about endlessly adding capacity but about continuously pruning unnecessary structure. Ongoing experimentation and a “ Harness ” mindset—regularly reassessing whether existing components still deliver net benefit—are essential. Ultimately, stronger models do not eliminate system design; they shift the optimisation direction, moving complexity to higher abstraction levels rather than erasing it.