The most transferable content in this session is not the demonstrations. It is a set of rules for writing instructions that an agent will follow — and one warning about how to keep them.
Be explicit about when a file applies
The design principle stated is that supporting files are provided alongside the main instruction file, and that the instructions are always explicit about when and how each should be used (34:44).
The reason given is the important part: the intent is that supporting material loads at the start but is used only for specific tasks (35:12). And the payoff is that the agent can skip a step entirely when it determines the step is unnecessary — such as configuring dependencies that are already present (35:12).
That is a genuinely useful pattern. Instructions written as a linear procedure get executed as a linear procedure, including the parts that do not apply. Instructions written as a set of conditional capabilities let the agent skip work, which is faster and less likely to break something that was already correct.
The concrete example makes it clear. One subtask — identifying which candidate to work on — was moved into its own supporting file specifically so it could be skipped when the user has already named the target (35:38).
That is instruction design as software design. The subtask was extracted because it has a precondition, and putting it in its own file is what makes the precondition checkable.
Keep your customisations out of the update path
The practical warning is the sort of thing that only comes from having been burned: if you customise the provided instructions, extract them elsewhere, rename them, or otherwise separate them from the original — because a bulk update of the shared instructions can overwrite your changes (33:49).
This is a familiar problem wearing new clothes. Editing a vendor-supplied configuration in place has been a known mistake for decades, and the fix has always been the same: keep your version somewhere the vendor's updates do not reach.
What makes it worth restating is that agent instruction files do not feel like configuration. They read as documentation, they live in a repository, and nothing about them signals that they are managed by someone else's update process. The failure is silent — your customisation disappears and the agent starts behaving as it did before, with no error to trace.
The customisation itself is straightforward: add pointers and details specific to your own code patterns, such as constraining the agent to particular modules (32:56). That is exactly the kind of local knowledge that makes an agent useful and that a shared instruction file cannot contain — which is why it will exist in every real adoption, and why the update-path warning applies to everyone.
The timings they do not hide
Two moments in the demonstration are more informative than the features.
A generation step is stopped early with the note that it can take up to ten minutes, so a pre-prepared project is used instead (5:40). A migration is started in the background because it takes a while, and the session continues with other material while it runs (29:17).
Neither is presented as a problem, and neither should be. But they establish the actual working rhythm of these tools, which is nothing like the interactive loop the interface implies. You start something, you leave, you come back. The presenter's own solution — begin the long-running task first and fill the time with something else — is the real workflow advice in the session, delivered by accident.
The testing idea worth watching
The most interesting capability described is tests that follow steps and adapt as the interface changes (15:40).
Interface tests break constantly, and they break for reasons that have nothing to do with correctness — a renamed element, a moved button, a restructured layout. Most teams respond by writing fewer of them, which is the wrong adaptation and the only affordable one.
A test that describes intent and locates the target at run time addresses the actual cost. The risk it introduces is the mirror image: a test that adapts to changes can adapt to a change that broke something, and pass. The session does not discuss where that line sits, which is the question anyone adopting this will hit in their second month.
关键数据
- up to 10 minutes
- how long a generation step runs, prompting the presenter to switch to a pre-prepared project 5:40
演讲章节
关键要点
- 01
Instructions state explicitly when and how each supporting file applies, so material loads at the start but is used only where relevant. 34:44
- 02
The agent can skip steps it determines are unnecessary, such as configuring dependencies that already exist. 35:12
- 03
One subtask was extracted into its own file precisely so it could be skipped when the user already names the target. 35:38
- 04
Customisations should be extracted and renamed, because a bulk update of the shared instructions can silently overwrite them. 33:49
- 05
Long-running steps are started first and left to run, which is the real working rhythm the interface does not imply. 29:17
提及的实体
相关演讲
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.