The instruction file: write the job down before it runs

Give an agent a big document and a library and ask it to do a thorough review. It will decide as it goes what to read, what to skip and what to check each part against. Sometimes those decisions are good. You only find out which afterwards, and the next run will make different ones.

The alternative is old-fashioned: write the job down first, have someone approve it, then run exactly that.

From index to plan

The Wordhouse has a short index, one line per topic saying what it covers. Wordhouse The model reads that index alongside the confirmed structure of the incoming document Structure first and proposes, for each part, which topics it needs. Clause 9.2 needs limitation of liability and indemnities. Clause 14 needs data protection and the AI addendum. The definitions need nothing on their own.

A person looks over that map and confirms it. Then it becomes the instruction file: a fully mapped task plan in which every part of the document has its topics, its instructions and the exact shape of the output it must return. Nothing runs until it exists, and nothing runs that isn’t in it.

Small rooms, clean context

The plan is then run as small jobs, grouped by topic. One job loads the liability topic once and works through every clause routed to it, wherever those clauses sit across the bundle. Another does payment terms. Each job sees what it needs and nothing that competes with it.

That is the compartmentalising the hub talks about. A single prompt holds every clause against every other clause at once; each job here works in a small, quiet room. Internal policy and instructions go in with the topics they apply to, rather than sitting in one long preamble everything has to wade through.

In the benchmark, this is where consistency came from. The pipeline gave the same classification to 14 of 15 planted departures in all three repeat runs. The single prompt managed 7. BigDocs: the benchmark

Is this just retrieval?

Letting a model choose from short descriptions instead of searching embeddings is not new. Andrej Karpathy’s LLM Wiki, LlamaIndex’s document summary index, “vectorless” retrieval tools such as PageIndex, Anthropic’s Agent Skills and the llms.txt convention all use a version of it, and they deserve the credit.

Two things are different here. The choices are made over a topic library, not over the raw documents. And they are fixed as a confirmed plan before anything runs, rather than searched for on the fly. You can read exactly what each job was given and why, before and after.

There is a practical benefit for anyone without an engineering team: there is no vector store to build, host or tune. The index is a text file.

Why approval matters

The approval step looks like a formality. It isn’t. It is the point where a person who knows the business can say “that clause is really about insurance, not liability” before the mistake is multiplied across a hundred findings. It also leaves a record: what the system was asked to do, by whom, and when. That record is what an assurance review will ask for, and most self-built tools can’t produce it.

What your team can do on Monday

Before the next big-document job, write a one-page plan: each section of the document, what it should be checked against, and what you want back for each. Give it to the model as the instructions, not the document alone. Even done by hand, you will see the answers become steadier, and you will know what you asked for.