Anthropic’s Wiki Recipe Pairs a Smaller Model With Prepared Knowledge

Anthropic’s document-wiki tutorial became easier to try on November 6: a commit merged in anthropics/claude-quickstarts replaced its separate, gated Dreams dependency with an explicit Managed Agents workflow. The wiki is a reusable set of linked document notes, stored outside the model’s weights. Builders can change the prompts, models and inputs used to prepare those notes before an agent answers questions.

The promising experiment is specific: can preparation let a cheaper model answer repeated questions well enough to replace a more expensive one? Anthropic reports a quality gain for Haiku on its worked example. They also show why “fifteen times cheaper” needs both halves of the comparison: Haiku using a wiki versus Sonnet searching raw documents.

A wiki the builder can change

The linked Markdown notes live in a Managed Agents memory store. They prepare relationships that passage search may leave the answering agent to assemble: names for the same entity, revised figures, or disagreements between documents. A product-support agent, for example, could consult prepared notes connecting a feature’s requirements and exceptions instead of reconstructing them for every question.

The worked corpus uses public filings about a completed acquisition, with two marked synthetic companion files. Its instructions distinguish a company’s reported figure from an estimate calculated on another basis. That is the useful ambition: preserve the qualification alongside the number, so later answers can carry it forward.

The rebuild makes that preparation an editable sequence. Extractors file document batches; a resolver investigates priority gaps; analyzers check the filed material; an organizer consolidates the wiki and repairs links. The lead agent writes and starts the workflow. Its instructions require later stages to stop if a document batch still cannot be extracted after retry. The intended safeguard is concrete: unread documents must not be mistaken for documents that say nothing.

This is substantial upfront work. The analyzers must reread their source batches in full, verify related notes and preserve unresolved conflicts. Their instructions require targeted edits and read-backs because concurrent writers can replace one another’s changes. The organizer then runs alone. Builders can tune these stages, including which work merits a stronger model.

What the smaller model gains

Anthropic’s notebook at the November 6 revision reports a 21-question benchmark over 27 runs, graded by two model judges. The comparison uses Haiku 5.5 and Sonnet 5.5. Scores are out of 100; answer costs are at list price.

The same-model alternative matters. Raw-document Haiku was already inexpensive. Preparation raised its reported score by three points while lowering answer cost modestly. Wiki-assisted Haiku came within 0.9 points of raw-document Sonnet. That supports testing a different allocation of work: spend on preparation to help the smaller model approach the larger model’s answers.

The README puts the benchmark’s average build at about $19 and cost recovery against raw-document Sonnet at about 240 questions. That arithmetic assumes the reported mean answer costs continue. Refreshes and human validation add work; a corpus that changes frequently, or receives few questions, has less opportunity to repay preparation. The notebook’s separate saved six-question sample is not the benchmark behind those quality scores.

Access still runs through Managed Agents beta. The current README says it is enabled by default for API organizations and directs permission failures to an administrator; removing Dreams from this recipe does not establish access for every account.

We inspected the public implementation and saved outputs without running the service. The benchmark questions and answer keys are absent, and two prompts differed from the shipped wording. The recipe also acknowledges lost content on busy shared pages. Citations and source-checking instructions do not establish completeness; the later read-only question sessions cannot repair missing knowledge.

For a support team considering this approach, the next useful signal is whether Haiku keeps answering real, recurring questions correctly after the documentation changes—and how much rebuilding and checking that requires. A stable corpus with repeated questions is the workload worth measuring first.