If We Want Them to Do Knowledge Work, Design Them as Knowledge Agents

Benjamin Clavié, Mixedbread17:55 · Sept 2026 · 13K views
Thumbnail for If We Want Them to Do Knowledge Work, Design Them as Knowledge Agents Watch on YouTube
TL;DR
  1. 1

    Coding agents work well partly because code has durable, searchable cues and narrowly defined tasks.

  2. 2

    Knowledge work needs both better search tools and organizational patterns that break open-ended problems into specialist research tasks.

  3. 3

    Searcher agents that return short memos reduced the gap between human and agent performance by about 40% on the benchmark described.

Summary

Benjamin Clavié argues that coding agents are an unusually easy case of knowledge work. Code has stable identifiers, file paths, method definitions, and clear tickets. Legal, medical, and financial work has implicit meaning, ambiguous clues, and questions whose intent must be reconstructed during the search. Humans have dealt with this through two connected systems: tools such as catalogues, bibliographies, and search engines, and organizations that divide work among specialists. Clavié applies the same pattern to agents. Search quality determines whether a task is affordable enough to use, while orchestration determines whether an agent can handle an open-ended question. In the examples he gives, optimized retrieval reaches high accuracy with fewer tool calls, and specialized searcher agents produce memos for a main agent. This architecture reduced the benchmark's oracle gap by about 40%. His final advice is to design agents around knowledge work rather than copy programming workflows.

Key ideas
03:42

Coding agents succeed because code has unusually durable search cues

Clavié says code is a special form of knowledge. Codebases contain identifiers, file paths, method definitions, and keywords that remain relatively stable and can be searched directly. Coding tasks also come with narrow instructions, such as implementing a feature or closing a ticket. Users do not usually ask a coding agent to invent a programming paradigm and build an application around it. These stable cues and bounded tasks make coding easier than open-ended legal, medical, or financial research.

05:05

The same phrase can mean different things in non-code knowledge work

The example of "30 days" shows why ordinary search is not enough. An agent finding that phrase in a document has to determine whether it refers to a deadline, a grace period, or a retention rule. It may even retrieve a medication schedule when the user is searching a contract. In legal work, the agent also has to infer the intended rule, identify the relevant domain, and decide whether that rule applies to the specific case. Meaning depends on context rather than a stable code-like cue.

05:55

Humans improved knowledge work through connected tool and organization loops

Clavié traces one loop from writing things down to the catalogue of the Library of Alexandria, bibliographies, library classification, and search engines. A second loop moves from the single gifted expert to monasteries, universities, bureaucracies, and specialized firms. He argues that these are really one process. New tools create new workflows and roles, which produce more knowledge and create demand for better tools. The people using a new tool also need to learn what it does and how their work changes.

08:06

Search quality decides whether a knowledge task is affordable to repeat

Tools are not neutral add-ons. Clavié says a task may be possible without a good tool but too expensive to perform regularly. He compares a library catalogue with searching through an uncatalogued collection, and a map with exploring without reliable geographic information. In the benchmark he discusses, a badly optimized retrieval tool reaches about 60 percent accuracy, which is too unreliable to trust. Optimization raises performance, while fewer tool calls reduce the cost enough to make the workflow usable.

09:22

BM25 needs a tuned baseline before it can be judged

Clavié cautions that there is no single BM25 setup. BM25 is a method for lexical search, and implementations or configurations can be optimized to different degrees. On the BrowseComp-Plus benchmark, the badly optimized version performs poorly, while tuned systems reach much higher accuracy. The strongest result he describes reaches 90.2 percent accuracy with 20 percent fewer tool calls. Compared with the unoptimized baseline, the system uses about 5 percent of the original spending.

11:14

Real knowledge work starts with decomposition by a senior decision-maker

Clavié uses a law firm workflow to explain the difference between coding tasks and knowledge tasks. A client first explains a problem to a partner, who identifies the facts, relevant laws, and aspects that need research. Assistants then investigate those parts with the tools they know and write memos. The partner may check a clarification, but relies mainly on the assistants' findings. An open-ended agent needs the same division of work because the initial question has not already been broken into a linear ticket.

12:42

Better tools can expose a ceiling that even human searchers cannot pass

In the MQA benchmark example, Clavié says an optimized BM25 system reaches the same ceiling for a human and Gemini 3. He does not interpret that as evidence that Gemini 3 matches a human. Instead, the result shows that neither can find the right information with unlimited searches through that tool. Better document handling, vision, and multimodal search move the ceiling higher by allowing the system to work with PDF layouts, tables, and images rather than relying only on OCR text.

13:31

Searcher agents close part of the gap by returning focused memos

Clavié's searcher-agent design asks a main agent to break a large question into subqueries. Separate searchers investigate the important aspects and return short memos, which the main agent uses to form the answer. On the benchmark he describes, this raises accuracy by 3.5 points. The oracle gap, defined as the difference between having perfect documents and the actual search system, falls from about 10 points to about 6. Clavié describes that as roughly a 40 percent reduction in mistakes.

15:13

Knowledge agents need trained tool choice and explicit orchestration

Clavié says agents should be designed around the way legal, medical, and other knowledge organizations divide work, rather than around programming workflows. An agent should know when to use grep-like lexical search, BM25, or semantic search over a PDF. These are primitives that models need to understand as different tools. Since context is finite and expensive, a main agent also needs an orchestrator and specialist searchers that organize information before it reaches the final answering step.

"The right orchestration of search will get you much better results because context is a finite resource."16:49
Who should watch
  • You are building agents for legal, medical, financial, or research workflows and need to understand why coding-agent patterns do not transfer directly.
  • Your retrieval system is expensive or unreliable, and you want a concrete way to think about tool tuning, search ceilings, and tool-call cost.
  • You are deciding whether to add subagents and want an example of using specialist searchers that return memos to a main agent.