Maria Naggaga spends a minute correcting a definition, and the correction is the most useful thing in the session.
Tool discovery, she says, is not searching a registry to find the right tool. It is selecting the right tool for a task while spending as few context tokens as possible (5:01).
Those are different engineering problems with different solutions, and conflating them is why agents with access to many tools perform worse than agents with access to few.
The arithmetic nobody puts on a slide
Her setup is a single agent for field operations with six integrations: identity, a document store, a ticketing system, a custom endpoint, chat, blob storage, search. The room agrees this sounds manageable.
It is not, and the reason is that each integration carries its own identity model, its own protocol, its own credential handling and its own failure behaviour. Multiply by the other agents an organisation runs — customer support, billing, network, inventory — and six becomes hundreds (8:21). Permissions, failure handling and debugging are not in that count.
The consequence she names is where the cost actually lands: developers spend their time on integration rather than on the thing that differentiates their product.
The fragmentation is not going to resolve itself
Tooling has not converged on one protocol and shows no sign of doing so. Her list runs through API specifications, agent protocols, connectors, skills, command line interfaces, hooks and plugins, and her aside is the honest one — whatever comes next will be added to it.
This is worth stating plainly because a common planning assumption is that the ecosystem will settle and standardising early on the eventual winner is the safe move. Her position is that betting on convergence is the risk, and that the abstraction has to survive the fragmentation rather than wait it out.
Bundling, and the part that saves tokens
Their answer bundles tools behind a single interface regardless of underlying type, so the agent does not need to know what a given tool actually is (9:21). Consumption is through one endpoint with one authentication path, reusable across agents rather than reconfigured per agent (10:03).
The demonstration makes the case better than the description. Configuring three protocol servers directly consumes roughly seventy lines of authentication code, most of it repeated; the bundled equivalent is a few lines and a generated URL.
But the feature that addresses her redefinition is the search step. Rather than loading every tool the agent nominally has access to into the context window, a search selects the one the task requires and loads only that (14:40). This is the token argument made concrete — an agent with access to two hundred tools pays the context cost of one.
Alongside it, browser automation shipped as a first-class tool built on an existing automation framework, covering scraping and form completion (17:02).
The other blockage: documents
Joe Filcik's half addresses a problem that shows up wherever agents meet real enterprise content, which is that the content is not in an API. It is in a slide deck, a scanned contract, a video.
Agents handle this badly by default. They write ad hoc code to open the file, miss content, mishandle tables, and consume tokens doing it. The alternative he describes is a pipeline — parse, classify, extract — applied uniformly across modalities, producing structured output rather than text of unknown fidelity (25:59).
The property that makes this usable in production is not extraction accuracy. It is that each extracted field carries a confidence score and a pointer back to its position in the source document (29:29). That combination is what permits selective review: high-confidence extractions pass automatically, the remainder route to a person, and the person can see exactly where the value came from rather than re-reading the file.
Anyone who has tried to operationalise document extraction will recognise why this matters. The blocker is rarely accuracy in aggregate. It is that without per-field confidence, the only safe policy is reviewing everything, which removes the reason for automating.
Found versus built
Filcik draws one distinction late that is worth more than the feature it introduces.
Some answers exist in a document and need finding. Others have to be constructed by reasoning across it — which clause survives a chain of amendments, what caused a failure described across several sections (30:57). Extraction handles the first. The second requires something that reads more like an investigation than a lookup, and it is the case he flags as the harder one.
The distinction generalises past documents. A great deal of disappointment with retrieval systems comes from asking questions of the second type and receiving answers produced by machinery built for the first. Naming the boundary is more useful than any particular tool for crossing it.
关键数据
- 6 → hundreds
- how integrations multiply once an organisation runs several agents 8:21
演讲章节
关键要点
- 01
Tool discovery is redefined as selecting the right tool for a task while consuming as few context tokens as possible — not as searching a registry, which is the interpretation she argues is wrong. 5:01
- 02
The integration arithmetic is the core problem: six integrations on one agent, each with separate identity, protocol and credential handling, becomes hundreds once an organisation runs several agents. 8:21
- 03
A toolbox bundles tools of any type behind a single consistent interface, so the agent does not need to know whether the underlying tool is a protocol server, an API specification, a skill or a connector. 9:21
- 04
Consumption is through one unified endpoint with one authentication path, reusable across every agent rather than reconfigured per agent. 10:03
- 05
Tool search loads only the tool required for the task into the context window, instead of every tool the agent nominally has access to. 14:40
- 06
Browser automation built on an existing automation framework shipped as a first-class tool, covering page scraping and form completion. 17:02
- 07
Document handling runs as a parse, classify and extract pipeline across every modality, rather than leaving the agent to write ad hoc code against each file type. 25:59
- 08
Extracted fields are grounded back to a position in the source document and carry a confidence score, which is what makes selective human review possible rather than reviewing everything. 29:29
- 09
The distinction drawn for a forthcoming agentic extraction mode is between answers that can be found in a document and answers that must be built by reasoning across it — such as which clause survives a chain of amendments. 30:57
提及的实体
相关演讲
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.
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.