峰会演讲

33:40

Saunier opens with the figure that 90 per cent of AI-generated prototypes never reach production and immediately declines to treat it as a problem, saying it is for good reasons. That is the right starting position and rarer than it should be. The failure he describes is structural rather than careless: generating a working application is fast, while everything that makes one safe to expose — authentication, access control, secret handling, tenancy — is not part of what gets generated because it was not part of what was asked. An engineer building by hand meets those questions as unavoidable steps; generation skips them, and their absence is invisible in a demonstration. His alternative is guardrails and templates with platform primitives already present, which matters because an agent cannot forget something it is not responsible for. Prompts are advice; templates are structure, and only one survives a model having an off day.

Yoann Saunier / Microsoft Build

45:17

The session opens with an analyst projection that over forty per cent of agentic projects will be cancelled by 2027, and the diagnosis offered is the useful part: none of these are model problems, they are runtime problems. Two failures make the case. An agent that restarts loses context, cache and intermediate state and pays the setup cost again, which turns a restart during a long-running task into total loss of accumulated work exactly when the value is highest. And an agent running as trusted code on a developer's machine inherits that environment — SSH keys, browser cookies, everything — which is the arrangement most agent development actually uses and does not survive a process running unattended against a prompt someone else influenced. The reframing is testable against the failures people describe, none of which are failures of intelligence.

Microsoft AI runtime team / Microsoft Build

43:33

The framing worth separating from the product is that agents are no longer static routers shuffling requests between fixed tools; they acquire skills, generate memory and accomplish things nobody programmed. A router can be tested exhaustively because its behaviour is bounded by configuration. A system that gains capability during operation cannot, because what it does next week depends on what it accumulated this week. The response described is continuous evaluation fed by every action and cost signal — the right shape of answer and a considerable operational commitment, since you end up running an evaluation apparatus permanently at a cost proportional to the thing evaluated. The quieter shift is agents woken by events rather than requests, which removes the natural boundaries a requester provides: unbounded cost, unattributable actions, and no clear answer to who authorised any particular piece of work.

Tina Sharkey / Microsoft Build

46:45

The method is stated plainly enough to hold them to: choosing a model is guess and check. What makes the walkthrough useful is that it attaches numbers to steps usually described qualitatively. A customer service agent handling returns starts at 76 per cent quality — their framing is not bad, not great, not shippable, with production needing 90 or better. The progression that follows is ordered by cost rather than sophistication: show the model a pattern to imitate, then supervised fine-tuning of a smaller model with scores moving as you go, then reinforcement where answers are checkable. The observation most likely to survive is about curriculum — you do not teach the hardest problem first, you teach addition before you teach arithmetic — which makes training data ordering a design decision rather than a preprocessing detail. What the session does not supply is the volume at which the effort amortises against serving cost.

Microsoft Foundry models team / Microsoft Build

16:26

The question is narrower than most sessions at this conference and more useful for it: an agent built with open-source tooling, and how it reaches production without being rewritten. The design principle underneath transfers regardless of platform. Keeping the tool boundary inspectable and the agent as normal code sounds unremarkable and is not, because a great deal of framework design pulls the loop inside a runtime you configure rather than write — which works until something breaks and the part you need to inspect is the part you did not write. Their observation about tool definitions is the transferable technical point: retrieving a remote tool server's instructions consumes context before anything is called, while local definitions avoid it and give up sharing. The correct answer is architectural rather than universal, and the failure is treating either as the default.

Facundo / Microsoft Build

21:50

The framing is the most accurate description of a common failure offered at this conference: agents can reason but cannot really read. Real enterprise content is scanned PDFs, long threads, documents with complex tables, images and audio — and an agent handed one of those writes custom code, uploads images, misreads tables and skips figures. What makes this failure persistent is that it degrades quality and cost at the same time, so it never presents as a tuning problem with a dial to turn. The alternative is a parse, classify and extract pipeline that produces structured output before anything reaches the model, with a claimed 85 per cent reduction in tokens. The reframing matters more than the number: reasoning capacity spent recovering structure is capacity not spent on the task, and the recovery fails silently — a misread table produces a confident answer built on wrong numbers.

Microsoft Content Understanding team / Microsoft Build

13:14

The most interesting number is not about the database: around 8 per cent of the lines of code modified in this release were changed by AI, offered as a measure rather than a productivity claim, by a team with no obvious reason to volunteer it. It is also more credible than most adoption statistics — small enough to believe and specific enough to check against a repository. The analytical content sits in the historical comparison: vector and embedding capability existed with modest uptake until an unrelated consumer product made the concept legible, after which adoption rose almost vertically. For anyone building infrastructure that is uncomfortable, because it means a feature's uptake may be gated on comprehension rather than capability. The architectural argument — let applications work against data where it lives rather than moving it through pipelines — is newly plausible because agentic access fits neither traditional profile.

Charles Feddersen / Microsoft Build

45:09

The chart organising this session is not about productivity. It shows roughly three times more issues arriving and considerably more open pull requests since January, which is the honest shape of a successful agent rollout and almost never the number presented. The team's response was to move from monthly to weekly releases, a change forced by throughput rather than chosen for confidence. Their code-survival metric — the share of a model's output that actually gets committed — is unusually well chosen because it is measured after the human decision and so cannot be inflated by generating more. The most transferable practice is running the editor with and without a change and attaching the comparison to the pull request, which turns the pull request into the specification. They also state plainly that running AI over community-submitted issues means running it on untrusted input, without detailing the mitigation.

Pierce Boggan / Microsoft Build

43:27

The observation that should change how you work is about a review loop that does not terminate: ask for a review, get findings, fix them, ask again, get new findings, repeated through a whole day until the speaker concludes he has become the machine in the loop. That is better read as a property of the arrangement than as model unreliability — traditional review terminates because a human gets bored or runs out of time, and removing the human cost removes the stopping condition with it. The organising idea of the talk is that your job is no longer building software faster but helping your agent build software faster, which reframes a portfolio of small side tools as accumulated leverage rather than failed products. His review-depth policy scales with blast radius rather than applying uniformly, and his renaming of the pull request as a prompt request inverts thirty years of open-source etiquette about what counts as a generous contribution.

Peter Steinberger / Microsoft Build

38:05

The finding that contradicts how most teams deploy AI assistance is stated almost in passing: the tenfold return arrives where an engineer is weakest rather than strongest, so someone without a security background suddenly shows a better security posture. That reverses the usual rollout order, which gives these tools to the strongest engineers first on the theory that leverage compounds on capability. It also creates a verification problem, because the reviewer most likely to be assigned shares the same gap. The speaker who previously ran the foundation behind Kubernetes brings a specific scepticism about lock-in, framed as this era already reproducing the last one's portability and cost-control problems — though the sharper observation is that context held in implicit memory or a conversation window has no export format at all. Their overnight scheduler blocks only for architectural decisions, which is a well-drawn line with no one watching it.

Priyanka Sharma / Microsoft Build

45:51

Most of this session is a platform tour. The part that will still matter is a taxonomy of three agent identities and the fact that capability is gated by which one you choose rather than by which model you use. An assistive agent extends the person operating it and inherits their access; an autonomous one runs in the background with permissions granted directly on cloud resources, and loses the tools that were previously reached through a person's identity; the third has its own account, alias and ability to act on its own behalf. That progression is an administrative commitment rather than a capability upgrade, which is why the last tier requires approval through an administrative console. The harness abstraction supplies tools and context compaction without extra work, and the demo's own network failures illustrate the operational character of these systems better than the architecture slides do.

Sean Henry / Microsoft Build

18:19

Three claims here are worth separating from the announcements around them. The speech numbers are meaningful in different ways: blind preference testing is the right evaluation for synthesis where no ground truth exists, and a latency under 150 milliseconds crosses the threshold where spoken exchange stops feeling like a request and starts feeling like conversation. The principles slide contains an actual position rather than decoration — capability should be learned rather than inherited, which takes a side in a live argument about building on existing base models versus training capability directly. And the training description carries the most transferable idea: generate solutions, score against verifiable ground truth, reinforce the better ones, with the clause about verifiability doing all the work. That explains the shape of progress across the field, and it is the same boundary Hassabis drew at Davos, arriving here as engineering description rather than forecast.

Dave Citron / Microsoft Build

31:40

The most revealing phrase here is a design goal rather than a feature: teaching not just how to use the packages but how to use them effectively, building applications that have good taste, because a merely functional dashboard is not what anyone wants. That is an admission about where the constraint has moved. Nobody in the demonstration worries about whether the agent can produce a working dashboard; the worry is whether it will produce a good one. For thirty years the limiting factor was construction, and the demonstration makes the point without meaning to by skipping past the building to the finished result. What remains is judgement about what should be built, which the tooling does not provide and which cannot be verified by a test. The narrative is honest about the consequence: requests arrive faster because the cost of asking fell along with the cost of building.

Ben / Microsoft Build

64:39

The most useful sentence across this hour answers whether you watch what the model is doing: it depends on the stakes. A small interface prototype gets no supervision; code running a sandbox inside his own system got close attention and a series of attempts to break it. That is a better review policy than most organisations have written down, because when generation becomes cheap, review is the scarce resource and spending it uniformly under-reviews the dangerous code. The observation that reframes the economics is that a hard problem means the model works for ten minutes while you do something else, so difficult tasks have become the cheaper ones in attention — inverting a relationship that has held for the entire history of software. The remark about trusting his own software after four months of use, rather than because an expert wrote it, is a real shift in what evidence counts.

Scott Hanselman / Microsoft Build

20:12

The argument for running models locally used to be privacy. Here it is more specific and better reasoned: with a smaller model you can work at the full context length and largely stop worrying about compaction, because agentic workloads run locally hit hardware limits quickly. Compaction is the failure mode that quietly degrades long agent runs, when an agent forgets a constraint from forty steps ago or keeps a summary that lost the detail that mattered. Framing local inference as a way to avoid it is a real trade with a stated boundary — not that local models are better, but that capacity to hold the whole problem can beat raw capability on any single step. The threshold claim that local models are now viable for real work is the kind that changes behaviour, and thirty seconds from nothing installed to working makes the experiment nearly free.

Michael Chiang / Microsoft Build

12:31

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

37:44

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

47:46

The specification change that matters is the context window moving from 32,000 tokens to 128,000 for smaller models and up to 256,000 for larger ones, because it changes which problems are solvable without infrastructure. A 32,000-token limit means retrieval, chunking and index management; at 128,000 many tasks fit whole and the workarounds become unnecessary. The deployment range runs from a browser with zero ongoing server cost through local runtimes to one-click hosted endpoints, and the strategically significant detail is interface compatibility — a local model speaking the same protocol as hosted APIs is substitutable without changing application code, which makes placement an operational choice rather than an architectural commitment. That is what makes open weights competitive: not being better, but making switching free.

Olivier / Google I/O

31:34

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.

Sachin Kothari / Google I/O

42:08

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.

Sona Karashkevich / Google I/O