Google I/O 2026

What Does a Screen Look Like When 80% of It Wasn't Your Doing?

Original speaker(s): Sona Karashkevich, Group Product Manager · Google / Mitchell, Antigravity · Google

Verified sourceSession date not verifiedpresentation42:08EN2 min read

Interface conventions encode an assumption that the person watching caused what they see — and when most of the work is not theirs, undo, progress and confirmation all stop meaning what they meant.

The design question this session raises is one almost nobody has answered: what should a screen look like when most of what happens on it was not done by the person watching?

The team puts it plainly. When 70 or 80 per cent of the work is not yours, something seems off (20:29) — and that observation, arriving from people building the interface rather than the model, is the more durable content here.

Why the discomfort is real

Software interfaces evolved around a contract. You act, the system responds, and the screen reflects the consequences of what you did. Everything from undo to progress indicators to confirmation dialogues assumes the person watching is the cause of what they see.

Break that assumption and the conventions stop working in specific ways. Undo means little when you did not do the thing. Progress indicators presume a single operation rather than several agents at different stages. Confirmation prompts multiply until they are dismissed reflexively, which is worse than not asking.

The team says they began designing for what happens when the entire interface starts changing without you (20:29), which is the correct framing. This is not a matter of adding an agent panel to an existing layout. It is that the layout encoded an assumption that no longer holds.

Permissions, named as a first-order concern

The related thread is permissions, described as top of mind (21:51), and its position in the design conversation rather than the security section is what makes it notable.

For a tool a person operates, permission is a property of the person: you can do what your account allows. For a system where an agent acts, permission becomes a question about a particular action at a particular moment, initiated by something that inferred it should happen. Whether that is authorised is not answerable from an account.

Every product in this category will have to answer this, and most of them will discover it after shipping.

The mundane technique worth stealing

Amid the architecture is a practical note that will save more time than anything else in the session: rather than doing the time-consuming version, define the persona in the system instructions and let the model hold it (8:28).

The reason this matters is that most people repeat framing in every prompt — explaining who the model should be, over and over, in a place that gets truncated and re-sent. Persistent instruction moves that framing somewhere durable, which is cheaper, more consistent, and removes an entire class of drift where the model gradually forgets what it was supposed to be.

Small, unglamorous, and the sort of thing that separates people who use these tools well from people who use them constantly.

Talk chapters

Key takeaways

  1. 01

    Their design starting point: when seventy or eighty per cent of what happens is not yours, something feels wrong — and the interface has to account for it. 20:29

  2. 02

    Permissions are treated as a first-order design concern rather than a security afterthought, because an agent's action is not authorised by an account. 21:51

  3. 03

    A practical note worth more than it appears: put the persona in system instructions rather than repeating framing in every prompt. 8:28

Entities mentioned

Related talks

Jeff Dean on Why Tools, Not Models, Are the Next Bottleneck (Google I/O 2026)
Jeff Dean on Why Tools, Not Models, Are the Next Bottleneck (Google I/O 2026)

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.

panel

"Pick Up the Extinct Animal": Where Robotics Actually Stands
"Pick Up the Extinct Animal": Where Robotics Actually Stands

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.

panel

When Developers Stop Opening the Editor, Chat Becomes an Interrupt Handler
When Developers Stop Opening the Editor, Chat Becomes an Interrupt Handler

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.

panel

The Moment It Stops Being Single Player
The Moment It Stops Being Single Player

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.

session

Why Google Dropped Chat Turns for Steps: The Interactions API at I/O 2026
Why Google Dropped Chat Turns for Steps: The Interactions API at I/O 2026

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.

presentation

Pichai Calls Google a Buffer Between People and the Raw Internet
Pichai Calls Google a Buffer Between People and the Raw Internet

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.

fireside