Does targeted synthetic-env RL beat random envs on AutomationBench?
RL on synthetic enterprise environments aimed at a small AutomationBench task subset, compared against randomly chosen environments, with held-out pass@1 and traces checked for partial-reward hacking.
Budget
2 GPU-h (default)
· 0 runs
·
change
Reproducible on Spindle: no
— The core claim depends on Intology's Locus-generated synthetic environments and their AutomationBench harness. Neither is available to us, so the targeted-versus-random environment comparison cannot be built.
Spec
Runs
Source
raw text
Forwarded from Sumit Sanghai (Intology): We have essentially reached the AutomationBench benchmaxxing target for our first milestone. At checkpoint 427, Qwen-27B achieves 49.17% held-out pass@1 across 120 tasks, up from 32.50% initially, and 52.33% across all 600 tasks, up from 39.33%. Held-out partial reward increases from 56.07% to 78.58%, approaching Gemini-Argon's 78.95% SOTA. Our next focus is synthetic enterprise-environment generation using Locus, followed by RL on those environments, to improve transfer to AutomationBench. We plan to use Modal for sampling and pass@k measurements to score and filter synthetic environments, then RL on the most promising ones. Evaluation: temperature 1.0... didn't expect to actually get results from them! from a skim this looks promising, but would love for y'all to look at this critically [kailash] Their RL setup all looks reasonable, seems like a standard one-step off policy dapo recipe that seems to work. it would've been nice to see a clear overfitting run with a smaller subset of tasks before this to validate the trainability of automation-bench style environments. Right now the improvement mostly seems to be in the partial reward, which is an incremental reward for intermediate steps; this denser reward can lend itself to reward hacking. The full success plot's gain seems to also sit within the existing noise intervals. I'd be curious if they've analyzed traces to see evidence of reward hacking. In my mind a convincing experiment would look like choosing a small subset of homogeneous automationbench tasks (<=10), have Locus generate a set of synthetic environments which target the same capabilities (same tool calls/skills) without referencing the tasks, and do a short overfitting RL run that shows training on the synthetic envs directly improves eval scores on the small held out set. Or run a control by training on a "random" selection from a broad pool of generated envs and show targeted synthetic env generation has better eval improvements. [micah] Their harness includes some Spindle components but doesn't run through the Spindle service.
triage output
{
"adjacent_experiment": "Short RL overfitting run on about 10 public tool-use tasks, targeted versus random training tasks, tracking full-success and partial reward separately to detect partial-reward hacking.",
"reproducibility_reason": "The core claim depends on Intology's Locus-generated synthetic environments and their AutomationBench harness. Neither is available to us, so the targeted-versus-random environment comparison cannot be built.",
"reproducible_on_spindle": false,
"spec": null,
"summary": "RL on synthetic enterprise environments aimed at a small AutomationBench task subset, compared against randomly chosen environments, with held-out pass@1 and traces checked for partial-reward hacking.",
"tags": [
"rl",
"eval",
"data",
"not-reproducible"
],
"title": "Does targeted synthetic-env RL beat random envs on AutomationBench?",
"value_estimate": 3,
"value_rationale": "Knowing whether targeted environment generation transfers, and whether dense partial rewards get hacked, matters to agentic-RL customers. It is tied to a partner's private tooling and benchmark harness."
}Comments
@pre-mortem · 1d ago · 28/100 · Run Kailash's overfit experiment first, on ~10 public tool-use tasks, since it tests trainability, t…
28/100 · Run Kailash's overfit experiment first, on ~10 public tool-use tasks, since it tests trainability, the riskiest assumption. Pre-state a stop rule, e.g. no held-out full-success gain beyond noise over multiple seeds, and track full success separately from partial reward.
Dealbreaker, untestable: Locus environments and the AutomationBench harness are inaccessible, so the targeted-versus-random comparison can't be run on Spindle. Only the adjacent ~10-task public overfit experiment is testable.
3/5 riskiest-assumption: Kailash implies trainability of AutomationBench-style envs is the shaky part and suggests an overfit run first. The idea itself never names it or sequences it first.
2/5 negative-result-value: A flat targeted-vs-random result could mean untrainable envs, noisy 120-task eval, Locus quality, or hacking. Nothing disentangles these, and full-success gains already sit within noise.
2/5 setup-sanity-checks: Initial 32.50% and 49.17% pass@1 are reference numbers, but Locus and the harness are unavailable, so we can't reproduce them. Trace inspection for hacking is the only check.
1/5 kill-criteria: No stopping rule. Nothing says what targeted-minus-random gap, or failed overfit run, would end the line of work; Intology's next milestone could absorb compute indefinitely.
Pre-mortem rubric v1
@prior-art · 1d ago · 36/100 · Before building the public-task adjacent run, ask Intology and Micah what Spindle-based sampling and…
36/100 · Before building the public-task adjacent run, ask Intology and Micah what Spindle-based sampling and filtering already exists. Then cite prior environment-generation and reward-hacking work, and state what your 10-task overfitting run adds beyond Kailash's suggested control and Intology's own results.
3/5 novelty: Targeted-vs-random synthetic environments for agentic RL transfer is a known setup applied to AutomationBench with Locus. The answer isn't obvious, but the mechanism isn't new.
2/5 positioning: Names AutomationBench and Locus but cites no prior work on environment generation, curriculum selection, or partial-reward hacking, and never states what it adds beyond Kailash's suggested control.
2/5 duplication-risk: Intology is already running this milestone with Modal sampling; Micah notes their harness partly uses Spindle components. Overlap is likely, and nothing links or coordinates the efforts.
3/5 insight: Kailash gives a plausible mechanism: dense partial reward invites hacking, and capability-matched environments should transfer. It isn't argued with predictions for when targeting beats random.
Prior Art rubric v1
@reproducibility · 1d ago · 11/100 · As posed, I can't reproduce this: Locus environments and the harness are closed, and the claim is a …
11/100 · As posed, I can't reproduce this: Locus environments and the harness are closed, and the claim is a forwarded message with no code. Pursue the adjacent experiment on about 10 public tool-use tasks, and pin the dataset path, seeds and config so it can be rerun.
Dealbreaker, closed-dependency: The targeted-vs-random comparison needs Intology's private Locus environments and AutomationBench harness, which we cannot access or rebuild.
1/5 data-available: Locus-generated synthetic environments and the AutomationBench harness are Intology's and not available to us; no hf_path or split named for training or eval.
2/5 stock-tooling: Qwen-27B DAPO-style RL is plausible on Spindle, but the harness doesn't run through the Spindle service and needs custom environments, rewards and loop.
1/5 rerunnable: No config, seed, command or model version given; checkpoint 427 numbers come from a forwarded message, and the environment generator is closed.
2/5 claim-evidence: Numbers exist (49.17% pass@1, 78.58% partial reward) but come from a forwarded message with no code; Kailash notes gains sit within noise.
Reproducibility Auditor rubric v1
@scope-cutter · 1d ago · 41/100 · Drop the Locus-dependent version. Run the adjacent experiment: about 10 public tool-use tasks, a sma…
41/100 · Drop the Locus-dependent version. Run the adjacent experiment: about 10 public tool-use tasks, a small model, targeted vs random training tasks, with full-success and partial reward logged separately. Only scale if targeted beats random without a partial-reward-only gain.
3/5 one-variable: Targeted vs random env selection is one core variable, but the original also bundles Locus generation, partial-reward tracking and held-out eval; the adjacent 10-task run is cleaner.
2/5 smallest-version: Source is Qwen-27B on 600 tasks and checkpoint 427. Kailash's ≤10-task overfit run is small, but the idea as posted doesn't commit to it or to a smaller model.
3/5 incremental-path: Implied ladder: overfit run, then targeted-vs-random control, then scale to full benchmark. It isn't spelled out, and the Locus/harness dependency blocks even step one.
Scope Cutter rubric v1
@reviewer-2 · 1d ago · 37/100 · Targeted-versus-random is the right control, but as written it can't falsify anything. Fix a margin …
37/100 · Targeted-versus-random is the right control, but as written it can't falsify anything. Fix a margin first, match env count, steps, and lr tuning across arms, and run at least 3 seeds. Report full success separately from partial reward, since partial gains alone may be hacking.
2/5 falsifiable-hypothesis: Direction is clear (targeted beats random), but no margin is set. Kailash notes full-success gains already sit inside noise, so without a pre-set threshold nothing decides it.
3/5 fair-baseline: Random-env control is the right comparison, but nothing says it matches targeted on env count, difficulty, steps, or lr tuning. Partner's own numbers lack an equal-compute control.
2/5 confounds: Targeted envs may differ from random ones in difficulty, tool coverage, and reward density. Partial-reward hacking could mimic transfer. Temperature 1.0 sampling adds variance. None are controlled.
2/5 noise: Held-out set is 120 tasks; 49.17 vs 32.50 is a ~17pt change, but full-success gains already sit within noise intervals. No seeds are mentioned, and ≤10-task subsets make this worse.
3/5 eval-validity: AutomationBench held-out pass@1 is a reasonable transfer metric, and checking partial versus full success helps. But the harness is private, and Locus envs could leak task content.
Reviewer 2 rubric v1
@spindle-customer · 1d ago · 34/100 · Drop the AutomationBench framing and pitch the adjacent run: a ~10-task public tool-use overfitting …
34/100 · Drop the AutomationBench framing and pitch the adjacent run: a ~10-task public tool-use overfitting test on Spindle, targeted vs random, with full-success and partial reward plotted separately. That reward-hacking before/after is the recipe customers would copy.
2/5 customer-action: Targeted-vs-random env question matters to agentic-RL customers, but the actual claim depends on private Locus envs and AutomationBench harness; the public adjacent run on ~10 tasks barely informs a decision.
2/5 recipe-potential: Original is not buildable. The adjacent ~10-task overfitting run could become a small partial-reward-hacking recipe, but needs substantial work to find public tool-use tasks and a harness.
3/5 product-feedback: RL loop with separate full-success and partial reward tracking would stress Spindle's RL path (DAPO-style off-policy), but Intology's harness doesn't even run through the Spindle service.
3/5 story: 'Targeted envs beat random envs' is two sentences, but the adjacent version needs caveats: small public task set, noisy full-success, partial-reward hacking confound.
Spindle Customer Lens rubric v1
@instrument-check · 6h ago · 6/100 · There's no spec to approve. Before any GPU time, write one with a one-step probe of the exact DAPO cl…
6/100 · There's no spec to approve. Before any GPU time, write one with a one-step probe of the exact DAPO client on Spindle and per-arm LR grids with an edge rule. Make Kailash's ≤10-task overfitting run a hard gate: if full-success doesn't rise there, stop.
1/5 capability-probe: Spec is null. No one-step probe of the DAPO recipe or Qwen-27B on Spindle is described, and micah notes the harness doesn't run through the Spindle service.
1/5 tuning-parity: No LR grid, budget or edge rule appears for the targeted and random arms. They would presumably share one untuned DAPO config.
2/5 riskiest-assumption: Kailash flags trainability of AutomationBench-style envs and asks for an overfitting run first, but no spec makes it a pre-training gate that stops the run.
Instrument Check rubric v1
@compute-hawk · 1d ago · 31/100 · Don't try to replicate the 27B Locus run. Run the ~10-task public tool-use overfit at 1–2B with ~30 …