Bad code an AI writes gets caught by a reviewer before it ever touches production. Every engineering team knows that layer of protection. A bad robot action doesn't get one. It doesn't wait for anyone's sign-off. It just happens, in a house full of glass, pets, and kids.
That line comes from "Towards Universal Post-Training for Robotics," a September 2026 essay by Perry Dong and Chelsea Finn of Stanford. The topic sounds academic: post-training for robots, the fine-tuning stage that comes after the expensive part. The argument inside it hits the exact question every business running AI agents keeps bumping into: how do you make a machine you depend on trustworthy on an ordinary Tuesday, not just impressive at a demo?
Short answer: Robotics is living through the same phase language models went through in the GPT-2 era. Pretrained models already do genuinely complex work, but fluent isn't the same as dependable, and what's missing is post-training. According to the authors, the four-step recipe that pulled LLMs through that phase is a map for robotics, and they're honest about where the map breaks: costly experience, thousand-step horizons, and a physical environment that never repeats itself.
TL;DR
- Robotics sits exactly where LLMs sat in the GPT-2 days: pretraining has scaled beautifully, the models are fluent and capable, and they're still not reliable enough to deploy. Post-training is the missing half.
- The four-step recipe that standardized LLM post-training can't be dropped onto a robot arm as-is. Real-world trials are expensive, tasks chain thousands of control steps, and the same command run twice produces slightly different behavior.
- Early evidence, per the authors: their EXPO-FT system reached 30/30 successes across six complex manipulation tasks using roughly 19 minutes of robot interaction on average. Three things it doesn't solve: a human still runs the loop, long horizons strain the scoring model, and compute time dwarfs the robot's clock.
Robotics is standing where GPT-2 stood
Anyone who used early ChatGPT remembers the feeling. It wrote smoothly, sounded informed, and occasionally made things up with total confidence. The authors compress that era into three adjectives: "fluent, knowledgeable, and completely unreliable." Their example is perfect. Ask GPT-2 how to roast a chicken and it answers with a meaningless loop, then drifts into a Reddit thread it hallucinated.
What does the picture look like today? Physical Intelligence, Generalist, DeepMind, and the other leading robotics labs have all shipped pretrained models that handle genuinely complex tasks: vision-language-action models (VLAs) and world-action models (WAMs), trained on enormous piles of data. The development of frontier robotics, the authors write, "looks a lot like that of language models in the GPT-2 days."
But capable behavior isn't reliable behavior. The authors run a very down-to-earth calculation: a robot that loads the dishwasher correctly 95% of the time will break something every week in a home full of glass, pets, and kids. To run autonomously in a kitchen or a factory, reliability has to sit much further out along the nines, meaning far closer to 99.9% than to 95%. The bar for a robot is higher than the bar for software, because software still has a human reviewer standing between the mistake and the world. A robot's mistake arrives before anyone sees it coming.
Why should a business owner read an essay about robots? Because the same problem shape is already running inside your software. The AI agent that drafts reports, answers customers, and chases invoices is living in its own demo era right now: brilliant in the meeting, uneven in production. And over the next 12 to 18 months, as physical robots move into warehouses, production lines, and commercial kitchens, the people who understood this lesson early will pick vendors who charge them less tuition.
LLMs escaped their GPT-2 era because of one missing piece. Robotics is missing that same piece.
The four-step recipe that saved LLMs from the demo era
The missing piece is post-training: the stage where a model learns from feedback on its own behavior instead of just from existing data. For language models, this stage stopped being an art practiced in a handful of labs. The authors describe what the field converged on as a recipe, a plug-and-play playbook for improving any model after pretraining. Their summary runs in exactly four steps:
- Start from a strong pretrained model.
- Define the environments and the reward, either verifiable checks or learned preference models.
- Run reinforcement-learning optimization with a specific family of algorithms, anchored to the reference model.
- Watch for known pathologies, like reward hacking, where the model games the score instead of doing the work.
The value isn't in any individual step. It's that the recipe turns fine-tuning into a road that already exists. In the authors' words, anyone who wants to fine-tune the latest LLM on a downstream task has "a concrete path to follow, with documented failure modes and sane defaults at every step." That's what made LLM post-training tractable at scale.
Robotics isn't there yet, and the authors say so plainly: RL for frontier robotics models "shows incredible promise in training frontier robotics models, but it is not yet a recipe. It's a craft." A craft means a few people with good intuition, seasoning by feel. To turn the craft into a recipe, they argue, the field needs two things. First, an algorithm designed for the job: stable on models with billions of parameters, and willing to learn from a small enough amount of experience to be practical on hardware, where every attempt costs real time on a real robot. Second, easier to overlook but just as important: a set of standard practices around the algorithm. A default way to define what counts as success. A default way to reset the scene between attempts. A default way for a person to give feedback and turn that feedback into learning.
The trouble shows up the moment you carry the recipe off the screen and bolt it to a robot arm. It jams at step two.
Why the ChatGPT playbook doesn't bolt onto a robot arm
The essay traces large-scale deep RL back to AlphaGo in 2016, which learned from a massive number of self-play games, the way LLM post-training churns through a massive number of parallel text generations. The common ingredient: in both cases, trying things is cheap and checking results is cheap. That's what makes this kind of RL work at scale. Physical robots break both halves of that assumption, and a third one too.
First, samples cost real money. A robot learning to fold laundry in the real world can't try a thousand different actions at each control step, while an LLM drafts a thousand completions without breaking a sweat. The obvious escape hatch, simulation, doesn't rescue you either. Modeling real-world objects accurately, the authors note, can be harder than learning the task itself. So the algorithm has to reuse old data from many update steps ago, exactly the fresh-only discipline classic at-scale RL throws away.
Second, robot tasks are long chains. RL for language has typically been framed as one response to one prompt. A robot task chains together thousands of steps. Picking up a glass looks like one action, but the policy has to output 500 small commands in a row, and the only reward comes at the end. Figuring out which of those 500 commands deserve credit is one of the hardest problems in the field, and the authors give a fair aside: recent agentic LLM tasks are getting longer too, just not with physics attached.
Third, the physical world doesn't repeat itself. Language and Go are deterministic: the same move, the same result. Send a robot the exact same command twice and you can get slightly different behavior, because objects slip, sensors are noisy, the floor is uneven, and there's wind. The agent has to assign credit across variations that compound over the whole horizon.
These pressures push the field toward value-based RL: methods that learn a scoring model, a value function, to spread credit across long horizons. The catch, by the authors' own admission: value-based RL at meaningful scale has been validated far less than the large-scale RL post-training regimes of LLMs. The old classics (DDPG, TD3, SAC) were built for a different generation of models. They assume actions come from a simple Normal distribution, while modern policies need diffusion or flow representations, because a grasp can go for the handle or the base and both are right. And they're fragile at scale, since value methods partly learn by predicting their own future predictions and treating them as ground truth, with small errors compounding over time.
Into that unflattering picture steps the first group to report going a real distance. Not by forcing the recipe to fit, but by redesigning the problem.
EXPO-FT: early evidence, and three things it doesn't solve
The authors' own system is called EXPO-FT, and they tested it on real robots doing tasks frontier pretrained models couldn't complete reliably: routing a string of holiday lights through hooks and plugging it in, sinking a pool ball, inserting a flower into the neck of a wine bottle, flipping an egg.
The clever part is a small design detail. The big model never gets RL'd directly. A lightweight edit policy proposes deliberately small, bounded nudges on the big model's actions. At each step the robot generates a handful of candidate actions from the frontier model, produces a higher-value edited version of each, and uses the value function to pick the best one. Because the edits are kept small, a nudge can't send the robot into anything dangerous, and all the volatility of RL stays confined to the small model. Meanwhile the pretrained base keeps training on the actions that were selected and worked, so improvements the edits discover get absorbed into the big model itself.
During learning, a human supervises the robot and intervenes whenever it starts to go wrong; those interventions feed back into training. That's human-in-the-loop done properly: not babysitting a machine, but teaching it at the exact moment it's about to fail.
The headline numbers, which should be read as self-reported results from the team that built the system:
| Metric | Number (per the authors) | How to read it |
|---|---|---|
| Success across six complex manipulation tasks | 30/30 runs | Reliability at a level people start talking about autonomous deployment, on short tasks |
| Robot interaction time to get there | ~19 minutes on average | Very short against traditional data-collection budgets |
| Compared against | SFT, HG-DAgger, DSRL, HIL-SERL | All self-reported by the same team; no independent replication yet |
Held up under independent testing, the practical meaning is big. According to the authors, a frontier model can be dropped onto tasks like these and post-trained to full reliability in the length of a short meeting. For a physical machine, that's the gap between "nobody dares leave it running alone" and "it works on a factory floor."
Now read the second number carefully, because it's the one people will misquote. Nineteen minutes of robot interaction is not nineteen minutes of post-training. Gradient updates on a model this large dominate wall-clock time, and the authors say closing that gap is what makes post-training a routine at all.
Three things the system doesn't solve, listed by the authors themselves. One: the human is still deep in the loop. Someone defines success, someone resets the scene between attempts, someone intervenes when things go wrong, and scale depends on how much attention each additional robot demands. Waymo appears as the reference point, remote operators watching many vehicles at once. Two: longer horizons make credit assignment harder and strain the value estimates, and the safety property is only as good as those estimates. The team tested the short end of that spectrum. Three: the compute bill, as above.
Underneath the algorithm, the essay leaves five standard-practice questions open with no default answer: how to specify reward (language got RLVR, "check the answer, check the tests," and robotics has no equivalent yet), who resets the scene, how much human feedback to feed in and when, how to tame hyperparameters that value-based RL is notoriously sensitive to, and how to weigh the initial dataset against fresh online experience. The authors call these among the most consequential open problems in the field, and they expect them to be solved the way LLM defaults were solved: by a community converging on shared answers.
That's where the original essay ends. The rest is how we read it for business.
The 5ac view: reliability is a process, not a feature
The most transferable thing in the essay isn't EXPO-FT's numbers. It's the shape of the argument. Robots don't become trustworthy by getting a bigger model. They become trustworthy through the system wrapped around the model: how success gets defined, how volatility gets fenced inside safe limits, how human intervention gets recycled into training data. The authors' closing line says it exactly: pretraining gave robotics models that know how to do almost anything at once, and post-training is how they learn to do things reliably every time.
Reliability isn't a feature you buy bundled with a model. It's a process you build around the model, and no API price list includes it.
That structure is the same problem your AI agents already have. An agent that shines in a demo proves nothing. What proves something is the loop behind it: who defines "done," how errors get measured daily, and whether a mistake flows back as training data or out as damage. In our own G-Company OS operations, the hard part has never been picking the model. The hard part is building that loop, the same way EXPO-FT built theirs: measure, intervene early, feed the feedback back in. The robot essay sharpens the analogy rather than softening it, because a robot doesn't even get the reviewer layer that software still enjoys.
If you're building agent systems for your business, two of our posts go straight at this problem: the agent control plane for Vietnamese SMBs covers the supervision layer when agents run autonomously, and the map of three kinds of agents — Codex, Pi, Hermes is a good place to choose your starting point.
Three posts in this same line go deeper: what a multi-agent OS actually is sets the foundation, the secure agent orchestration layer for Vietnamese SMBs covers the boundary controls that keep volatility fenced in, and token cost control in agentic orchestration takes on the compute bill EXPO-FT has not closed.
Takeaway
The next time a robotics or AI-agent headline crosses your feed, bring three questions from the original essay. One: how many nines does it claim, 95% or 99.9%? Two: who defines "success" here, and what measures it? Three: when it fails, does the failure come back as training data or as your incident report?
One move you can make this week, no robot required: pick a process your company still runs by hand, let an agent try it for two weeks, and measure its real accuracy day by day instead of trusting the demo. If you don't know where to start, Agentic AI Ops for Vietnamese SMBs (currently Vietnamese-only) describes the measure-intervene-learn loop we'd build first.
FAQ: Post-training lessons from robotics for AI agent builders
How is post-training different from pretraining for robots?
Pretraining is what gives a model the ability to do almost anything at once, and that half has scaled beautifully in robotics. Post-training is the stage where a model learns from feedback on its own behavior instead of only from existing data. Language models turned that stage into a shared recipe. For robots, the authors argue, it is still a craft. That is the missing half.
Why can't the LLM post-training recipe drop straight onto a robot?
Because three assumptions behind large-scale reinforcement learning break on a physical machine: trials on a robot are expensive, tasks chain together long horizons with the reward arriving only at the end, and the physical environment does not repeat itself, so the same command can produce slightly different behavior. Simulation does not rescue it either, the authors note: modeling real objects accurately can be harder than learning the task.
What does EXPO-FT prove, and what does it leave unsolved?
According to the authors, EXPO-FT lifts a pretrained model to high reliability on real manipulation tasks, with far less interaction time than traditional data collection. Three things stay open: a human still defines success, resets the scene, and intervenes; longer horizons strain the value estimates behind the safety claim; and compute time still dominates the robot's clock. Every benchmark figure is self-reported by the team that built the system, not independently verified.
What should a small-business owner take from this lesson?
Don't buy reliability as a feature bundled with a model. Pick one process you still run by hand, let an agent try it, and measure real accuracy day by day instead of trusting the demo. Before you scale, answer the same questions: who defines done, how errors get measured daily, and whether a mistake comes back as training data or as damage.
Sources
- Towards Universal Post-Training for Robotics, Perry Dong & Chelsea Finn (09/2026) — every claim, quote, and figure in this post comes from the original essay via a verified research note.
- Author positionality note: Chelsea Finn co-founded Physical Intelligence, the company named in the opening of the original essay and the ecosystem behind the EXPO-FT system the authors built themselves. The source is a position piece, not a peer-reviewed paper, and its benchmark figures are self-reported by the team that built the system, not independently verified. This post keeps "according to the authors" framing at every point where those figures appear.
- This English article was written in English for the 5ac audience, not translated from the Vietnamese version; both follow the same thesis and structure.
Reliability is a process, not a feature. 5ac.vn builds and runs the measure — intervene — learn loop for small-business agent teams every day. See G-Company OS pricing to start with the plan that fits.