Paper link: arXiv:2608.14312
Imagine training legs at the gym. The coach assigns three squat sets: bodyweight warm-up, 80% max load, then bodyweight again. You ask why, and the coach says: "I give this plan to everyone."
That sounds absurd—but it describes the current state of agent RL training. Environment-synthesis methods like few-shot, Self-Instruct, and Evol-Instruct apply the same rewriting strategy to every seed task, regardless of whether that task is too easy or too hard for the current policy. A seed with a 90% pass rate gets pushed harder; a seed at 5% gets pushed even further out of reach. Seed pass-rate information is completely ignored.
Envs-FORGE's core improvement: estimate the seed task's pass rate first, then decide how to rewrite it.
Three operations × two directions
Envs-FORGE models environment synthesis as an action-selection problem. For each seed task, there are three "projection" operations:
- Increase: make the task harder
- Reduce: make the task easier, creating a "bridge task"—stepping one notch back from a seed the current policy cannot reach
- Diversify: keep difficulty but change the scenario
- In-depth: deepen within the same domain
- In-breadth: extend across domains
Each projection can proceed along two evolution directions:
MILP: turning guesswork into solving
Prior synthesis methods are essentially "fixed recipes": Evol-Instruct always increases complexity; Self-Instruct always diversifies. Envs-FORGE expresses these fixed recipes as "action masks" in the MILP—they are special cases of the general framework.
The MILP objective simultaneously optimizes:
1. Frontier matching: the synthesized environment difficulty distribution should match the current policy's capability frontier 2. Skill coverage: synthesized environments should fill gaps in the target skill map 3. Validation feasibility: every synthesized environment must pass a validator (executable test cases providing reliable reward)
The solution yields 100 validated environments, each with executable tests. These feed directly into the GRPO training loop.
Results: a 9.2-percentage-point gain
GRPO training on Qwen 3.5 35B:
| Benchmark | Base | Envs-FORGE | Strongest baseline | Gain | |------|------|-----------|---------|---------| | tb-core | 40.0% | 49.2% | 46.8% | +9.2pp | | tb-2.0 | 23.0% | 29.4% | 27.3% | +6.4pp | | SWE-bench Verified | 73.4% | 77.1% | — | +3.7pp |
Across model sizes from 4B to 35B, tb-core improves by 6.8–9.2 percentage points.
Key comparison: all four synthesis methods (few-shot, Self-Instruct, Evol-Instruct, Envs-FORGE) output 100 validated environments using 2.27M–2.88M synthesis tokens. Envs-FORGE's advantage is not "more data" or "more compute"—it is choosing better rewriting strategies with the same resources.
Bridge tasks: the neglected middle ground
One of the paper's most interesting concepts is the "bridge task." When a seed's pass rate is far beyond the current policy's capability, training on it directly is useless—the policy learns nothing. Evol-Instruct keeps increasing difficulty, pushing the seed further away; Self-Instruct diversifies, but the new seeds may be equally out of reach.
Envs-FORGE's Reduce projection creates an intermediate task that "steps back one notch"—from a seed the policy cannot reach, down to a difficulty where learning actually happens. It resembles Vygotsky's zone of proximal development: learning happens at the edge of capability, not far beyond it.
This concept directly echoes the principle of "granularity isomorphism": the granularity of optimization should match the granularity of the thing being optimized. Agent capability is continuous, so environment difficulty in synthesis should be continuous—not a one-size-fits-all difficulty increase.
Honest reporting: costs and limitations
The paper does not dodge costs. MILP solving itself requires compute; while total synthesis tokens are comparable to baselines, the solver's extra overhead is not fully quantified. Appendix B provides a full audit trail of the MILP solving process—branch-and-cut search, solution decoding, and fallback boundary conditions are all documented.
The paper also acknowledges evaluation-scope limitations: tb-core and tb-2.0 are Terminal-Bench subsets, mostly command-line tasks; SWE-bench Verified tests code-repository repair. Whether broader task types (web interaction, multimodal agents) benefit similarly needs follow-up validation.
Resonance with the ACE workflow
Envs-FORGE's MILP framework is structurally isomorphic to ACE's RPI workflow. ACE separates research-plan-implement into three steps, compressing context independently per step; Envs-FORGE separates increase-reduce-diversify into three projections, choosing a strategy independently per projection. Both say the same thing: don't mix different kinds of work into one step.
ACE's "one line of bad research = thousands of lines of bad code" and Envs-FORGE's "one environment at the wrong difficulty = a wasted round of RL training" are the same lesson. In the agent era, upstream granularity choices determine downstream efficiency.
Conceptual lineage
Envs-FORGE instantiates the "granularity isomorphism" principle in environment synthesis. Heddle and CodeRescue raise decision granularity from "per-call" to "trajectory/recovery-action" level; Envs-FORGE raises synthesis granularity from "fixed recipe" to "per-seed pass-rate-customized strategy." All three point to: the unit of optimization in agent systems must align with the natural granularity of what is being optimized.
"Division of labor beats unification" shows up here too: fixed synthesis recipes are "uniform treatment"; MILP solving is "allocation on demand." Colibrì running a 744B-parameter model with 1,300 lines of C, Euclid-MCP's LLM+Prolog split, Rebucca's small-model+large-model review—now joined by Envs-FORGE's MILP+LLM split, the cross-domain consensus grows stronger.
---
Paper: arXiv:2608.14312 Code: github.com/DataArcTech/DataArc-SynData-Toolkit Full HTML: arxiv.org/html/2608.14312v1