A demo agent has one failure mode, a wrong answer. A production agent can call an API twice, refund the same customer twice, act on a stale record, or quietly do half a job and report success. This pack is about the controls that go around the model rather than the model itself. It starts with the reframe, moves to a stack that exists and runs, then to the two hardest parts nobody solves on the first try, turning expert procedure into something an agent can execute, and knowing when to throw the whole thing away. It ends on money, because that is where the argument with your finance team happens.
Why first: it changes what kind of problem you think you have. Munaf's point is that the moment an agent can call an API, you inherit every distributed systems failure at once: timeouts where the outcome is unknown, retries that duplicate a side effect, stale context. The rest of the pack is people solving specific instances of the problem he frames here.
Why second: Munaf gives you the shape of the problem, Navan gives you a stack that is running. Milev and Kanagala argue against reaching for multi-agent orchestration first, and describe the plainer thing that works: one agent that loads skills on demand, with hooks capturing goals and reasoning because ordinary logs drown in model output.
Why here: the two talks before this are about controls. This is about the input those controls act on. Buykin's claim from Maersk is that a procedure written as screenshots of human clicks cannot be automated, and that an agent-ready procedure has to state its preconditions, decisions, identifiers, validation, recovery and evidence. It is the least glamorous talk in the pack and probably the most useful.
Why here: you have now built something. Kus's warning is that the part you just built has a half life measured in months, and he tells the story of asking an engineer to rebuild working agentic search immediately after shipping it. His rule for when to switch is the one thing that keeps this from being demoralising: not a new paper, an eval set showing better customer outcomes.
Why last: everyone above assumes someone is paying for this. Hong's argument is that token spend is a diagnostic and a terrible target, and he walks through Ironclad measuring lines of code, then open pull requests, then merged ones, then merged ones weighted by complexity. It is the talk to send to whoever asks what the spend bought.