The Model Layer & The Long Tail

The first book made one assumption on every page: the model is given. You do not build it. You wrap it, steer it, feed it context, and hold it accountable. The intelligence arrives from a lab, and the engineering begins after the weights are frozen.

That assumption is where this book starts, and it is the first thing to break.

The center of gravity in model-building has moved. For years the story was pre-training: scale the parameters, scale the data, and watch the loss curve fall. That story has not ended, but it has stopped being where the interesting gains come from. The gains now come from what happens after pre-training — supervised fine-tuning, preference optimization, and, above all, reinforcement learning. This is the post-training turn. It is what converted raw language models into systems that reason and act, and it is why a chapter on training belongs at the front of a book about building with AI.

Alessandro Cappelli of Adaptive ML names the trap that makes this turn easy to miss. Teams assume the demo is the hard part and production is "the last mile." He argues the inverse: the MVP is the first mile, and the real work is getting a system to keep improving after it meets the real world, which introduces defects no pre-launch evaluation ever covered (Alessandro Cappelli, Adaptive ML). Nathan Lambert of Ai2 describes the same moment from the research side: six months after DeepSeek and OpenAI's o1, everybody has a reasoning model, the basics are widely understood, and the live question is where the technique goes next (Nathan Lambert, Ai2). Both are describing a field that has stopped treating the model as a fixed input. The behavior you want is trained in. Jack Rae, who leads thinking within Gemini, frames the underlying method plainly: progress comes from finding an intelligence bottleneck in the current model and removing it — in the architecture or in the training (Jack Rae, Google DeepMind).

This chapter argues that once you accept that behavior is trained in rather than prompted in, the rest of Part I follows. How you serve the trained model is Chapter 2. Who can afford to build it is Chapter 3. Which modality it targets is Chapter 4. But the hinge is here: the model is no longer given. Increasingly, you are training it.

Behavior is trained in, not prompted in

Post-training is not one technique. It is a menu, and the rungs climb in cost and power.

The workshop material from OpenAI's developer experience team lays the menu out directly: supervised fine-tuning, direct preference optimization, and reinforcement fine-tuning are distinct tools, each suited to a different kind of gap (Ilan Bigio, OpenAI). Supervised fine-tuning teaches a model to imitate examples of the output you want. Preference optimization teaches it to prefer one response over another. Reinforcement fine-tuning goes further: it optimizes against a reward, so the model can discover behavior no example set spelled out. The names matter less than the ladder they form. Each rung absorbs a different signal, and the highest rung absorbs the one that matters most in production — a measure of whether the work was actually good.

The reason the top rung has taken over is that the target moved from text to action. A model that only answers can be tuned on answers. An agent — a model that calls tools and takes steps in the world to finish a task without checking in at every turn — has to be tuned on whole trajectories of behavior. OpenAI's fine-tuning team frames agent reinforcement fine-tuning as the most powerful way to raise an agent's performance precisely because an agent is defined by its ability to interact with the outside world to get things done on its own (Will Hang & Cathy Zhou, OpenAI). You cannot write down every correct trajectory by hand. You can only reward the good ones. That is a training problem, and it is a reinforcement-learning-shaped one.

Reasoning and agency are the same training problem

The field talks about reasoning models and agents as if they were two research tracks. They are one.

Will Brown of Prime Intellect makes this the thesis of his talk on training agentic reasoners. People treat reasoning as one thing and agents as another, with separate considerations for each. He rejects the split: "The high level thesis of this talk is like — no, they're kind of the same thing." (Will Brown, Prime Intellect) The unification is mechanical, not rhetorical. A reasoning model is trained to produce a long internal chain before it answers. An agent is trained to produce a long external chain — call a tool, read the result, call another — before it finishes. Train multi-turn tool use with reinforcement learning and the "reasoning" and the "acting" become the same loop: a sequence of steps optimized against whether the final result was correct. Modern systems built this way, like o3-style deep research, are reasoners and agents at once because the training made no distinction.

This is why the recent capability jump did not come from a bigger base model. It came from training models to think and to act in the same loop. Aakanksha Chowdhery of Reflection.ai, who led research on PaLM and worked on Gemini before turning to autonomous coding, traces the same arc: the frontier moved from pre-training scale, through inference-time tricks like majority voting, to reinforcement learning at training time as the durable source of gains (Aakanksha Chowdhery, Reflection.ai). Once you see reasoning and agency as one training problem, the strategic questions collapse into one question too: what reward are you training against, and can you compute it at scale.

Thinking is a training signal that scales

The reason to invest in training-time reasoning is that it compounds. More training-time reinforcement learning buys more inference-time gain.

Nathan Lambert states the relationship cleanly: "You can scale RL at training time and the numbers will go up and that's deeply correlated with being able to then do this inference time scaling." (Nathan Lambert, Ai2) The two scaling knobs are linked. Spend more compute teaching a model to reason and it also gets more out of the extra compute you give it at answer time to think longer. That is a different economics from pre-training, where the only lever was a larger model. Here the lever is how well the model uses a variable thinking budget, and that skill is trained.

Jack Rae's framing explains why labs pour effort into this specific capability rather than raw scale (Jack Rae, Google DeepMind). Advancing intelligence is a matter of finding the current bottleneck and removing it, and for the current generation of systems the bottleneck was the inability to think before answering. Removing it was a training change, not just an architecture change. Thinking, in other words, is not a prompt you write. It is a behavior the lab trained, and it is the behavior that turned a fast autocomplete into something that can work a hard problem.

Reinforcement learning is what carries a model into production

Of the post-training methods, reinforcement learning has a property the others lack: it can keep learning from production.

Cappelli puts the claim at its strongest: "Reinforcement learning RL is not just any other algorithm for post-training, but is an algorithm that at its core will bring models to production." (Alessandro Cappelli, Adaptive ML) His reasoning is about feedback. Prompt engineering cannot systematically absorb a production signal — patch one defect in the system prompt and you likely introduce another, with no mathematical handle on the tradeoff. Supervised fine-tuning can absorb feedback, but only by rebuilding the dataset every time the world surfaces a new edge case, which is expensive and never finished. Reinforcement learning was designed to integrate a reward signal continuously. It treats production data as part of the training loop rather than as something that lives outside it. That is why, in his account, it is the method that closes the gap between a demo and a system that improves in the field — and why he opens with the blunt statistic that ninety-five percent of generative-AI pilots never reach production at all.

The payoff is not only accuracy. Cappelli's deployments at Fortune 500 scale turn on economics that reinforcement learning improves in three ways. It reaches the quality of a supervised fine-tune with fewer parameters, so the served model is smaller and cheaper — decisive when a company like AT&T summarizes every customer-agent call and the bill runs into the millions. It fits latency budgets a large frontier model cannot: speech-to-speech support tolerates only a few hundred milliseconds of delay, which forces a small, fast model, and reinforcement learning is the most efficient path to making a small model good enough. And it produces a model the business owns, trained on its own data, so a silent vendor-side update cannot shift the product's behavior overnight. Accuracy is the headline; cost, latency, and ownership are why the method sticks.

Sylendran Arunagiri of NVIDIA reaches the same destination from the opposite direction, and lands one of the chapter's most useful correctives: "It's not about powering them up with the next biggest LLM in the market. All they need is simple data flywheels." (Sylendran Arunagiri, NVIDIA) The instinct when an agent underperforms is to reach for a larger frontier model. The better move is usually to build the loop that feeds real-world outcomes back into the system so it improves over time. The flywheel is the productionizing mechanism, and reinforcement learning is the training method built to turn it.

Code is the domain where RL scales first

Reinforcement learning needs a reward. The domains where it scales fastest are the ones where the reward is free and honest.

Chowdhery's argument for autonomous coding rests entirely on this (Aakanksha Chowdhery, Reflection.ai). Inference-time and reinforcement-learning techniques only pay off reliably in domains with automated verification — math, with calculators and formal proofs, and code, with unit tests and compilers. In those domains a model's output can be checked by machine, cheaply and without a human in the loop, which gives the training process a reward signal it can trust and run millions of times. She points to results where coverage on a SWE-bench-style benchmark climbs toward roughly eighty percent as sample count rises, and notes the catch: plain majority voting does not carry that gain into practice, because a correct generation can be too rare to find by sampling alone. The way past that ceiling is reinforcement learning at training time rather than tricks at inference time. Her framing of autonomous coding as the "root node" problem follows from the same fact — code is where verifiable rewards are most abundant, which makes it where reinforcement learning has the most room to run.

This is also why unverifiable domains lag. A reward model made of another neural network can be gamed; a compiler cannot. Execution feedback and unit tests reduce the reward-hacking risk that plagues reinforcement learning with neural reward models, which is the specific reason Chowdhery's team treats autonomous coding as the "root node" problem — the place to start building toward broader capability, in the spirit of what David Silver and Rich Sutton call the "era of experience." A roughly thirty-five-person company betting on that thesis is a wager that the reward, not the model, is the scarce resource. The further a task sits from an automatic checker, the harder the reward is to build, and the reward is the whole game. Code is not special because it is important. It is special because it grades itself.

The data recipe beats model size

For reasoning quality, the differentiator has moved from the size of the model to the quality of the data pipeline that trains it.

Ryan Marten of Bespoke Labs makes the case with an open project: "Open Thoughts, which is our project to create the best open-source reasoning data sets." (Ryan Marten, Bespoke Labs) The resulting model, OpenThinker, reached state-of-the-art among small open reasoning models — outperforming DeepSeek distillations — and it got there not by adding parameters but by curating the reasoning traces it trained on. The lesson is that a competitive reasoning model can be built in the open when the data recipe is good enough, which relocates the advantage from the pre-training budget to the dataset.

Chang She and Noah Shpak, working on training-data platforms at LanceDB and Character.AI, give this a structure with their hierarchy of needs for training-dataset development: model quality depends critically on how the dataset is constructed, and dataset construction is part craft, part science (Chang She & Noah Shpak). It is the same point Arunagiri's data flywheels make from the production side (Sylendran Arunagiri, NVIDIA): the pipeline that produces and refines training data is now the lever, not the parameter count. When the differentiator moves to the data, the discipline moves with it.

You probably don't need fine-tuning — until you do

The turn to training does not mean every team should train. Most should climb the cheaper rungs first.

Kyle Corbitt, who runs a fine-tuning platform, opens against his own interest: "The title of my talk is that you probably don't need fine tuning — this is an awkward title, given that I am doing a fine-tuning platform." (Kyle Corbitt) His maturity curve runs from simple instruction prompting, through few-shot examples and retrieval, and only then to fine-tuning — with reinforcement learning further still. The mistake he warns against is jumping to training before exhausting the cheaper rungs, which is common and expensive. Prompting and retrieval solve a large share of problems at a fraction of the cost, and they solve them today, without a training run.

Abi Aryan's survey of domain adaptation makes the same map from the enterprise side: the methods run from prompt engineering to retrieval to fine-tuning, and the right choice depends on the dataset and the problem, not on fashion (Abi Aryan). Read alongside Cappelli's argument, this is not a contradiction but a sequence. You probably do not need fine-tuning to reach a working MVP. You probably do need training to keep a high-stakes system improving once it is in production and the cheaper rungs stop absorbing new failure modes. The skill is knowing which mile you are on.

The hard part is operations, not the algorithm

The reinforcement-learning algorithms are, by now, well understood. What stops teams is the machinery of running the loop at scale.

Cappelli is direct about the cost: running PPO means orchestrating four models simultaneously, which is hard enough that most teams cannot do it without dedicated infrastructure — the problem his platform exists to absorb (Alessandro Cappelli, Adaptive ML). Chowdhery gives the same figure from the research side and shows it is not merely a PPO quirk: PPO-style RLHF keeps four copies of the model in memory, and even DeepSeek's GRPO, which drops the value model, still needs three (Aakanksha Chowdhery, Reflection.ai). Holding several large models in memory at once, in sync, is an operations problem before it is a research one.

The infrastructure underneath compounds the difficulty. Modern models increasingly use mixture-of-experts designs that train larger networks efficiently by distributing layers across many machines, and that distribution only works over a specialized network fabric — rail-optimized InfiniBand, in the Crusoe Cloud account — engineered to move data between GPUs fast enough to keep the training busy (Crusoe). Daniel Han's full workshop frames the live question bluntly — why is reinforcement learning suddenly everywhere, and is it truly effective — and answers it across kernels, quantization, and agents, which is to say across the operational surface, not the theory (Daniel Han). The technique is not the moat. The ability to run it is. This is the thread the next chapter picks up, where serving and inference economics become the constraint that decides what a trained model can actually do in production.

How you know training worked

Training is only worth doing if you can tell whether it helped. For a specific use case, that is harder than it sounds.

Emmanuel Turlay puts the difficulty plainly: there are metrics and benchmarks, but they mostly apply to generic tasks, and there is no one-size-fits-all process to evaluate a model's performance on a particular use case (Emmanuel Turlay). A leaderboard score tells you little about whether a fine-tune improved the job in front of you. You have to build the evaluation for the use case, and that evaluation is what turns a training run from a gamble into a measurement.

The common shortcut is to let a strong model grade the outputs. Alex Volkov of Weights & Biases endorses the method but with a guardrail: you should not try an LLM judge without a bit of human in the loop (Alex Volkov). The judge scales the scoring; the human keeps the judge honest, calibrated against real preferences. This is the same shape as the training loop itself — a machine-computed signal, checked against human judgment where it matters. Evaluation is not a separate discipline bolted on after training. It is the reward signal, viewed from the other side. If you cannot measure whether training worked, you cannot train toward anything, and the turn to reinforcement learning was, at bottom, a turn toward optimizing a signal you can trust.

For a few years the frontier looked like a two-lab race. There were the labs that could train a frontier model, and there was everyone else — the developers who called their APIs. That picture is now wrong.

The first two chapters took the model apart from the inside: how it is trained (Chapter 1) and how it is served (Chapter 2). This chapter zooms out to the labs and the strategy. Building a frontier model has become its own engineering discipline, with its own culture — set by release cadence, by the choice to open or close the weights, by which benchmarks the field decides to chase, and by the hardware that shapes every design decision underneath. And that discipline is no longer scarce. Simon Willison, reviewing the field, had to cut his own scope: "I counted 30 significant model releases in the past six months." Simon Willison That is roughly one serious model release a week, from more labs than any one engineer can track.

The volume underneath that headline is larger still. Eugene Cheah, counting uploads rather than launches, put it at "more than 50,000 AI models have been uploaded to Hugging Face per month… that is more than one AI model a minute." Eugene Cheah The frontier is not a place a handful of labs guard. It is a crowded, fast-moving field, and the strategy of building at it — not just the technique of training — is now worth studying in its own right.

"Stagnation" is a training-budget story, not a ceiling

The most common complaint about the frontier is that it has stalled. The complaint mistakes a spending decision for a physical limit.

Dylan Patel of SemiAnalysis traces the felt stagnation to a plain fact about what the field is actually running: "The models that we're using today are largely the same as the models that were trained in 2022." Dylan Patel The flagships people use are, in his account, smaller models trained for longer — same generation of architecture and pre-training, refined rather than replaced. When a newer model beats an older one at a smaller size, the gain comes from training it better and longer, not from a new idea about how to build it. The apparent plateau is not the ceiling of what the architecture can do. It is the lag between what has been trained and what could be, given a bigger run and more post-training.

Read that way, "stagnation" is a budget and scheduling story. The leap is still available; it just costs a training run nobody has finished paying for yet. This is also why the hardware chapter is not separable from the strategy chapter: what a lab can build at the frontier is set by what it can afford to train, and what it can afford to train is set by the compute substrate underneath (Chapter 2). The complaint about a plateau is really a complaint about the pace at which the field is willing to spend.

Frontier progress is bottleneck-hunting

Labs do not advance by improving everything at once. They advance by finding the single thing most holding the best current system back, and unblocking it.

Raia Hadsell, VP of Research at Google DeepMind, frames frontier research as exactly this search: progress toward general intelligence has been marked by identifying the fundamental bottlenecks inside existing models and building the fix — in the architecture or the training — that removes them. Raia Hadsell The discipline is diagnostic before it is inventive: the hard part is naming the right weakness, not generating candidate improvements. Jack Rae, tech lead for thinking in Gemini, describes the same method at work on one capability. His team's excitement about thinking comes from seeing it as a way of "unblocking bottlenecks towards intelligence" — and, in his telling, if you can identify the crucial shortcoming in your most advanced system, the fix often follows. Jack Rae The training method that produced Gemini's thinking is Chapter 1's subject; the point here is the research culture around it.

Frontier progress is a sequence of correctly chosen bottlenecks, and choosing them is the skill that separates the labs. It also explains how a smaller team can compete without a larger team's compute. If the next gain comes from the single right unblocking rather than from broad, expensive improvement across the board, then a team that diagnoses the bottleneck correctly can leap without matching anyone's budget. Bottleneck-hunting is a strategy that rewards focus over scale — which is part of why the frontier stopped being the exclusive property of the labs that could spend the most.

Code is where labs learn to model computation

Nearly every frontier lab starts its reasoning work in the same place: code. The reason is deeper than code being a lucrative market or a tidy source of training signal.

Jacob Kahn of FAIR describes the goal behind Meta's Code World Model plainly: "Our primary goal is to build models that reason, plan and make decisions. And we start with code because it's an interesting sandbox in which to think about reasoning." Jacob Kahn The word that matters is sandbox. Code is constrained; it has rules; and, unlike most of the world, it can be executed, so the model can be trained to predict what a program does, not merely how it looks. That is a different ambition from writing plausible code — it is modeling computation itself, the semantics under the syntax. Code is chosen as the first world simple enough to simulate honestly, and reasoning learned there is meant to generalize outward. Poolside makes the same bet from the opposite end of the market. "Poolside exists to close the gap between models and human intelligence… We're building our own models from scratch to do this," its founders say — starting from code, and pairing next-token prediction with reinforcement learning to make the leap. Poolside Both treat code not as the destination but as the training ground for general reasoning. (Why code's rewards are so cheap to verify — the mechanics that let this training scale — is Chapter 1's argument; the strategic choice to start there is this chapter's.)

The open-model gap has largely closed

The industry spent years assuming the best models would stay closed, and that open weights would trail by a generation or two forever. That assumption has broken.

The turning point was DeepSeek-R1. Eugene Cheah calls it "the first open source model to catch up and surpass GPT-4," and draws the lesson the whole field took from it: "you do not need a billion dollars to compete with the big labs." Eugene Cheah R1 did not just close a benchmark gap; it broke out of the AI-engineering bubble into mainstream business awareness, which is where Amir Haghighat of Baseten picks up the story — the DeepSeek-R1 news cycle is what put open models on the agenda of the largest enterprises, not just the hobbyists. Amir Haghighat And the competition did not stop at parity: MiniMax now presents its M2 as, in its own framing, the number-one open model, built for agentic coding. Olive Song The claim on the frontier is no longer "closed beats open." It is that open-weight models trade blows with the best closed ones, from teams that never spent a closed lab's budget.

That change is what matters most to the engineer reading this. It permanently alters who gets to build on the frontier rather than merely rent it. When the best available weights were closed, building on the frontier meant calling an API and living inside another company's rate limits, pricing, and update schedule. When the best available weights are downloadable, a team can run the frontier on its own infrastructure, fine-tune it, and inspect it. The gap the industry assumed was permanent turned out to be a lead measured in months, and a lead measured in months is not a moat.

Open source is a strategy, not charity

When a lab releases its weights, it is easy to read the move as generosity. The labs releasing them describe something colder and more deliberate: a way to build an ecosystem and set the standard others build on.

Mistral is explicit that the openness is the strategy, not a side effect. Devendra Chaplot frames his talk around exactly that question — "why we do open source and how we do open source" — from a lab whose commercial platform and flagship models sit alongside the open ones. Devendra Chaplot Google's Gemma team names the payoff directly. Kathleen Kenealy, the team's technical lead, describes the north star as "building something to empower and accelerate the amazing work being done by the open source community" — and measures success by what gets built on top. Kathleen Kenealy The mechanism is control through adoption: Omar Sanseviero defines an open model as one "that you can take, you can download, you can run in your own infrastructure, your own devices… fine-tune for your own use cases." Omar Sanseviero Every one of those actions builds on the releasing lab's format, its tokenizer, its fine-tuning conventions. Alibaba has run the same play for years, shipping the Qwen series continuously since 2023 toward the stated goal of a generalist agent model. Junyang Lin Open weights are how a lab that is not first in raw capability can still become the substrate the field standardizes on.

Benchmarks are how the field steers itself

A benchmark looks like a neutral scoreboard. It is closer to a steering wheel. What the community agrees to measure becomes what the labs optimize, and therefore what gets built.

Alex Duffy makes the mechanism the whole point of his talk: benchmarks are memes, in the original sense of ideas that replicate and shape behavior, and "what we measure shapes AI — and us." Alex Duffy A benchmark that captures the field's attention pulls training runs, data curation, and architecture choices toward the abilities it rewards; the measurement becomes a self-fulfilling prophecy about what the next generation is good at. This is the political layer of the frontier. Deciding which benchmark counts is deciding, in advance, what the next round of models will be trained to do — and the labs that set the benchmark others chase gain the same kind of standard-setting power that open weights confer.

That gives the choice of benchmark real power — and it explains why the field's inability to measure well is such a load-bearing problem. In Amplify's 2025 survey of 500 practitioners, evaluation was named the single most painful part of AI engineering. Barr Yaron The field steers by benchmark, yet building good ones is the thing practitioners find hardest. That is not a small tension. If measurement is the steering wheel, a field that cannot measure well is a field driving toward whatever is easiest to score.

The frontier is a discipline, not a club

Put the pieces together and the frontier stops looking like a club with two members and starts looking like a discipline with many practitioners.

The felt stagnation is a training-budget lag, not a wall (#476). Labs advance by hunting bottlenecks, not by improving everything at once (#013, #267). They start reasoning work in code because it is the first world they can simulate honestly (#067, #049). Open-weight models have caught the closed frontier, from teams without closed-lab budgets (#439, #189, #074) — and the labs releasing them do so to own the standard, not to give it away (#009, #528, #480, #400). Over all of it, the benchmarks the field chooses to chase quietly decide what the next generation will be good at (#253, #137). None of this is the technique of training a model, which Chapter 1 covered, or the economics of serving one, which Chapter 2 covered. It is the strategy of building at the frontier as a distinct thing worth doing well.

What this chapter leaves open is a question of direction. The frontier is crowded and fast — but crowded and fast toward what? So far the whole account has been about text and code. The next move is into other modalities: vision, audio, action, the physical world. That is where Chapter 4 begins.

Part I broke one assumption: that the model is a given. Every chapter in it was about building the model — training it, serving it, pushing it at the frontier, and pointing it at speech, media, and recommendation. Part II breaks a different one. Here the model is capable enough. What fails is the assumption that the generic agent playbook fits the domain you are working in. This is the long tail of AI engineering: the places strange enough that the standard harness has to be unlearned before it can be rebuilt. Robotics is the first, and the sharpest, because the domain is not a text box. It is physics.

Chapter 4 closed on the car and the humanoid as foundation models — Waymo's EMMA and Nvidia's GR00T N1, the driving stack and the robot's control policy each framed as one model to be trained rather than a pipeline to be engineered. That was the model layer reaching its last modality. This chapter enters the world those models have to survive. A chatbot that answers wrongly can be corrected on the next turn. A robot that moves wrongly has already knocked something over. The physical world adds constraints the text harness never has to handle: control loops that run in real time, sensor and actuator latency measured on the wire, the impossibility of a clean undo, and data that arrives as telemetry rather than text. Each one forces the playbook to give something up.

One model for any robot

The frontier bet in robotics is framed the same way the frontier bet in language was: not a fleet of task-specific policies, but a single general model.

Physical Intelligence states the ambition without hedging. "Our mission is to make a model that can control any robot to do any task," says Quan Vuong. Physical Intelligence That is the foundation-model paradigm aimed at bodies: one model that generalizes across robots and tasks, replacing the bespoke controllers that made robotics work only inside constrained environments like a factory line. It is the same move that produced the general-purpose chatbot, now made in a domain where a wrong output has mass and momentum. The talk is careful about how far off this is — "this is not something that's ready today," Vuong says, with several scientific breakthroughs still needed to get there — which is exactly why it opens the chapter as a vision rather than a shipped result. The goal has flipped from writing a policy per robot to training one model for all of them; whether that goal is reached is the open bet the whole field is now making.

The bug is the system, not the policy

The first thing the physical world makes you unlearn is where failure comes from. In a text agent, a bad output usually means a bad model. In a robot, it usually does not.

Rishabh Garg, who works on Tesla's Optimus, puts the diagnosis plainly: when a carefully trained control policy does not behave as expected, "the issue will look like it's the policy but it's actually the software system." Tesla Optimus His talk is about what happens between the controller and the wire — getting data from sensors into the system and commands out to the actuators, across a communication protocol with its own timing and electrical characteristics. A robot's behavior is shaped by the control policy, the software configuration, and the physics of that link, all at once. The failures that look like intelligence problems are, again and again, engineering problems: a timing skew, a dropped message, a protocol quirk. The lesson is uncomfortable for a field that likes to credit or blame the model. In embodiment, most of the intelligence you can actually ship lives in the system around the policy, not the policy itself.

Physical data breaks agents that handle text fine

The second thing to unlearn is that data is data. The agent harness that works on text falls apart on the physical world's exhaust.

Dmitry Petrov of DataChain frames physical data as a different kind of matter entirely — video recordings, sensor readings, robot telemetry, often all combined in one project — and reports that agents handle it badly out of the box. He cites a published result to make the size of the gap concrete: "Anthropic published that accuracy for data projects on their agents is only 21% until you add specific data harnesses to them and provide context." DataChain The fix is not a better base model but a domain-specific data harness — layered context built around the model so it can reason over telemetry the way it reasons over prose. This is the same lesson Chapter 3 drew for codebases, transposed to a domain where the "codebase" is a stream of sensor readings. Text was legible to the agent by default; physical data is not, and making it legible is the work.

A general-purpose robot can learn a trade

If the frontier bet is one model for any task, the near-term evidence is narrower and more concrete: a general-purpose robot trained into a single working role.

CloudChef is the case study. Nikhil Abraham describes taking a bimanual robot that "was not meant for cooking — it was just a robot with two hands," putting it "through culinary school," so that "it's now a professional chef that's working in various different kitchens." CloudChef The claim that matters is not that a robot can cook; it is that a general-purpose body was trained into a skilled trade and that the skill transfers to kitchens it was never trained in. That is the domain's version of generalization — not answering an unseen question, but performing a physical task in an unseen environment. It is a single company's account of its own system, and the strongest figures (learning a recipe from one demonstration, working across novel kitchens) are the company's to prove. But it is the shape of the bet made real at small scale: the body is general, the training makes it a professional.

Reaching most robots means going small

The third thing to unlearn is that more capability means a bigger model. For embodiment at scale, the constraint runs the other way.

Cormac Brick of Google draws the line by counting devices, not benchmarks. If intelligence is to reach not just a handful of expensive robots but the vast number of ordinary devices, "we are going to need tiny models." Google A cheap robot cannot host a frontier model; it has the compute, power, and latency budget it has, and that budget decides what can run on-device at the edge. So the number of robots that can be intelligent at all is bounded not by how good the largest model is, but by how capable the smallest useful one can be made. This is a different argument from the on-device economics of Chapter 2, which was about cost and access — turning a subscription into an energy bill, keeping data private, working offline. Here the point is reach: broad embodiment depends on small models because most bodies cannot carry a large one. Brick argues the edge case from inside Google's edge effort, so the framing is a builder's; the constraint it names is not.

Cheap, open, hackable bodies

The fourth shift is about who gets to build at all. Robotics is starting to follow the path open models cut through text: from proprietary labs toward hardware a developer can actually buy and modify.

The humanoids that draw the hype — Tesla's Optimus, 1X, Unitree — are proprietary and expensive. K-Scale Labs offers the counter: an open-source humanoid, built hardware-to-software for developers, at $8,999. K-Scale Labs Hugging Face pushes the same idea further down the price curve with Reachy Mini, a $300 open-source robot that is designed to be hacked. Reachy Mini Neither is a frontier machine, and both are early — the significance is not the spec sheet but the pattern. Open weights let a developer run, fine-tune, and inspect a model instead of renting it through an API; open, affordable, hackable hardware promises the same for the body. It is the same democratization argument the text ecosystem already made, now pointed at atoms, and it pairs naturally with the previous section's tiny models: cheap bodies and small models are two halves of the same push to move robotics out of the lab.

What robotics makes the playbook unlearn

Put the chapter together and it is not a survey of robots. It is a list of things the generic playbook has to give up the moment the environment stops being a text box.

The goal is still one general model (#175) — that carries over from Part I intact. But the failure model inverts: the bug is the system between controller and wire, not the policy (#110). Data stops being legible by default; telemetry needs its own harness before an agent can reason over it at all (#890). Generalization stops meaning an unseen question and starts meaning an unseen kitchen (#229). Bigger stops being better, because reach is bounded by the smallest model a cheap body can run (#936). And the hardware itself is beginning to open the way the models did, which is what makes any of this reach past the lab (#276, #725). Real-time loops, latency on the wire, the missing undo, telemetry instead of text — every constraint in this chapter is one the text harness never had to handle, and each one forces a specific unlearning.

That is the pattern Part II will repeat. Each domain in the long tail takes the capable model as given and then breaks the playbook in its own particular way. Robotics breaks it on physics. The next chapters break it on stakes and on trust, where the domain that resists the playbook is not the physical world but the regulated one.

The long tail ends in the domains that look least like engineering: a game, a classroom, a song. The generic playbook breaks here too, but not the way it broke in the last chapter. The constraint is no longer stakes. It is subjectivity, pedagogy, and play. There is no ground-truth label for a fun level, a good lesson, or a moving piece of music, and often no way to check the answer at all. A wrong output does not cost a patient or a lawsuit; it costs the experience, which is the whole product.

That would seem to be the model's home turf — the place where fluent, plausible, creative output is exactly what you want. It is not. Across chess, mobile games, tutoring, and music, the practitioners who shipped something real converge on the same discipline: keep the model in a narrow lane — translating, generating, or coaching — and let a structured system around it hold the ground truth. The weight of the evidence sits with games, so this chapter leads there.

Games

The model explains; the engine computes

The cleanest statement of the pattern comes from chess. Anant Dole and Asbjørn Steinskog, engineers at Play Magnus — Magnus Carlsen's company — walked through the pipeline behind their production chess coach, the game-review feature that tells a player why a move was good or bad. Their talk is called "how we built our AI chess coach that now you can use and is in production" chess coach, and the design is a study in restraint.

The system never lets the model touch the chess. Stockfish plays the whole game and produces the ground-truth best move and evaluation for every position. A research network from the University of Toronto predicts what a human at a given rating would actually play, so the coach can say a move is brilliant because only a small fraction of players at your level would find it. Hand-built detectors extract the tactical structure — forks, pins, threats, defensive resources — into a large structured package. Only then does an LLM enter, and only to turn that package into English. It is explicitly forbidden from reasoning about the position on its own. The reason is blunt: LLMs hallucinate moves and cannot calculate, but they are excellent at explaining once the analysis is handed to them. The model is a translator, and everything that has to be true is computed before it speaks. That is the chapter's whole thesis in one architecture — the structured system owns the truth, and the model owns the words.

The puzzles stay human, and the agents run local

The New York Times games team draws the same line from the other side. Shafik Quoraishee and Joanne Song, presenting local agentic patterns for accessible mobile games, open with a disclaimer they clearly mean: "Our puzzles are made by people. They're not made by AI." They repeat it plainly — "There's no AI in the games themselves" NYT mobile games. The craft that makes a puzzle worth solving stays human-authored; the AI lives at the edges, in accessibility and responsiveness, not in the ground truth of the game. Their argument for pushing agentic behavior on-device is the same one that ran through the inference chapter — local execution buys low latency and reach — applied to play. It is the earlier NYT case study, Quoraishee's look at "the interplay between human intuition and artificial intelligence in puzzle-solving" in Connections NYT Connections, carried to its conclusion: the model can help around the puzzle, but the puzzle is human.

Generating the content is easy; making it good is not

The demos make building a game with AI look solved. The practitioners who tried it say the opposite. Jeff Schomay built a small exploration game and reports, without hedging, "I made a game with 100% AI generated content" Infinite Game — and the interesting part of his talk is not that the generation worked but where it strained. A game needs a flood of cheap, disposable ideas while you prototype and near-infinite depth once you play, and generating that volume is now the trivial part; making the generated content actually good is the problem that remains. Danielle An and David Hoe of Meta put the caution in their title — "Think You Can Build a Game with AI? Think Again!" Build a Game with AI. The difficulty in game-making with AI has moved, but it has not disappeared. Generation is cheap; judgment about what is worth generating is not.

The pipeline can run itself, and the bar is a human trainer

Autonomy is arriving anyway. Stephan Steinfurt of TNG built a chess YouTube channel run entirely by AI AI chess channel — a creative pipeline that generates and publishes with no human in the loop. What makes the case sharp is the standard he set it against. A major German newspaper, surveying new approaches to combining AI with chess, had written that "it could easily take another 5 years until AI explains chess as well as a human trainer." Steinfurt quotes that line as the claim he set out to challenge, not as his own verdict. The measure the field reaches for is not benchmark accuracy but a person: the human trainer who can explain the game well. It is worth setting beside the Play Magnus loop, which improves its own commentary automatically — a user reports bad output, an agent rewrites a detector and regenerates the explanation — yet still stops to ask an engineer to approve the change from their phone. Full autonomy is technically in reach; the human is kept at the one gate where taste is the product.

Education

The constraint is pedagogy, not capability

Education is where it is most tempting to treat a better model as the answer, and the practitioners are the ones resisting it. Shawn Jansepar, who leads AI and learning at Khan Academy, frames the Khanmigo work not as a model problem but as an organizational one — "Khan Academy's journey to become an AI-first organization" Khanmigo. Scaling a tutor turns out to be about roadmap, product, and learning outcomes across a whole institution, not about which model sits underneath. The binding constraint is pedagogy: what actually helps a student learn, which is a design question no capability jump answers on its own.

Stefania Druga makes the urgency concrete from the multimodal side. She notes that 70% of generative AI users are Generation Z, citing a recent Salesforce study, and argues "education needs a wakeup call" Multimodal Education. Her interest is in combining sound, image, and video into learning activities that build critical and creative thinking — the model as raw material for a designed experience, not as the teacher. In both cases the model is capable enough already; the unsolved work is turning capability into learning, and that is pedagogy's problem, not the lab's.

Creative

Making music is an orchestration problem, not a model

Creative production lands on the same shape the media chapter described. Thor Schaeff of Google DeepMind walked through Gemini's audio stack as a chain of specialized parts, not a single generator Gemini audio stack. One model reads a recording for speaker, emotion, and language in a single structured call; a small set of base voices is steered by a written "director's note"; a native speech-to-speech model handles live conversation without a cascaded transcribe-then-speak pipeline; and a separate music model, Lyra, is invoked as a callable tool by the conversational model to compose a song on request. The product is the composition of these pieces under structured control. Phlo Young's workshop carries the framing in its title — "AI Music Generation, From Prompt to Production" AI Music Generation — the same prompt-to-production arc, treated as a pipeline to be assembled rather than a single button to press. This is the generative-media argument from the model chapter, seen from the domain side: in creative work the craft is not one great model but several specialized ones, composed well.

One lane, many domains

Three subjective domains, one discipline. The chess coach lets an engine calculate and uses the model only to narrate. The Times keeps its puzzles human and sends the AI to the edges. The infinite-game builders find that generation is cheap and judgment is not. Khan Academy and the multimodal educators treat the model as capable material for a designed experience whose real constraint is pedagogy. The music stack composes specialized models under control rather than trusting one to do everything. In every case the model is a component in a system, never the system — kept in the lane it is good at, while something structured, and often someone human, holds the ground the experience stands on.

That is the counterintuitive result of the long tail. Where correctness is fuzzy and the output is the whole point, the answer is not to give the model more room. It is to draw its lane more precisely, and to be clear about what only a person, an engine, or a designer can own. The domains that look least like engineering turn out to demand the most of it.