In one financial tool-use task, a trained 4 billion parameter model outperforms a 235 billion parameter baseline, but only because the team knows which behavior to reward. Human preference, imitation and verifiable correctness produce different systems, and the base model must already contain skills that reinforcement learning can combine. Product work makes those distinctions concrete. An inbox or coding task needs a realistic environment, and engineers still have to read the rollouts because reward hacks can look like progress. When a task has no exact answer, judges, grounding and known end states have to provide a usable signal. Asynchronous rollouts keep GPUs busy but introduce stale-policy variance, so environments, inference and training must run separately without losing the tests that defined success.
Why start here: Almeida asks what the model is actually being trained to want. Human preference produces a good assistant, while correctness or calibrated decisions imply different systems. Bigio comes next because he turns Almeida's three objectives into concrete choices among SFT, DPO and RFT.
Why here: Almeida separates the goals; Bigio shows what each learning signal can and cannot teach. His warning that RFT needs a clean grader also explains why Singh looks earlier in the training process for the atomic skills that RL will later combine.
Why here: Bigio starts with a capable model and chooses a post-training method. Singh asks how the model became ready for that method at all: mid-training supplies agentic data, and supervised learning supplies skills for RL to compose. Crawford then shows one of those compositions in action through disciplined tool use.
Why here: Singh explains why RL needs the right prior; Crawford shows what RL can change once that prior exists. A 4 billion parameter model succeeds by inspecting tables, reading schemas and recovering from errors. Brown follows by asking how a product team can define and measure that behavior before training it.
Why here: Crawford diagnoses one product behavior and trains for it. Brown gives that work a reusable form: an environment joins the product harness to tasks and rewards, then supports evaluation, data generation or RL. Corbitt comes next with a complete environment built from a real inbox.
Why here: Brown defines the environment; Corbitt shows how easily a plausible one can still teach the wrong lesson. His email agent needs realistic data and a reward without loopholes. Hang and Zhou then widen that case study into a method for adapting tool behavior through exploration.
Why here: Corbitt catches reward hacks by reading the rollouts. Hang and Zhou show what those rollouts are for: exploration lets an agent adapt its tool calls to a new domain and budget, provided the reward resists shortcuts. Brown follows with the harder case, where there is no exact answer to grade.
Why here: Hang and Zhou assume success can be graded cleanly. Brown deals with reports, browsing and other work where it cannot. Grounding, judges and known end states manufacture a usable signal. Garg and Li come next because generating enough exploratory rollouts turns reward design into a systems problem.
Why here: Brown shows how to create harder tasks; Garg and Li show the cost of sampling them. Synchronous RL waits for the slowest rollout, while asynchronous RL trades idle GPUs for stale-policy variance. Brown's final talk keeps that trade-off but places it inside a complete post-training architecture.
Why end here: Garg and Li isolate the throughput problem. Brown reconnects it to everything before it: one environment can produce evals, SFT data, distillation data or RL rollouts, while separate inference and training services stop long agent runs from blocking the batch. This is the assembled system the first nine talks prepare.