Your AI agent already knows your website. Your knowledge base is for everything else.

Why a knowledge base full of your homepage teaches your AI agent nothing

The most common mistake with a support widget's knowledge base is filling it with things that are already true of the website it sits on. Your pricing page, your feature list, your about page: the widget can already see all of that, because it's embedded right there on your site. Pasting your own marketing copy into the knowledge base doesn't add information. It just repeats what the widget already had access to.

A knowledge base earns its keep by covering the things that are true about your product but aren't written down anywhere public. That's a much shorter list than most teams expect, and it's usually sitting in your support history already, not in a document someone needs to write from scratch.

What actually belongs in it

A known bug and its workaround belongs in a knowledge base. If support has been telling every customer who hits a specific Safari rendering issue to try a specific setting change, that's exactly the kind of answer an AI agent can give instantly instead of making the customer wait for a human to remember it.

The reasoning behind a policy belongs there too, not just the policy itself. "Refunds are handled case by case" tells a customer nothing useful. "We generally refund within the first thirty days if the account saw limited use, and ask for more context after that" is something an agent can actually apply to a real question.

Internal terminology belongs there as well, especially anything customers use that doesn't match what your own team calls it. If your product has a feature customers keep referring to by an old name, or a workflow your team has an internal shorthand for, writing that mapping down once means the agent stops getting confused by it forever.

Specific beats summarized every time

An entry that says "there are some known issues with the mobile app" helps nobody, including the AI agent trying to answer from it. An entry that says exactly which version introduced a bug, what the symptom looks like, and what to tell a customer to do about it right now is something the agent can actually quote back accurately. If you already know the specific answer, write the specific answer. Summarizing around it just reintroduces the vagueness a real support agent would never accept from a person.

System prompt versus knowledge base

These two things get confused constantly, and the distinction is simple once you see it. The system prompt controls how the widget behaves: its tone, how it handles a frustrated customer, what it should never promise, whether it asks one clarifying question at a time instead of a list. The knowledge base holds facts: specific, checkable things that are true about your product today. Behavior goes in one place, facts go in the other, and mixing them up is usually why a widget either sounds robotic or gives confidently wrong answers.

Where to start with zero entries

Nobody starts with a finished knowledge base, and trying to write one from a blank page is the reason most never get built. The realistic starting point is your own support history. Pull up the last month of conversations, or ask whoever handles support directly, for the five to ten questions that come up again and again that would never make it onto a help center page. Those are usually the exact things a customer would otherwise wait on a human for, and they make a far better first knowledge base than anything written to sound complete.

Attractable's Knowledge Base sits right in the dashboard for exactly this: paste in an answer or upload a file, and the widget treats it as the first place to look before it ever has to guess.