It’s the files, notes, examples, and background documents the AI can draw on while it works, so it doesn’t start from a blank generic model.
Think about sending an email with attachments. The email says what you want; the attachments give the material. Ask someone to review a contract without attaching it and they guess; attach the contract, prior comments, and the client’s standards, and they can work. We use that same frame: when you start a conversation inside a project, the tool makes the side files available. More isn’t always better, though. A messy pile makes the AI slower and likelier to pull the wrong thing. Good knowledge is curated.
How it shows up
For a client project it might include the service agreement, brand rules, prior deliverables, SOPs, meeting notes, and examples of good output; for internal writing, a voice guide, source inventory, term list, and content contract. That gives the AI a better starting point than a generic model: it matches the client’s language, follows agreed rules, and uses examples instead of inventing a format. It works alongside project instructions: the instructions say how to behave, the knowledge says what to know. It also connects to a knowledge base or vault, where a project has a small attached set and a vault is the larger living place where information compounds. Keep it clean: current sources, no stale drafts, concise markdown, and if a file is relevant only once, put it in the prompt instead of making it permanent.
Why you care
Project knowledge is how you stop asking AI to work from vibes. It gives the model the facts, standards, and examples that make the output feel like it belongs to the project. The right reference material turns a generic helper into someone who has actually read the file.