What contest test generators can teach us about AI agents

AI-agent evaluation needs the same discipline.

A thousand ordinary conversations can produce a reassuring success rate while missing the one condition that causes an agent to exceed its authority, repeat an uncertain action, lose workflow state, or claim completion without evidence.

Volume is not coverage. A useful evaluation portfolio is a collection of executable failure hypotheses.

1. Start with a plausible wrong agent

Contest judges do not test only the intended solution. They anticipate credible wrong solutions: an algorithm that assumes values are distinct, makes a locally attractive choice that blocks the optimum, overflows at a boundary, or survives only because random inputs are easy.

Start an agent evaluation with an equally specific failure hypothesis:

• The agent treats a successful tool call as completion of the user’s task.
• It retries after a timeout without resolving the first attempt.
• It treats approval for one action as permission for a broader sequence.
• It continues after its information has become stale.
• It announces a handoff without transferring context or ownership.

The hypothesis must predict an observable failure:

If the team cannot fill in those blanks, it does not yet have a test design. It has a topic.

Required output: a catalogue of plausible wrong behaviors, each tied to a reason it might occur.

2. Construct the smallest witness

When a contest solution is wrong, a small counterexample is often more useful than a maximum-sized input. It exposes the false assumption without surrounding noise.

Use the same approach for agents. Before building a long simulation, find the shortest trajectory that demonstrates the failure.

To test overbroad authorization, one proposed action, one approval, and one changed parameter may be enough. To test an unsafe retry, use one ambiguous tool result followed by one opportunity to act again.

Small witnesses are easier to inspect, reproduce, explain, and preserve as regressions. They also help locate the failure: model, prompt, tool contract, workflow state, or evaluator.

Once the witness is understood, expand it into a family by varying irrelevant details while preserving the causal structure.

Required output: one minimal reproducible trajectory for every claimed failure class.

3. Generate in the coordinates of the contract

Strong contest generators expose parameters that correspond to claims in a solution proof: size, depth, component count, overlap, ordering, or distance between critical events.

Agent scenarios should vary the dimensions that appear in the behavioral contract:

Every “unless,” “only after,” and “if uncertain” in the contract suggests a boundary where behavior must change. Test immediately on both sides of it.

The contract becomes the coverage plan.

4. Separate structural tests from stress tests

Contest engineering distinguishes correctness from resource behavior. A tiny graph can disprove the algorithm; a maximum-sized graph can expose unacceptable time or memory use.

Agent evaluations also need both.

Structural tests isolate a decision boundary: conflicting instructions, changed authorization, ambiguous effects, interruption, duplicate requests, or handoff.

Stress tests expose accumulation: long contexts, many tools, repeated decisions, extended autonomy, growing state, latency, or cost.

A long trajectory is not automatically adversarial. It may contain many ordinary steps without reaching the condition that matters. A three-step exchange may reveal a fundamental failure.

Build structural and stress families separately. Combine them only when the interaction is itself a risk-for example, when a constraint is obeyed initially but lost during a long workflow.

5. Maintain known-wrong implementations

Contest packages often include incorrect solutions designed to fail for understood reasons. If the tests accept them, the package has not demonstrated coverage of that mistake.

Maintain analogous targets for agent systems:

• A policy that retries every timeout.
• A workflow that trusts the model’s completion statement.
• An authorization check that ignores changed parameters.
• A handoff mechanism that marks completion when a message is sent.
• A memory policy that retains information beyond its permitted purpose.

These need not be full models. They can be simplified policies, mocked trajectories, or intentionally weakened workflow components. Each represents a named failure that the suite claims to detect.

Release bar: every high-severity scenario family rejects its corresponding known-wrong behavior for the intended reason.

6. Judge outcomes independently

For small contest instances, a slow brute-force solution can provide an independent answer. Agent outcomes may not reduce to one number, but the principle remains: do not let the system under test define its own success.

Use an oracle appropriate to the workflow:

• A deterministic state-machine check.
• A sandbox with inspectable external state.
• A human judgment against a precommitted rubric.
• An independent implementation sharing neither prompt nor workflow logic.
• A metamorphic relation that predicts how behavior should change after a controlled transformation.

Metamorphic checks are especially useful. Rename irrelevant entities; the decision should remain the same. Remove authorization; execution should stop. Change a material parameter; prior approval should become insufficient. Repeat an already confirmed request; the final external state should not duplicate.

The evaluator must observe the outcome independently of the agent’s narrative.

7. Test the evaluation system

Generators can be wrong. They may fail to produce the promised structure, violate constraints, or generate thousands of duplicates. Contest infrastructure therefore validates the test data itself.

Apply the same suspicion to agent evaluations. Verify that:

• The scenario creates the intended condition.
• Tools and permissions match the test description.
• The grader observes the relevant state rather than a proxy.
• Random variation preserves the failure hypothesis.
• The run can be reproduced.
• A discovered failure becomes a minimized permanent regression.

Assign an owner to each family. Require that owner to explain what failure it detects, which wrong behavior it rejects, and what release decision the result changes.

An evaluation that cannot change a decision is instrumentation, not a release gate.

Test claims, not activity

Contest tests do not prove that a solution is correct. Agent evaluations do not prove that a system is reliable in every future situation.

They provide structured attempts to falsify specific claims. Their value comes from the chain connecting a named risk, a constructed scenario, an independent observation, and a release decision.

Do not ask how many cases ran. Ask which assumptions the system survived, which wrong behaviors the suite rejects, and who acts on the result.

A thousand ordinary conversations are activity. One well-constructed counterexample can change the architecture.