The most expensive way to use AI is to drag your PDF in every time

The default pattern

Somebody on your team has a question about a policy document. They open their AI client, drag the PDF in, ask the question, get the answer. The interaction takes a minute. It works. Tomorrow, someone else has a different question about the same document — they open a fresh chat and drag the same PDF in again. So does the third person, and the fourth.

This is the path of least resistance and it’s how most teams actually use AI today. It also has two problems that don’t show up until the bill arrives or the answer goes sideways.

Problem one: you’re paying to prepare the same text every time

Before an AI model can reason over a document, the client has to turn it into something the model can use. For a small file that means pushing the text straight into the model’s context; for a large one it means chunking and embedding it so the relevant parts can be retrieved. Either way the work is real and metered — paid for in tokens, in processing, in waiting for the upload to finish.

The catch is that this preparation is scoped to the conversation. Every fresh chat starts from zero, so the same PDF gets re-processed — re-embedded or re-injected — each time someone opens a new one. The project and workspace features the AI companies ship only move the boundary: the preparation is still redone far more often than the document ever changes. Same text, same work, same money. Multiply across a policy library, a claims handbook, and a customer-success team using AI a dozen times a day, and you’re paying to prepare the same content thousands of times a month.

None of this work has to be redone. Once a document is embedded, the embeddings are reusable forever — they describe the document, not the question being asked of it. A knowledge layer that caches them server-side turns that recurring bill into a one-time cost.

Problem two: large documents quietly fail in chat

Every AI model has a context window: a hard ceiling on how much text it can hold in memory at once. The ceiling has been getting bigger every year, and people have started to assume it doesn’t matter. It still matters.

Drop a 200-page contract into a chat. The client either refuses, truncates silently, or paginates through the document in passes — and in every case, parts of the document fall out of working memory before the model finishes thinking. The answer that comes back looks confident, because the model is always confident, but it’s grounded in whatever fragment happened to be in context at the moment of generation. The bits the model couldn’t see get filled in by a probability engine.

The fix is to stop sending the whole document. If retrieval can find the three paragraphs that actually answer the question, the model only needs those three paragraphs in context — the rest of the budget goes to reasoning. Answer quality improves at the same time the token bill drops.

What it looks like when you stop doing this

A knowledge layer that sits between your documents and your AI client cleans both problems up at once. Documents get embedded once, on ingest, and the embeddings persist. When a question arrives, only the matching chunks travel into the model’s context. The same document can answer ten thousand questions and the embedding cost is paid exactly once.

This is what Laminae does. Buckets manage the storage and the embeddings; MCP exposes them on an open standard so any AI client connects without a custom integration. Your team keeps using the AI client they already like. The repeated upload pattern just quietly stops being the way work gets done.

The cost story isn’t the only argument for building a knowledge layer — provenance and auditability are arguably bigger ones — but it may be the easiest one to explain to whoever signs off on the AI budget.