AI-assisted analysis. See our editorial policy.
Human editorial review not recorded
Sundar Pichai describes Google's position in a phrase that repays attention: the buffer between people and the raw internet (6:27).
He offers it as continuity — search did it, browsers did it, apps did it, and agents do it more. The framing is accurate and it is also the most contested claim in the industry, because a buffer decides what passes through, and the thing being buffered has a view about that.
The problem the framing creates
Pichai reaches immediately for the counterweight, and the example is deliberate: people feel a connection to creators they follow, and that connection is a large part of what the products are for (6:47).
This is the tension the whole company is currently managing. A buffer that answers the question directly serves the person asking and starves whoever produced the answer. A buffer that routes them onward preserves the ecosystem and delivers a worse experience. Every interface decision in AI search sits somewhere on that line, and there is no position on it that satisfies both sides.
He does not resolve it here. Nobody has.
Where he is precise
Asked about competition, his answer avoids the usual posture. He describes an environment where the participants have different strengths and weaknesses and, notably, different cadences of pre-training and release (25:40).
That last detail is the substantive one. Frontier labs are not running the same race at different speeds; they are running on different clocks. A lab that pre-trains on a long cycle and one that ships incremental improvements continuously will trade the lead repeatedly without either gaining ground, and any snapshot ranking captures where the cycles happen to sit rather than who is ahead.
It is a more honest description of the competitive situation than the leaderboard framing the industry prefers, and it comes from someone with an interest in the leaderboard framing when his own models are on top.
The security answer is the one worth extracting
The exchange on cyberattacks is brief and contains the session's most checkable claim: models are getting better at cyber (8:59), and the question is whether AI-enhanced attacks are increasing (9:09).
The asymmetry here is the thing. A capability that helps a defender find a vulnerability in their own code helps an attacker find it in someone else's, and the attacker needs one while the defender needs all of them. Pichai notes Google has been working on security for decades, which is true and is not an answer to the asymmetry.
What makes this the most consequential thread in a thirty-minute conversation is that it is the one where capability improvements do not obviously net out positive, and where the timeline is now rather than at some future threshold.
What the format allows
This is a stage conversation at a developer conference, held the day after the announcements it discusses. It is well suited to elaboration and poorly suited to pressure, and the transcript shows that: each answer is received and followed by a new topic.
What survives is the framing rather than the news. Google as a buffer, competition as differing clocks rather than a single race, and security as the domain where better models do not straightforwardly mean better outcomes. None of those are announcements. All three are more durable than what was announced.
Talk chapters
Key takeaways
- 01
He describes Google's role as the buffer between people and the raw internet, with search, browsers, apps and now agents as successive versions of the same function. 6:27
- 02
His counterweight is the connection people feel to creators they follow — which is the interest a buffer that answers directly does not serve. 6:47
- 03
On competition he describes labs running on different pre-training and release cadences rather than at different speeds in a single race. 25:40
- 04
He acknowledges models improving at cyber work, in a domain where an attacker needs one vulnerability and a defender needs all of them. 8:59
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 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.
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.