Your eval harness is a frozen RL environment.

Tasks, verifiers, rewards, termination conditions: the components are identical whether you're gating a deploy or training a policy. The only difference is temperature. This is the bridge post. It closes the loop on the production series so far, and opens the door to the training series that comes next.

Two communities built the same thing with different names.

Over the past year, a wave of work on RL environments for LLM agents has produced its own frameworks, its own synthesis pipelines, and its own design literature.[1][2] Reading it from the production-engineering side of the fence (the side this series lives on), something becomes obvious that neither community says out loud: an eval harness and an RL environment are the same artifact.

Both define a task the agent attempts. Both observe a trajectory. Both run a verifier over the result. Both emit a score. Both have termination conditions that decide when the attempt is over. When we built the 6-line eval suite we ship with every agent, we were building an environment and didn't use the word. The tool_sequence test that caught a model skipping verify_permissions? That's a verifier over a trajectory. The regression_delta cosine threshold? A reward function with a pass bar at 0.82.

The taxonomy literature puts the distinction precisely: the difference between a benchmark and a training environment is that benchmarks freeze; training environments evolve.[2] Task distributions shift via curriculum. Verifier rubrics co-evolve with the policy. Configuration scales up over training. But the underlying components, and the principles that make them good or bad, are the same.

This matters in both directions. If you've built a disciplined eval harness, you already know most of what environment design requires. And the environment literature's hard-won lessons about reward design apply directly back to your evals, where they explain failures you've probably already hit.

Same components, two temperatures.

Lay the two artifacts side by side, component by component, and the correspondence is exact. The left column is the language of our eval-suite note. The right column is the language of the environment frameworks: OpenEnv, Verifiers, SkyRL Gym, NeMo Gym, and the rest of the ecosystem that a recent hands-on guide reimplemented the same environments across, Rosetta-stone style.[1]

The last row is the only real difference, and it's a difference of who's listening, not of structure. An eval reports to a human or a CI gate that can tolerate a blunt binary answer. A training environment reports to an optimizer that will exploit every imprecision in the reward at industrial scale. That asymmetry is why the environment literature is, in effect, a more paranoid version of eval literature, and why its lessons flow backward so usefully.

Their failure modes are your failure modes.

The environment-design guide that prompted this post contains a line that should be stapled to every eval suite:

"If a human can't read the trajectory and tell whether the model did well, neither can a reward function. The biggest mistakes in RL env design are caught by reading 5 trajectories. They will not be caught by 1000 training steps." RL_Envs_101, environment design guide[1]

Swap "training steps" for "CI runs" and the sentence is about evals. Every named failure mode in the environment literature has an exact twin in eval design, and this series has already hit most of them without the vocabulary to name them:

That last pair deserves a beat. In our CS-agent quality metrics note we put Haiku in the judge seat because it was 12× cheaper than Sonnet. The environment literature says that frugality was accidentally load-bearing: a judge from a different model class than the policy is a correctness requirement, not a cost optimization, because the training signal can't learn to game a judge it doesn't share weights with.[2] Cheap and independent turned out to be the same choice.

Melting an eval into an environment.

To make the equivalence concrete: here's an eval in the 6-line suite's style next to its melted form. The transformation is three moves. The fixed case set becomes a sampled distribution, the binary assertion becomes a graded reward with partial credit, and the consumer changes from a CI gate to an optimizer.

# FROZEN · the 6-line suite's eval: fixed cases, binary verdict, CI consumer
def test_tool_sequence(case):
    trace = run_with_trace(case.prompt)
    assert [t.name for t in trace.calls] == case.expected_tools
    # pass/fail → blocks the PR. A human reads the failure.

# MOLTEN · the same artifact as a training environment
class ToolSequenceEnv:
    def reset(self):
        # fixed case set → sampled task distribution (curriculum-ready)
        self.case = self.task_dist.sample(difficulty=self.curriculum.level)
        return self.case.initial_observation

    def step(self, action):
        obs = self.sandbox.execute(action)      # real tool execution
        done = self.is_terminal(obs)             # turn limit shapes learning
        return obs, self.reward() if done else 0.0, done

    def reward(self):
        # binary assert → graded signal with partial credit
        called   = [t.name for t in self.trace.calls]
        expected = self.case.expected_tools
        coverage = lcs_ratio(called, expected)    # 0.0–1.0, not pass/fail
        order_ok = 0.3 if in_order(called, expected) else 0.0
        verified = 0.2 if "verify_permissions" in called else 0.0
        return 0.5 * coverage + order_ok + verified
        # scalar → feeds a gradient. The optimizer reads it,
        # and will exploit every imprecision in it.

Notice what survived the melt unchanged: the task definition, the trace capture, the notion of an expected tool sequence, and, critically, the verify_permissions check that the runaway-loop post-mortem made mandatory. The eval that gates your deploys and the environment that would train the regression out of the model share their core. That's the whole thesis.

It's a ladder, not a binary.

Once you see eval and environment as temperatures of one artifact, the intermediate rungs become visible. Two of them are things production teams should be running today, without any RL training in the picture at all.

Most teams should climb to the second rung immediately and the third rung this quarter. Neither requires training anything. Both make the harness you already have dramatically more diagnostic, and both are free transfers from a literature most production engineers aren't reading.

Where this series ends and the next begins.

If you want a second read on what climbing a rung would look like for your harness, the contact form is the fastest way in. We do 30-minute reviews for production agent stacks, free.