Agent-Training

TL;DR for operators Organizations already possess large amounts of procedural knowledge: internal runbooks, tool instructions, operating procedures, and reusable agent skills. The difficult part is turning that knowledge into training tasks with the correct tools, files, constraints, hidden information, and evaluation logic. Skill2Env: Capability-Oriented Environment Synthesis from Skills for General Agents1 treats that as an environment-construction problem rather than an instruction-generation problem. Its pipeline produced 2,963 executable tasks by organizing recurring agent demands into five capability dimensions and translating them into reusable difficulty patterns. ...

TL;DR for operators Synthetic data should not be budgeted as a cheaper substitute for human examples. It should be treated as infrastructure for producing controlled training experience. The operational sequence is: generate tasks that can actually be executed and scored; verify and repair them before spending compute on trajectories; choose a training objective that reinforces the capability you want rather than merely reproducing successful-looking behavior; and test the resulting model outside the environment in which that experience was generated. ...

TL;DR for operators A team can have stable API contracts before it has an executable sandbox, populated user state, and reliable integration infrastructure. The usual assumption is that serious multi-step agent training must wait, because later API responses need to reflect what earlier calls changed. ESAT challenges that sequencing. Lee et al. generate stateful training trajectories from API specifications without the target environment, then validate and filter the interactions before training.1 On AppWorld, training with ESAT-S52 trajectories generated from 52 synthetic applications independent of AppWorld improves Task Goal Completion by 8.4 to 47.0 percentage points across evaluated models and usually outperforms training on trajectories collected inside the real AppWorld environment. ...

Logs are useful. They are also lazy. A business agent that fails halfway through a product search, customer-support flow, compliance checklist, or research workflow will usually leave behind a long trace: thought, action, observation, thought, action, observation. The standard instinct is to read the failed trace as a chain. This step followed that step; the final reward was bad; therefore the chain was bad. Very tidy. Also very wasteful. ...

A failed automation run usually tells you more than a successful one. A coding agent compiles the wrong program and receives a concrete error. A web-navigation agent clicks into the wrong product page and sees that the attributes do not match. A task agent tries an invalid action and the environment complains, patiently, like a machine that has seen too much. In each case, the system does not merely say “failed.” It gives clues. ...