Why a smaller information surface gets you better answers

The instinct is to pour everything in

The first time a team builds with a vector database, the default move is to point ingestion at everything. All the docs, all the spreadsheets, all the meeting notes, all the policy PDFs — one big upload, one big index, one tidy mental model.

It also produces worse answers than you’d get from a smaller, scoped index. The reason is structural, not about model quality.

What “semantic proximity” actually does

Embeddings work by placing text in a high-dimensional space, where things that mean similar things end up near each other. That’s what makes them useful — you can find content by meaning, not by exact words.

It’s also blunt. A paragraph about “parental leave” from your HR handbook lives near a paragraph about “extended absence” in your customer-support playbook, because those phrases share meaning even though they belong to different domains. They sit close in embedding space whether you wanted them adjacent or not.

In a single giant index, every search pulls candidates from across that whole space. Ask the HR assistant about leave policy and the support playbook comes back too, ranked plausibly enough that the re-ranker can’t always sort it out. The candidate pool was polluted from the start.

The graph-traversal problem

This effect gets worse the bigger and more interconnected the corpus is. Large knowledge bases traverse incorrectly — a query about one project drifts into adjacent projects with overlapping vocabulary, the result set mixes facts from three places, and the answer comes back confidently citing all of them.

This is the failure mode that’s hardest to spot, because the answer reads like it should be right. The AI client cites its sources, the sources exist, the text matches — just from the wrong project. You only catch it by going back to the original document, which is exactly what people stop doing once they trust the system.

Scope is the fix

Bounding the retrieval surface up front avoids both problems. One bucket per concept or project, each with its own MCP endpoint, each searched independently. The customer-support assistant only ever queries the support bucket. The HR assistant only ever queries the HR bucket. Board minutes live in their own bucket and never accidentally surface in unrelated conversations.

This is the structural argument for buckets. It’s also why Laminae doesn’t ship a “point us at your whole drive” mode — scoping is the point. The team decides what each bucket is about, the search surface stays bounded, and the answers don't drift.

What good scoping looks like in practice

In our experience three rules of thumb get you most of the way: one bucket per business function, one bucket per active project, and one bucket per long-running domain (a policy library, a year of board minutes, a customer-support handbook). When in doubt, split. Buckets are cheap; bad answers are not.

Big indexes feel impressive on the demo. Small, scoped ones do better work the day after.