The moment that opens this panel is small and does a lot of work. A robot was asked to pick up the extinct animal. It selected a dinosaur toy (1:40).
Nothing in its training data connected that phrase to that object. The capability arrived from language models and transferred into a machine with hands — which is the whole premise of the current wave, stated as an anecdote rather than a claim.
What physical intelligence actually requires
Kenjiro's framing separates this from the software case in a way worth holding onto: these systems need to understand what it means to exert force on the world, and how to use a body to exert it (4:12).
That is not a harder version of image recognition. A model that identifies a cup has done nothing about how much force closing on it will crush it, how its mass shifts once it holds liquid, or what happens when the grip is slightly wrong. Physical intelligence is about the consequences of action, and consequences are the one thing a dataset of internet images contains almost nothing about.
The form factor argument
The panel takes the humanoid question seriously rather than defending it, which is the more interesting treatment.
Rodriguez's answer is not that human shape is optimal — she notes the range of morphologies available and treats the choice as open (5:33). The argument for humanoid form is that the world is already built for it: doorways, stairs, tools, workspaces. Choosing a shape optimised for a task means rebuilding the environment around it.
Her practical point is more revealing. Boston Dynamics values being able to do data collection at scale and deployment at scale on the same hardware (8:54). That is an argument about the development loop rather than about biomechanics — every deployed unit generates data that improves the model that runs on units already in the field, and only if the same machine does both.
Where they are sceptical
The most useful passage is where Rodriguez pushes back on the technology her own field is most excited about.
World models generate video that looks realistic. Asked to produce footage of dexterous manipulation, the results do not hold up (30:27) — because looking right and being physically consistent are different properties, and video generation optimises for the first.
This matters because synthetic data is the proposed answer to robotics' data problem. If generated video is convincing to a human eye and wrong about contact, friction and deformation, then training on it teaches a policy to expect a world that does not exist. Her scepticism is domain-specific and evidence-based, and it is the sort of thing that only appears in a conversation between practitioners.
What the panel establishes
Two things, neither of them a product claim.
The capability transfer is real: understanding arriving from language models is showing up in machines that have never seen the object in question. And the remaining gap is not perception but consequence — force, contact, the physics of being wrong, and the fact that the most promising shortcut to more training data is currently unreliable in exactly the dimension that matters.
That is a more useful picture than a demonstration reel, and it explains why timelines in this field keep slipping in a way software timelines do not. The failures are not in the part that got solved.
演讲章节
关键要点
- 01
A robot asked to pick up the extinct animal selected a dinosaur toy, with nothing in its training data connecting the phrase to the object. 1:40
- 02
Physical intelligence is framed as understanding what it means to exert force on the world and how to use a body to do it — knowledge about consequences rather than categories. 4:12
- 03
The humanoid case is not that the shape is optimal but that the world is already built for it, with morphology treated as an open question. 5:33
- 04
Boston Dynamics values collecting data at scale and deploying at scale on the same hardware, which is an argument about the development loop rather than biomechanics. 8:54
- 05
Rodriguez is sceptical of generated video for dexterous manipulation: it looks realistic and does not hold up, because looking right and being physically consistent are different properties. 30:27
提及的实体
相关演讲

Four of Google's model, product and search leads on what changes once agents run for hours rather than seconds, and the most quotable argument comes from Dean: the constraint is moving out of the model and into the tools around it. By Amdahl's law, an agent spending half its time in tools built for human-speed interaction cannot gain more than a doubling however fast the model becomes — which reframes a great deal of current infrastructure work as latency debt. Their internal response is concrete: rewriting Python tooling into Go, framed as a fully specified translation task rather than an open prompt, produced order-of-magnitude speedups overnight. Reid supplies the counterweight from Search, where acceptable latency turns out to scale with how much work is being taken off the user rather than being a fixed budget. Woodward's detail is the quietest and perhaps the most telling: teams that have stopped writing product documents for humans and now write context files for models to act on directly.

Pichai's framing of Google as the buffer between people and the raw internet is offered as continuity — search did it, browsers did it, agents do it more — and it is also the most contested claim in the industry, because a buffer decides what passes through. He reaches immediately for the counterweight, the connection people feel to creators they follow, which is precisely the tension the company is currently managing without resolving. Two answers are sharper than the format usually produces. On competition he describes participants running on different pre-training and release cadences rather than at different speeds in one race, which is a more honest account than the leaderboard framing and comes from someone with an interest in leaderboards. On security he acknowledges models improving at cyber work, which is the one domain where better capability does not obviously net out positive, since an attacker needs one vulnerability and a defender needs all of them.

The observation that organises this session is not about capability but about attention. Engineers increasingly file a ticket rather than opening an editor, and the code comes back — which changes what the surrounding tools are for. If the agent works while you do something else, the conversation between you is no longer a workspace; it is the mechanism by which the agent surfaces a question it cannot resolve alone. Interfaces built for continuous conversation optimise for flow, and interfaces built for interruption should optimise for the opposite. A runtime constraint follows immediately: an agent that starts a long-running job cannot block until it finishes, which turns out to be a workflow-engine problem rather than a model one. The panel's closing formulation — that deciding what to build is the hard skill and always was — reads as reassurance and functions as a warning, since that judgement is downstream of exactly the work now being delegated.

The most honest moment here is an aside about how the presenters have tracked their own projects: plans in documents, plans in spreadsheets, plans in bug comments, and once a plan written on a receipt. That describes the actual category being addressed — not software nobody has built, but the small internal tool every team improvises badly because building it properly was never worth the effort. The demo turns on a single question: the generated app is strictly single player, so what happens when you want to share it with the team? That boundary is where improvised tools historically died, because it is where accounts, shared storage and access rules begin. Here it is crossed in one step, with the access rules generated and deployed automatically — which is convenient, and is also the moment the application acquires obligations nobody reviewed.

The clearest statement at I/O of how an agent API differs from a chat API, and the reasoning behind each departure is stated rather than assumed. Three changes matter. Conversation state moves to the server: a call returns an identifier, and passing it back continues the thread, retiring the client-side history array. The data model abandons alternating user and model turns for discrete steps, on the argument that a trace containing reasoning, tool calls, environment responses and compaction was never really a conversation and modelling it as one distorted it. And agents receive their own persistent remote environment rather than acting on the caller's machine — addressable by identifier, and shareable, so a research agent's output files become an application builder's input without passing through the context window. Schmid is explicit that scaffolded environment files are deliberately not model input, which is what keeps large artefacts out of the context budget. Schaeff's first half covers the real-time voice path, where the notable property is speech-to-speech across ninety languages with transcription of both directions.

The case for local inference is made in three clauses representing different kinds of constraint: cost, where a local model removes an API call; availability, where the application works on a flight; and data, where requirements prevent information leaving the device. Only the third changes what is buildable rather than what is affordable. What makes this newly practical is unglamorous — instruction set extensions integrated into the runtime rather than a modelling breakthrough — with around thirty per cent improvement reported in image editing functions. The guidance on fine-tuning inverts the usual advice: adaptation matters most for the smallest models, because their capability budget is already spent and getting them to perform on your problem means spending some of it there. The two examples do the real work, since neither is a cheaper version of a cloud application.
