Agentic AI

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.

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.

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.

Microsoft Build

Bennett puts an eleven-line agent on screen and runs it repeatedly: pass, pass, pass, fail, fail, fail. It works about half the time, and nothing in the code says so. That breaks the debugging method conventional software allows, because every test run becomes a sample rather than an observation and a fix appears to work when you happen to draw three passes. His demonstration is the argument: changing the model and rerunning raises the success rate to around ninety per cent with no change to the application at all. The number matters less than the method — he knows the change worked because he measured a rate before and after, and without instrumentation the swap would have been indistinguishable from luck. The uncomfortable implication is that if model choice moves reliability that far with no application change, most published comparisons of agent patterns are reporting noise around a variable they did not control.

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.

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.

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.

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.

Microsoft Build

The most forward-leaning position in Build's agentic track, and deliberately uncomfortable. Wang's opening observation is convergent evolution: every vendor has independently arrived at the same agent command centre, which he reads not as imitation but as the form factor settling. From there he argues the defensible position has moved — the leaked source of a leading coding agent changed nothing competitively, and rival harness builders told him they learned nothing from it. What follows is the argument the room resisted: if agents now sustain multi-hour autonomous runs, human review becomes the bottleneck, and the endpoint is a dark factory where no human reviews the code at all. He does not present this as desirable. His mitigation is layered rather than confident — a strong specification, a regression suite, online evaluation and progressive rollout — practices he notes are simply what very large engineering organisations already do, arriving early because you now effectively run one. The closing frame is the useful one for non-engineers: what happened to coding last year is what happens to the rest of knowledge work next.

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.

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 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.

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 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.

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 Build

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.

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.

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.

Microsoft Build

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.

Microsoft Build

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 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.

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 I/O

The distinction Reese draws early is the one that matters: an embodied reasoning model is not a vision model bolted to a robot but the logic unit of the system, fine-tuned on robotics data for spatial understanding, and reasoning about a scene's physics rather than its pixels. That collapses the seam between perception and planning where most traditional robotics failures lived, because the planner no longer receives categories with everything uncategorisable discarded. The browser-based demonstration carries an argument about access as much as capability, since robotics has been gated on hardware and a physics engine in a browser moves the constraint from equipment to ideas. The session's sharpest moment is its last: a model that hallucinates in software produces a strange recipe, and the same error rate attached to something exerting force is a different category of event — a gap of orders of magnitude, not an increment.

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.

Google I/O