# Your team keeps re-explaining the same things to a model

**Author:** John Morabito (Founder, /winston)
**Published:** September 20, 2026
**Reading time:** 10 minutes
**Canonical:** https://www.winstondigitalmarketing.com/playbooks/internal-ai-knowledge-base-for-marketing-teams/

Someone on your team typed out what your company does, who it is for, and what you will not say, into a chat window this week. So did someone else, in different words, both versions roughly right. Neither one exists anywhere now that the tab is closed.

Nobody counts this, so nobody notices it. Prompt libraries get built. Procedures get packaged into Skills. The facts underneath both get retyped from memory every time, by whoever happens to be doing the work, and the output varies for reasons that cannot be traced back to anything you can fix.

What is missing is a knowledge base: the stable facts, written down once, that everything else reads from. It is the least interesting layer of an AI setup and the one most likely not to exist.

## Facts, instructions, procedures

Three layers, and most of the trouble comes from running them together.

A **knowledge base** holds what is true regardless of the task. Your positioning. What you charge and how work is scoped. The claims legal will not sign off on. Which client is on which plan. What you tried last year that did not work. None of it tells the model to do anything.

A **prompt** is a reusable instruction for one kind of output. Write the meta description. Draft the follow-up. That is the [prompt library](https://www.winstondigitalmarketing.com/playbooks/prompt-library-for-marketing-teams/), and it is about how to ask.

A **Skill** is a packaged procedure, the steps and the checks and the files it needs, bundled so a model can pick it up and run it without being walked through. [Writing one](https://www.winstondigitalmarketing.com/playbooks/how-to-write-a-claude-skill/) is mostly an exercise in being explicit about a process you have been doing by feel.

Keep them apart because they change at different rates and for different reasons. Facts change when the business changes, and you hear about it from a person. Instructions change when someone works out a better way to ask. Procedures change when the work itself changes.

The way this usually goes wrong is small and reasonable. Someone writes a good prompt and pastes the company boilerplate at the top so the output comes back on-brand. It works, so the pattern spreads. Then pricing changes, and that paragraph is now wrong in every prompt containing a copy of it, and there is no list of which ones those are. A month later some of the library is producing stale output and the rest is fine, and nothing about either one looks different.

So the rule is that a prompt references a fact instead of carrying a copy of it, and a Skill describes a procedure instead of restating the business. If editing one of the three forces you to go edit the other two, they were already merged.

## A drive full of decks is not a knowledge base

The first answer everyone gives is that they already have this, it is all in the drive.

What is in the drive is a few hundred files, and the answer to what you charge for a technical audit lives on slide 31 of something called Q2_pitch_v4_FINAL, next to an org chart and three case studies.

A colleague can find that. They know roughly which deck, and they know to distrust anything with v4 in the name, and they know someone redid the pricing in March. Retrieval knows none of that. It matches on what a file says, and a pitch deck says almost nothing in its body text, because a pitch deck is a person talking over pictures.

Three things source material has to be, which a drive is not:

- **Words, not layout.** Prose that carries the meaning on its own, rather than bullet fragments that only made sense while someone narrated them.
- **One subject per file.** So that a match is a hit rather than a maybe, and so that updating one fact does not mean opening a document about five other things.
- **Complete on its own.** A file that refers to the new rate, or to what we agreed in the offsite, is worthless to anything that was not in the room.

The test is a person. Could someone who started on Monday read only the file the search returned and answer the question correctly, without asking anyone? If not, retrieval cannot either, and for the same reason.

## Write each entry so it survives being found alone

Assume every file will be read by itself, out of order, by someone with no context. That single assumption produces most of the format.

**One topic per file.** Pricing is a file. Pricing and packaging and the approval chain is three files that have been stapled together.

**Head it in the words someone would use to ask.** The first line names the subject plainly. "What we charge and how projects get scoped", not "Commercial framework". Internal jargon is the main reason a file that contains the answer never comes back as a result.

**Date it with the last time a person confirmed it.** Not when it was created. When somebody last read it and said yes, still true. Those are different dates and only the second one is useful.

**Say the thing.** Internal documents are full of phrases like the usual approach, or as discussed. A retrieval hit on that sentence returns nothing anyone can act on. Write out the acronym once. Name the number.

**Leave the voice out of it.** This is not where the brand lives. "We do not take on clients in that category" is a better entry than any sentence about client philosophy, and it is better precisely because it is blunt enough to be checked.

**The single-file test.** Open one entry at random and read only that entry. If you had to already know something to make sense of it, the file is not finished. This catches more bad entries than any review process, and it takes a minute.

## Keep client facts apart

For an agency this is the part with real consequences. Everything above is quality. This one is a phone call you do not want to make.

One client's unannounced launch, their margins, the campaign that failed and the reason it failed, should not be reachable by anyone working on a different account. The awkward part is that the mechanism making a knowledge base useful, one pool of facts that everything can read, is exactly the mechanism that makes this go wrong.

- **A separate store per client.** A distinct project, folder, or whatever the tool's unit of isolation happens to be. Not one store with a client field on each record, because a field is a filter, and a filter is something a person forgets to apply at four in the afternoon.
- **A shared store for what is yours.** Process, templates, checklists, positioning, the things you would teach a new hire. Everything reads that one.
- **Nothing client-specific in the shared store.** Not as an illustration, not anonymized. Anonymized client details stay recognizable to the client they came from, which is the only audience that matters here.
- **Retire the store when the engagement ends**, on whatever schedule the contract specifies, and the same day you turn off the rest of their access.

Then there is the leak that has nothing to do with architecture. Someone has a quick question, pastes a client's real numbers into a general chat window to get it answered, and moves on. No system prevents that. It is a rule you state out loud and restate, and it belongs in the same conversation as the one about how the stores are split.

## Maintenance is the reason these die

The failure mode has nothing to do with the technology. Someone builds the knowledge base during a good week. It is accurate the day it ships. Nothing is wrong with it. Then a price changes, a service gets renamed, a policy quietly reverses, and nobody is assigned to notice. The decay is invisible, which is what separates it from a broken tool. A broken tool announces itself.

Eight months on, the model answers a question with last year's pricing, in the same confident register it uses for everything else. Someone catches it. The credibility of the whole thing is gone by the end of the afternoon, and the team goes back to pasting context by hand, which was the original problem.

Two practices prevent this and both are dull:

1. **Date every entry with its last human confirmation.** This works even when nobody reviews anything, because a file dated eleven months ago tells the reader something a file with no date does not.
2. **Give every entry an owner and a review cadence.** A named person owns the pricing file. Once a quarter they open it and either change the date or change the content. Twenty minutes, on a recurring calendar entry, not on anybody's good intentions.

One rule on top of those: a fact that changes gets changed in the same motion. If new pricing is decided in a meeting, the file is updated that day by whoever ran the meeting. Later is where this dies, every time, because later is the point at which the update stops being anyone's job in particular.

Growth is not a health signal either. A knowledge base that doubles every quarter is usually accumulating duplicates, superseded entries, and one-off notes that were never general. Deleting is maintenance, and the smaller version that people trust beats the complete one they do not.

## How you know it is working

Usage numbers will not tell you. The signal is behavioral, and you can watch for it.

People stop pasting context by hand. Someone opens a chat and goes straight at the task. Draft the follow-up for the dental client, no preamble about who that client is or what they sell or what tone to take. That is the whole test, and until it happens the thing has not landed regardless of how good it looks.

The counter-signal is just as readable. If people still keep a personal copy of the boilerplate in a note somewhere, they either do not trust the knowledge base or find it slower than their own copy. Both are worth asking about directly, because the answer is usually specific and fixable.

Two checks worth running deliberately:

- **Ask the same factual question twice**, from two different projects or two different people, and compare the answers. Two different answers means the fact lives in two places, or in none.
- **Ask for something it should not have.** A question about one client from inside another client's context. If an answer comes back, your isolation is decorative.

## Where to start

Do not start with a taxonomy. The ones that fail usually started with someone designing the category structure for content that did not exist yet.

1. For one week, note every time anyone types a fact into a chat window that was already true the day before.
2. Sort that list by how often it came up. The top ten are your first ten files.
3. Write each one as a single topic, headed in plain language, dated today.
4. Split by account immediately, before there is anything to untangle. Client-specific goes in per-client stores, general goes in the shared one.
5. Give every file an owner and a review date before you write the next file. If no one will own it, do not write it.
6. Stop at ten. Ten entries people trust are worth more than two hundred they check by hand.

The knowledge base is what a prompt library and a set of Skills both assume and neither one supplies. Build it first and both get shorter, because they stop carrying context that was never theirs to carry. Build it second and you spend a month pulling boilerplate back out of everything. If the repetition is worst in your search work specifically, the procedure layer that sits on top of this is [Claude Skills for SEO teams](https://www.winstondigitalmarketing.com/playbooks/claude-skills-for-seo-teams/). Getting all three layers separated, owned, and maintained is most of what we do in an [AI marketing engagement](https://www.winstondigitalmarketing.com/services/ai-marketing/) before any of the more interesting automation is worth turning on.

## Frequently asked questions

### What is an AI knowledge base for a marketing team?

It is the set of stable facts about your business that every AI task needs and none of them should have to be told. Positioning, pricing, what the service lines include, the claims legal will not approve, how each client's account is set up, what you decided last quarter and why. These are facts rather than instructions, they are true regardless of which task is running, and they change when the business changes rather than when someone improves a prompt. Without this layer, people supply the facts by hand at the start of every conversation, slightly differently each time, and the output varies for reasons nobody can trace.

### What belongs in a knowledge base versus a prompt or a Claude Skill?

Facts go in the knowledge base. Reusable instructions for one kind of output go in the prompt library. Packaged procedures, the steps plus the checks plus the files they need, go in a Skill. The reason to keep them apart is that they change at different rates and for different reasons. Paste your pricing paragraph into forty prompts and the day pricing changes you have forty wrong prompts and no list of which ones. A prompt should reference the fact rather than carry a copy of it, and a Skill should describe the procedure rather than restate the business.

### Why is a shared drive full of decks not a knowledge base?

Because retrieval matches on what a file says, and a pitch deck says almost nothing in its body text. It is a person talking over pictures. A colleague can find the pricing on slide 31 of a deck with v4 in the filename because they know which deck and they know to distrust the old one. Retrieval knows neither. Source material has to be words rather than layout, one subject per file so a match is a hit instead of a maybe, and complete enough that a file makes sense read on its own. The test is whether a new hire could answer the question correctly from the file the search returned, without asking anyone.

### How do you keep client information from leaking between accounts?

Give every client its own store, a separate project or folder or whatever the tool's unit of isolation is, rather than one pool with a client field on each record. A field is a filter and filters get forgotten. Keep a shared store for things that are yours, the process, the templates, the checklists, the positioning, and put nothing client-specific in it, not as an example and not anonymized, because anonymized client details stay recognizable to the client. Retire a client's store on the schedule the contract specifies. Then say the rule about pasting out loud, repeatedly, because the likeliest leak is a person dropping real numbers into a general chat window to ask a quick question.

### Why do internal AI knowledge bases stop working?

Maintenance, almost always, and the decay is invisible in a way a broken tool never is. Someone builds it in a good week and it is accurate the day it ships. Then prices change, a service gets renamed, a policy is reversed, and nobody is assigned to notice. Months later the model answers confidently with last year's price, someone catches it, and the credibility is gone in an afternoon. Two practices hold it: date every entry with the last time a person confirmed it true, so a stale file flags itself to the reader, and give every entry an owner who reviews it on a schedule. Add one rule, which is that a fact that changes gets changed in the same motion, not later.