company-context-builder

The last section is the one everyone skips. It turns each document into a declaration of its own blast radius, so changing a belief tells you what to go fix. The third is the one people resist. A labeled gap makes an AI say "your documents do not say." An unlabeled guess makes it answer confidently and wrong.

### Apply the new-hire test
Read each file and ask: would I hand this to someone on their first day and expect them to qualify a deal correctly.

If no, it is not done. The most common failure is a file that describes the ideal customer beautifully and never says who to walk away from.

The third file is the one nobody writes and the one that fixes the most. An AI handed only an ICP will qualify everything in, because it has no basis to say no. Handed disqualifiers, it can refuse. That single file improves output more than the other three combined.

Sixteen-part frameworks collapse into these four. Most of the extra parts are one of three things: evidence that already lives in your CRM, something that changes monthly and is therefore not foundation, or a different view of one of the four.

Writing the files is half the job. Nobody reading them is the other half. Climb these in order and stop when it works.

Rung one: yourself

The failure mode is forgetting. You will not remember to attach the files, and any system that depends on you remembering has already failed.

Load the context at the tool level, never at the conversation level. In Claude Code, that is a line in your project instructions. In Claude or ChatGPT, that is a project with the files loaded, and that project is where this work happens.

The rule: never attach, always inherit. If you are attaching a file, enablement is broken.

Rung two: your team

Five to fifty people. The failure mode is copies drifting.

• One shared AI project. Everyone works inside it.
• One named person re-uploads when a file changes. Not a team. A person. If it is nobody, it is already dead.
• Staleness is silent, so detect it: once a month, ask the shared project your CHECK question. Wrong answer means the upload is stale. That is the entire monitoring system and it takes thirty seconds.

Most companies never need rung three. Be honest about whether you do.

Rung three: your organization

Fifty plus, multiple teams, agents running in production. Copies stop working because you cannot re-upload to forty projects.

Now you need live reads, in order of effort:

1. Raw file URLs plus a token. Agents are happy, humans cannot use it, zero build.
2. A small internal site that rebuilds when a file changes. Humans get a URL, agents can fetch it. This is the right answer for most companies and almost nobody does it.
3. An MCP server. Agents get real tools instead of a wall of text. Most work, highest ceiling.

What makes it organizational is not the technology. It is two process hooks: a new hire gets the path on day one, and every new tool gets connected to it during setup. The market expectation now is that tools ship an MCP. If your context has an address, every tool you buy inherits your company's brain on day one instead of starting blank.

The most common mistake after this conversion is keeping the files in two places and syncing them.

Two copies that must agree is a job, and nobody runs it. Six weeks later they disagree and nothing tells you which is wrong. You have not built a backup, you have built a second source of truth with a delay.

One home. Links everywhere else. The other tool holds a link, not a copy. When you outgrow the home, move the files. Do not start mirroring them. If you genuinely need both, the copy is pulled automatically by a machine and no human ever touches it.

Run this once, at the start, to settle the argument about whether the tool is the problem.

Hold the tool constant. Vary only the format. Same question, same assistant, three sources:

1. Your existing deck
2. A plainly written document saying the same thing
3. The four documents, once written

Ask all three: "Is this account a fit, and would we walk away from it? Answer yes or no first."

What you will see, in order: the deck returns both sides and commits to nothing. The plain document returns an answer and misses the walk-away half. The four documents answer both halves and cite themselves.

That comparison is the whole argument. It is not Drive versus Notion versus anything else. The tool never moved. Only the format did.

Do not run this as a tool comparison. Testing your Drive against someone's Notion changes two variables at once and you learn nothing about which one broke.

Run both before you call this done. Both take under two minutes.

The qualifier test. Give marketing's AI and sales's AI the same real account. Ask each to qualify it in or out, with the reason. Different answers means they are reading different context. The same answer with different reasons is nearly as bad.

The disqualifier test. Ask "what would make us walk away from this deal." A generic answer means there is no disqualifier file and the AI is improvising.

A measured example of what failing looks like. One real ICP deck, run through an AI connector: roughly 17,000 tokens of which most was layout, the connector refused it on size, and when it did parse, it returned both sides of every qualifier. The document could not say no to anything. A search of the same company's Drive for "ICP" returned over thirty candidates, ranked a competitor's template first, and included four byte-identical copies. A Notion page read came back with pixel column widths to fourteen decimal places and several hundred empty cells.

None of those documents were badly written. They were unreadable to a machine, which in 2026 means unused.

The skill refuses to do these things, and you should too.

• Never write a claim no source supports. A gap gets labeled as a gap, not filled with a plausible sentence.
• Never resolve a contradiction on your behalf. It surfaces conflicts and waits. The human decides.
• Never produce more than four files on the first pass. More files is the next problem, not this one.
• Never recommend changing tools before changing format. Drive is not the problem. Thirty formatted documents are the problem.
• Never claim the context is live when it is a copy. If someone re-uploads by hand, say so and name them.

Everything above gets you four documents that are true today. They were opinion when you wrote them, the market moves, and nothing will tell you when they stop being true. Staleness never throws an error. The assistant keeps answering confidently from a nine month old belief and you find out when a deal dies.

So the last piece is a loop, and it has four parts.

What feeds it. What actually closed and what actually lost. Call transcripts. And the observation nobody captures today: when five discovery calls in a row surface a pain that appears nowhere in your documents, the documents are behind the market. A manager is the only person positioned to notice that, which makes managers a sensor rather than an audience.

What it produces. Proposed edits. Specific, cited, one per claim. "Three of the last eight closed lost deals hit a pattern that is not in who-we-say-no-to. Here is the proposed line."

Who runs it, and who owns it. These are two different jobs and conflating them is why loops die.

The gate that matters. Proposals, never automatic edits. A document that rewrites itself is a document nobody trusts, and the first silent wrong edit ends the whole project. The owner clicks accept. That is the entire governance model and it needs no committee.

Run it monthly. The month it produces nothing is useful information too.

This method came out of trying to point AI at real GTM documents and watching it fail confidently rather than loudly. The failures above were measured, not imagined. The fix was not a better tool. It was four plain files and one person who owns each.