ai:knowledge
An AI knowledge base for agencies: answer from your context, not the open web.
By Loan Laux · September 10, 2026 · 9 min read
An AI knowledge base for agencies is a curated, retrieval-ready collection of your own material (won proposals, SOPs, client context, past decisions) that your AI tools pull from before they answer. Without one, every model falls back on the open web and produces the same competent-generic output your competitors get from the same tools. With one, the same model drafts in your voice, scopes like your senior people, and cites the project where you solved this exact problem before.
The build is less technical than agencies expect and more editorial: most of the work is deciding what goes in, keeping it current, and connecting it to where your team already works. This post covers what belongs in the knowledge base, three architecture tiers from zero-code to a proper retrieval pipeline, and the failure modes that turn it into an expensive folder of stale PDFs. It pairs naturally with custom agents, which are only as good as the context they can reach.
Why your AI output sounds like everyone else's.
Ask a frontier model to draft a proposal, a QA plan, or a client email and you get fluent, structurally sound, completely generic output. Not because the model is weak, but because it knows nothing about you. Its training data is the open web plus everyone's public best practices, so its default answer is the average of every agency's blog.
Your actual differentiation lives in material the model has never seen: the proposal that won the client, the SOP that survived contact with a real launch, the postmortem on the project that went sideways, the pricing logic behind your rate card. An AI knowledge base is the mechanism that puts that material within the model's reach at answer time, so retrieval grounds the output in your work instead of the internet's median.
This is the same principle behind retrieval-grounded proposal automation, applied to the whole agency instead of one workflow.
What belongs in it (and what doesn't).
Start from the questions your team actually asks and the drafts they actually produce, then work backwards to the documents that would ground them. The usual core:
:
Won proposals and SOWs
Your best five to ten, not all of them. These carry your scoping logic, pricing structure, and positioning in a form models use well.
:
SOPs and process docs
How you run QA, launches, handoffs, and reporting. If it isn't written down yet, that gap is the first finding.
:
Client context
Per-client brand rules, terminology, stakeholders, and history. The material that makes output usable for this client rather than a client.
:
Decisions and postmortems
Why you chose this stack, what went wrong on that build. The judgment layer that keeps AI answers from repeating old mistakes.
:
Rate cards and service definitions
What you sell, how it's priced, what each service includes and excludes. Grounds every scoping and sales draft.
The three tiers of an AI knowledge base for agencies.
You do not need a vector database on day one. Escalate through three tiers and stop at the first one that answers your team's real questions:
01:
Project knowledge in tools you already pay for
Claude Projects let you upload documents that ground every chat in that project, shared with the whole team on Team and Enterprise plans. Notion's AI search answers questions from your workspace and connected apps with citations. Zero engineering, live in an afternoon.
02:
Connectors to where documents already live
Through MCP, Anthropic's open standard for connecting AI to external systems, Claude reads your Google Drive, Notion, or Slack directly. No copying files into a second system that drifts out of date; the source of truth stays the source of truth.
03:
A retrieval pipeline, when agents need it
Documents chunked, embedded, and indexed for similarity search, using something like pgvector if you already run Postgres. Justified when custom agents or client-facing products need programmatic retrieval with access controls, not before.
The build, step by step.
01:
Inventory what you'd trust
Walk your drives and wikis and list the documents you would hand a sharp new hire on day one. That list is usually far shorter than the folder count suggests, and that's fine.
02:
Curate ruthlessly
Exclude drafts, duplicates, and anything outdated. Retrieval has no judgment: if the 2023 rate card is in there, it will surface next to the current one and the model can't tell which is true.
03:
Structure for retrieval
One topic per document, descriptive titles, a date and an owner on everything. Split the 80-page everything-doc; a retriever pulls passages, and a passage from a well-titled, single-topic page lands with its context intact.
04:
Connect it where work happens
Wire the knowledge base into the chat tool, the coding assistant, and any agents, via project knowledge or connectors. A knowledge base only reachable through a separate portal is a wiki with extra steps.
05:
Test with real questions
Collect twenty questions your team actually asked this month and check the answers against ground truth. Wrong answers trace back to missing, stale, or badly structured documents. Fix those, not the prompt.
06:
Name an owner and a rhythm
One person owns the knowledge base. New proposals and postmortems flow in as part of project close-out, and a quarterly prune retires what stopped being true.
Where each kind of knowledge should live.
Not everything belongs in the same layer. A practical split:
| Knowledge | Best home | Why |
|---|---|---|
| Stable process (SOPs, checklists, voice rules) | Skills or project instructions | Procedural knowledge the AI should apply, not look up |
| Reference material (proposals, case studies, rate cards) | Project knowledge or a curated library | Retrieved and quoted when a task matches |
| Living documents (client docs, tickets, meeting notes) | Source tools, reached via connectors | Changes daily; copies go stale the day you make them |
| High-volume history (all past projects, archives) | Embedding index with metadata | Too big for uploads; only needed programmatically |
Knowledge base or Skills? Both, for different jobs.
Agencies who have read our Claude Skills guide ask where skills end and the knowledge base begins. The line is procedural versus referential: a skill tells the model how to do a task your way (the QA checklist, the proposal structure, the brand voice rules), while the knowledge base is what it consults for facts (what we quoted last time, what this client's stakeholders care about, what the postmortem concluded).
In practice they compound. A proposal skill that encodes your structure, pulling from a knowledge base of won work, produces drafts that are both shaped like yours and grounded in your history. Either alone gets you halfway.
Where this breaks.
The failure modes are consistent across every agency we've seen attempt this:
- The dump-everything launch. Pointing the AI at the whole shared drive feels thorough and poisons the well: retrieval surfaces the abandoned draft as confidently as the final version. Curation is the product.
- No owner. Six months in, the knowledge base describes the agency you were, and the team quietly stops trusting answers. Staleness is a governance problem before it's a technical one.
- Ignoring access boundaries. Client A's context must not surface in client B's drafts, and NDA material needs the same walls it has everywhere else. Per-client separation and permission-aware connectors are requirements, not polish.
- Building tier three first. An embedding pipeline over uncurated documents is engineering spent making bad retrieval faster. The editorial work is the prerequisite for every tier above it.
Do it yourself, or bring us in.
Tier one is genuinely a do-it-yourself job: a senior person, a week of curation, and project knowledge in the tools you already run. Where agencies stall is the unglamorous middle, when the curation backlog meets client work and nobody owns the prune, or when agents need real retrieval and the build crosses into engineering.
That's the shape of our involvement too: our AI engineers build the retrieval layer alongside your team when tier three is justified, and managed operations keep the knowledge base current, permissioned, and trusted after launch, because a knowledge base nobody maintains is worse than none at all.
Frequently asked questions.
Do we need a vector database for an agency knowledge base?
Usually not at first. Project knowledge uploads and connectors to your existing tools cover most team-facing use, with no engineering. An embedding index (pgvector on a Postgres you already run is a common choice) becomes worth it when custom agents or client-facing products need programmatic retrieval over more material than uploads can hold.
How is this different from our existing wiki?
The wiki is where humans go to read; the knowledge base is what your AI tools consult before they answer. They can share documents, and connectors mean the wiki can be a source. The differences are curation (only material you'd stand behind) and reach (it's wired into the tools where drafts actually get written, not waiting to be searched).
How do we keep client data from leaking between accounts?
Separate client context by boundary the tools enforce: one project per client rather than one pile, permission-aware connectors that respect your existing access rules, and per-client collections with access controls if you build a retrieval pipeline. And keep credentials and anything you wouldn't paste into a team-visible doc out entirely.
How much maintenance does it actually need?
Steady but small, if it's designed in: adding the proposal and postmortem at each project close-out, plus a quarterly prune of what stopped being true. Budget a few hours a month with a named owner. The expensive version is the neglected one, because a knowledge base that returns stale answers trains the team to ignore it.
Where should we start?
Curate your ten most-trusted documents into a shared project this week and have the team run real questions through it. You'll learn more from twenty real answers than from any architecture debate. If you're unsure this is your highest-value move, an AI workflow audit will rank it against the alternatives.