Google

What generalises past the products is where agents get their reach: connectors for mail, chat, drive, calendar and contacts, with search across them. That list is the substance, because an agent with access to a person's calendar, correspondence and documents can do work another cannot — not by reasoning better but by knowing things. The example offered is ordinary and the shift underneath is not: the value of a meeting summary is not the summary, it is that attending stops being the only way to know what happened, which changes the calculus of every scheduling conflict. The uncomfortable part is that the connector list is simultaneously the product and the risk surface. An agent that can search mail to answer a question can search mail to answer a question it was manipulated into asking, and the permission model governing a person was not built for that.

Google Workspace developer team / Google I/O

The session builds on the observation that thinking models consume large numbers of tokens while reasoning, which means serving no longer resembles the profile that shaped serving infrastructure. Their account of where difficulty lives transfers past any hardware: the hard problems are memory management, scheduling and utilisation, not arithmetic — the chip does the arithmetic, and the surrounding system decides whether it is busy. The concrete bottleneck is key-value cache management as contexts lengthen and concurrency rises, with reuse rather than recomputation as the optimisation. The batching change is small to state and large in effect, because variable-length output stopped being an edge case and static batches are held hostage by their slowest member. The commercially decisive claim is that none of this requires rewriting the application layer, since gains behind an unchanged interface are adoptable by teams who never think about hardware.

Google TPU software team / Google I/O

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.

Aaron Walsh / Google I/O

The design question raised here is one almost nobody has answered: what a screen should look like when most of what happens on it was not done by the person watching. The team states it plainly — when seventy or eighty per cent of the work is not yours, something seems off — and that observation, from people building the interface rather than the model, is the durable content. Software conventions evolved around a contract where you act and the system responds, and breaking it disables specific mechanisms: undo means little when you did not do the thing, progress indicators assume one operation, and confirmation prompts multiply until they are dismissed reflexively. The related thread is permissions, named as a first-order design concern rather than a security afterthought, because permission stops being a property of a person and becomes a question about an action initiated by something that inferred it should happen.

Mitchell / Google I/O

The most useful moment is an aside rather than a demonstration: why do all that manual work ourselves, asked immediately after an application crashes. What follows is an argument about which parts of operational work were only ever done by people for lack of an alternative. Troubleshooting is one of the few engineering activities that is genuinely unschedulable — it interrupts whatever was planned and costs attention at the worst moment — so reducing the interruption is worth more than the hours saved. The deployment description contains the detail separating a demonstration from something operable: monitoring with automatic rollback, without which an agent that deploys is a mechanism for producing outages faster. What the session does not address is the failure mode this architecture creates, where a fix addresses a symptom, deploys cleanly and passes monitoring while the real defect remains.

Google Cloud agent platform team / Google I/O

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.

Sundar Pichai / Google I/O

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.

Logan Kilpatrick / Google I/O

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.

Sam Phillips / Google I/O

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.

Philipp Schmid / Google I/O

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.

Jeff Dean / Google I/O

The most consequential sentence here concerns what happens after the demo: sometimes you want a quickly assembled application as a proof of concept, and other times you want it to stick around with real users and persistent data. The security additions are best read as answers to the failure modes that creates — keeping prompts off the client, restricting model access to the application, rate limits preventing a few users consuming everyone's quota, ignoring prompts arriving from the client. Each assumption being corrected is one a rapidly built application makes by default, harmless in a demonstration and consequential the first day it is public. The claim that strong security rules were written by the agent deserves the most scrutiny, because an overly permissive access rule produces no visible symptom — it works fine while allowing access it should not.

Firebase Team / Google I/O

The most instructive fix in this session is not a model change: a response was taking too long and containing too much, so the presenter constrained the prompt to a single sentence under fifteen words and got a very fast response. On a phone, output length is the cost, because every token is generated on the device's own processor while the user waits. That reorganises how these features are built, since the constrained version satisfies the product requirement and the performance requirement with the same change. The first section runs in airplane mode, which settles what is actually being demonstrated. The privacy argument is made about receipts containing card numbers, and the demonstration then reaches for the larger cloud model for the harder version of that task — a tension the session does not comment on. The structural improvement, marking a data class as generable, removes an entire category of runtime failure.

Yolanda / Google I/O

The most revealing moment in this segment is not the hardware but a question the assistant asks before acting: would you like to confirm. On any other device that is unremarkable; on glasses it states the entire design problem. Every consumer transaction interface built in two decades has relied on a visual review step where errors get caught, and a device worn on the face has no review screen in any meaningful sense. What replaces it is the assistant restating what it is about to do, which must contain everything a user would have checked and be short enough to listen to — two requirements that pull against each other. Adding a tip after confirmation shows this is a conversation with amendments rather than a single transaction, which makes the boundary between negotiating and committing a design decision rather than an emergent property.

Android XR Team / Google I/O

The transferable content here is not the demonstrations but a set of rules for writing instructions an agent will follow. Supporting files are provided alongside a main instruction file, with explicit statements about when and how each applies, so that material loads at the start but is used only for specific tasks — and so the agent can skip a step entirely when it is unnecessary. One subtask was extracted into its own file specifically so it could be skipped when the user has already named the target, which is instruction design as software design. The practical warning is that customisations should be extracted and renamed, because a bulk update of the shared instructions can silently overwrite them. Two unremarked demo moments establish the real working rhythm: start the long-running task first and fill the time with something else.

Sandhya / Google I/O

The claim most likely to matter here is about data rather than computation. The measurements behind modern structural biology began accumulating in the 1970s and took roughly fifty years of painstaking work to become the database that made the protein-structure breakthrough possible — and a quantum computer could produce valuable training sets where collecting them experimentally is impractical. That inverts the usual framing, because a dataset does not need a fully error-corrected machine: it needs to be produced once, correctly, and then has permanent value. The technical status report is specific, with coherence times improved roughly tenfold and the remaining obstacles described as system-level engineering rather than physics. The most actionable statement concerns cryptography, where an algorithmic result rather than hardware progress moved the timeline inward.

James Manyika / Google I/O

The example that justifies this session is a farming application in rural Maharashtra translating agricultural insights and weather warnings into a regional Marathi dialect, offline. That is not a latency argument — the user is unreachable by a hosted model twice over, once through connectivity and once through dialect coverage, and neither problem is solved by a more capable model in a data centre. The most concrete engineering claim concerns speech, where a conventional approach needs a separate 100-to-200-megabyte model per language while the on-device approach needs one small adapter across all supported languages, turning a linear install cost into a nearly fixed one. The guidance to always use the smallest model that reliably solves the use case is the opposite instinct to server-side development, where there is always a later.

Karen / Google I/O