Book a time

BigDocs

The Agentic Wordhouse: a dimensional model for your words

Peter O'Hanlon, founder of Koncura · Part 3 of 10

BigDocs: part 3 of 10

The benchmark behind this series: see the results

Most organisations keep their words the way their systems keep transactions: one document per occasion. This customer’s contract, that customer’s contract. Last year’s tender, this year’s. Every employment agreement, every version of the leave policy, every answer support has ever written about single sign-on. It is an operational store of words, and like any operational store it is perfectly good at recording what happened and poor at answering questions across it.

What do we usually accept on intellectual property? What notice period have we agreed before, and with whom? What did we say about encryption at rest in the last five security questionnaires, and were we consistent? To answer any of these from the raw documents you have to read everything that might hold the answer, and most of what you read has nothing to do with the question. Hand that pile to a model and you have built the Stroop test into the prompt.

Standing on the LLM Wiki

The closest relative of this idea, and its best-known one, is Andrej Karpathy’s LLM Wiki, published in April 2026. Raw sources stay untouched in one folder. An agent compiles them into a wiki of linked markdown pages, keeps an index the agent reads first instead of loading everything, and periodically tidies the wiki for contradictions and stale claims. No vector database, no embedding pipeline. It is a smart idea and I’d recommend reading it.

The Wordhouse is a logical extension of it rather than a new idea. It reuses patterns from knowledge and data management, and it points them at a different job. The LLM Wiki is built for getting information out of a large corpus, so it sensibly lets the wiki maintain itself. The Wordhouse is built for making decisions in a focused domain, so it is deliberately reviewed by people. The result is less a wiki and more a decision store.

Three ways to store words for a model

The operational store. Documents as they were written. Complete, but every question means reading the lot.

Embeddings. Chop the documents into pieces, turn each piece into a vector, and retrieve the pieces that look most like the prompt. Fast and clever. But it retrieves what is semantically similar to the question, and relevance is a broader idea than similarity. An intellectual property clause may depend on a definition of “deliverables”, a confidentiality carve-out and a licence-back in a services schedule. Those are relevant to the decision and look nothing like each other, or like the question.

The Wordhouse. Like a data warehouse, it holds precomputed dimensions across the raw operational corpus. The dimension here is the topic. Each topic gathers everything that belongs together for a decision, whatever it looks like, so the work at run time is cheap: open the topic, and the right material is already there.

Word-marts

A data warehouse is usually organised into marts, one per business area. The Wordhouse works the same way. A legal word-mart holds the major groups of clauses that turn up again and again in blended, alternative forms: intellectual property, limitation of liability, data protection, termination. An HR word-mart holds notice, leave, restraint and overtime. A sales word-mart holds the question families from tenders and security questionnaires. A support word-mart holds product capabilities.

Inside a topic, each instance carries more than the wording:

  • the exact source text, copied verbatim, with where it came from and when;
  • our position on it: accept, negotiate or reject;
  • a risk assessment;
  • the alternatives and fallbacks we can offer;
  • when to stop and send it to a person;
  • links to related topics.

Those links matter. Intellectual property links to confidentiality and to the definitions. An agent working a clause can follow them, so the Wordhouse can be traversed like a knowledge graph when a decision reaches across topics.

Owned and reviewed, not self-maintaining

Because each topic holds decisions, each topic has an owner. Legal owns intellectual property and liability. HR owns notice and leave. The bid lead owns the security answers. The owner reviews changes to their topics before they count, and that review is a human-in-the-loop point built into the design rather than a check bolted on at the end.

This is the main difference from the LLM Wiki, and it follows from the job. A wiki over thousands of sources can’t wait for people to approve every page, and doesn’t need to. A word-mart of twenty topics that decides what the business will sign should wait, and can, because it is small enough to read.

It is also less rigid. There is no required metadata header on each file and no particular tool to read it in. Each topic is a markdown file with structure inside it: the decisions, positions, dates, risks and links sit in the body, where the owner reads them. Open it in Obsidian, a text editor or anything else; it is just markdown.

The question is how an agent finds its way to the right topic. Vectors are strong here; they are fast. Full documents are far too much. The Wordhouse uses a third route: a summary of each topic sits in an index, and the agent reads the index and chooses. Not so much self-query as vectorless query.

In BigDocs the agent doesn’t choose on the fly. It proposes which topics each part of the incoming document needs, a person confirms it, and that becomes the instruction file. The instruction file Each loop then works with focused content from a few topics, nothing that competes with it, and its output accumulates into the final result.

There is almost no infrastructure. The Wordhouse is a folder of markdown files and an index. Nothing to host, nothing to tune, and a lawyer, an HR manager or a bid writer can open any topic and read it like a briefing note.

Building it, and the real cost

The cost of a warehouse is building and maintaining it, and the same is true here. Topics can come from three places:

  • seeded from what you already know: the groups your lawyers, HR team or bid writers already use;
  • extracted from the structure of the documents themselves, their headings, clause types and schedules;
  • proposed by an agent as it reads.

It stays flexible. Topics can be split when they grow too broad, merged when two turn out to be the same thing, and deduplicated when the same position arrives from several sources. An agent can suggest that maintenance or carry it out, but the topic’s owner approves it before it counts. Maintaining the Wordhouse

What it bought in the benchmark

In the benchmark, a legal word-mart was built from Common Paper’s standard agreements plus a short policy layer: 22 topics and 174 positions. Because every position has an identifier and a source, the pipeline named a checkable position for 85 to 87 percent of the clauses it reviewed, and every position it named existed. The single prompt, working from the same paper and policy in raw form, cited a source in between 1 and 17 percent of its reasons. It had nothing fixed to point at. BigDocs: the benchmark

That is the return on the Wordhouse. It gives every decision something to stand on.

What your team can do on Monday

Pick one recurring big-document job. List the ten topics that come up every time. For each, gather the last five times you dealt with it and put them in one file, word for word, with where each came from and what you decided. You will learn more about your own positions from that afternoon than from any amount of prompting, and you will have the start of a word-mart.