Because nobody told it the facts. A model knows a great deal about the world and nothing at all about your pricing, your process, or the four things your team refuses to do. When you ask it to write about your business, it fills those gaps with plausible invention.
Most teams respond by writing longer prompts. That works once, then someone else asks a slightly different question and the guessing starts again. The prompt is not the problem. The missing information is.
An internal knowledge base fixes this properly. It is a small, deliberate set of documents that state what is true about your organisation, written so a model can read them. It is less work than it sounds, and it is the single highest-value AI project most small teams are not doing.
It is a set of plain text documents describing your business, stored somewhere your AI tools can read, and kept current. Not a wiki full of meeting notes. A curated set of facts, decisions, and constraints that anyone, human or model, would need in order to represent you accurately.
The difference from a normal company wiki is intent. A wiki accumulates. A knowledge base for AI is pruned, because everything in it competes for attention and anything wrong in it will be repeated with total confidence.
Think of it as the briefing you would give a very capable contractor on their first morning. What you sell, who for, how you work, what you charge, what you have said publicly, and what you never claim. That is the whole scope.
Six things, and not much else. Your services and what each includes. Your pricing model. Your process and typical timelines. Your verified facts and numbers. Your voice and terminology rules. And your list of things you must never claim.
That last one carries more weight than people expect. A document that says "we do not state a founding year", "we never quote client results that are not on the public case study page", and "we never describe ourselves as the best in a category" prevents a specific class of error that is otherwise very hard to catch in review.
Verified facts deserve their own file with sources attached. If your homepage claims a number, write it down along with where it came from and when it was last checked. This is the file that stops a model repeating a figure that was true two years ago.
Leave out anything you would not want quoted. Internal debate, half-formed strategy, and anything confidential should stay out, because the whole point of the exercise is that this content gets used in output. Our guide to stopping AI from making your blog sound generic covers the voice half of this in more depth.
Plain markdown, short files, descriptive headings, one topic per file. No tables of contents, no clever cross-references, no PDFs. A model reads text, so give it clean text with structure that signals what each section contains.
Front-load every section with its conclusion. A heading that says "Pricing" followed by three paragraphs of context is worse than one that says "Pricing" followed immediately by the model and the ranges. Retrieval systems tend to pull sections, so each section needs to make sense alone.
Write in complete, self-contained sentences. "Usually four to eight weeks" is a fragment that means nothing out of context. "A standard marketing site build usually takes four to eight weeks from kickoff to launch" survives being pulled into a completely different conversation.
Keep files small enough to read in one sitting. If a file has grown past a few pages, it is probably two topics and should be split. Small files also make it obvious when something is out of date, which is half the maintenance problem solved.
Wherever your team already works, with a copy your tools can reach. In practice that means one of three places: a folder of markdown files in a Git repository, a dedicated space in Notion or Confluence, or a project workspace inside the AI tool itself.
We favour the Git repository for anything a developer touches. You get version history, review on changes, and the files sit next to the work. When someone changes the pricing document, it goes through the same review as a code change, which is exactly the level of care that file deserves.
Notion and Confluence win when non-technical people own the content, which is often the right answer for voice and positioning documents. The tradeoff is that changes happen quietly and nobody reviews them, so pair it with a scheduled read-through.
Project workspaces inside AI tools are the fastest to set up and the easiest to let rot, because the content lives in one product and nobody else can see it. Fine for a personal workflow. Not where your company facts should live permanently.
The Model Context Protocol is an open-source standard for connecting AI applications to external systems. It matters here because it is how a tool reaches a live source of truth rather than a copy someone pasted in three months ago.
Its own documentation offers the clearest analogy: "Think of MCP like a USB-C port for AI applications." One standard connection, many possible sources on the other end. Instead of building a bespoke integration per tool per data source, you connect once.
Support is broad rather than vendor-specific, which is the main reason to take it seriously. MCP is supported across Claude and ChatGPT as well as development tools including Visual Studio Code and Cursor, so a server you stand up is not tied to whichever assistant your team prefers this year.
Do you need it on day one? No. Start with files. Move to MCP when the answer needs to be live rather than written down, like current project status or what is actually in your CMS right now. We went through the practical cases in our article on what an MCP server is and why web teams should care.
No, and this is the most common objection we hear. Large context windows mean you can paste more in. They do not mean the right information gets pasted in, stays current, or is the same for everyone on the team. Capacity is not curation.
There is a quality argument too. A model given twelve tightly written pages about your business will represent you better than one given four hundred pages of everything you have ever published. Extra volume adds noise, and noise includes your outdated claims sitting alongside your current ones with nothing to distinguish them.
The organisational argument is stronger still. A knowledge base is a shared artefact. When one person improves the pricing document, everyone benefits on their next task. A long prompt someone wrote in a chat window helps exactly one person once, and disappears.
So treat context capacity as headroom rather than strategy. It removes the excuse that your documents will not fit. It does not remove the need to write them.
It makes sending the same documents repeatedly much cheaper, which is precisely the usage pattern a knowledge base creates. Anthropic documentation describes prompt caching as letting you resume "from specific prefixes in your prompts", reducing both processing time and cost for repeated context.
The numbers are worth knowing if you are building this into a workflow. Anthropic prices cache writes at 1.25 times the base input token price and cache reads at 0.1 times. For Claude Opus 5, with base input at 5 dollars per million tokens, that works out to 6.25 dollars per million for a five minute cache write and 50 cents per million for a cache hit.
There is a floor to be aware of. The minimum cacheable prefix varies by model, from 512 tokens on the newest models up to 4,096 on some others, and Anthropic states plainly that "shorter prompts cannot be cached, even if marked with cache_control". A tiny knowledge base will not benefit.
The default cache lifetime is five minutes, measured from the start of the request that writes or reads the entry. That suits a working session rather than an occasional question, so the saving is real for automated pipelines and modest for a person asking one thing a day.
Give every file an owner and a review date, and put the review in the calendar. A knowledge base that nobody owns is worse than none, because people trust it. Wrong information delivered confidently is the specific failure mode you are trying to prevent.
Tie updates to events rather than to a schedule where you can. When pricing changes, the pricing file changes in the same piece of work. When a case study goes live, the verified facts file gains its numbers that day. Event-driven updates survive busy quarters in a way that quarterly reviews do not.
Date every claim inside the files. "Average project timeline, last confirmed August 2026" tells a future reader whether to trust it. An undated fact is indistinguishable from a guess after about six months.
Finally, check the output. Read what your tools produce and look for anything about your business you cannot trace back to a file. Those are your gaps, and they are the most efficient way to find what is missing. Our guide to writing prompts that actually help with web work covers how to ask in a way that surfaces these.
Write two files this week. One called facts, listing every number and claim you make publicly with its source and the date you last checked it. One called constraints, listing what you never say. Those two prevent most of the errors that matter.
Add the services, pricing, and process files next, then the voice document. Five short files will cover most of what a model needs to represent you accurately, and you can write all five in an afternoon if you stop trying to make them comprehensive.
Resist building tooling before you have the content. Teams get excited about retrieval systems and MCP servers and end up with excellent plumbing connected to three out-of-date paragraphs. The documents are the hard part and the valuable part.
If you want a second pair of eyes on what your AI tools should know about your business, or you keep catching invented details in your own content, we are happy to help you sort it out. Get in touch at phoenix.studio and we will talk through what to write down first.
Tell us where you want to go. We'll tell you how we'd get you there.