AI-assisted analysis. See our editorial policy.
Human editorial review not recorded
The most useful part of this session is not the demonstration. It is the aside where a speaker asks why we do all of that manual work ourselves (3:43), immediately after an application has crashed.
Everything that follows is an argument about which parts of operational work were only ever done by people because nobody had an alternative.
The loop they build
The sequence is deliberately mundane. An application crashes. Rather than reading logs, forming a hypothesis and reproducing it, they ask an agent to look at the code and find what caused the failure (5:10).
The structural claim underneath is that the application logs continuously, and the agent detects failures on its own and addresses the root cause (19:13) — shifting manual troubleshooting into something that scales (18:15).
That framing is worth pausing on. Troubleshooting is one of the few engineering activities that is genuinely reactive and unschedulable: it happens when something breaks, it interrupts whatever was planned, and its cost is paid in attention at the worst moment. Anything that reduces the interruption is worth more than the hours it saves.
Where the caution shows
The deployment description contains the detail that separates a demonstration from something operable: monitoring with automatic rollback, so a failing deployment returns to the previous state (30:20).
This is the correct pairing and it deserves emphasis. An agent that can deploy without an agent that can undo is a mechanism for producing outages faster. The rollback is not a convenience feature; it is what makes the autonomy acceptable at all, and its presence is a reasonable test of whether a demonstration is describing production practice or a stage.
The claim about attention
The speaker's argument for keeping everything in one surface is that it avoids context switching (15:19), and this connects directly to what the VS Code team admitted at Build in the same week — that switching between agents is unsolved and exhausting.
Both are describing the same constraint from opposite sides. If an agent works for nine minutes, that time is either recovered for something else or spent watching. Recovering it requires being able to leave and return without reconstructing state, which is a property of the interface and the agent's ability to explain itself rather than of the model.
They also show the intermediate work rather than only the outcome — the skill is opened so you can see what it plans to do (12:38), explicitly so it is not magic. That instinct is right, and it is the mechanism by which returning gets cheaper.
The part not addressed
An agent that detects failures, identifies root causes, deploys fixes and rolls back on failure is operating a production system.
Nothing in the session covers what happens when its root cause analysis is wrong — when the fix addresses a symptom, deploys cleanly, passes monitoring, and leaves the real defect in place with the evidence now removed. Rollback protects against deployments that fail. It does not protect against deployments that succeed at the wrong thing.
That is the failure mode this architecture creates, and it is the one that will define whether these systems are trusted with production a year from now.
Talk chapters
Key takeaways
- 01
The organising question is asked after a crash: why do all that manual work ourselves, rather than asking an agent to find the cause. 3:43
- 02
The system logs continuously and the agent detects failures on its own and addresses the root cause, shifting troubleshooting into something schedulable. 19:13
- 03
Deployment includes monitoring with automatic rollback, without which an agent that deploys is a mechanism for producing outages faster. 30:20
- 04
Their argument for one surface is avoiding context switching — the same constraint the VS Code team named as unsolved the same week. 15:19
- 05
They open the skill so its plan is visible, explicitly so the process is not magic — which is what makes returning to a running agent cheaper. 12:38
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.
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.