AI-assisted analysis. See our editorial policy.
Human editorial review not recorded
The most revealing moment in this segment is not the hardware. It is a question the assistant asks before doing anything: would you like to confirm (8:50).
The sequence leading to it is a coffee order placed by voice through a delivery service, followed by a confirmation, then a request to add a twenty per cent tip (7:55, 8:50). On any other device this would be unremarkable. On glasses it is the entire design problem, stated compactly.
Why confirmation carries more weight without a screen
Every consumer transaction interface built in the last two decades has relied on a review step. You see the item, the price, the address and the total before anything happens, and that visual review is where errors get caught — wrong quantity, wrong location, wrong card.
A device worn on the face has a display measured in a few lines. There is no review screen in any meaningful sense. What replaces it is the assistant restating what it is about to do and waiting for a yes.
That places an unusual load on one sentence. The restatement has to contain everything a user would have checked visually, and it has to be short enough to listen to. Those two requirements pull in opposite directions, and the demonstration resolves it by keeping the transaction simple — a known item from a known place.
The interesting case is the one not shown. What the confirmation sounds like when the order has four items, a substitution and a delivery window is a question this format has to answer, and the demonstration selects an example where it does not arise.
The tip is the tell
Adding a tip after the confirmation (8:50) looks like a throwaway detail and is not.
It shows the interaction is not a single transaction but a conversation with amendments. Which means the confirmation is not a final gate — it is a checkpoint in a dialogue that continues, and the thing being agreed to can change after agreement.
That is more natural than a form and considerably harder to reason about. In a form-based flow there is a moment where the state is fixed and committed. In a conversational one, the boundary between negotiating and committing is soft, and where exactly it falls has to be a design decision rather than an emergent property.
The platform choice that matters more than the demo
The commitment made in passing is that these pair with both major mobile platforms (2:55).
For a device category whose predecessors were tied to one ecosystem, that is a strategic decision with real consequences. It widens the addressable market immediately, and it constrains what the product can do — because the deep integrations that make an assistant genuinely useful on a phone are the ones a competing platform does not grant.
An assistant on glasses that can see what you see, answer questions and place an order through a third-party service can do all of that without privileged access to the phone. An assistant that manages your messages, calendar and notifications across both platforms equally cannot. The cross-platform commitment quietly defines which half of the category this product is in.
What is actually being demonstrated
Strip away the format and the capability shown is an assistant that hears an ambient conversation, retains a reference to something discussed earlier, and acts on it through an external service.
That is not new as a capability. What is new is the absence of a moment where the user picks up a device and directs attention at it. Removing that moment is the entire value proposition — help in the moment without pulling you out of it — and it is also what removes the review step.
The confirmation prompt is the seam where those two things meet. Whether it holds up outside a rehearsed order is the question that determines whether this category works, and it is the one a keynote segment is structurally unable to answer.
Talk chapters
Key takeaways
- 01
The assistant asks for explicit confirmation before completing an order, which is the only review surface a screenless device has. 8:50
- 02
A tip added after confirmation shows the interaction is a conversation with amendments rather than a single committed transaction. 8:50
- 03
An order is placed through a third-party delivery service by voice, from a reference to something discussed earlier in the conversation. 7:55
- 04
The devices pair with both major mobile platforms, which widens the market and constrains how deeply the assistant can integrate. 2:55
Entities mentioned
Organizations
Related talks

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.

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 anecdote that opens the panel does the work: 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. That transfer from language models into machines with hands is the premise of the current wave. What the practitioners then describe is where it stops. Physical intelligence is about exerting force and using a body to do it, which is knowledge about consequences — the one thing a corpus of internet images contains almost nothing about. The humanoid question gets an honest treatment: not that human shape is optimal, but that the world is already built for it, plus a development-loop argument about collecting data and deploying on the same hardware. The most useful passage is scepticism about the field's favourite shortcut: generated video looks realistic and does not hold up for dexterous manipulation, because looking right and being physically consistent are different properties.

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.

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.
