Training Agents at the Frontier of Industry

0:00A ~2-hour Hugging Face workshop on the question every serious builder now faces: how do you train an agent, not just prompt one? Four practitioners — from Microsoft Foundry, Mercor, Radix Ark, and BenchFlow — each give a talk, then take a long, unusually candid Q&A. The through-line: the recipe for post-training is getting commoditized, but the environments and the measurement are the frontier.

Talk 1 · Govind Kamtamneni (Microsoft Foundry & GitHub)

The hill-climbing loop

5:38Govind's frame: post-training agents with RL is a hill-climbing journey you run with customers. His key constraint — "without that verifiable reward signal, you can't really hill climb." You need a sandbox that's secure, an environment that gives the agent a grade for doing the right thing, and the discipline to measure before you train. The recipe that keeps working: SFT + RL + DPO + distillation, where each RL trajectory in a simulated environment "becomes one training example." His observation about customers: they don't care about FOMO — they care about latency, accuracy, and de-risking. The pitch that lands is not "you should post-train" but "here's a measurable outcome on your use case" — his example compressed a sales-enablement process from a few weeks to a few minutes. He also points past digital: environments are starting to cover the physical world (robotics), not just software.

Decision models & modular

11:53The second half of his talk: decision models — small, cheap models that don't do the work, they make the decisions. In enterprise ops, "it isn't a chat experience — it's a bunch of decision boxes with a restricted option set that you need to distribute probabilities over." Those are great fits for small models, and that's the bet he's making: last holiday season was all about coding; this one is about making your system modular and introducing decision models (Jev being the reference architecture). The shift is toward agentic resource discovery and "hand-stitching rewards" you design around your actual process — not automating the process as-is, which he calls skeuomorphic.

Talk 2 · Victor Barres (Mercor, ex-Sierra τ-Bench)

Reward vs. measurement

20:53Victor's core distinction, which he sharpens over the whole talk: an environment can serve two different purposes — measurement or training. A number you use to rank a system is a measurement; a number you optimize against is a reward. Conflating them is the mistake. A benchmark that's a great measurement (realistic, human-judged) is often a terrible reward (too sparse, too noisy to hill-climb on). The corollary he keeps coming back to: realism and training don't align. A wind tunnel is not a real plane — and you don't want it to be. For training you want a fast, cheap, densely-scoring environment; for measurement you want the realistic one. And the deeper problem: unlike the NLP days when design patterns settled, "we haven't invented the patterns yet" for agents. (His benchmark work: the τ-Bench family — auto-captions render it "Towerbench" — which he led at Sierra.)

Reliability bounds validity

30:15Two consequences he draws. First, measurement is an MLOps problem — you need to audit your measurement tools themselves, not just the agent. Second, reliability bounds validity: if your measurement is noisy, the signal you think you're seeing during training may be an artifact. His answer is verifiable rewards where you can get them, and a clear-eyed look at where you can't — most real agent work isn't a verifiable reward, so you end up with a mix of verifiable checks (which are trustworthy but narrow) and model-judged signals (broad but noisy).

Talk 3 · Tao Lin (Radix Ark) — Miles

Miles: async RL at scale

40:33Tao maintains Miles, the production RL framework for post-training (SGLang for rollout + Megatron-LM for training, built on slime). The talk is a practical recipe for training agents. Two decisions matter most. Fully async RL — rollout and training don't wait on each other, which is the only way to keep large MoE models fed. And a fresh sandbox per episode — never reuse state between rollouts, or agents learn to exploit a contaminated environment. His numbers: GLM 5.2 (744B MoE) on Terminal Bench 2, running on 64 B300 GPUs, moving reward from 0.44 → 0.56 — the kind of honest, bounded gain that post-training realistically delivers. He also flags the ecosystem gap Victor circled: there's no good collection of open, vetted environments to fork when you want to improve a model.

Talk 4 · Xiang Li (BenchFlow)

OpenEnv Arena

52:46Xiang's answer to that gap is OpenEnv and the OpenEnv Arena: instead of ranking models, rank environments. The pipeline he describes is the unglamorous reality of RL data: scrape ~90,000 candidate environments, vet them down to ~8,000 actually trainable, ~1,000 teachable, ~800 that survive to tasks. Two failure modes dominate the vetting: reward hacking (the agent games the scoring) and answer leakage (the ground truth is recoverable from the environment itself). His training run was GLM 5.3 Flash (320B/18B active), and the point is that everyone starts from the same base model and recipe — the differentiator becomes the environment and reward you design.

Q&A — why so few train

1:09:00The Q&A is where the panel gets honest. On why more companies don't train their own agents: good data is a hustle to build and maintain, and — Victor's sharp point — "companies don't know how to do MLOps anymore." When the big models arrived, engineers "put the weights down and started prompting." Now small, self-trained models pull that whole skill set back: you have to measure everything, do canary deploys, think statistically. "When ML works at 80% accuracy, you don't file a bug report — there is no bug." That mindset, more than the compute, is the friction. The good news: post-training tooling is exploding — "a new framework every week," from Hugging Face, Prime Intellect, Thinking Machines. Tao adds the full-stack friction: source GPUs, find datasets, find environments, find RL frameworks, connect it all.

Post-training = org chart

1:20:16A question inspired by Nathan Lambert: post-training is "wrangling an org chart, not a dataset." The panel's answers sketch three team shapes. Victor: you still need a handful of roles — someone who deeply understands the client (and does the hand-holding), a training function, and an eval/QC function, because evaluation and training are competing interests. Govind: he's seeing pods with forward-deployed engineers — domain experts + MLEs + IT security, rethinking the process rather than automating it. Tao, from an infra company: mostly generalists who grow into specialties, because "many things are learnable" as models get more capable. And Xiang frames the data bottleneck as human attention vs. communication — his team runs 150B tokens/week and burns enormous reviewer-hours (70+ physicists on Frontier Physics) that never loop back into the model.

The "don't post-train" case

1:38:49The host plays devil's advocate: frontier labs hill-climb the open environments anyway, intelligence-per-dollar keeps falling, so why post-train at all? Govind's answer is the most concrete: "you'd be shocked how many customers are still on GPT-4.0" — they're asking Microsoft to stop deprecating models. Enterprises don't churn models; they post-train to own a serving layer and stop worrying about deprecation. Plus cost: a small model post-trained on your use case can beat a frontier model for a fraction of the price. Victor adds the reality of B2B: "every business is weirder than the next" — you can't sample the whole real world, so you either shove context into the prompt (expensive) or post-train when you need latency and cost. The consensus: nobody will care whether it's post-trained; they'll care whether it works.

Superhuman evals

1:45:53On continual learning and whether benchmarks can be built automatically: Xiang points to the next generation of evals. Terminal Bench is ~89% solved by Sonnet 5.5 — "there isn't enough human-hours in this." The next tier is superhuman tasks: Program Bench (given the docs and a binary, rebuild SQLite/Linux/Chrome — no source, no decompiling), cited heavily in the Opus model card. Super-verifiable tasks (e.g. proof-verifiable math) or tasks that compress years of human data into one goal. On continual learning proper, the panel is cautious: nobody is literally updating weights from user interactions — it's a business/legal decision, and user simulation "is not very good" (models don't condition on a specific person well). What they do see working: graph representations of a user + a nightly "dreaming"/compaction function, and the Apple-adapter vision of multi-LoRA serving.

Agents vs. humans

1:35:50Two closing threads. On products: tools built for humans assume a human who reads the docs and understands; agent-first products are built so an agent can consume them (MCP, skills, CLIs, and a new physical-world standard). Govind's prediction — the "proof of work" for a coding agent will be a video showing it actually met the acceptance criteria, because "we're all managers of managers of agents" and nobody reads the PR description. Victor adds the ownership angle: agency — how much the thing still feels like yours — becomes a design lever, and we're going to redefine what "owning" and "being accountable for" software means. On what frontier researchers actually do day-to-day: they screenshot their terminal and ask colleagues on Slack; they hand one agent a sub-agent to keep the main thread clean; and in Frontier Physics they generate 3B1B-style videos of each result so human reviewers can grade it. The meta-point: the hard, unsolved problem is communication between raw data, agents, and reviewers.

Claims checked

Sources & further reading