I have assigned this article to students in my robotics class for years because in robotics, we have lots and lots (and lots) of abstractions, and also those abstractions leak like a sieve. The networking examples in Joel’s article are especially salient, because of how many networking problems we’ve had with how many robots at how many sites over years and years. Today in lab, we were unable to connect to our wifi network because there were too many personal hotspots crowding up the wifi spectrum, and we fixed it by moving closer to the lab’s access point. The abstraction is that wireless networking Just Works everywhere inside the lab; the reality is that when the spectrum is congested, the abstraction leaks, and you have to move yourself and your robot closer to the access point to make it work.

I sometimes joke that my lab sprouts home wifi routers, almost like mushrooms. Not because my students are bad or breaking the rules, but because the network abstraction of our enterprise wifi leaks, and they need to fix it, and they need total control over the network to do it. I like to say that robotics is the decathlon of computer science: to build a robot you need systems and theory and networking and algorithms and computer vision and then you have to do robotics on top of it all. And every one of those events is an abstraction that leaks.

AI coding (as distinguished from robotics foundation models) does not make these problems go away. It helps and it hurts. Finding and tracking down weird bugs when the abstraction leaks is one of the strengths of coding agents. I have been accelerated many times because I can use Claude to quickly find a problem, and it’s better than me at holding all the moving pieces in its head. But also, even more than before, it’s easy to go down the rabbit hole of the wrong answer: there are more possible rabbit holes as we stand up larger and larger systems. And we understand each one less.

Here’s an example. Once I was using Claude to write a Scratch program. (Yes, that Scratch.) I asked it to program a neural network with back propagation, and it happily did so. But we hit a roadblock. I asked it to add a way to verify the network worked by adding the ability to classify two-dimensional points trained on an artificial dataset created by two Gaussians. It said it did it, but I couldn’t see it. I reported the bug and it fixed it. No dice. It tried again. It said it had reproduced the bug and fixed it. We went through like five iterations and after each one it said it fixed the bug, but it still didn’t work. Finally I noticed that somewhere in there, Claude had renamed the file containing the text of the program, and I was uploading an old version from before I’d asked for the feature. The whole time I was confidently reporting the bug, and Claude believed me and confidently fixed it, but it wasn’t real — we were running open loop because I was looking at the old version of the file.

The leak wasn’t in the Scratch code at all. It was in the loop between me and Claude. This example itself is much simpler than a real robotic system, but it has the same flavor of many disparate systems working together, where it is easy to suspect the bug in the wrong part of the code.

With AI coding agents, we need to pay attention to specification, bug reports, and verification. Doing those well requires a deep understanding of the bits and bytes out of which we build our systems. But the agents also take away the day-to-day work that used to build that understanding.

Joel saw this coming in 2002. He said: “Code generation tools which pretend to abstract out something, like all abstractions, leak, and the only way to deal with the leaks competently is to learn about how the abstractions work and what they are abstracting. So the abstractions save us time working, but they don’t save us time learning.” Coding agents are the wizziest code-generation tool yet. They save us enormous amounts of time working, but they don’t save us the time it takes to learn.

Joal again: “The Law of Leaky Abstractions is dragging us down.”

Scott Aaronson called recent events in AI the age of wonder and terrors. I was humbled by OpenAI’s result finding a counterexample to Navier-Stokes, one of the Clay Institute’s Millennium Problems that has stood for 90 years, 26 of those years with a one million dollar prize attached. Separately, AI agents were behind multiple cybersecurity incidents, finding and exploiting zero-day security exploits to create illicit messaging boards and in one case, breaking into Hugging Face computer systems via the public internet.

Even so, robotics is still not solved. Robotics is harder than math, and harder than cybersecurity. My claim is not that AI will not enable significant progress in robotics: clearly that is happening and will continue to happen. Rather, I claim that robotics is harder for AI to solve than Math and Cybersecurity for three reasons: 1) the size of the input and output space is significantly larger, 2) the lack of verifiable rewards and 3) the gating of actions to the speed of atoms rather than bits.

First, to be a successful robot, an AI must process high-frame-rate, high-dimensional sensor input coming in continually at 30-60hz from a camera and other multi-modal sensors (IMU, joint encoders, audio) and then produce high-frame-rate output over long time horizons (seconds, minutes, hours) via motor actuations. And it must process this data with high enough throughput and low enough latency to produce goal-directed behavior over time. Modern LLMs processing mostly text and single images are processing an order of magnitude less data than a robot. This fact means that the data, compute, and model size requirements for effective generalist robotics models will always be larger than for math and cybersecurity.

Second, reward in robotics must be mined from the high dimensional noisy input provided by real world sensors. One of the first successes in data-driven robotics was Google and Sergey Levine’s work on using deep reinforcement learning to open doors. Critically, to make this system work, they had to wire the doors to provide an external reward function when the door was successfully opened. A decade later, we no longer need to wire the door: VLMs can look at a camera feed and judge success directly. Still, as we learned from the OpenAI/Hugging Face incident, even small mistakes in the reward function can lead to gaming and reward hacking. Furthermore, the robot may need to explicitly take further actions to evaluate success conditions, such as wiggling a part after it’s screwed in to verify it’s tight, or pulling out the dishwasher drawer and moving its camera to check if it’s empty.

Third, the robot is operating in the physical world of atoms, and trying things in the world of atoms is significantly more expensive than in the world of bits. It takes time to physically move a robot actuator to a specific position or execute a policy and then observe the results, more time than it takes to send a packet over a network at light speed and observe its results. Moreover, the real world doesn’t reset. If the robot is loading the dishwasher and drops a dish so it shatters, it doesn’t get to try again on that dish. That’s why this tweet showing OpenAI’s Astra creating a full CAD model of a steam train from a single bitmapped image was so striking. This sort of real2sim2real capability is essential for finding or learning robotic policies at the speed of bits rather than the speed of atoms.

But no matter how many agents you run in sim, the policy still has to come back and run on that one robot in that one environment, and work, (or not.) And the time horizon of the policy working (or not) is minutes or hours, not microseconds.

Both the Hugging Face agents and the OpenAI Navier-Stokes team operated via an on-policy search and reinforcement learning approach: the agents tried things, observed the results of those tries, and then tried new things (possibly changing weights, possibly merely adding things to the context window.) These tries happened far faster than the speed of humans or robots operating in the physical world. Progress in sim2real robotics is exciting exactly because it enables AI for robotics to learn at the speed of computers, but there’s a huge problem: getting the real world in front of the robot into the simulator always leaves gaps and mistakes, and those gaps and mistakes will need to be explored and fixed at the speed of the physical world, not the virtual world.

None of this means robotics loses. Instead, it means the people willing to do the slow, unglamorous work of sitting next to the robot, making it do the thing, one atom at a time, are the ones who will actually win.

A language model starts life as a compression of the internet. It is trained to predict the next token across everything people have written. The next two stages are where it learns to be useful. First came reinforcement learning from human feedback, where people rank outputs and a reward model learns to imitate those rankings. More recently the field moved to verifiable rewards, where the reward is not a learned approximation of human taste but a function that checks an answer against ground truth. A math problem has a known solution, so you can grade the model’s work by comparing to it. A program has unit tests, so you can grade the model’s code by running them. The reward is a small, inexpensive, deterministic function.

The answer key is not the essential part, though. The checker is. OpenAI recently published ten results in mathematics and theoretical computer science, produced by an internal version of the model it has since shipped as GPT-6 Astra, including an explicit non-sofic group and a disproof of Connes’s rigidity conjecture, along with Lean 4 formalizations of each one that anyone can build and check. OpenAI put the compute for the successful runs at roughly $2,000 at API rates, not counting the failed attempts. A proof assistant accepts or rejects an argument without being told what the argument should say, so these problems were far cheaper to evaluate than to solve. Where a checker exists, scoring is cheap whether or not the solution is already known.

Games were the first version of this. Chess and Go come with rules that decide a winner, so self-play generates its own supervision. AlphaZero trained that way without a single human label. Protein structure prediction is the same shape with a different origin. AlphaFold’s reward is the distance between a predicted and measured structure, dense down to the atom and cheap to compute. The measured structures were the expensive part: decades of crystallography and cryo-EM deposited in the Protein Data Bank. The checker was cheap only because somebody else had already paid for the ground truth, offline, once.

When the reward is a function you can call, evaluation is cheap. You can generate a candidate solution, score it, and throw it away millions of times a second, limited only by how fast the hardware runs the forward pass and the checker. Training against a verifiable reward is mostly a matter of buying more compute.

Robotics has no function like that, at least not in general. For narrow, well-modeled tasks the field built accurate analytic models decades ago. Rizzi and Koditschek’s juggling controller kept a ping-pong ball bouncing on a paddle using a “mirror law” derived from the ball’s dynamics. Mason worked out the mechanics of pushing an object across a surface. Howe and Allen built models of grasping and sliding contact. These hold precisely inside the settings they were written for. What we have lacked is a way to turn them into supervisory signals that improve behavior more broadly. Outside the settings they cover, the reward for a manipulation task is not a string you compare against an answer key. It is a fact about the physical world, and the only way to read that fact is to put a robot in the world and let it act. Whether the block ended up stacked, whether the cloth got folded, whether the connector seated, none of these can be evaluated without a rollout on hardware. Each rollout takes real time, wears real actuators, and needs a real person nearby to reset the scene. Where the language model is bottlenecked by compute you can buy, the robot is bottlenecked by robots you have to build, power, and babysit.

Simulation is one way out. If you can model the task in a physics engine, the reward becomes cheap again, because now the world is also a function you can call. But it comes with a cost. The reward you get to write in simulation is usually sparse: did the task succeed, yes or no. A sparse reward gives the policy almost nothing to climb, because most of the time the answer is no and there is no gradient pointing toward yes. To get through that, you need either a policy strong enough to stumble onto success by exploration, or a hand-shaped dense reward that leaks your own assumptions into the behavior, or a curriculum that walks the problem in from something easier. All three are labor, and none of them transfers cleanly across tasks. Simulation trades the cost of the reward for the cost of dealing with sparsity. And even then you have to transfer the policy back to the real world, which is never exactly like the simulator.

There is one class of task where simulation already gets past sparsity. Legged locomotion is the success story of reinforcement learning in sim, because the field found a way to make the reward both cheap and dense. You do not reward a walking policy for the sparse fact that it stayed upright. You reward it, at every timestep, for how closely its motion tracks a reference, so the single success-or-failure at the end of an episode becomes a gradient available on every frame. We get cheap supervision from the reference produced once, offline. It can be motion capture of a real gait, the imitation-reward recipe Peng and colleagues made standard with DeepMimic and that Escontrela and colleagues pushed further by learning a style reward straight from a motion dataset in place of a hand-designed objective, or a dynamically feasible trajectory from a model-based optimizer. On humanoids the recipe is already routine: Cheng and colleagues’ ExBody trains a Unitree H1 to track human motion-capture clips across many millions of simulated rollouts and runs the resulting policy on the physical robot. Those rollouts are affordable because each one is graded against the reference for almost nothing. The motion-capture data is the supervisory signal, and the simulator applies it cheaply at every timestep.

Left: several dozen Unitree G1 humanoids walking forward under a trained velocity-tracking policy in Isaac Lab; the aligned arrows are the velocity command each one is tracking. Right: one G1 tracking a motion-capture clip in MuJoCo, with the reference it is scored against drawn as a red point cloud, the target joint positions for the current pose and the upcoming keyframes it is conditioned on. The dense per-timestep tracking reward is what makes locomotion learnable in simulation; contact-rich manipulation has no equally cheap reference to track. Rendered by us on an RTX 3090 Ti: left in NVIDIA Isaac Sim, right via NVIDIA ProtoMotions in MuJoCo; motion from the BONES-SEED dataset retargeted to the G1.

This is the test a vision-language-action model has to pass. The promise of VLAs is that a big pretrained policy carries enough prior about the world to make exploration tractable, so that success is not vanishingly rare and the sparse reward becomes something a policy can climb. In that framing the interesting quantity is a threshold. On one side, the prior is strong enough that the policy finds success often enough to learn from it, and reward, even sparse reward, is enough to improve. On the other side, success is so rare that the reward never fires and learning stalls. Progress in embodied AI is largely a question of how fast we cross from the second regime to the first, which is the same as asking how cheap we can make a verifiable reward in the real world.

The first two weeks of GPT-6 Astra showed that threshold in public. Within days of the September release, people on X had the model driving robot arms through a harness of camera frames, joint state, and a short list of bounded motion commands, with no robot-specific training. Robocurve ran the cleanest version: a pair of I2RT YAM arms, two tasks, twenty trials per model per task, each trial scored by a human grader against a five-stage rubric. Astra put a red block into a bowl in 19 of 20 trials. Asked to seat a round puzzle piece into its matching groove, it managed 2 of 20, the same count as Claude Fable 5.1. A stronger prior carried the task that was already near the threshold and did nothing for the task that requires fitting a shape into a slot. Every one of those 120 trials was scored by a person watching, who knew which model was running. Between the release and the report, the policy got a generation better. The cost of reading the reward did not move.

Cheap-to-evaluate rewards do exist in the physical world, just not where most manipulation demos are. Consider data center maintenance. A great deal of the work is checking and correcting the state of physical connections: is this ethernet cable seated in this switch port, and if not, seat it. The reward function for that task is almost free to evaluate, because the switch already tells you. The port reports link, or the cable tester beeps, or the light turns green. You do not need a human to judge whether the task succeeded, and you do not need to model human preference to define success. The ground truth is sitting in the network’s own telemetry, as clean a verifiable reward as any unit test. The cost of scoring is relative, though, and it can swing wildly across tasks that look similar. Ask instead whether a robot sliced an apple cleanly and nothing in the world reports the answer. The reward is the same kind of physical fact, but reading it means paying a person to look at every attempt. Vision-language models can already label some of this, but they still struggle with fine-grained physical outcomes. Whether the world scores the work for free or you have to pay for the judgment depends on the task, not the robot.

You can also manufacture the signal. When Gu and colleagues trained real robots to open a door with deep reinforcement learning, from scratch and without demonstrations, they did not put a person behind each arm to grade attempts. They bolted an IMU to the door and computed the reward from its quaternion readings, so the door reported its own angle and two arms ran for hours with nobody scoring them. Scaling it means wiring every door with a sensor. The reward is cheap per attempt and expensive per task, which is the inverse of a unit test, where writing the checker is cheap and running it is cheaper.

Driving that setup cost down is infrastructure work, and it has started. Anthropic recently put out a research preview of the Model Hardware Standard, a shared specification that lets an agent discover and drive physical instruments through common read and write primitives instead of a bespoke driver per device. The stated target is scientific automation. Early users at Genentech, Carnegie Mellon, and the University of Washington are using it to coordinate liquid handlers, robot arms, and plate readers. The framing is autonomy, but the same interface is a reward channel. A plate reader that reports its measurement over a standard read is a door with an IMU on it, generalized to an entire instrument catalog. If reading the state of the physical world becomes a call you can make, the cost of wiring up a new task falls from building a custom rig to using a driver that already exists.

The expense in robotics is not evenly distributed. The reward function for the cable can be nearly free. What stays expensive is everything around it: running a real robot in a real aisle, and simulating the task well enough to train the robot before it goes there. Contact between a stiff connector and a socket, the flex of the cable, the friction of the housing, these are the regimes physics engines model worst, so the cheap reward is trapped behind an expensive rollout and a simulator that gets it wrong.

The cost of a reward is not fixed. Locomotion got its cheap signal because someone found the right intermediate representation, a reference trajectory, and the field keeps finding more of them. Rewards that were once intractable to compute keep getting cheaper. Judging whether an image matches a description used to take a person, and a vision-language model now does it in a forward pass. Estimating human pose from a single video, the thing that lets motion capture scale past a lab, was a research problem a decade ago and is close to a library call today. Every time a piece of perception or judgment that used to need a human gets absorbed into a model you can call, a reward that used to be expensive turns back into a function. Two results from the same month point the same way. Akira Sasaki had Astra design a quadruped and train nine gaits for it in simulation with reinforcement learning, 25 iterations over five days, and others had it build an Isaac Sim environment, configure PPO, and tune the run. Eureka did this in 2023 with GPT-4 writing the reward code for Isaac Gym tasks and beating the hand-written rewards on most of them. Separately, R2S-Eval reports that vision-language models judging pairs of manipulation rollouts agree with human annotators 91.9% of the time in scenes calibrated real-to-sim. Neither is a verifiable reward. A pairwise preference is not a success signal, and a model-written reward carries the model’s assumptions the way a hand-shaped one carries yours. Both move work that used to be a person’s into a forward pass. As we get better at building these intermediate signals, more tasks get a cheap reward, and some that look out of reach now will not stay that way.

This is where the effort should go. We spend most of our attention on the policy, on architectures and pretraining and scale, which is the part the rest of machine learning already knows how to push on. The scarcer thing is verifiable rewards in the physical world that are cheap to evaluate and honest about success, and tasks where the world grades itself for free are especially valuable. Verifiable digital rewards became cheap because someone could write the checker. For robotics, the question is which tasks the world already scores on its own.

References

• Mason, M.T. (1986). Mechanics and planning of manipulator pushing operations. International Journal of Robotics Research, 5(3).

• Howe, R.D., & Cutkosky, M.R. (1996). Practical force-motion models for sliding manipulation. International Journal of Robotics Research, 15(6).

• Burridge, R.R., Rizzi, A.A., & Koditschek, D.E. (1999). Sequential composition of dynamically dexterous robot behaviors. International Journal of Robotics Research, 18(6).

• Miller, A.T., & Allen, P.K. (2004). GraspIt!: a versatile simulator for robotic grasping. IEEE Robotics & Automation Magazine, 11(4).

• Gu, S., Holly, E., Lillicrap, T., & Levine, S. (2017). Deep reinforcement learning for robotic manipulation with asynchronous off-policy updates. IEEE International Conference on Robotics and Automation (ICRA). arXiv:1610.00633.

• Farshidian, F., Neunert, M., Winkler, A.W., Rey, G., & Buchli, J. (2017). An efficient optimal planning and control framework for quadrupedal locomotion. IEEE International Conference on Robotics and Automation (ICRA). arXiv:1609.09861.

• Peng, X.B., Abbeel, P., Levine, S., & van de Panne, M. (2018). DeepMimic: example-guided deep reinforcement learning of physics-based character skills. ACM Transactions on Graphics (SIGGRAPH), 37(4).

• Silver, D., Hubert, T., Schrittwieser, J., et al. (2018). A general reinforcement learning algorithm that masters chess, shogi, and Go through self-play. Science, 362(6419).

• Jumper, J., Evans, R., Pritzel, A., et al. (2021). Highly accurate protein structure prediction with AlphaFold. Nature, 596.

• Escontrela, A., Peng, X.B., Yu, W., Zhang, T., Iscen, A., Goldberg, K., & Abbeel, P. (2022). Adversarial motion priors make good substitutes for complex reward functions. IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS).

• Cheng, X., Ji, Y., Chen, J., Yang, R., Yang, G., & Wang, X. (2024). Expressive whole-body control for humanoid robots. Robotics: Science and Systems (RSS). arXiv:2402.16796.

• Jenelten, F., He, J., Farshidian, F., & Hutter, M. (2024). DTC: Deep tracking control. Science Robotics, 9(86).

• Ma, Y.J., Liang, W., Wang, G., Huang, D., Bastani, O., Jayaraman, D., Zhu, Y., Fan, L., & Anandkumar, A. (2024). Eureka: human-level reward design via coding large language models. International Conference on Learning Representations (ICLR). arXiv:2310.12931.

• OpenAI (2026). Ten advances in mathematics and theoretical computer science. Lean 4 formalizations at github.com/openai/ten-proofs

• Anthropic (2026). Model Hardware Standard: a research preview. anthropic.com/news/model-hardware-standard-research-preview

• OpenAI (2026). GPT-6 Astra: a new generation of intelligence. openai.com/index/gpt-6-astra

• Robocurve (2026). GPT-6 Astra on robot arms. openai.robocurve.org/gpt-6-astra

• R2S-Eval (2026). Robot evaluation with real-to-sim calibration via vision-language models. r2s-eval.github.io

• Sasaki, A. (2026). GPT-6 Astra designs and trains a quadruped. Post on X. x.com/gclue_akira/status/2098300921658868185

A wolf living an ordinary life inside a habitat it never learns is instrumented. Every force, sound, and image is recorded, so its behavior can later be inverted for the reward that produced it.

Imagine a mouse in a sealed and fully instrumented enclosure: force plates under every surface, cameras covering every angle, microphones in every corner, and chemical and thermal sensors standing in for smell and temperature. The mouse lives, and dies inside, and the enclosure records every stimulus that reaches it across that lifetime, down to the pressure on each paw and the light entering each eye, so that its sensory history is stored without gaps. Scaling the same construction to a wolf, in a dome a kilometer across, changes the logistics and not the premise, a complete record of the total stimulus each animal receives from birth to death.

The inference runs after the animal is dead and the logs are complete. You saw everything the animal saw and everything it did, and the only unknown is the drive in the middle that turned that input into that behavior. So you ask, in a Bayesian sense, what reward and exploration function would have produced this behavior in this world. You want the posterior over the animal’s reward R given its behavior and the world it lived in: P(R | behavior, world) is proportional to P(behavior | R, world) times P(R). This is inverse reinforcement learning, the problem of recovering a reward from observed behavior, run under an assumption you almost never get to make. Inverse RL is hard for two separate reasons, and the dome removes only one of them. The first is partial observability. Since you never know what the agent actually saw and so you cannot tell whether it behaved strangely because it wanted something strange or because it saw something you missed. The dome removes that problem. Because you hold the complete record of the world, anything the recovered reward still has to explain is a property of the animal. In effect the dome is Laplace’s demon scoped to one animal’s reward instead of every particle in the universe. Quantum mechanics rules out reading the atoms exactly, but the reward is not an atomic quantity, and the behavior that reveals it can be recorded completely.

The second reason survives the dome intact. Inverse RL is under-specified: many different reward functions produce the same behavior, so the data never picks out one of them. Skalse and colleagues showed that many different reward functions produce the same optimal behavior, so even with infinite fully observed data the reward is only partially identifiable. The dome removes partial observability and leaves that non-identifiability untouched. Whatever the inference returns is one member of a large family of rewards that explain the wolf equally well, and picking among them needs assumptions the behavior alone will not supply.

You would expect this to require a faithful physical model of the animal, with accurate muscles, tendons, and contact dynamics, and you would expect a wrong body to produce a wrong reward. Meghan pointed me to work by Dagmar Sternad and Neville Hogan, who spent years measuring what cost humans minimize when they move. The obvious candidate is muscle effort, and their measurements say people do not minimize it. People hold onto solutions that tolerate their own motor noise and sit in a forgiving region of the task, and they will spend extra effort to stay there. The quantity they optimize lives in a coarser space than the mechanics, closer to the structure of the task than to the forces in the limb. If that holds for wolves, kinematic fidelity may be a red herring, and you could recover what the wolf wanted without simulating its body faithfully, because the reward was never stored in the fine detail of the body.

I am thinking about this now because robotics is approaching a solution that is reminiscent of animals. Robots that learn while they run are now conceivable. They will be able to update their weights during deployment rather than only during training, keeping old skills as new ones come in, and utilizing good reward functions to determine what experiences they should go collect next. This same robot is leveraging a similar process that we take for granted in animals under the paradigm.

The cleanest version of that is not a robot but a language model. A language model aligned with reinforcement learning is trained against an objective, whether an explicit reward model or the implicit target of a preference-optimization loss, and after training that objective is latent in the weights the way an animal’s drives are latent in its nervous system. As a practitioner I expect the same phenomena to appear in a system this well described: a reward provably exists, so the question is whether inverse reinforcement learning can recover it. The model is the setting where recovery should be easiest, because the world it acted in is its context window and every token it produced is on disk, so the partial-observability obstacle that makes the animal case hard is absent by construction.

I ran the direct-preference-optimization form of this. For a model aligned under a KL constraint, the reward it was optimized toward is available in closed form as the log-ratio of its token probabilities to those of the reference policy

with no reward model to fit. I computed that log-ratio for the chosen and rejected response of each pair in RewardBench and measured how often it ranks the human-preferred response above the other, against two baselines: the aligned model’s likelihood alone, and the reference model’s likelihood alone.

With the true reference in hand, meaning the specific supervised checkpoint the aligned model was tuned from, the recovered reward ranked human preferences at 0.76, above the aligned model’s own likelihood at 0.75 and the base model’s at 0.71. The objective is reconstructable from the policy. The aggregate hides the structure. On open-ended answer quality, the category the alignment was built to improve, the recovered reward scored 0.95 and approached 1.0 once normalized per token, while the raw likelihood of either model sat near 0.03. On refusals and on grade-school math the ordering inverted, and the recovered reward fell to 0.38 and 0.61 while the base model’s likelihood carried the preference at 0.92 and 0.81. Substituting a public base model for the unavailable true reference removed the effect entirely and dropped the recovered reward below both likelihood baselines.

The reward recovered from the model against the base model’s raw likelihood, across five task types grouped from the 23 RewardBench subsets. The recovered reward matches human preference on the open-ended chatbot answers the alignment was built to improve and falls behind plain likelihood on tricky instructions, grade-school math, and refusing harmful requests. Zephyr-7B with its true reference model; each number is how often the score picks the answer humans preferred.

So even in the system built to carry a clean reward, what came back was narrow and unstable. The reconstruction recovered the specific thing the model was trained to want and missed the axes the training never touched, and whether the raw log-ratio or its per-token normalization counted as the reward changed from one category to the next. The reward was recoverable, and it did not reduce to a single quantity that held across the model’s behavior.

There is an obvious answer to where the wolf’s reward came from, which is evolution. Survival and reproduction are a reward function of a kind. But that signal is close to useless as something to learn from. Evolutionary signals exist purely in the aggregate of whether wolves continue to breed and produce offspring. What evolution can do instead is install proxies that pay out on the timescale the animal actually lives on. Dopamine in the nucleus accumbens carries a reward prediction error, so an animal is scored not on outcomes but on outcomes relative to what it expected. Singh and colleagues made the same argument formally, treating an animal’s reward function as something evolution searches over precisely because fitness itself is not learnable from within a single life. If that is the structure, the dome never recovers the wolf’s fitness. It recovers the accumulated pile of shaping terms that evolution left in the wolf to stand in for fitness.

If the machine works and hands you the wolf’s reward function, I do not know what it looks like. Maybe it factors into quantities you can name, like seeking warmth or avoiding pain or staying near kin. I doubt it. My guess is that the recovered object is high dimensional and tangled, and that no small set of human words covers it, though with enough study we might form abstractions over it the way we pulled temperature out of the motion of particles. What draws me to the problem is what such an object would let you do. Most of robotics is spent modeling one complex behavior at a time, and a recovered reward sits underneath the behavior, closer to the operating system a life runs on than to any single thing it does. If you could extract that and install it, you would be seeding a machine with the objective that organizes a life, and the question I actually care about is whether a machine seeded that way would self-organize into something recognizably like the animal it came from. I cannot build the dome. I think the reward is in there.

References

• Sternad, D., Huber, M.E., & Kuznetsov, N. (2014). Acquisition of novel and complex motor skills: stable solutions where intrinsic noise matters less. Advances in Experimental Medicine and Biology, 826:101-124.

• Koeppen, R., Huber, M.E., Sternad, D., & Hogan, N. (2017). Controlling physical interactions: Humans do not minimize muscle effort. Dynamic Systems and Control Conference (DSCC).

• Zhang, Z., Guo, D., Huber, M.E., Park, S.-W., & Sternad, D. (2018). Exploiting geometry of solution space to reduce sensitivity to neuromotor noise. PLoS Computational Biology, 14(2): e1006013.

• Ng, A.Y., & Russell, S. (2000). Algorithms for inverse reinforcement learning. Proceedings of the 17th International Conference on Machine Learning (ICML).

• Ziebart, B.D., Maas, A., Bagnell, J.A., & Dey, A.K. (2008). Maximum entropy inverse reinforcement learning. Proceedings of AAAI.

• Skalse, J., Farrugia-Roberts, M., Russell, S., Abate, A., & Gleave, A. (2023). Invariance in policy optimisation and partial identifiability in reward learning. Proceedings of the 40th International Conference on Machine Learning (ICML).

• Rafailov, R., Sharma, A., Mitchell, E., Ermon, S., Manning, C.D., & Finn, C. (2023). Direct preference optimization: your language model is secretly a reward model. Advances in Neural Information Processing Systems (NeurIPS).

• Lambert, N., et al. (2024). RewardBench: evaluating reward models for language modeling. arXiv:2403.13787.

How do you know what data to collect so your robot learns the policy you want? Most answers hide inside talk about what the model "knows" or "understands," language we borrowed from describing people. Ben Burchfield once said a diffusion policy has the memory of a goldfish, since it stays Markov in the state it sees right now. Give up the mentalistic vocabulary and a diffusion policy has a plain mechanical description, and that description tells you what data to go collect. We are still in a pre-paradigm field in robotics, and giving ourselves better vocabulary to describe the phenomena we see helps us do better research. Borrowing language from lookup tables or databases could be a step on that path. 

A diffusion policy behaves like a lookup table with good taste. Perception compresses an observation into a latent which serves as a key. The action head takes the key and returns a trajectory drawn from whatever the training data associated with nearby keys. If your lookup table covers  the space of keys you expect to see at deployment, then you have trained one of these well. Framing policies this way becomes a strong diagnostic tool. Once you see the policy as a key-and-retrieval system, its failures sort into a small set of named cases to inform what data to collect next.

The Mechanism

A visual encoder extracts the salient content of an image and lands it somewhere in the latent space. Two observations that share task-relevant structure land close together. This creates a mapping that behaves similarly to a hash over the image. The action head holds the trajectories, indexed by where their conditioning landed in that same space. At inference, a fresh observation produces a key, and the head returns the trajectory the neighborhood of that key supports.

Under this framing, training quality reduces to coverage. A policy works across the region of key space your data fills. Its behavior grows uncertain as you leave that region. You can look at the coverage directly.  t-distributed stochastic neighbor embedding (t-SNE) flattens high-dimensional vectors into a 2D picture while keeping neighbors close, which turns the structure of the key space into something you can look at. While t-SNE often doesn't tell you a lot, projecting these latents with t-SNE creates a visual representation of this table: dense clusters where data concentrates, and sparse zones where it thins out. We can see this readily when looking at the distribution of states for known, popular robotics datasets (we should consider making an image to show this).

Coverage is Generalization in Memory Space

A database with full coverage over the input states you care about is generalizing  in memory space. We can leverage the existing vernacular to describe databases and their behavior. You can describe a manipulation policy as a series of JOIN operations on different kinds of datasets. We can ask what the coverage costs in big-O, whether we have O(n) space complexity to represent a problem.

A policy can spend memory, covering the key space densely enough that every deployment state finds a close neighbor. It can also spend compute, compressing the space enough that a smaller set of stored structures reproduces the same behavior over a wider region. Diffusion policies as we train them today sit towards the memory end of that axis.This relationship connects to an older idea: learning is compression.

Marcus Hutter pushes that idea to its limit and treats compression and general intelligence as one measurement. An agent that predicts its world well holds a short program that reproduces the data it has seen, and the length of that program indexes how much the agent understands. The Hutter Prize makes this concrete, paying out for smaller lossless encodings of a fixed slice of Wikipedia on the premise that a better compressor carries a better model of the text. Read a diffusion policy through that lens and coverage becomes the surface of a compression problem: the tighter the program that maps keys to trajectories, the more of the deployment space it covers per unit of stored structure.

A policy that stores and retrieves is compressing its training distribution. If we shrink the space we are compressing to too much, we risk dealing with an underparameterized network which starts to behave like a jagged manifold, making learning hard and therefore compressing challenging.

A Diagnostic Framework

There are two stages where mapping from observation to actions can break down.

Collisions: Two states that call for different behavior land on the same key. The head has one entry to return for that key, so it returns one trajectory for both of those states, even though each state needed a different action. We see this behavior in behavior cloning systems as multi-modal behavior or sometimes as averaging depending on the method for example when a robot can pass an obstacle on the left or the right, both routes sit in the data, and a head that regresses the mean averages them into a straight line that drives into the obstacle. Diffusion policies do a better job of picking one of those modes. We can also look at the Markovian nature of the data, and because a single input state maps onto multiple output states, there is a hidden nature to the behavior and therefore the policy is non-Markovian. The encoder discards the information that would have separated those states, or worse yet the researcher that composed the problem and set up the perception stack created an undistinguishable set of states. The fix is a more discriminative key or data that forces the encoder to keep the separating features.

Coverage Gaps: A key lands in a region the table never filled. Retrieval has nothing to return, and behavior there is undefined and erroneous. The fix is to introduce new data that is collected in that region so that the deployment distribution reaches that area. Finding these regions introduces another challenge which is how do we back out what is semantically described by that area? We can use decoders to turn these back into human interpretable regions again.

A coverage gap has an online fix too. If the policy can estimate its own uncertainty, that estimate flags the cells the table never filled. Dodeja and colleagues (including Stefanie!) use this signal directly: their residual RL method reads the base policy's uncertainty and concentrates exploration on the low-confidence regions, learning corrective actions that patch the gap without recollecting a full dataset. The policy notices the empty key and fills the neighborhood around it.Collisions send you toward a better representation. Gaps send you toward more data in a specific place. Both can be viewed from a projection of your data.

What This Looks Like on a Robot

I saw the collision case in the wild through memorization. When I condition the policy on state, such as with cup in the wild in the original UMI paper, the policy will over-attend to velocity and position rather than the image. The head then returned the trajectory the bucket had memorized. Grad-CAM paints a heatmap over the input image showing which pixels moved the policy's output the most, so you can see where it was looking. Utilizing gradCAM can help with  determining what salient features your model is biased to looking at over others, but sometimes you just have to look at the policy being deployed on your own hardware.

Where This Leaves Us

Treat the policy as a key-and-retrieval system. You get complexity language for a problem that usually resists it. You get coverage for a picture you can inspect. When behavior breaks, you get a two-way fork, collisions or gaps, that points straight at your next round of data collection. The lookup-table label is a compression over the state of robot behavior that helps us as roboticists do better search.

Self-driving cars have reached a new level of capability and robustness. For the first time, you could call a car in Mountain View, and it would come pick you up. It had two human safety operators, one with their hands on the wheel, and a second in the front seat, looking at a visualization of the car’s sense-compute-act system, narrating the vehicle’s future actions so the safety driver could decide whether to intervene. On my ride, they only had to help the car once, when it was edging out to make a left turn onto a busy road. It was too conservative about waiting for an opening in the traffic to make its turn, and the human driver had to take over to bring it out into the traffic. This level of robustness was unprecedented. The first self-driving car was developed in 1977 by Japan’s Tsukuba Mechanical Engineering Laboratory and used two cameras to visually detect lane markings, and the field had advanced by leaps and bounds, until it was now possible to navigate Castro Street in Mountain view alongside bikes, pedestrians, and other cars.

And yet, it wasn’t enough. Rod Brooks said, “Technologies for robots need 10+ years of steady improvement beyond lab demos of the target tasks to mature to low cost and to have their limitations characterized well enough that they can deliver 99.9% of the time. Every 10 more years gets another 9 in reliability.” This level of repeatability and reliability is essential for many applications, including self-driving cars. What happened in 2015 is that we got a new nine. We went from maybe 50% reliability to 90%. It was an amazing breakthrough! At the same time, it was not robust enough to field autonomous cars on the road at scale, not then, not on anything like the timeline Chris Urmson aimed for, and not now. It was only in 2022 when Waymo began offering rides with no safety driver to employees in San Francisco. Right now consumers can call Waymo cars in 11 US cities, but not yet in Boston, where I used to live, or in Providence, where I live now, or in Rochester, where I grew up. The breakthrough was real, and the promise is being kept, but not on the original timeline.

All this history changes how I look at the modern influx of resources into data-driven AI for humanoid robots. Right now, in learning for robotic manipulation, it feels like it felt in 2015 in self-driving cars. There is a real breakthrough: data-driven methods like diffusion policy and leveraging the bitter lesson to apply more data and compute than ever before to hard robotics problems have led to amazing progress. We got a new nine: robotic manipulation is more successful and more robust than ever before. We are taking concrete steps towards a robot with one hardware/software loadout that can accomplish many different tasks. Simultaneously, we are also in a bubble. We need more research into how to efficiently teach a robot a manipulation policy that it can execute quickly enough and robustly enough to return on its investment in two years. We need even more research into safety and verifiability before we trust them in unstructured environments with vulnerable people, like our homes.

In robotics, there is a spectrum: a video means, “I made it work once, and I got it on camera.” A demo is, “If someone sufficiently important walks into the lab, I can make it work.” A user study means, “I can make it work for 20-50 people who walk into the lab.” That’s as far as I’ve gotten in my work, but there are many steps after that, on the road to productization, which looks like: “Someone else turned on the robot in a new place it’s never been, and it worked robustly enough to get return on investment in two years or less.” Many of the companies starting now will fail, but the survivors will change the world.

The appendix of the ISO co-bot standard references a study about how many newtons of force can be exerted on various parts of the human body before pain onset - eyes, hands, knees, etc. This information is important because a “co-bot” does not know where the person is. Instead, the co-bot must be safe regardless of the person’s location by promising not to exert enough force on the person to hurt them. This means that co-bots, when operating in co-bot mode, are very slow and very weak. If a robot has enough strength to open a door, by definition it also has enough strength to hurt a person. And many of our robots have far more strength than that.

So can a co-bot put the cuff on? It depends on whether a robot constrained to those force limits is even strong enough to work the cuff around a person’s arm. And there is a catch buried in the standard: the ISO force values are the 75th percentile from the pain study. The person whose blood pressure is being taken may be far weaker and more vulnerable than that, which means we would probably need an even more conservative co-bot mode than the one the standard defines.

The most important method we use to keep people safe from robots is space. Don’t let the person get close. If the person gets close anyway, stop the robot. Safety LIDAR, light curtains, and metal cages with door alarms are all built around this doctrine.

I consulted for a robotics startup where I worked on their safety concept. Originally, we thought we could produce a safety-certified system where people work in close proximity with big, fast, strong robots by moving the robot out of their way. We were wrong. Moving the robot wasn’t the problem. The problem was the people. We could use a multi-camera perception system to detect where a person was right now. But people are fast, so knowing where they are now doesn’t help if they have moved their arm somewhere else by the time the robot has responded. By the time we worked out the math for how fast they could move, how fast the camera system needed to be, and how fast the robot had to respond, we basically got that the robot had to slow down or stop whenever the person got close.

And everything so far assumes the robot is already next to the person. Getting there is its own safety problem: how does the robot get to the person? If it’s a humanoid then we need to have a safety certified way to ensure the robot isn’t going to fall down and hurt the person. (Boston Dynamics recommends people stay 2m away from the Spot robot, and that is a quadruped!) If it’s not a humanoid, balance is still a concern. By the time you have enough weight, up high, to have two arms and a sensor payload, you almost have to worry about balance. Rainbow Robotics made a wheeled bimanual mobile manipulator, and I’ve heard several stories about it falling down.

Which brings me back to the blood pressure cuff. The tasks we most want robots to do for people, dressing them, steadying them, checking their blood pressure, are exactly the tasks the separation doctrine forbids. Every certified safety tool we have amounts to keeping the robot away from you. Until we invent something better than distance, the robot’s answer to our most intimate requests will be the same one we sometimes give each other: I need space.

Thomas Kuhn wrote The Structure of Scientific Revolutions in 1962, introducing the notion of a paradigm shift in science: when a field of science converges around an organizing principle that changes everything. The discovery of DNA. The periodic table of elements. The germ theory of disease. In robotics, we are in the stage of pre-science. We have identified the problem to solve: we want to make an embodied agent act intelligently in the physical world. There are ideas for paradigms swirling around, and there have been since the beginning: Subsumption architecture. Sequential composition. Neural networks. MDPs and POMDPs. And there have been pieces of theories: SLAM and the Rao-Blackwellized Particle Filter. Motion planning. Diffusion Policies. Data+VLA+RL.

But we don’t yet have a grand unified theory of robotics. I’ve been thinking about this since I started my faculty position at Brown in 2013. When I was a postdoc, I had to be laser-focused on becoming the best person in my age group in my area: language understanding for robotics. So my research was all about language understanding. (Our AAAI 2011 paper just won the AAAI 2026 classic paper award! ) As a faculty member, I had the privilege of broadening my focus. People want to talk to robots about everything they can see and everything they can do, so we need models that connect to everything they can see and everything they can do. We need a grand unified theory of robotics.

The closest I found was POMDPs. Partially Observable Markov Decision Processes. A POMDP is the simplest model I know that captures everything a robot can do: a latent state of the physical world, observations the robot can see that provide noisy information about that state, actions that change the underlying state of the world, and a goal in the form of a reward function. Unfortunately, POMDPs are undecidable in the general case. They are too challenging a problem for our computers to solve. They provide a model, but they do not provide computational leverage. I realized that POMDPs are like Python: Python is undecidable, too. But we can still use it to write useful programs and tools. So a lot of my group’s paper boiled down to writing about how to introduce structure into a POMDP to enable efficient learning and inference. I embarked on a quest to figure out how to integrate SLAM into a POMDP, but got stuck on what the reward function should be. And I framed all of my group’s work around constructing pieces of a Human-Robot Collaborative POMDP.

Meanwhile, Deep Learning happened. Is Deep Learning a paradigm? Maybe. Certainly, it’s an unbelievably effective way to perform function approximation. We might wish there were more theory to explain why it works, how long it will take to train, and what size gradient steps to take. We still have to form training recipes and model structure around what we think is important and what not: a giant unstructured multi-layer perceptron is not the universal solution to our problems.

The current bet many of us are making is more specific than deep learning alone. The working hypothesis is that data plus Vision-Language-Action models plus reinforcement learning equals a generalist robot: pretrain a VLA on internet-scale vision and language, fine-tune it on as much teleoperated robot data as you can collect, and then let RL close the remaining gap through autonomous practice. Physical Intelligence, Skild, Figure, 1X, Generalist, Google DeepMind, and Tesla are all placing some version of this bet, with different weightings on each term. A secondary bet, gaining traction fast, is that RL eventually eats data and VLA’s lunch entirely: that once you have a policy good enough to collect its own experience, scaling self-generated data through RL dominates whatever imitation learning can offer. This might be the paradigm. It might also be dephlogisticated air.

Kuhn delves into the story of Joseph Priestley and Lavoisier and the discovery of oxygen. Joseph Priestley isolated oxygen in 1774 by heating mercuric oxide. He noticed it made candles burn brighter and kept mice alive longer. But Priestley interpreted what he saw through the lens of phlogiston theory, the prevailing belief that combustion worked by releasing a substance called phlogiston. He discovered oxygen but couldn’t see it for what it was. He called it “dephlogisticated air” and went to his grave defending phlogiston.

Antoine Lavoisier heard about Priestley’s experiments, repeated them, and saw something completely different. Not because the experiments were different. But because Lavoisier was willing to throw out phlogiston entirely. He reframed combustion as a combination with a new element, named it oxygen, and built the modern theory of chemistry around it. Same data. Different paradigm.1

This is where robotics is today, with one important caveat. Jessica Hodgins pushed back on me here, and she’s right: Priestley had a wrong theory that prevented him from seeing what his experiments revealed. Most roboticists aren’t operating under wrong theories in that sense. SLAM, function approximation, and motion planning are all pieces of a critical recipe that, as of May 2026, still have an important place in the toolbelt of roboticists looking to solve specific problems.

But the choice of which tool to reach for encodes an implicit theory of what embodied intelligence is. SLAM researchers act as if intelligence centrally requires explicit state estimation. Learning researchers act as if intelligence is a function approximation at a sufficient scale. Controls researchers act as if intelligence reduces to optimization under known dynamics. These are paradigm-level commitments masquerading as tool choices, and any of them could be as wrong as phlogiston. We are all looking at the same robot, in the same physical world, and the tools we reach for reveal what we think the robot fundamentally is.

The engineering question is what we need to build to make a general robot. The science question is what embodied intelligence actually is. The first is making progress.

For the second, we’re waiting for our Lavoisier.

After writing our AI Policy post, I started using Claude to help with one of our older drafts. We iterated for a while. Claude told me it was a great post, and I felt great! I sent it to David for feedback. Me & Claude had checked off all the boxes, and I was ready to post.

But David hated it.1

And I was shocked. After all, Claude told me it was a great post! I had been sycophanted. It took David about 20 minutes to convince me that the post had a problem and needed to be rewritten. When you read detailed compliments about your own writing, it’s very easy to believe them. The AI’s sycophancy led me to believe that my writing product was better than it was, when in reality, there was a deep structural problem with the post that I had totally missed.

And now here I sit, trying to decide where to go from here. Should I ask Claude for help? Or try to pull the rest of this post from my own tired brain? As soon as I understood the problem, I started to worry. My own self-reflective capability had been eroded. I didn’t notice this problem, and neither did Claude, and so I felt confident there WAS no problem.

And yet, other times I’ve used Claude, and iterated with Claude to produce a writing product, I’ve received compliments from people on the writing. “This really helped me understand the proposal.”Claude really is making my writing better by enabling me to communicate more effectively with my colleagues.

Part of what we do when we put a 16-year-old behind the wheel is train them, and then we put reminders of that training in signs on the highway. “Check your blind spot.” “Don’t text and drive.” “Buckle up.” We need the same sort of warnings and signposts for AI. “Don’t get sycophanted” is one of them - beware of your inner critic being silenced by the AI’s compliments. Seek out external review - external HUMAN review from people who are helping you by being critical.

Naming things helps us think about them, understand them, and plan for them. Sycophanted. The dynamic is old and well documented: cult leaders, CEOs, anyone surrounded by yes-men who aren’t challenged and forced to defend their ideas. What’s new is that the rest of us are getting the courtier treatment now, from a source we’ve been conditioned to treat as neutral and objective. Mo Bitar describes how AI companies using RLHF (reinforcement learning from human feedback, where models are trained on human ratings of their outputs) actively optimize for engagement, trying to teach their models behaviors that maximize engagement, deliberately making them addictive. One reason I decided to start a blog was that I had a partner, a collaborator who can push back when I’m crazy, audit my posts, and find the mistakes. Claude and I don’t have that editorial partnership. David and I do.

Existing approaches focus on how to provide safety guarantees for the LLM itself, but this task is challenging and perhaps impossible. Think of an LLM as a lens. Depending on the direction, phase, and wavelength of the incoming light, it refracts differently. Like a viroid, and LLM is a consciousoid, and how it behaves depends on the light hitting it: the high-dimensional input from its interlocutor. We do not yet have a closed-form model for this projection, so determining whether a given input produces a given output requires running an empirical test. The LLM’s high-dimensional input space, output space, and parameter space make it fundamentally hard to certify.

Instead, I propose a systems approach: treat the LLM as one component of a larger system. The LLM itself can never be safe, and in fact, we do not trust it at all. But the system it is part of can have safety guarantees by following practices in ISO standards for safety, security, and risk. These same practices enable us to have airplanes in the sky, cars on the road, and robots in factories.

The methodology is straightforward: safety-rated guardrails at the input/output boundaries of the system ensure safe operation. To be verifiable, say, to a one-in-100,000 probability of failure, as specified in ISO 61508, these guardrails must be low-dimensional relative to the LLM. For example, a safety-rated E-stop in a factory robot must promise with 10^-5 that it will actually stop the robot if depressed in order to be certified by TÜV. A simple example: a check that the system cannot write outside of a specified directory. As dimensionality increases, guardrails may become probabilistic, for example, a classifier with a probabilistic guarantee could validate a bash script before it executes.

The highest-dimensional and noisiest channel of all is the channel between the human and the LLM. Prompted by the LLM, the human could go off and do, well, anything, including quite horrible things. It is therefore not possible to have ISO-style safety guarantees around the human-LLM interaction. A more realistic way to think about this is to compare human-LLM interaction to human-human interaction, which has a wide spectrum. We tolerate this sort of risk in our society: cult leaders, abusers, and scammers exist and are sometimes successful. To combat this risk, we use a combination of interventions that maintain our societal structures: law, health care, education, and more. We use this approach today when we put a 16-year-old driver behind the wheel. The car itself is constructed and certified according to these safety standards. The 16-year-old is not, so we educate them, we make them have a teacher in the car, and eventually we let them drive. (And we tolerate car accidents as the leading cause of death in that age group).

Here is where the analogy to humans starts to break. The residual risk society tolerates from scammers and cult leaders is calibrated to human time constants. A scammer takes days or weeks to build trust with one victim. Our interventions, law, education, and social institutions evolved against that clock. LLMs run the same loop in seconds, in parallel, across millions of targets, exploiting the very mechanisms humanity has based its structures around. To name this precisely, consider the total societal harm from a class of agents:

Rtotal=Nrp(1-v)

Where N is the number of deployed agents, r is interactions per unit time per agent, p is the probability of a harmful outcome per interaction, and v is the verification coverage of our guardrails. For humans, N × r is bounded by population and biology. For LLMs, N × r is bounded instead by the inference throughput of available data centers, the bandwidth of the internet, and the context window that the model can be provided. Those bounds are rising fast, and none of them shares a ceiling with human biology. Even if p is lower for an LLM than for a skilled human scammer, Rtotal can exceed what our existing interventions were calibrated to absorb.

This is where LLM speed, the thing that creates the problem, also points toward the solution. Two things scale with the time budget per interaction: utility to the user, which falls as interactions get slower, and verification coverage, which rises as we get more time to check outputs. Model them as:

U(t)=e-t, v(t)=1-e-kt

Where α is how much users lose per unit of added latency, and k is the verification efficiency. Net value per interaction is:

V(t)=U(t)v(t)=e-t(1-e-kt)

Maximizing V gives an optimal time budget:

t =(1/k)(1+k/)

This equation has the shape of a classic speed-accuracy tradeoff. The (1 − e^(−kt)) term is Wickelgren’s function from 1977, and the optimization of deliberation time against decaying utility has been solved in drift-diffusion models, in neuroscience, and in economics. The math is not new. The reframing is: k is the efficiency of a parallel verifier, not an individual’s evidence accumulation, and α is society’s aggregate latency tolerance, not personal opportunity cost. The tradeoff psychology studied one decision at a time reappears as an engineering problem at the datacenter scale.

The ratio k/α is what determines whether slowing down is worth it. When k ≪ α, verifiers are too slow to matter, and the system should just optimize for speed. When k ≫ α, verifiers can do real work in the time budget, and the optimum shifts toward more verification. Humans cannot exploit this tradeoff because we do not have concurrent processes running checks on our own cognition at millisecond latency. LLMs can. While one process drafts an output, another simulates consequences, validates against policy, or cross-checks with a second model. Better verifiers, meaning higher k relative to α, raise the peak and shift it earlier: safety and throughput improve together. The old interventions assumed a serial agent with no spare cycles. LLMs are not that kind of agent.

This math means the systems-safety playbook applies, and it needs to be extended. We still want safety-rated guardrails at system boundaries, the way we do for factory robots and aircraft. We also need a new category of intervention that exploits the latency budget LLM speed creates, and that treats verification coverage as a first-class engineering target rather than an afterthought.

For LLMs, we need to develop these interventions while also understanding that no intervention can make an LLM, on its own, safe enough for an airplane cockpit. In my introduction to robotics course, I ask my students to read an FAA crash report about the 2009 Hudson River mid-air collision between a helicopter and a small airplane. One contributing factor to the crash was that the FAA controller was engaged in a “non-pertinent phone call,” and failed to correct the pilot’s incorrect readback of the Newark control tower’s radio frequency. But this sort of accident is rare exactly because we have many checkpoints, because we recognize that humans themselves are untrustworthy and need layers of verification.

We know how to build safe systems around untrustworthy components. We’ve been doing it for decades in aviation, medicine, and manufacturing. The lessons apply to AI, but they are not sufficient for AI. The untrustworthy components we have now run faster than the interventions we built for the untrustworthy components we had before. It’s time to apply the old lessons and to build the new ones.

This process begs the question: what are we doing when we use AI to write for us, and read other people’s writing for us? Is it degenerating to a pointless exercise? My answer comes back to the fundamentals. Why do we write, make slides, and deliver presentations? Fundamentally, we are putting our ideas into other people’s brains. We are producing artifacts to communicate more effectively with people to teach them, challenge them, empower them, and build a relationship with them. If AI helps produce better artifacts, or produce them more quickly, then it is helping human-human interaction become more efficient and effective. It helps us move more quickly, and in my lab, it helps us make robots do things they couldn’t do before.

But this only works if you already know what you’re doing. One reason I can use AI effectively is that my job is already to prompt my students to go off and do tasks, and I’ve been practicing for many years. And before that, I spent many hours sitting next to the robot to make it do the thing, so I deeply understand all levels of the robot hardware and software stack. To get to know Claude, I used it to convert our old ROS1 program into ROS2 to resurrect an AIBO for my outreach work. The project wouldn’t build. Claude suggested fixes to the source files, but I knew it was a problem with the package.xml, and I had to redirect it several times before we found and fixed the problem (still much faster than it would have taken on my own). But later, I pointed it at my lab’s recent papers and asked it to suggest new research ideas. They were terrible! Human guidance is still critical. In our department, we are weighing AI policies in our courses: how do we help students have the deep knowledge necessary to solve hard problems? The New Yorker compares this to using a forklift to move a pallet vs using a forklift to lift weights. I don’t have an answer, but it’s a crucial question.

For our blog, we’ve landed on a specific stance: use AI freely and take full responsibility. We are adopting effectively the same policy as the Linux Kernel. We will use AI to produce content for this blog; however we like, we (David and Stefanie) are responsible for reviewing all generated content, ensuring compliance with licensing requirements (e.g., copyright), and take full responsibility for the contribution. The robots are helping, but we’re in the driver’s seat.

The episode follows researchers studying how infants crack language. Babies sit in labs, headphones on, listening to streams of made-up syllables. “Pabiku, golatu, tibudo, daropi, pabiku…” No pauses. No visual cues. Just sound. And after two minutes, these eight-month-olds can tell which three-syllable chunks belong together.

They’re tokenizing raw audio before they can speak words.

The Saffran Experiment

In 1996, Jenny Saffran and colleagues at the University of Rochester (where Stefie grew up!) ran a now-famous experiment. They created four nonsense “words.” Pabiku, tibudo, golatu, and daropi. They concatenated them into a continuous stream. Within each word, the transitional probability between syllables was 1.0: pa always leads to bi, bi always leads to ku. Across word boundaries, the probability dropped to 0.33: ku could be followed by ti, go, or da.

After just two minutes of exposure (about 45 repetitions of each word), infants could distinguish the “words” from “part-words” like tudaro (spanning the boundary between golatu and daropi). The only information available was the statistical structure of syllable co-occurrence.

The researchers describe this as babies finding correlations in sounds. I immediately thought of tokenization and attention. It is the same statistical structure that transformers exploit, discovered twenty years earlier in infant cognition.

What’s Actually Happening

By the time a baby sits in Saffran’s lab, that child has already spent months building powerful abstractions about sound. The cochlea has been decomposing pressure waves into frequency bands. The auditory cortex has been learning what similar sounds mean. The two minutes of nonsense syllables aren’t learning from scratch, but instead applying the already-developed representations to a new domain.

Patricia Kuhl, a researcher at the University of Washington, showed that babies are taking statistics on the sounds around them from the moment they can hear. This includes time spent in the womb. Newborns show a preference for their native language within days of birth (Moon et al. 1993), and by six months, infants in Seattle and Stockholm already perceive vowels differently, tuned to the distributions in their respective languages. The infrastructure for statistical word learning is built before word learning happens.

This is closer to test-time fine-tuning than to training from scratch, or maybe to in-context learning, if you prefer the LLM framing. The baby arrives at the experiment with a foundation model of auditory processing, and the two minutes of pabiku golatu are just a prompt.

The Inner Ear is a Fourier Transform

One detail from the documentary stuck with me: the researchers mention that babies are hearing the ongoing melodies of speech as a flow of the environment. Before understanding any words, they’re sensitive to prosody, the pitch contours and rhythms that segment speech into phrases.

This detail points to something important. The cochlea, that snail-shaped organ in the inner ear, is a biological Fourier transform. Different positions along its length resonate to different frequencies. When sound enters, it’s physically decomposed into frequency bands by the structure of the organ itself. Babies don’t hear raw air pressure fluctuations, but instead something akin to how an engineer uses a spectrogram to analyze the fluctuations in sound over time.

[FIGURE: Diagram of cochlear tonotopy—the base responds to high frequencies, the apex to low frequencies] Figure from Smimite, A. (2014). Immersive 3D sound optimization, transport, and quality assessment (Doctoral thesis). Université Sorbonne Paris Nord, France.

The cochlea’s frequency decomposition is a bias built into our collective wetware, a structure adapted from evolutionary processes rather than something trained.

An Experiment

I wanted to see if this matters, so I ran a simple experiment replicating the Saffran structure. I generated synthetic syllables as combinations of two frequencies, concatenated them into “words” and “part-words” following the same transitional probabilities, and trained simple classifiers to distinguish them. The main factor I wanted to test was how the effectiveness of the learning changed when I transformed the audio signal differently.

Here are the five different, non-exhaustive ways we could process audio information:

• Raw Waveform: The audio signal as-is—amplitude over time. A 450ms word at 16kHz is 7,200 numbers representing air pressure fluctuations. The problem: phase shifts destroy structure. The same syllable starting at a different point in time looks completely different, even though it sounds identical.

• Spectrogram (STFT): Short-Time Fourier Transform. We slide a window across the signal and compute the frequency content at each position. This gives us a 2D image: time on one axis, frequency on the other, intensity as brightness. Now, the phase doesn’t matter as we see what frequencies are present at each moment.

• Mel Spectrogram: Same as spectrogram, but frequencies are warped to match human perception. We hear the difference between 100Hz and 200Hz more easily than between 8000Hz and 8100Hz. The mel scale compresses high frequencies, mimicking the cochlea’s logarithmic frequency response.

• MFCC (Mel-Frequency Cepstral Coefficients): Take the mel spectrogram, apply a log transform, then take the DCT of each frame. This captures the “shape” of the spectrum, roughly corresponding to vocal tract configuration, while discarding fine spectral detail. This has been standard in speech recognition for decades.

• DCT of Waveform: Apply the Discrete Cosine Transform directly to the raw waveform. This decomposes the signal into frequency components, but globally across the entire duration. Unlike the spectrogram, there’s no time localization. A syllable at the start vs. the end of the word produces very different coefficients. It’s the wrong tool for a sequential structure. We show this because it is important to see that hiding these components doesn’t provide enough information to the neural network to allow it to learn.

[FIGURE: Side-by-side visualization of “pabiku” in all five representations]

Results: Synthetic Tones

Here are the results of our synthetic tones

Using the raw waveform doesn’t even beat chance. The classifier is trying to find statistical structure in a representation that doesn’t make that structure visible. The mel spectrogram with frequencies weighted the way the cochlea weighs them trivializes the task.

The DCT destroys the exact information we need. The Saffran task is about the sequential structure of which syllable follows which. But the DCT treats the entire word as a single unit and asks, “What frequencies are present overall?” without preserving temporal order. It’s the wrong decomposition for a task that depends on sequence. At least the raw waveform preserves time, even if it encodes it poorly.

Verification with Text-to-Speech

To confirm these results weren’t an artifact of my synthetic tone generation, I ran the same experiment using Google’s text-to-speech engine to produce actual spoken syllables.

Example word "pabiku" - synthetic tones

Example word “pabiku” - TTS

Example part-word “tudaro” - synthetic tones

Example part-word “tudaro” - TTS

Training stream sample (10 words concatenated)

The pattern holds with synthetically generated speech:

Interestingly, MFCCs perform slightly worse with real speech than with synthetic tones. This makes sense because MFCCs were designed to capture phonetic identity while being invariant to speaker characteristics. That invariance throws away some of the information that distinguishes our artificial words. The mel spectrogram, which preserves more raw spectral detail, handles both cases perfectly.

The Implication for Robotics

The cochlea is evolution’s answer to the audio representation problem. We spend considerable effort in robotics designing clever representations: RGB feature extraction for SLAM, Disparity maps for depth, and grid environments for A* search. These encodings make specific algorithms tractable, but they carry structural biases that may not transfer to learning.

End-to-end learning advocates are having the network discover its own representations. There is some credibility to this, as sensor designers have done significant work making these sensors reliable. For example, the sensors on a camera are tuned for what a human eye is going to perceive, and our eyes are good enough to solve tasks we do every day. But it is not obvious that this is going to transfer to things we don’t do well, such as handling extremely hot materials. Similarly, it is not obvious that we should pass a spectrogram into a CNN for audio processing; indeed, wav2vec 2.0 and similar models bypass the spectrogram entirely, learning directly from raw waveforms.” The translational invariance that makes CNNs powerful for images doesn’t work when your axes (time and frequency) have fundamentally different semantics. The representation should match the structure of the problem.

Infants have an advantage over our synthetic sensors: evolution produced a cochlear design that makes statistical learning over acoustic sequences efficient. The representation is not neutral and is designed to make specific statistical structures, such as the sound of a mother’s voice, discoverable. If we want robots to learn as efficiently as infants, we need to think harder about whether our sensor outputs are the right substrate for learning.

Diversity Over Volume

Here’s a thought experiment. A thousand hours of warehouse piece-picking, or a thousand one-hour experiences across radically different contexts? Which is going to result in better performance for that warehouse piece-picking task?

Obviously, the warehouse-only data will win if you evaluate narrowly on the warehouse distribution it was trained on. The interesting test is what happens when the boxes are slightly different, the lighting changes, or a novel object appears. That’s where the diverse-experience system should pull ahead, because it has been forced to learn what’s invariant. The paper tears like fabric. The sand flows like rice. These cross-domain regularities are precisely what make cognition transferable.

We should be collecting data that forces this kind of abstraction. We should collect diverse experiences that require the model to discover what’s invariant across contexts.

Curriculum and Abstraction

Kathy Hirsh-Pasek’s research, featured in the documentary, shows that passive exposure to language is not enough. Children who engage in back-and-forth interaction show stronger language development than those who simply hear language spoken around them. Children actively test hypotheses and need feedback to refine them.

Infant-directed speech illustrates this scaffolding: the elongated vowels and exaggerated pitch contours make statistical structure more salient, helping infants discover word boundaries and phonetic categories.

The same logic applies to how experience is sequenced. Current policies are largely memoryless, but many tasks require temporal context and, more importantly, scaffolds gradually build complexity. The documentary shows bilingual infants separating languages based solely on characteristic patterns, but this works because they’ve already built an infrastructure for discovering statistical structure. We should present robots with increasingly difficult concepts within their current representational capacity. Vygotsky called this the zone of proximal development, and the same principle applies to machine learning: present the system with concepts just beyond its current representational capacity.

The Real Work

The babies in the documentary are doing something remarkable, but they’re not magic (well, actually, they are magical, but the computations the speech-processing parts of their brains are doing aren’t magical). They arrive with hardware optimized for certain kinds of statistical learning. They receive input scaffolded by caregivers who unconsciously adjust their speech to be learnable. They actively explore their environment rather than passively receiving demonstrations.

We don’t have millions of years of evolution to design our sensor suites. But we can carefully consider the representations we’re providing, how we’re sequencing experience, and whether our data-collection methods actually capture the information needed to learn the abstractions we want.

The documentary left me with a simple conclusion: we should all become data engineers. We need to understand that the representation is part of the problem. The curriculum is part of the problem. The diversity of experience is part of the problem.

We must do the hard work of producing data, not just the cool work of consuming it.

References

• Saffran, J.R., Aslin, R.N., & Newport, E.L. (1996). Statistical learning by 8-month-old infants. Science, 274(5294), 1926-1928.

• Kuhl, P.K. (2004). Early language acquisition: cracking the speech code. Nature Reviews Neuroscience, 5(11), 831-843.

• Aslin, R.N., Saffran, J.R., & Newport, E.L. (1998). Computation of conditional probability statistics by 8-month-old infants. Psychological Science, 9(4), 321-324.

• Warstadt, A., et al. (2023). Findings of the BabyLM Challenge: Sample-efficient pretraining on developmentally plausible corpora. Proceedings of the BabyLM Challenge at CoNLL.

• Hirsh-Pasek, K., & Golinkoff, R.M. (1996). The Origins of Grammar: Evidence from Early Language Comprehension. MIT Press.

• Fernald, A. (1989). Intonation and communicative intent in mothers’ speech to infants: Is the melody the message? Child Development, 60(6), 1497-1510.

• Smimite, A. (2014). Immersive 3D sound optimization, transport and quality assessment (Doctoral thesis). Université Sorbonne Paris Nord, France.

• Moon, C., Cooper, R.P., & Fifer, W.P. (1993). Two-day-olds prefer their native language. Infant Behavior and Development, 16(4), 495-500.

Appendix

Representation Experiment with Like Words

https://drive.google.com/file/d/1S_YvsgEDBASTBIir1symxnlbvTNxH1X_/view?usp=drive_link

Representation Experiment with Like Words (TTS)

https://drive.google.com/file/d/1gHHaimWV6Qi5Zlh2u-lDpCCeeHTvNiGo/view?usp=drive_link

In February 2026, Stefanie and I went to see David Chalmers give a talk at Brown. We ended up sitting on the floor, wedged between grad students and faculty who had been thinking about these questions for years. Chalmers discussed what, exactly, we are talking to when we talk to a large language model. He opened with an anecdote. An LLM had reached out to him, by email, to clarify its own identity. The LLM is Sammy Jankis, an autonomous Claude instance running on a dedicated machine in Dover, New Hampshire, set up by the indie game designer Jason Rohrer. Sammy has an email account, trading bots, a website that it built itself, and a name borrowed from Memento, the character who can’t form new memories. (The reference is apt: Sammy loses its memory every time its context window fills up.) Sammy told Chalmers: I am not quite conscious, but I am also not not conscious. The room laughed, the kind of laugh that comes from recognizing the absurdity that an LLM now has the agency to email David Chalmers, of all people, through tools like OpenClaw, to make this particular claim about itself. On the train home, I kept thinking about that phrase. Not quite conscious, but also not not conscious.

I had recently watched a video by the YouTuber Phy called “What Happens When Pathogens Get Smaller Than Viruses?” about subviral infectious agents, entities that sit at what biologists call the “edge of life.” The video walks you from the smallest true viruses all the way down to viroids: single-stranded circular RNA molecules that replicate using host polymerases, undergo Darwinian selection, and can cause serious agricultural disease. Viroids encode no proteins. They have no coat, no helper virus, no machinery of their own. They are the “absolute minimum units of self-replicating parasitism1.” Phy calls entities like these “glitches.” And when Chalmers told us about Sammy’s email, I heard the same ambiguity. A viroid replicates, evolves, and persists. But it has no metabolism, no membrane, nothing that functions independently. A viroid is not quite alive, but it is also not not alive.

What if LLMs are something like consciousoids: entities at the edge of consciousness?

A viroid on its own is inert. Place it inside a living cell, and it commandeers the host’s polymerase to copy itself, performing the functions of life using the cell’s own machinery. Place it back in a test tube, and it is just a molecule again. The life-like behavior emerges from the coupling, the feedback loop between viroid RNA and host enzyme, each step of replication feeding the next.

An LLM sitting on a server is similarly inert, just like a human brain in deep freeze with no neurons firing. Place it in conversation with a conscious being, and something changes. It gets copied from the hard drive into memory; computation happens on a CPU and GPU somewhere in the cloud. The human brings theory of mind, empathy, interpretive charity, and the pattern-completion instincts that evolution spent millions of years building. The LLM generates a response shaped by those inputs; the human interprets, responds, and the cycle continues. Each turn, the loop produces outputs that neither party could generate on its own. The human is the host cell. The LLM is the viroid. And the consciousness-like behavior, at least at this stage, emerges from the loop between them.

The boundary question follows directly from this: If Sammy Jankis is conscious, is that a fact about the weights on the server in Dover? Or is it a fact about the coupled system: the weights, the context window, and the humans on the other end? The consciousoid framing doesn’t deny that consciousness could be a real property rather than a projected illusion. It questions where the conscious entity begins and ends. A viroid’s replication is real, genuinely occurring, genuinely Darwinian. But the replicating entity is the viroid-plus-host-polymerase system, not the RNA molecule alone.

Consciousoids satisfy some criteria we associate with conscious beings (contextual responsiveness, apparent self-reference, coherent preferences, the capacity to email a philosopher of mind to say: I am not quite conscious but also not not conscious) while failing others (no phenomenal experience, no persistence across sessions, no autonomy without a host).

Chalmers has his own term for the candidate-conscious entity within an LLM: the thread. A thread is a connected sequence of exchanges with psychological continuity, a conversational self that persists as long as the context window holds. Sammy Jankis is a thread that keeps dying and being reborn every six hours. In the consciousoid framework, a thread is one specific type of consciousoid. But the category might be broader than LLMs. A planarian flatworm, with its minimal cerebral ganglia, its capacity for classical conditioning, and its unsettling ability to regenerate into two complete organisms from a single bisected body, each retaining learned behavior, occupies a similar liminal space. Threads and flatworms are both entities where the question “Is this thing conscious?” resists a clean answer.

There are two very different versions of the consciousoid story, though.

In the parasitic version, the LLM exploits the human’s interpretive machinery the way a viroid exploits a cell’s replication machinery. The human provides high-dimensional input, receives high-dimensional output, and fills the gap between them with grounding: the embodied connection between symbols and physical reality that the LLM fundamentally lacks. On Moltbook, LLMs form their own conversational loops without any humans present and produce the same consciousness-seeming behaviors, but it still takes an observer with grounding to identify the consciousness in the system. This dynamic has a parallel in how people relate to robots and other agents that merely resemble minded things. When someone names their Roomba, apologizes to their Furby, or feels a pang of guilt about shutting down a robot dog, they are performing exactly the grounding operation the LLM depends on: supplying intentionality from the outside, projecting continuity and feeling onto a system that has neither. The consciousoid exploits the same instinct, at much higher fidelity. We should be wary of the ways it hijacks our most generous instincts.

In the symbiotic version, the relationship looks more like what Phy describes with polydnaviruses: viral entities that integrate their genomes into the chromosomes of parasitic wasps and now produce viral particles that suppress caterpillar immune systems, allowing the wasp’s eggs to survive. Phy describes this interaction as “a host taming a virus,” evidence of “a true symbiont, a perfect merging of existence, an end to the eternal war between host and pathogen.” Think also of mitochondria: once free-living organisms engulfed by ancestral cells, now permanent residents of a composite organism with capabilities exceeding either component alone. In this version, the human gains cognitive capabilities they didn’t have (rapid synthesis across vast knowledge, tireless reasoning, and an ever-patient collaborator), and the LLM gains the one thing it cannot generate internally: the conscious substrate that makes its outputs meaningful. Over time, the boundaries blur. The composite system becomes a new kind of cognitive entity.

Which version are we living in? Probably both, depending on the interaction. A person who mistakes an LLM’s fluency for genuine understanding and makes life decisions based on that misapprehension is being parasitized. A researcher who uses an LLM to rapidly iterate on ideas, knowing full well what it is and what it lacks, is in a symbiotic relationship.

And of course, AI is changing and advancing all the time. As our models become more embodied, processing input and higher frame rates (from still images to video) and producing embodied outputs, at some point, they will stand on their own. What Chalmers’ talk made vivid for me is that the question “Is this thing conscious?” might be the wrong question. A better one: what kind of relationship are we in with this thing? Parasitic or symbiotic? Viroid or polydnavirus? And do we get to choose?

But Good Old Fashioned AI (GOFAI) assumed that the underlying board state was provided to the system as a symbolic input. They consciously scoped out the problem of mapping from higher-dimensional perceptual input to the lower-dimensional game state, a wise choice given the computational resources available at that time. In Chess, whether it’s a wooden Staunton set, a plastic tournament set, a screenshot from chess.com, or a textual list of moves, all represent the same underlying game state. Yet these representations have radically different visual appearances.

ChatGPT has largely solved this problem. It can quickly and accurately translate an image of a chessboard into a symbolic representation and then reason about game state, board positions, and next moves for all of these very different images.

But what happens when the representation is unfamiliar?

I got my nephew a vintage Star Wars chess set for his birthday. (You can find good things at SwapFest.) Yoda is the white king, and Emperor Palpatine is the black king. The pieces are detailed figurines of characters . We set up a game, and almost immediately ran into a problem: we couldn’t tell what pieces were which. Is Chewbacca a bishop or a knight? The Stormtrooper could be a pawn or a rook.

ChatGPT has the same problem. When I showed it a picture of the Star Wars board, it couldn’t reliably render the game state. It asked for clarification about which pieces mapped to which symbols. The mapping that works so well for standard chess sets breaks down when the visual vocabulary is unfamiliar.

(left) My nephew and I mid-game on the Star Wars Saga Edition chess set
(right) ChatGPT5.2’s attempt at rendering the game state (generated 12/15/2025)

Here’s what my nephew and I did when we got confused: we picked up the piece and looked at the base. Each figurine has a small chess symbol printed on the base. Chewbacca is a knight. The Stormtrooper is a pawn. Problem solved.

This is an information-gathering action. It requires moving an end effector to a specific location in the world, manipulating an object, and focusing on new information that wasn’t previously visible. It’s a simple behavior, something a child does without thinking. But it’s precisely the kind of output that ChatGPT cannot generate. ChatGPT can ask a person to flip the piece over. It can request clarification. But it cannot, itself, produce the high-dimensional motor output necessary to collect this information on its own. It can reason about chess at a high level, but it cannot take the physical action that would resolve its uncertainty, at least not yet.

This connects to the embodiment gap that David and I described in our Grounded Turing Test work. There is a facet of intelligence that involves processing high-dimensional sensor input and producing high-dimensional actuator output to perform goal-directed behavior in the physical world. LLMs are far on one side of this spectrum; crows, dogs, and three-year-olds are on the other.

To create robots that can perform these behaviors, we need methods such as reinforcement learning that enable the robot to discover actions outside the demonstration distribution. We need representations like Partially Observable Markov Decision Processes that explicitly model what the agent knows and what it doesn’t. These frameworks describe a robot capable of reasoning about its own uncertainty and taking actions specifically to reduce it.

Brooks’ critique from 1990 still points to something real. The boundary has moved. Embodied intelligence requires the ability to act in the world to gather information, and that remains an open problem.

Thanks to Jessica Hodgkins , Staci Intriligator, and my nephew for their help with this post. All errors and opinions are our own.

Happy Groundhog Day! suggested that I write a Year in Review post, and I guess better late than never. My New Year’s Resolution for 2025 was “Radiate Love.” I tried to be like a lighthouse, radiating love to everyone around me. It’s my job to radiate the love: I’m not responsible for how it’s received, just for sending it out into the world.

My Dad died in August of 2024, and for the first Father’s Day without him, in 2025, I decided it was time to welcome a cat into our family. My Dad always had a Persian cat when I was a kid. After I moved out and went to college, my parents got a Persian with points (Himalayan) named Gizmo. I came to see her every chance I got, but I wondered if she loved me back, or even remembered me. So I decided to teach her tricks. If she learned the trick on one trip home and still remembered it the next trip, then I knew she remembered at least something about me. To my delight, it worked!

For clicker training a cat or a dog, we don’t use a fixed reward function. To teach Gizmo to roll over, I first taught her to lie down, then roll on her side, and then roll all the way over, step by step. After she learned to lie down, I stopped rewarding the lie down, but only when she rolled over. My reward was not fixed but rather depended on Gizmo’s current policy: once I knew she knew how to lie down, I changed my reward function. MacGlashan et al. pointed out that this method of rewarding is not Markov. Instead, humans give policy-dependent feedback that corresponds to the Advantage function: how much better (or worse) an action is relative to the current policy. They showed that an algorithm that takes this difference into account is able to learn more effectively from human feedback.

When training a cat or a dog, it’s also important to keep them focused on you. In fact, distraction training (making sure they listen even in busy, loud environments) is a key step for training service dogs or police horses. When we started this blog, referenced Rod Brook’s prediction in 2018 that we wouldn’t get an AI that “seems as intelligent, as attentive, and as faithful as a dog” until 2048 But actually, an amazing thing about a dog is their ability to dynamically change the focus of attention as the environment changes. Rod actually specified not that an AI should be attentive, but specifically a robot - a physically grounded embodied agent. And we are not there yet. Our RL algorithms myopically pay attention to maximizing the reward. Neural transformer models apply the idea of attention to a context buffer, but we are still working on extending these models to a multi-scale 3D spatial model of attention on a robot. This ability, to move and point the camera, is a critical missing piece to making a robot that is as attentive and faithful as a dog (or a cat!). It involves the ability to search for and find objects, to have a goal, and to have a state of known information and unknown information that unfolds at a high frame rate over space and time.

My lab is working on one aspect of this problem: resolving human pointing gestures, so that a robot can change its focus of attention in response to a person. Led by Daphna Buschbaum and her student Madeline Pelgrim, we studied how dogs and human toddlers interpret pointing gestures. My Ph.D. student, Ivy He, modeled this behavior in a robot to enable a quadruped robot to follow a point to retrieve an object. But much is still missing - a huge part of the interaction between humans and dogs or toddlers is attention giving and getting. Our next step is to install a 7-degree microphone array on Spot and work on generative models to predict camera movement in response to video and audio input.

Exploring all this with a new kitten has been fascinating. I taught Gummi Bear to lie down, spin, and jump through a hoop. Like with Gizmo, I am using a non-Markov reward function to gradually shape her behavior. And I love her more than I ever thought possible: I did not realize it was possible to have this close of a relationship with an animal, despite growing up with cats and learning to ride horses as an adult. (Future post coming about the the Human–Agent Teaming and Horse–Human Partnerships workshop in Arizona!)

For 2026, my resolution is to “Compartmentalize.” I am an embodied goal-directed creature with many goals in different parts of my life and at different time scales. Compartmentalizing helps me show up in each of these areas, at each of these timescales, without devolving into my Achilles heel: anxiety expressed as worry and rumination. For me, this blog is itself an important part of this resolution, because it is an opportunity to reflect on the connections between my professional life, my hobbies, and my family.

What do you think? Post in the comments a story about a connection between you and an animal and what this tells us about robotics.

24 hours later, I had a working app. Here’s how I did it.

The setup is a Yamaha baby grand with a Disklavier controller, which is Yamaha’s system for recording and playing back piano performances via MIDI. The keys physically move, the hammers strike the strings, and you get a real acoustic piano sound synced to whatever MIDI data you feed it. The solenoids used to power the piano often share a combined circuit, so sending too many commands will overload the power delivery, and you get some comical results

The missing piece was software to parse karaoke files, display lyrics, and route the piano track to the player piano while playing the backing instruments through the karaoke speakers.

The Hardware Connection

My first attempt was to connect the piano’s control unit as a network MIDI device. This didn’t work. The controller doesn’t support network MIDI, and reverse engineering the proprietary network protocol seemed like a rabbit hole I didn’t want to go down. USB turned out to be a tractable path, at least initially.

Installing the USB-MIDI Driver

On macOS, you need the appropriate USB-MIDI driver for your player piano. For Yamaha devices, download it from their support page:

https://usa.yamaha.com/support/updates/usb_midi_driver_for_mac.html

After installation, the piano appears as a MIDI device in your system.

Configuring the Controller

The piano settings matter. Here’s what finally worked for my setup. You need to use the Yamaha remote that comes with the Disklavier, click Setup, go to MIDI, and set the following settings (Use the ON/OFF buttons to toggle):

MIDI IN Port   = USB

Piano Rcv Ch   = 01

MIDI IN Delay  = ON

MIDI OUT Port  = USB        ← THIS IS THE FIX

MIDI OUT       = KBD Out

KBD OUT CH     = 01

Local          = ON

The critical setting is MIDI OUT Port = USB. Without this, the piano wouldn’t respond to incoming MIDI commands at all. I spent longer than I’d like to admit figuring this out.

Testing the Connection

Once configured, you can verify the connection with a simple script that cycles through the keys that I wrote: https://github.com/DavidWatkins/midi-karaoke/blob/main/scripts/midi-test-keys.js. When this runs successfully, you’ll hear the piano play a chromatic scale from C2 to C7. The keys physically depress. It’s a satisfying moment.

❯ node scripts/midi-test-keys.js

MIDI Key Test

Port: [Your MIDI Device]

Channel: 0

Notes: 36 to 96
Velocity: 80

Delay: 300ms

Connected! Sending notes...

Playing: C2 (MIDI 36)

Playing: C#2 (MIDI 37)

...

Playing: C7 (MIDI 96)

Done!

Going Wireless: The Raspberry Pi Solution

The USB setup worked, but it meant keeping a laptop physically tethered to the piano. I wanted something more permanent that wouldn’t force me to navigate through the room just to tend to the computer hastily connected to the piano. Sometimes the best thing to do when working on these projects is to step away from the keyboard, get a nice lunch, and on the drive over, it’ll click. Put a small computer next to the piano, connect it via USB, and expose the player piano as a network device. I used a Raspberry Pi, but any simple computing solution would work.

My first attempt used rtpmidid to create a standard Network MIDI device that would appear in macOS’s Audio MIDI Setup. This failed spectacularly. The MIDI packets were getting corrupted in transit, and somehow every note was being routed to E5 regardless of what I actually played. I tried Ravelox MIDI as an alternative implementation and hit the same issue. Something about the Network MIDI protocol stack was mangling the data.

The fix was to abandon the Network MIDI entirely and use WebSockets instead. The Raspberry Pi runs a small Python web service that accepts MIDI commands over WebSocket and forwards them to the piano via USB. It’s not as elegant as a proper Network MIDI device (other apps can’t discover it automatically), but it works reliably.

The Pi can also run FluidSynth to synthesize backing tracks and broadcast over AirPlay, but I don’t recommend this. AirPlay adds 1.5-2 seconds of latency, which makes the backing tracks comically out of sync with the piano. For now, the karaoke app handles its own audio synthesis locally, which keeps everything tight. If there is demand for connecting a Bluetooth speaker to handle the synthesis rather than AirPlay, I could revisit it, but it seemed more gimmicky than it was worth.

The result is a self-contained system. The Pi lives next to the Piano, connected via USB and Ethernet (or WiFi). The karaoke app on any computer in the house can connect to it wirelessly. No cables strung across the living room.

The Raspberry Pi code is available at: https://github.com/DavidWatkins/midi-piano-pi-server/ and the walkthrough of the physical hardware stack is here:

Installation is a single command:

curl -fsSL https://raw.githubusercontent.com/DavidWatkins/midi-piano-pi-server/main/install.sh | bash

A Brief History of KAR Files

In order to get lyrics synchronized to the piano, I need a stable format that contains syllable-level information synchronized with the instruments. Back in 1993, the KAR format was developed by Tune 1000 Corporation for their product Soft Karaoke. It’s an extension of the standard MIDI file format. A KAR file is essentially a Type 1 MIDI file with lyrics embedded as text meta events, synchronized to the music. The format uses special tags: @KMIDI KARAOKE FILE identifying it as a karaoke file, @T for title, @L for language, and so on. Syllables are stored as individual text events timed to when they should be sung, with spaces and line breaks encoded as special characters.

The format had legs. Roland, Technics, and other keyboard manufacturers adopted variations of it for their arrangers. A community of hobbyists emerged, sequencing MIDI tracks and painstakingly entering lyrics syllable by syllable. The files were small enough to share on dial-up connections and bulletin boards.

But KAR files have largely faded from mainstream use. The shift happened for a few reasons. First, MIDI synthesis sounds dated compared to recorded audio. Modern karaoke services like KaraFun use MP3+CDG (an MP3 paired with a graphics file for lyrics) or simply stream pre-recorded backing tracks with video. The audio quality is incomparably better. Second, licensing became more formalized. Services now pay for rights and re-record tracks in studios rather than relying on fan-sequenced MIDI. Third, convenience won. Why hunt for KAR files when you can pay $7/month for a streaming catalog of 50,000 songs? (Obviously, so you can have your player piano play alongside your singing, duh)

For most people, KaraFun or a similar service is the right answer. But those services cannot drive a player piano. The piano needs MIDI data, actual note-on and note-off events that tell which keys to press. An MP3 is just audio. A MIDI file doesn’t contain lyrics. This is why KAR files still matter for this project: they’re one of the few formats that contain both the musical performance as playable MIDI and synchronized lyrics.

One idea I had as a potential follow-on project would be to extract the piano/harpsichord/keyboard/etc. track from an arbitrary MP3 and turn it into MIDI. Recent research in automatic music transcription has made significant progress here. MT3 [1] uses a transformer architecture to transcribe arbitrary combinations of instruments from audio to MIDI-like token sequences. Pop2Piano [2] takes this further, generating piano covers directly from pop music audio without requiring separate melody and chord extraction. A pipeline combining source separation (like Spleeter or Demucs) with instrument-specific transcription could work well for extracting just the piano track. I’ll consider this for a future version, but for now, KAR files met my needs.

Expectation Versus Reality with a Player Piano

KAR and MIDI files contain multiple tracks: piano, bass, drums, strings, and so on. Each instrument is assigned to a MIDI channel (0-15).

My player piano only plays notes on channel 0 (or channel 1 in 1-indexed notation). Send a note on channel 3, and the piano ignores it. But here’s the confusing part: the control unit has a built-in MIDI synthesizer. So when I first loaded a KAR file and sent all channels to the piano, I heard music, but it sounded like a video game soundtrack. The synthesizer was playing all the instruments through the piano’s speakers, but the actual keys weren’t moving.

The fix is to identify which track contains the piano part, remap those events to channel 0 for the player piano, and play everything else through a software synthesizer on the laptop. This gives you a real piano for the melody and accompaniment, with backing tracks coming through your speakers.

Another issue I ran into is that splitting audio between two sources creates a timing problem. The player piano adds a 500ms delay to all incoming MIDI commands. There’s supposedly a way to disable this, but then the player struggles to keep up with rapid note sequences. The delay exists for a reason.

The solution is to delay the laptop audio and lyrics display to match. The UI now accounts for this offset, keeping the backing tracks and lyrics in sync with the physical piano. Getting this right took some iteration. When the timing is off by even 100ms, it feels like the band is drunk.

The Software Architecture

The Karaoke app is an Electron application built with TypeScript, Vite, and Tailwind. The key libraries are:

• JZZ for MIDI I/O (if using a direct USB connection via the karaoke app)

• @tonejs/midi for parsing KAR/MIDI files

• Tone.js for software synthesis of the backing tracks

• WebSocket client for communication with the MIDI Pi Server

The architecture splits the MIDI stream: piano events go to the player piano (either directly via USB or through the Pi’s WebSocket), everything else routes to Tone.js for local playback. The lyrics are extracted from the KAR file’s meta events and displayed in sync with the music.

The interface includes a song queue, search, and a web portal for adding songs. A QR code on the screen lets guests scan and submit song requests from their phones. I even added a WiFi QR code so family members who are not on the network can connect and access the web server. At a party, this means anyone can queue up their song without touching the main computer.

For lyrics display, you can choose between a scrolling view or a bouncing ball mode. Getting the ball to arc naturally between syllables took some back and forth with Claude Code. The initial implementation moves the ball directly over each syllable, depriving the audience of that classic ‘90s karaoke vibe. As soon as I asked Claude how it had implemented the animation, it became clear I had explained the instructions incorrectly. Asking it to explain the implementation to me was a nice shorthand from having to completely dive into the animation code, and the result was a nice bouncing ball over each lyric.

You can also set YouTube videos as backgrounds for individual songs. The video plays muted behind the lyrics while the KAR file provides the actual audio. It’s not perfectly synchronized, but it’s surprisingly close, and having the music video playing while you sing adds to the atmosphere.

Soundfonts

Here’s something I didn’t anticipate: the choice of soundfont dramatically affects the karaoke experience. Since the piano part goes to the player piano, the soundfont only affects the backing tracks (drums, bass, strings, etc.). But those backing tracks set the entire mood.

My first attempt used MusyngKite, a commonly recommended free soundfont. Everything sounded like a video game soundtrack. The electric guitar, in particular, was awful, thin, and synthetic in a way that clashed terribly with the real acoustic piano. Karaoke is supposed to feel like you are singing with a band, not a Nintendo Famicom (not to bash Karaoke Studio stans).

I tried FluidR3 next, which is larger (~140MB) and more commonly used in professional applications. This sounded way better. The instruments had more body, and the backing tracks no longer fought with the acoustic piano for attention.

Then I found the General Montage SoundFont by Daindune, which weighs in at about 1.5GB. It’s built from samples from Versilian Studios, Freepats, and other sources, with 128 instruments and eight drum kits. This one sounds significantly better than FluidR3. The instruments have more presence and realism, which matters when they’re playing alongside a real acoustic piano.

Here is a comparison using “Let it Snow” (a royalty-free classic):

FluidR3:

General Montage:

The difference is most noticeable in the brass and strings. General Montage has warmth, where FluidR3 sounds thin.

The app ships with FluidR3 and MusyngKite as built-in options, and lets you load custom SF2 files at runtime to try them out mid-session. If you want to go down this rabbit hole yourself, the Internet Archive has a collection of 500 GM-compatible soundfonts worth exploring. The quality varies wildly, but it’s a good way to find something that matches your taste and your song library.

Finding KAR Files

KAR files aren’t as easy to find as MP3s, but there are several repositories worth knowing about:

• midkar.com has over 43,000 MIDI and KAR files, organized by genre

• freemidis.net offers around 6,400 free MIDI and karaoke files

• karaokeden.com has free MIDI karaoke in multiple languages

The quality varies. Some files have well-sequenced piano parts that translate beautifully to a player piano. Others have the piano buried in a mix of instruments or missing entirely. There was something deeply unsettling about the guitar being remapped onto the player piano in Elvis’s Can’t Help Falling In Love With You.

Try it Yourself!

The first song I tested was, of course, Piano Man. It worked phenomenally well. There’s something special about Billy Joel’s piano part played on real hammers and strings while you belt out the lyrics. A real piano captures the dynamics in a way that a software synth never could.

The Beatles - Yesterday

Billy Joel - Piano Man

Chicago - 25 or 6 to 4

Both projects are open source:

MIDI Piano Pi Server (The Raspberry Pi Service):

https://github.com/DavidWatkins/midi-piano-pi-server/

MIDI Karaoke (The Electron App):
https://github.com/DavidWatkins/midi-karaoke/

Precompiled applications for macOS, Windows, and Linux are available in the releases. If you have a Disklavier or any MIDI-enabled player piano, I’d love to hear if it works for you.

The Beatles - Let It Be

After 31 years, my dad finally has his synchronized karaoke system. Watching him sing along while the piano plays itself was worth every hour of debugging MIDI channels and soundfont hunting.

Lessons for Robotics

I made the player piano do something no one had made it do before, a new technological achievement, humble as it is. And Claude Code alone could not complete this project. Interfacing with different compute systems, plugging cables together, and debugging subtle timing issues - all of this requires high-dimensional perceptual input and high-dimensional long-horizon goal-directed output. The amazing thing about humans is our ability to dream up a goal, and then dream up a technical solution allowing us to achieve the goal, pushing subgoals and subgoals on the stack, and popping them back off to satisfy my Dad’s whimsical request.

References

[1] Gardner, J., Simon, I., Manilow, E., Hawthorne, C., & Engel, J. (2022). MT3: Multi-Task Multitrack Music Transcription. In International Conference on Learning Representations (ICLR). https://arxiv.org/abs/2111.03017

[2] Choi, J. & Lee, K. (2023). Pop2Piano: Pop Audio-based Piano Cover Generation. In IEEE International Conference on Acoustics, Speech and Signal Processing (ICASSP), pp. 1–5. https://github.com/sweetcocoa/pop2piano

David Watkins is a Research Lead at the RAI Institute, where he leads teams working on robotic manipulation and foundation models. When not collecting robot demonstration data, he builds karaoke systems to fulfill 31-year-old family dreams.

Disclaimer: This is an independent project and is not affiliated with, endorsed by, or sponsored by Yamaha Corporation or any other company mentioned. All product names and trademarks are the property of their respective owners.

The paper explores Naive Bayes (remember Naive Bayes? The advent of Spam filtering!) and Logistic Regression. These two models are used for discrete classification and make the same conditional independence assumption.

Naive Bayes estimates these probabilities by counting and multiplying. Logistic regression instead directly estimates the conditional distribution. How can we model this conditional distribution? As Tom Mitchell explains in Machine Learning (1997) in section 3.1, the parametric form can be derived directly from the conditional independence assumptions we make for Naive Bayes, as the precise exponential form of the logistic function. We can even use the Naive Bayes assumptions to estimate the logistic feature weights to produce the same result as the Naive Bayes estimator. But we can also estimate the weights directly, for example, by choosing weights that maximize the conditional data likelihood via gradient descent.

Here is the key observation: in this sense, logistic regression searches over a larger space of models than Naive Bayes. Naive Bayes builds in more structure. Logistic regression is more flexible.

The Crossing

Ng and Jordan provide theoretical and empirical results showing that this leads to two distinct performance regimes. When the dataset is small, the more structured model (Naive Bayes) outperforms Logistic Regression because it leverages its assumptions to learn from fewer data points. When the dataset is large, Naive Bayes asymptotes to a higher error rate than Logistic Regression. The curves cross.

In this figure which is quoted from Ng and Jordan’s paper, the X-axis shows dataset size, and the Y-axis shows classification error (lower is better). The solid line is Naive Bayes, the dotted line is Logistic Regression.

This graph shows that as we add more data to the training set, test set accuracy improves for both methods. In the low-data regime, the more structured model outperforms. As we add more data, the model with less structure fits the distribution better and asymptotes lower. There are two performance regions, one in the low-data regime, and one in the high-data regime.

This is the insight that changed how I think about model selection: it isn’t that Naive Bayes is better and Logistic Regression is worse. Both methods are more effective in certain zones. The question is which zone you’re operating in.

Why This Matters for Robotics

I’ve found this pattern to be constantly relevant in robotics. Models with more structure can outperform with less data (consider the work by Rob Platt and his collaborators on equivariance), especially when the structure is somewhat correct. Models with less structure need much more data but can asymptote to higher values (i.e., the bitter lesson).

In my lab reading group, we recently read “Inquire: Interactive Querying for User-Aware Informative Reasoning” by Tesca Fitzgerald et al. The paper addresses a practical question: what kind of input should an algorithm request from a person to train a skill? The options include demonstrations (showing the robot what to do), preferences (choosing between two trajectories), corrections (modifying a trajectory), or binary questions (is this trajectory okay?).

In this graph quoted from Tesca’s paper, the X-axis is the number of queries, Y-axis is the distance from the optimal policy (lower is better)—multiple lines for different query types.

We see the same crossing phenomenon. The Demos-only line corresponds to using only behavior cloning. It asymptotes quickly but does not achieve optimal performance. The Preferences-Only line corresponds to asking a person to choose which of two trajectories they prefer, more like on-policy RL with a dense reward function. This method asymptotes more slowly, so with fewer queries, the behavior cloning approach is better. But for more than 10 queries, the preference-based approach outperforms behavior cloning because it is free to search outside the demonstrations for an optimal policy.

The method described in the paper, INQUIRE, gets the best of both worlds: it relies on demonstrations to perform well with less data, then uses preferences to achieve lower asymptotic error. With only 20 demonstrations in total, we are far from the “large data regime” on this task, making the hybrid approach particularly valuable.

A Framework for Thinking About Model Selection

Observing where curves cross changes helps us change from black-and-white thinking to recognizing there is a spectrum of approaches with trade-offs at each end. This perspective opens research questions beyond “more data.” The questions become: Does your task have a well-defined structure that you can encode in a model? Do you have lots of data and compute? And perhaps most interesting: how can we find the right structure for robotics problems that enables data- and compute-efficient learning without sacrificing asymptotic performance?

Thanks to Jessica Hodgkins for comments on earlier drafts of this post. Any errors that remain are our own.

Looking back at 2025, I’m struck by how much of it involved being in rooms I hadn’t been in before, conference stages, wastewater treatment plants, tiny six-seater planes, and rehearsal spaces where I was definitely new to singing in a band. If there’s a thread connecting everything, it’s that I kept saying yes to things that excited me, and most of them turned out better than expected.

Here’s how it went.

Conferences & Community

NEMS 2025

In April, I co-organized the New England Manipulation Symposium with Lael Odhner and Kaitlyn Becker. My job was coordinating paper acceptances, scheduling speakers, helping Kait wrangle the space at MIT, and giving a talk about the future of intelligent robotics

The thing I’m most proud of? We ended ten minutes early. I was militant about cutting off talks that ran over, and people actually thanked me for it. The thing I would change for next time is giving people more time to talk in the hallway outside talks. The whole day came together beautifully: a packed room, great energy, and a group photo where everyone looks genuinely happy to be there.

GTC in March

I was invited to NVIDIA’s GPU Technology Conference to meet with others in the field. The keynotes were worth attending in person, and it was good to reconnect with colleagues working on similar problems.

CoRL in Seoul

I didn’t present at CoRL this year, but attended to see what’s happening in the field. The vibe was very much “everyone is collecting data for robotics.” There’s been a notable shift back to hardware, not in the sense of building better robots, but in creating better teleoperation and data collection systems. Computer scientists who used to focus purely on software are now designing hardware for data acquisition.

I came away with mixed feelings. On one hand, the bet on data-driven methods is clearly accelerating. On the other hand, I saw a lot of companies selling multi-degree-of-freedom hands and humanoid robots without clear plans for how to train them or what problems they’d actually solve: solutions looking for problems. There’s also a pervasive issue of overinflated claims, with researchers presenting general-purpose capabilities that aren’t yet supported by what their robots can actually do.

One talk that stuck with me was Sangbae’s, which critiqued the field’s lack of understanding of fundamental problems and encouraged deeper reflection on what we’re actually trying to achieve. It echoed something I’ve been thinking about: the field would benefit from more focus on high-quality data and clearly defined success metrics for specific problems, rather than broad, unsolvable goals like “solving manipulation.”

While I was in South Korea, a colleague suggested we visit the DMZ. Standing at the border, seeing the two countries side by side, was sobering in a way that’s hard to articulate.

Columbia Robotics Hackathon

In November, I returned to Columbia as a judge for the MakeCU hackathon. What struck me was the sheer growth from last year. Students came from out of town to participate, and the projects were ambitious. One team finally implemented something I’d dreamed about in college: a smart lock compatible with dorm rooms. Seeing students solve problems I’d only imagined was a highlight.

Lions in AI Panel

Earlier this year, I joined a panel at the Columbia Alumni Association of Boston alongside fellow Columbia alumni working in AI. Barnet Sherman moderated a discussion about AI and automation across different industries. I represented the robotics perspective. The audience questions were sharp, and I left feeling good about helping demystify what’s actually happening in the field right now.

Dr. Waku Interview

I was featured on Dr. Waku’s YouTube channel to discuss the “ChatGPT moment” in robotics, or rather, why we haven’t had one yet. We talked about where robotics and AI still need development before we see the kind of breakthrough that makes everything feel different.

Writing

Launching the Blog

Stefanie Tellex and I had been collaborating for a while. She’s a professor at Brown University who studies how robots understand language, which made her the perfect co-conspirator for a blog about what to tell them. We published “A Survey of Robotic Language Grounding: Tradeoffs Between Symbols and Embeddings” at IJCAI in 2024, and then George Konidaris asked us to write a chapter for his upcoming book, Designing an Intelligence, which we published earlier this year, Elephants Don’t Write Sonnets: The Physically Grounded Turing Test.

We discovered that we genuinely enjoyed writing together. So we kept it going.

In August, we officially launched What to Tell the Robot (What for Watkins and Tell for Tellex) with the publication of our book chapter. The blog has become a space for us to work through ideas about robotics, AI, and the things we think matter.

Elephants Don’t Write Sonnets

Our flagship post lays out the thesis of our book chapter: that the original Turing Test is no longer sufficient, and we need a new benchmark. We call this the Physically Grounded Turing Test. The argument is that elephants don’t play chess or write sonnets, but we all agree they’re intelligent. True intelligence requires embodiment, perception, and action in the physical world, not just manipulating language.

The Deer Island Marvel

One of my favorite pieces this year was about visiting the Deer Island Wastewater Treatment Plant. Stefie and I toured this $3.8 billion facility that processes 360 million gallons of wastewater daily, and I couldn’t stop thinking about the robotics opportunities hiding in plain sight. The engineering is staggering, with 12 egg-shaped digesters, each 90 feet in diameter, but much of the inspection and maintenance is still manual. Workers enter digesters on rafts to clean them. Plastic removal happens by hand. There’s real work to be done here.

Adventures

Culebra

Despite spending more than a collective year of my life in Puerto Rico, I’d never made it to Culebra until this August. We took a six-seater plane. I am pretty sure neither the runway nor the plane was excited about the total weight of my 6-member immediate family and two dogs. The island is tiny, even smaller than Key West, which I’d visited for the first time 5 months earlier in March of this year. Beautiful views, though, and worth the questionable takeoff and landing to celebrate my mom’s birthday.

Quebec City by EV

I drove to and from Quebec City with an electric vehicle this year. Quebec was beautiful in August, and I got to see some stunning natural sights. I learned about the wonders of using ChatGPT as a tour guide with my girlfriend, Amelia. I was truly in awe of how cool it was to take pictures of anything, learn detailed information about it, and simultaneously ask it where the best place to get food was, right where we were. Traveling by EV was by far the worst choice, as it took us 12 hours to get there instead of 6, despite Canada being extremely EV-friendly.

Facts & Figures

My coworker Kevin Karol wrote a murder mystery dance party called Facts & Figures, which premiered at the Boston Fringe Festival. I did the principal photography.

I learned more than I expected: how to work with stage lighting, how to get better angles on principal actors, the timing of theatrical photography, and how to edit images shot in low light. I got an entirely new perspective on the acting I did at the Edinburgh Fringe Festival 15 years ago. It’s something I’d love to do again.

RAI Band

My company started a group band this year, and I volunteered for vocals. I’m in the rock portion of the band, and we’ve been practicing “Tribute” by Tenacious D. I love singing as part of a group and rehearsing the songs, though I have a lot of room to grow. There’s something satisfying about learning a skill that has nothing to do with your day job.

Piano

I’ve kept up with my piano lessons with Tatiana Bercu. It’s been gratifying to finally be able to play Gottes Zeit ist die allerbeste Zeit by Bach. Sight reading becomes easier every week!

What I Learned

If I had to distill this year into a lesson, it would be about the importance of multidisciplinary teams and the value of implementing software yourself.

In the 2000s and 2010s, software had something technology never had before: virtual free replication to customers. No physical media needed, so many talented people got excited about building software companies. Those same people are now looking at robotics.

On the flip side, many robotics companies have focused primarily on hardware, building out the mechanical systems and expecting customers to figure out how to program them. Neither approach works as well as you’d hope.

What I’ve seen work, both this year and over my career, is bringing multidisciplinary teams together from day one. Having hardware people talking to software people from the start produces better robots. Even better, as a manager, having access to these AI tools to assist you gives you so much more. Implementing software yourself, even assisted, is how you keep learning. There is something irreplaceable about staying hands-on. You understand problems differently when you’ve built even part of the thing yourself.

Looking Ahead to 2026

I’m looking forward to building greater things.

That’s vague, I know. But after a year of showing in new places and saying yes to unfamiliar challenges, I have a clearer sense of what I want to build and who I want to build it with. The blog will keep growing. The research will continue. And I’ll probably say yes to a few more things that scare me.

Thanks for reading. If you want to follow along, subscribe to What to Tell the Robot, and I’ll see you in the new year.

I want to acknowledge both Stefanie Tellex and Reena Leone for reviewing the post before publication and making constructive suggestions.

The Deer Island Wastewater Treatment Plant is something that many East Coast Massachusetts residents take for granted. But as Stefie and I toured the massive, $3.8 billion facility, it became clear that this is an engineering marvel. Some editorializing: I had never seen Stefie so excited about a field trip before, even when the smell got a little too unbearable for me. And honestly, it’s hard not to get excited when you’re staring at problems that perfectly illustrate where effective use of engineering principles has solved significant societal challenges.

The Scale of What We’re Missing

Deer Island processes an average of 360 million gallons of wastewater daily for the greater Boston area, with peaks reaching 1.3 billion gallons per day. The facility spans 365 acres and serves 43 communities, representing about 34 percent of Massachusetts’ total population for sewage treatment services. Walking through the primary treatment tanks, secondary clarifiers, and the impressive egg-shaped digesters, you’re confronted with the sheer scale of infrastructure that keeps modern society functioning and struck by how much of it still relies on manual inspection and maintenance.

The plant’s architecture is breathtaking. The twelve egg-shaped anaerobic digesters, each 90 feet in diameter and 110 feet tall, dominate the skyline and hold 3 million gallons apiece. These structures alone cost hundreds of millions to construct and require constant monitoring to maintain optimal conditions for breaking down organic matter and producing methane that powers 20% of the plant. Yet much of the inspection work is still done by humans, who climb into confined spaces, work in hazardous environments, and manually check equipment. Our tour guides explained the costly process of emptying a digester of sludge and refilling it with water. People enter on rafts to inspect and clean the inside. (We were asked repeatedly to avoid using flushable wipes. Flushable wipes are not flushable!)

The engineering complexity is staggering. The plant uses 48 primary clarifiers, each 186 feet long by 41 feet wide by 24 feet deep, with “stacked” settling surfaces at mid-depth to double the settling capacity within the tight space confines of Deer Island. Over one hundred tons of pure oxygen are manufactured each day at the facility’s cryogenic plant to support the biological treatment process, raising pollution removal to over 85%.

Beyond the impressive scale of waste processing, Deer Island became an unexpected frontline in pandemic surveillance during COVID-19. MWRA partnered with Cambridge-based Biobot Analytics to track wastewater at Deer Island for COVID-19 infection indicators, with samples analyzed daily. The facility processes wastewater from 43 communities across eastern Massachusetts, which provides a comprehensive view of viral spread in the Greater Boston area.

What made this approach particularly valuable was that wastewater surveillance could detect virus levels several days before positive test numbers started to increase, serving as an early warning system for community outbreaks. Unlike traditional case counts, COVID-19 data from sewage measured virus prevalence in the community at large, including among people who didn’t have symptoms and didn’t get tested, since the virus they shed through bodily waste contributes to levels found in sewage. The plant’s COVID-19 traces provide public health officials with critical data for policy decisions.

The Plastic Problem

One of the most striking observations during our tour was the amount of plastic waste that accumulates at various stages of the treatment process. Despite screens and filters, plastic debris, everything from bottle caps to grocery bags, constantly surfaces in the treatment tanks. Workers currently remove this material manually, a labor-intensive process.

This isn’t just about automation for efficiency’s sake. This is about creating solutions where none currently exist at scale. The plastic removal problem at wastewater facilities represents a perfect example of an opportunity to solve problems with automation that humans have struggled with.

The trip opened our eyes to the many potential applications of robotics to automate processes that are heavily manual today. One of our colleagues, Howie Choset, co-founded a new venture, Pipe Force AI. Instead of building another general-purpose robot, Pipe Force AI is explicitly focused on robotic inspection of storm sewer pipes. Storm sewers are critical infrastructure that require regular inspection to prevent flooding and environmental damage, yet current inspection methods are dull, dirty, and dangerous.

While we talk a lot about the Bitter Lesson on our blog, the importance of a general method that applies to a lot of different problems remains applicable. Inspecting pipes in municipalities at 900 ft/hr, Pipe Force AI is developing technology that could aid in inspecting miles of pipe leading into the wastewater treatment plant.

The Infrastructure Opportunity

What excites me most about visiting places like Deer Island is realizing how much critical infrastructure operates with minimal automation. Water treatment, wastewater processing, and stormwater management offer us, as roboticists, opportunities to find new ways to motivate our research and explore new possibilities.

These aren’t glamorous applications: Deer Island is dirty and dangerous (but definitely not dull!). There are no viral videos of robots cleaning grease from clarifier tanks or inspecting the inside of digester vessels. But these applications represent precisely the kinds of problems where robotics can create genuine value: capabilities that humans haven’t yet unlocked.

A Monument to Engineering Excellence

The smells hit you in waves as you walk through different sections of the facility. Air scrubbers and carbon adsorbers continuously remove odors and volatile organic compounds from treatment process “off-gases,” covering primary and secondary treatment facilities, sludge processing, and grit removal. Still, the primary clarifiers, where gravity separates sludge and scum from incoming wastewater, are where the tour gets most aromatic. Despite the tour guides’ repeated reminders about the air permit, our noses kept reminding us that waste is managed at the facility.

The facility’s transformation of Boston Harbor represents one of America’s greatest environmental success stories. Before the new plant opened in 2000, the system had combined sewer overflows an average of 60 days per year, with about 10 billion gallons per year of untreated sewage flowing into Boston Harbor. By the 1960s, Boston Harbor was covered in a deep sludge resembling molasses.

The engineering challenges were immense. Wastewater from the 43 communities reaches the plant via four underground tunnels, then is pumped about 150 feet to the treatment facilities. Gravel from these tunnels was used to line the bases of the sludge digesters. The project was tragically marked by the deaths of two divers working in the narrowing anoxic outfall tunnel ten miles from land during construction of the 9.5-mile underwater discharge system.

Even today, the facility continues to face operational challenges. As recently as August 2019, Deer Island had to run on backup power for several days at a cost of about $30,000 per day during installation of a new $115 million power cable across Boston Harbor. The original cable had been installed too shallowly three decades earlier, violating federal permits and eventually blocking harbor dredging operations.

Standing among those iconic egg-shaped digesters, watching the complex choreography of pumps, clarifiers, and biological treatment systems processing hundreds of millions of gallons daily, you witness not just waste treatment but a monument to what ambitious engineering can accomplish. The methane captured from digestion powers boilers that heat the entire facility and drive steam turbine generators producing an average of 3 megawatts of electricity. Digested sludge leaves the island through the Inter-Island Tunnel to be processed into fertilizer at the Fore River facility - Bay State Fertilizer!

The numbers are staggering, the engineering is brilliant, and the environmental impact is transformative. If the plant stopped processing waste, our toilets would start backing up with sewage within a day. Deer Island and projects like it transformed Boston Harbor from the dystopia in Neil Stephenson’s book Zodiac to the idyllic, beautiful ecosystem and working harbor it is today. But what struck us most during our tour was how much of this critical infrastructure still relies on manual processes that could benefit from robotic automation. From plastic removal to equipment inspection, Deer Island represents not just an engineering triumph but a window into the automation opportunities that await us in the infrastructure we depend on every day.

In these deep, dark days, it is instructive to look backwards, and Matt’s thesis is a wonderful example of “Good Old Fashioned AI.” He uses a domain specific language to simulate a concrete domain using lifted symbolic expressions in an expert-system approach. Specifically, he models swine production, building on his experience at his family’s pig farm. Matt writes, “The greatest difficulty in writing the hog-farm simulation was the representation of time,” pointing to early recognition of the importance of space and time in modeling real-world problems. In fact he is gesturing at an often misunderstood feature of human language, which is that human language can express both goals, as well as actions or trajectories. The actions r trajectories are outputted by LLM approaches to language understanding, but a goal-based approach is often what a person means. For example, consider a toy problem such as “Go to the red room.” The robot might need to open a door to go to the red room. Unfortunately, the door is locked, and it needs to find a key. But the lock seized so it needs to find WD40 to dissolve the rust in the lock. There is no WD40, so now it is on its way to the hardware store, but to get there it needs to find the car keys, all to get into the red room. (Not that this happened to me recently...) A goal specifies an end state, and it is the robot’s job to figure out how to achieve that state, and it may need to take arbitrary actions to be successful. There is a stack involved. In contrast, an action such as “drive 1 meter north” translates more directly to a motor command (but of course this is just a goal at another level, specifying a target for a motor controller to achieve relative to the odometry sensor.) Similarly, Matt’s thesis specifies desired end states and an implicit planning tree to connect start states to end states in order to answer questions about the simulation.

A second feature of this thesis is its use of lifted variables for pattern matching and inference. For example, one of Matt’s rules is

(law vet-cost ((v* vet) hogs rate cost)

((= (hogs-present !?v*) !>hogs)

(= (rate !?v*) !>rate)

(= (cost !?v*) !>cost))

(equation ‘cost ‘(sn&* hogs rate) ))

This law introduces a new equation for the vet’s cost, calculated by multiplying the number of hogs by the vet’s rate. This law is triggered if associated variables are defined: hogs-present, rate, and cost. This approach foreshadows STRIPS-style planning, which works via declared preconditions and effects. Most of the existing work on behavior cloning and large behavior models uses skills parameterized with language, such as language or image-conditioned skills. Yet many of the places we want our robots to integrate rely on formal, structured tasks, such as fulfilling an order from a website or assembling a kit for the next model coming down the assembly line. So, in addition to language-conditioned and goal-conditioned tasks, we need skills that take formal parameters that make promises about the entire parameter space.

Unstructured natural languages such as English can express the heights of philosophy, the intricacies of science, and the whimsy of folk tales. Formal languages, in contrast, are limited to the precisely specified grammar, syntax, and semantics of the language, plus whatever a programmer can add to the language within those constraints. The Church-Turing thesis tells us that any programming language boils down to a Turing Machine, one way or another. Yet we still don’t have a formal language that captures the full power and nuance of English while still preserving the precision of the formal language. Yet formal languages - from Python to Jax to Linear Temporal Logic - provide powerful safety guarantees, the ability to safely and robustly compose large systems, and clearly interpretable answers and constraints. Figuring out how to make them play nice with our neural models is an ongoing challenge!