Most of this session is a tour of a platform. The part that will still matter in a year 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.
The three kinds
The first is assistive: an agent that acts as an extension of the person operating it, inheriting their access and working within their session (39:02).
The second is autonomous: it runs in the background, can be assigned permissions directly on cloud resources, and can be triggered by something other than a human (39:02). And it carries a specific limitation — the tools available in the assistive case are not available here (39:28).
The third has its own user account, with an email alias, the ability to send messages and create documents on its own behalf (39:57).
That progression is not about capability in the model sense. It is about what the organisation's identity system is willing to grant, and the limitation on the middle tier is the informative part: an autonomous agent loses access to the tools that were reachable through a person, because those tools were reached through that person's identity in the first place.
Why this is the real design decision
Everything teams argue about — which model, which framework, how the prompts are structured — sits above a question that is settled earlier and changed less easily.
An assistive agent inherits the permissions of whoever runs it, which makes it powerful and makes it stop when they stop. An autonomous one runs continuously and can only reach what has been explicitly granted, which is safer and narrower. An agent with its own account is a principal in the directory, and everything that follows — audit trails, offboarding, what happens when it acts wrongly — is an identity-management problem rather than an AI problem.
Choosing the third means creating an entity that participates in the organisation's systems the way a person does. The session presents this as a capability improvement. It is also an administrative commitment, which is why deploying one requires approval through the administrative centre (41:19) rather than a deployment pipeline.
What the harness abstraction is for
Their definition of an agent harness uses a vehicle analogy: the model is the engine, and an engine alone is not useful without wheels, steering and everything else that makes it drivable (4:04).
The concrete payoff is that attaching one brings tools and context compaction without additional work (26:47). Compaction is the interesting inclusion. Keeping a long-running agent within its context limits is a problem every team solves, badly and repeatedly, and it is genuinely the sort of thing that belongs in a framework rather than in application code.
The demo detail that reveals most about operating these things is the maintenance routine: the agent curates its own skills, deleting ones that have gone stale (14:01), on a schedule rather than continuously, because the environment it needs is not kept running permanently.
Two things follow from that. Accumulated capability decays and needs pruning, which nobody plans for. And a persistent agent is not persistent — it is a set of stored state plus a sandbox that gets recreated, with a retention policy attached (19:30) and a backup arrangement the operator has to design themselves (19:03).
The unglamorous truth in the demo
At one point the connection to a document store fails mid-demonstration (12:11), and later a session has to be recreated because the network was poor (19:03).
Live demos fail and that is not a criticism. But it illustrates the actual operational character of these systems better than the architecture slides do. An agent running remotely, holding state in a sandbox, reaching services over a network, is a distributed system with the failure modes of a distributed system. The harness supplies the car around the engine. It does not supply the road.
关键数据
- 30 days
- retention window before an unused agent sandbox file system is removed 19:30
演讲章节
关键要点
- 01
An autonomous agent can hold permissions directly on cloud resources and be triggered by something other than a person. 39:02
- 02
The autonomous tier loses tools that the assistive tier could reach, because those tools were reached through a human identity in the first place. 39:28
- 03
The third tier has its own user account, alias and ability to send messages and create documents on its own behalf. 39:57
- 04
Attaching a harness brings tools and context compaction without additional work, which is the strongest argument for the abstraction. 26:47
- 05
The agent prunes its own stale skills on a schedule, because accumulated capability decays and the environment is not kept running permanently. 14:01
提及的实体
相关演讲
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.
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.
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.
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.
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.
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.