Enviro-Mental Gymnastics: Why Cross-Environment Agents Still Trip Over Their Own Feet

Demo day is easy.

Give an AI agent one workflow, one tool stack, one database schema, one approval rule, and one forgiving evaluator, and it may look surprisingly competent. It files the ticket. It updates the CRM. It writes the SQL query. Everyone nods. Someone says “agentic transformation,” because apparently every procurement meeting now needs a spell.

Then the environment changes.

The ticketing system has a different status logic. The CRM hides a field behind a permission layer. The SQL table uses a naming convention invented by someone who has since left the company. The reward signal is no longer “finish the task,” but “finish the task without triggering a compliance exception, confusing the customer, or spending $14 in tokens to answer a $3 question.”

That is where many agents stop looking intelligent and start looking like interns with supernatural confidence.

The paper AutoEnv: Automated Environments for Measuring Cross-Environment Agent Learning tackles exactly this uncomfortable gap: agents are often tested as if intelligence means doing better inside one familiar world, while real deployment demands adaptation across many worlds with different dynamics, observations, and rewards.¹ The authors propose AutoEnv, an automated framework for generating heterogeneous agent environments, and use it to build AutoEnv-36: 36 validated environments with 358 levels. They then formalize agent learning as a component-centric loop—Selection, Optimization, and Evaluation—and test whether fixed learning strategies survive when environment diversity increases.

The answer is not “no learning works.” That would be too simple, and therefore too comforting.

The more useful answer is: fixed learning methods work locally, adaptive method selection helps, but the current tools still saturate quickly. In other words, agents do not only need better prompts, better code, or better models. They need a way to learn which kind of learning fits the world they are in.

AutoEnv starts by manufacturing worlds, not ranking models

The paper’s central move is methodological. Instead of beginning with yet another leaderboard, it begins with the environment problem.

Most agent benchmarks are expensive to build and narrow in rule distribution. Coding agents face coding tasks. Web agents browse websites. Game agents play a specific kind of game. These are useful, but they encourage an optimistic habit: if an agent improves inside one family of environments, we quietly pretend the improvement will travel.

AutoEnv makes that assumption harder to hide.

The authors define environments through the familiar reinforcement-learning ingredients: state space, action space, transition function, reward function, observation function, and termination condition. But the useful engineering idea is the three-layer split:

That separation is the paper’s first important mechanism. If the base rules and the visible “skin” are decoupled, researchers can test whether agents actually learn environmental rules or merely follow surface semantics. A poison label can help, hurt, or lie. A wall symbol can mean obstacle in one world and path in another. Cute? No. Useful? Very.

AutoEnv then turns an environment theme into a structured design, converts that design into a YAML-style domain-specific language, uses coding agents to implement the environment, generates levels, and validates them. The resulting environment package includes environment code, an observation layer, a validator, level files, action-space descriptions, and agent-facing instructions.

This is not merely benchmark construction. It is benchmark construction as a factory process.

Validation is the boring part that keeps the benchmark from becoming confetti

Synthetic environments are easy to generate badly. A model can hallucinate rules, create unreachable goals, produce broken code, or build a reward function that behaves like a random-number generator wearing a lab coat.

AutoEnv tries to reduce that problem with a three-stage verification pipeline.

First, it checks execution: can the environment run without crashing or hanging? Second, it checks level generation: can the environment reliably generate valid levels with reachable goals and meaningful reward structures? Third, it performs reliability testing with differential model evaluation: if a weaker model consistently beats a stronger one, the reward structure may not be measuring skill, so the environment is discarded.

This does not make the benchmark perfect. It does make it less disposable.

Across 100 environment themes, AutoEnv reports 90.0% execution success, 96.7% level-generation success, and a 74.7% reliability verification rate, leading to a 65.0% overall success rate. The average generation cost is reported as $4.12 per environment. Human review of themes improves the overall success rate from 60.0% in the fully automated setting to 80.0% in the supervised setting.

That last point matters. The paper is not claiming that LLMs can autonomously generate flawless evaluation worlds at industrial scale. It is showing that automated generation plus verification can reduce environment scarcity. For business readers, this distinction is crucial. The value is not “replace evaluation design teams.” The value is “make it cheaper to generate a wider set of test worlds before your agent meets the real one and embarrasses everyone.”

AutoEnv-36 is small, varied, and deliberately uncomfortable

From the validated pool, the authors select 36 environments with 358 validated levels. The environments are distributed across three main dimensions:

The environment names are intentionally varied: InterDimension, BioLumine, MagneticField, AgriculturalSimulation, GridNavigation, TileArrangement, AlienDecision, WarehousePuzzle, and others. This is not a single task family with different wallpaper. The environments cover navigation, partial observability, resource control, pattern reasoning, planning, and counterintuitive or inverted semantics.

The benchmark evaluation is not presented as a model beauty contest, although the table naturally tempts readers in that direction. Seven language models are evaluated across AutoEnv-36. Average normalized rewards range from 11.96% for GPT-4o-mini to 48.73% for o3, with GPT-5 close at 46.80%. Claude-4-Sonnet averages 40.67%, Gemini-2.5-Flash 39.41%, DeepSeek-V3.1 34.01%, and Kimi-K2 31.49%.

The important interpretation is not that o3 “wins.” Fine, it tops the table. Confetti withheld.

The better interpretation is that strong models remain far from consistently solving the environments. The benchmark has enough difficulty and variation to produce stratified performance, but not enough ceiling saturation to make the results meaningless. Full-observation environments are easier than partial-observation ones. Binary-reward environments are easier than accumulative-reward ones. These patterns make intuitive sense: more visible state and simpler success conditions reduce the burden on memory, exploration, and reward interpretation.

Then comes the strange result: inverse-semantic environments score higher than aligned ones.

At first glance, this looks like good news. Maybe agents are finally robust to misleading labels. Maybe they can ignore words and infer rules from interaction. Maybe the machines have learned healthy skepticism. Charming thought. Mostly wrong.

The inverse-semantics result is a trap, and the appendix catches it

The paper does something useful here: it does not overclaim the surprising result.

The main AutoEnv-36 table shows that inverse-semantic environments obtain higher average scores than aligned ones. A careless summary would say agents handle counterintuitive semantics well. The authors instead run a “Skin Inverse” ablation, which is the right kind of suspicion.

The ablation changes only the skin or observation layer while keeping the underlying dynamics and reward function unchanged. This isolates whether agents can truly adapt to inverted semantics, rather than benefiting from inverse environments that happen to be structurally easier.

The results are sobering.

This is one of the more business-relevant parts of the paper, even though it sits in the appendix.

A deployed agent may correctly \astsay\ast that a workflow is unusual, that a label might be misleading, or that a rule might be inverted. That does not mean it will reliably convert that suspicion into action. The gap between “I understand the exception” and “I behave correctly under the exception” is exactly where many enterprise agents fail.

The paper’s correction is precise: higher performance on inverse-semantic environments does not imply robust inversion handling. It likely reflects easier structural difficulty in those generated environments. The ablation supports the narrower and more useful claim: current agents may verbalize counterintuitive rules, but still struggle to turn those hypotheses into stable, reward-maximizing behavior.

The learning framework treats the agent as editable machinery

After building the environment side, the paper formalizes the learning side.

The authors describe agent learning through four objects: candidates, components, trajectories, and metrics. A candidate is a version of the agent. A component is a modifiable part of that candidate, such as prompt, code, memory, tools, or model. A trajectory records interaction with an environment. Metrics evaluate the result.

Learning then becomes a three-stage loop:

1. \ast\astSelection\ast\ast chooses which candidates to continue improving.
2. \ast\astOptimization\ast\ast modifies the selected component using feedback from trajectories and metrics.
3. \ast\astEvaluation\ast\ast runs the updated candidate and measures performance.

This is a useful abstraction because it puts very different agent-improvement methods into one shared frame. Prompt optimization, workflow rewriting, code self-modification, and model adaptation can all be described as different choices of candidate, component, selection rule, optimization signal, and evaluation rule.

For the experiments, the paper instantiates eight learning methods from combinations of:

The distinction between dynamics-based and instruction-based learning is especially important. Dynamics-based optimization tries to infer environment rules and failure patterns from trajectories. Instruction-based optimization focuses on rewriting the agent’s guidance to avoid observed mistakes. Prompt-level updates change what the agent is told. Agent-level updates can change implementation logic.

This is where the paper becomes more than an environment benchmark. It asks whether learning methods themselves generalize across worlds.

Fixed learning methods work locally, then lose their magic

The first learning experiments use a six-environment subset designed to cover different capabilities and difficulty profiles. This subset is not the full benchmark; it is a controlled diagnostic panel. Think of it as a lab test before sending the agent into the full obstacle course.

On Qwen-2.5-7B, the baseline ReAct-style agent averages 17.53% across the six environments. Several learning methods improve on it. Dynamics + Agent reaches 24.75%. Instruction + Agent reaches 22.33%. SFT reaches 25.09%. The per-environment upper bound, which picks the best method for each environment, reaches 28.86%.

The main evidence here is not “SFT wins.” The SFT baseline is an in-domain, per-environment specialization baseline, not a claim of cross-environment generalization. Its purpose is comparison: can training-free learning methods compete with a specialized training approach? Sometimes yes, depending on the environment. But no single method dominates everywhere.

The second six-environment experiment uses DeepSeek-V3.1 with eight methods. The baseline is 34.99%. The best single method, Instruction + Prompt under Pareto Selection, averages 42.99%. The all-method upper bound reaches 46.34%. Again, the gap between the best fixed method and the per-environment upper bound shows that environment-method matching matters.

More interestingly, mismatched methods can hurt. The paper notes that Dynamics + Agent under Pareto Selection drops below baseline on AgriculturalSimulation. Another environment, MemoryMatching, remains at 0% across configurations in the six-environment table. TileArrangement shows large variation depending on the method. This is exactly what cross-environment learning should reveal: not only where learning helps, but where the wrong learning strategy becomes expensive decoration.

Then the authors scale to all 36 environments using Gemini-2.5-Flash and four Best Selection methods. This is the key stress test.

The baseline is 39.41%. The best single method, Dynamics + Prompt, reaches 42.40%, only about 3.0 points higher. The per-environment upper bound reaches 47.75%. That upper bound is 8.34 points above baseline and 5.35 points above the best single method.

Here is the pattern in one table:

The key business lesson sits in the full-benchmark result: a fixed improvement recipe does not scale smoothly across heterogeneous environments. It may work nicely on a curated subset, then flatten when the world becomes messy.

Very corporate. Very realistic.

The upper bound is not a product feature; it is a diagnosis

The paper defines a Learning Upper Bound as the best performance achievable when each environment can choose the best method from the available method space. This is not a deployable agent. It is an oracle-style diagnostic: “If we knew which learning method suited each environment, how much better could we do?”

That upper bound matters because it separates two problems.

The first problem is whether useful learning methods exist. They do. Across many settings, some method improves performance.

The second problem is whether the system knows which method to use. Usually, not well enough.

For agentic AI products, that difference is operationally important. Many teams still treat agent improvement as a sequence of universal knobs: improve the system prompt, add memory, add tools, add reflection, rewrite the planner, fine-tune, then hope the demo stops hallucinating. AutoEnv suggests a better diagnosis: identify the environment type first, then select the learning intervention.

A partially observable workflow with sparse rewards may need memory and exploration discipline. A semantically misleading workflow may need explicit hypothesis testing and feedback integration. A highly structured symbolic task may need planning logic, not prettier instructions. A fragile API workflow may need code-level error handling. A customer-service environment may need evaluation metrics that include tone, escalation correctness, and policy compliance.

One agent architecture. Many worlds. One learning method? That is the part that should make buyers nervous.

Business relevance: build the gym before choosing the athlete

The practical path from this paper to business use is not “adopt AutoEnv-36 for enterprise workflows.” The benchmark is synthetic, text-heavy, and small relative to real business diversity. Its validators are useful but imperfect. Its learning method space is intentionally limited. Its results support evaluation architecture, not ROI forecasts.

The useful inference is architectural.

Before deploying an agent into production, a team should build a portfolio of environment tests that differ along the same kinds of dimensions AutoEnv formalizes: reward structure, observability, semantic reliability, action constraints, and feedback density.

This is where the paper becomes uncomfortable for teams selling “general agents.” Generality cannot be demonstrated with one clean workflow. It has to be tested across controlled variations of the workflow: hidden fields, misleading labels, sparse feedback, reversed incentives, partial observability, tool failures, multi-step dependencies, and non-obvious reward trade-offs.

The business value is cheaper diagnosis, not magical autonomy.

A practical enterprise adaptation of the paper would look like this:

1. Define the workflow as an environment, including allowed actions, hidden state, observation limits, reward criteria, and termination rules.
2. Generate controlled variants: easy, partial-information, misleading-label, exception-heavy, sparse-feedback, and adversarial versions.
3. Run the agent across all variants, not only the one that appears in the sales deck.
4. Track which failure modes respond to prompt changes, code changes, memory changes, tool changes, or model changes.
5. Build a controller that selects improvement methods based on environment features and past trajectories.

That last step is the hard part. It is also where the paper’s upper-bound logic points. The gap between best fixed method and per-environment upper bound is not merely a metric. It is a product roadmap.

The appendix case study shows why “component” is not a cosmetic word

The learning case study on AgriculturalSimulation is useful because it makes the component framework concrete.

In the prompt-only setting, the agent’s code is frozen and only its instruction prompt changes. Over iterations, the prompt becomes more structured: observe before acting, keep priorities, and choose one high-value action per step. This improves behavior without changing implementation.

In the instruction-agent setting, both prompt and implementation are updated as one learnable component. The edits focus on robustness: safer resets, better logging, and graceful failure handling. This is not “better reasoning” in the abstract. It is less fragile plumbing.

In the dynamics-agent setting, the agent gains internal strategy analysis. It tracks recent actions and rewards, summarizes strategy insights, and conditions future actions on those learned patterns. This is closer to environment modeling: not merely “what did the instruction say?” but “what does this world reward?”

For business systems, this distinction matters. Some failures are instruction failures. Some are implementation failures. Some are memory failures. Some are environment-modeling failures. Treating all of them as prompt problems is convenient. It is also lazy.

AutoEnv’s component-centric framing is valuable because it asks: which part of the agent should be allowed to change, under which signal, selected by which rule, and evaluated against which metric?

That is the level at which serious agent operations should happen.

What not to overread

The paper’s limitations are not decorative; they affect interpretation.

First, AutoEnv-36 is still small. Thirty-six environments and 358 levels are enough to expose cross-environment behavior, but not enough to claim coverage of real-world environment diversity.

Second, the benchmark is primarily text-based. The authors explore multimodal skin generation in the appendix, but the main experimental results are not a broad test of embodied, multimodal, or physical-world agents.

Third, normalized reward depends on validator-estimated upper bounds. The paper explicitly notes that agents can sometimes exceed 100% normalized accuracy when the validator’s maximum reward estimate is imperfect. That does not invalidate the benchmark, but it does mean the metric should be read as an approximate comparative signal, not divine arithmetic.

Fourth, the learning method space is limited. The eight methods are deliberately structured combinations of selection strategy, optimization signal, and target component. They are useful for controlled analysis, not an exhaustive map of all possible agent learning.

Finally, the adaptive-selection result is an upper-bound style diagnostic, not a finished controller. The paper shows that choosing different methods per environment would help. It does not fully solve how a production system should identify the right method automatically before wasting time and money.

These boundaries do not weaken the paper’s main contribution. They keep it honest.

The real lesson is that agents need curricula, not just prompts

AutoEnv is interesting because it changes the evaluation question.

The usual question is: “How well does this agent perform on this task?”

The better question is: “How does this agent learn when the task distribution changes?”

That second question is much harder, and much closer to business reality. Real workflows are not static games. They are collections of semi-formal rules, hidden exceptions, inconsistent labels, fragile tools, ambiguous rewards, and occasional human interventions. An agent that improves inside one environment may be learning the equivalent of office folklore, not intelligence.

AutoEnv does not solve cross-environment learning. It builds a cleaner room in which to observe the failure.

That is already valuable.

The paper’s most important result is not the average score of any particular model. It is the shrinking gain of fixed learning methods as environment diversity grows. A method that looks promising on six selected environments becomes much less impressive across 36. Adaptive selection recovers part of the gap, but diminishing returns suggest that merely adding more hand-designed learning methods will not be enough.

The next generation of agent platforms will need to treat learning strategy as a first-class object. Not just “run reflection.” Not just “rewrite the prompt.” Not just “fine-tune the model.” The system must ask: what kind of environment is this, what kind of feedback does it provide, what component should change, and how should that change be validated?

Until then, cross-environment agents will keep doing enviro-mental gymnastics: elegant in the warm-up, wobbly on the landing, and very surprised when the floor moves.

\ast\astCognaptus: Automate the Present, Incubate the Future.\ast\ast