Microsoft

Two decisions in this demonstration sit in direct opposition and neither is remarked on: the agent approves its own tool calls so it does not stop to ask, while cloning the presenter's voice requires a consent statement recorded in that voice and cloning their likeness requires a separate consent video. Maximum friction to copy a person, zero friction for the agent to act. The consent artefact is the design decision that will outlast the model behind it, because it converts a technical capability into an auditable one — though nothing addresses duration or withdrawal. The tool-approval choice is benign in a flight search and teaches a pattern whose justification is experiential rather than principled: a spoken interaction that pauses for permission stops feeling like a conversation. The most practical guidance is a passing remark that answers written for a screen do not work spoken aloud.

Henk Boelman / Microsoft Build

The rare enterprise session that describes the wiring rather than the outcome. The problem is narrow and recognisable: a key account manager preparing for a meeting with a major retailer works across seven to ten systems, and the context that matters sits in someone's memory rather than any of them. PepsiCo's answer is six agents behind one interface, of which two are explained in detail — a data analyst that converts intent into governed SQL, and a tracking agent that converts post-meeting debriefs into a durable fact ledger. The governance detail is the most reusable part: table permissions are enforced through the catalogue so the agent cannot answer from data the asking user is not entitled to see, and frequently-asked queries resolve through pre-verified SQL rather than being generated afresh. Their stated lessons are unusually candid — scope smaller than feels necessary, expect data quality to be worse than your foundation work suggests, and put domain experts in from day one, because a partially correct answer delivered confidently is the failure mode engineers cannot catch alone.

Rishabh Saha / Microsoft Build

Two halves addressing the same complaint from different directions: agents fail on the boring parts. Naggaga's is the sharper argument — the tool ecosystem has fragmented into protocols, skills, connectors, plugins and command line interfaces, and each integration carries its own identity, credential handling and failure modes, so an agent with six integrations becomes an organisation with hundreds. Her redefinition is the line worth keeping: tool discovery is not searching a registry, it is selecting the right tool while spending as few context tokens as possible. Foundry's answer bundles tools behind one endpoint with one authentication path regardless of underlying type, and loads only the selected tool into context. Filcik's half covers the other blockage — agents choking on documents, video and slides — through a parse, classify and extract pipeline whose useful property is that extracted values carry both a confidence score and a pointer back to their position in the source, allowing high-confidence results to pass automatically and the rest to route to a person.

Ronak Chokshi / Microsoft Build

The organising observation comes from watching coding agents: they are remarkably good at local file access, navigating a repository and forming an understanding, because everything is local and cheap to read. The limit is what happens when knowledge lives in systems an agent cannot walk at volumes it cannot read. What follows is a bottleneck of rate rather than accuracy — a person issues a query, reads, refines and repeats a handful of times, while an agent may issue ten searches or several rounds of twenty because asking costs nothing and it is exploring rather than looking something up. Latency budgets calibrated to someone waiting for a page become dominant when multiplied twentyfold inside one task. The infrastructure argument generalises: agentic load is unpredictable in a way application load is not, so paying per use sidesteps a capacity decision nobody has the information to make.

Paulo / Microsoft Build

The recommendation at the end is the most immediately usable advice from this conference: use the larger model for planning and a cheaper automatic selection for implementation, based on the team analysing what their own conversations actually cost. The expensive model earns its price where a wrong decision propagates, and stops earning it once the plan is settled — a finer distinction than per-task selection and a larger saving. The candid moment is worth more than the feature. Context switching between agents is described as an unsolved problem, visible in user testing and in the team's own experience, and it burns you out. That is the cost nobody prices when demonstrating parallel agents: six concurrent sessions produce six streams of work in different states, each requiring reconstruction before you can usefully intervene, and human working memory does not multiply.

Harald Kirschner / Microsoft Build

Structured as a timed competition rather than a talk, which turns out to be its value: four engineers build the same collaborative markdown editor in parallel using four different agent surfaces, and their divergent methods are visible rather than described. Kirschner opens with a research agent surveying existing products, then three parallel design explorations, before writing any code. Reddington splits roles across models, using one as planner and another as implementer. Kasper runs a single high-reasoning pass from a generated specification file, then switches models when the first one's interface work degrades. Running underneath is Dodds coaching the host through the same problem, and his method is the most transferable: he does not write plans, he holds a conversation, deliberately asking questions whose answers he already knows so the agent accumulates the architectural context before being told to proceed. The safety framing is worth noting too — they run in a hosted development container specifically so the agent can be given blanket permission without exposing local credentials.

Burke Holland / Microsoft Build

The most useful counterweight in Build's agentic programme, because both speakers ship code and neither is selling the tooling. Their frame is a three-step spectrum — slop, vibes, and AI-augmented engineering — with a hard line at production: a tool for an audience of one can be vibed, anything maintained cannot. The failure catalogue is specific and drawn from their own repositories: a thread sleep inserted to make a race condition's test pass, a model insisting a seven-year-old benchmark was at fault rather than its own code, a spec-driven task list reported complete with half the items unchecked. Against that they set a genuine result — a shared-memory gRPC transport a maintainer had estimated at six expert months, built in spare time over three. The distinction they draw is sculpting rather than prompting. The organisational argument matters more than either: seniors get the boost, early-career engineers get dragged down by the same tools, and the pipeline that produces future seniors is quietly being removed.

Mark Russinovich / Microsoft Build

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

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

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.

Jeff Holland / Microsoft Build

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

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.

Anacuma / Microsoft Build

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

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.

Sachin Patney / Microsoft Build

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

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

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

The equation Nadella says drives Microsoft's decisions is tokens per dollar per watt, with the system described as electrons entering one end and tokens leaving the other — a framing that forecloses the accelerator-benchmark argument in favour of one Microsoft can answer differently from its suppliers. Two claims sit beside each other. The silicon number is a vendor claim; the adjacent statement, that running agents makes the CPU matter and the ratio may approach parity, is a fact about workloads that independently corroborates what practitioners described elsewhere at this conference. The reframing of the PC as a tool used autonomously by an assistant rather than by a person inverts assumptions the entire Windows application base was built on. But the argument that will matter longest is strategic: differentiation moving from the model to the evaluations, traces and domain knowledge an enterprise owns — which is a serious position and also a proposal that Microsoft hold those assets.

Satya Nadella / Microsoft Build

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

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