The Context Layer

Every company I've watched adopt AI hits the same wall: the answers are fluent, confident, and useless. The instinct is to feed it more data. That instinct is what keeps it broken.

You connect an assistant to your business. You ask it something an experienced employee could answer in four seconds — "can we rush this customer's order?" — and you get back a paragraph that would apply equally well to a bakery, a machine shop, or a law firm.

So you give it more. You point it at the shared drive. You export three years of Slack. You dump every PDF anyone has ever written. And the answers get worse — not vaguer now, but confidently wrong in ways that are much harder to catch.

The problem was never how much the model could see. It was that nobody had ever written down how the business actually works in a form anything could use. That written-down thing is what I call the context layer, and building one is mostly an editing job, not an engineering job.

More data is not more context

This is the part that takes people a while, so it's worth being blunt about it: an unfiltered dump of your company's files is worse than nothing. Not slower. Not noisier. Actively worse, because it converts a model that would have said something obviously generic into one that says something specific and wrong.

The mechanism is simple. Your shared drive contains the current rush-order policy and also the one from 2019 that nobody deleted. It contains the real price list and four stale quotes. Nothing in the folder structure says which is true. A human knows to ignore the old one because they remember it being replaced. The model has no such memory — it just finds a confident, well-formatted, authoritative-sounding document and uses it.

Play with it. Toggle sources on and off and watch what happens to the same question.

What actually belongs in it

A context layer is not a document repository. It's a written account of how the business operates, maintained deliberately, small enough that a person could read the whole thing in an afternoon.

Never add anything without stating why

This is the single practice that changed my results the most, and it sounds almost too simple to matter.

I don't drop material into a knowledge base. I talk through it first — what this document is, why it's going in, what questions it's supposed to make answerable, and what it should not be used for. Then it gets written in, in a structured form, rather than pasted in raw.

Bad:   [pastes 40-page operations manual]

Good:  This is our operations manual, current as of March.
       I want it in so the assistant can answer questions about
       escalation paths and turnaround commitments.
       Sections 1-3 are org history — skip them.
       Section 7 pricing is stale; we handle pricing live from
       the CRM, so leave it out entirely.

Two things happen. The obvious one: the stale pricing never enters the system, so it can never be retrieved and repeated back to a customer. The subtle one: stating the purpose out loud forces me to notice when I don't actually have one — and about a third of the time, that's the moment I realize the document doesn't need to go in at all.

Every piece of context should be traceable to a question someone actually asks. If you can't name the question, you're archiving, not building context.

Prune as aggressively as you add

The half of this nobody does. A context layer gets better through subtraction at least as often as addition, and the review pass is not optional maintenance — it's the work.

When I review a page I'm asking two questions: where is this thin, and where is it distracting. Thin means a question I'd expect it to answer, that it can't — that gets expanded. Distracting means content that competes with the thing that actually matters, pulling attention toward a plausible but wrong answer — that gets cut, even if it's accurate.

That second category is counterintuitive and it's where most of the gains are. True but irrelevant content is not harmless. It's a distractor, and the more authoritative it looks, the more damage it does.

It decays, and that's the actual business

A context layer is not a deliverable. It's a living thing with a half-life. The business changes, the document doesn't, and the gap between them is invisible until someone acts on a wrong answer.

Here's what that looks like over eighteen months, with and without a monthly review pass.

This is why I think of the context layer as an operating responsibility rather than a project. Somebody has to own it, and the ownership is monthly and forever. That's not a flaw in the model — it's the same reason your CRM rots if nobody tends it.

The loop

If you're starting this week

Don't begin with the shared drive. Begin with one workflow — the one where somebody gets interrupted most often — and write down how it actually works, including the exceptions that live in one person's head. That'll be two or three pages. It will outperform an entire indexed file server, and you'll have it by Friday.

Then resist the urge to scale it before it's correct. A small context layer that's true beats a large one that's mostly true, because "mostly true" is indistinguishable from "true" at the moment someone reads the answer.