Write it for a reader that takes every sentence literally and cannot ask a colleague. One topic per article, conditions in full, no "usually" without the exceptions, an owner and review date on every page, and explicit notes on what must not be said. Then test the agent against it and fix the articles, not the prompt.
What goes wrong with knowledge bases written for people?
People fill gaps from experience. A help article that says "refunds usually take a few days" is fine for a support worker who knows card refunds take longer than wallet refunds and that weekends do not count. An agent reads "a few days" and repeats it to a customer whose refund will take ten.
Human-oriented articles also mix audiences, and old versions linger because nobody deletes them. Two articles cover the same topic with slightly different answers. People cope by knowing which one the team actually uses. An agent retrieves whichever matches the question's wording best. The basics of what a knowledge base is and how teams usually organise one are in what a knowledge base is.
What are the practical steps?
- One topic per article. "Returns for opened items" and "returns for unopened items" are two articles, not two paragraphs in one. Retrieval works on chunks; mixed articles return mixed answers.
- State conditions in full. Who it applies to, which products, which channels, which countries, from what date. If an answer differs for business customers, say so in the article, not in someone's head.
- Replace vague words. "Usually", "normally", "in most cases" become the actual rule and the actual exceptions. If the honest answer is "it varies", say what it depends on.
- Separate customer-facing and internal text. Mark internal notes clearly so the agent can use them for routing but never quote them.
- Write the "do not say" lines. For sensitive topics, include what must not be said: no estimates of claim outcomes, no reasons for fraud blocks, no legal advice.
- Give every article an owner and a review date. An article with no owner goes stale. An expired review date should drop the article from the agent's sources until it is checked.
- Delete, do not archive in place. Retired articles must leave the agent's retrieval entirely. "Outdated" banners do not stop a model quoting them.
- Test and fix. Replay real questions. When the agent answers wrongly, look first at the article it retrieved.
What does a rewrite look like?
Before: "Refunds are usually processed within a few days. Contact us if you haven't received yours."
After:
| Field | Content |
|---|---|
| Topic | Refund timing after a return is accepted |
| Applies to | All consumer orders paid by card or digital wallet |
| Rule | Refund is issued within 2 working days of the return being accepted at the warehouse |
| Then | Card refunds appear within 5 working days of issue; wallet refunds within 1 |
| Exceptions | Orders paid by gift card are refunded as gift card balance, same day |
| Do not say | Do not promise a date the bank will show the refund |
| Hand over when | The refund was issued more than 10 working days ago and has not appeared |
| Owner | Payments operations lead |
| Review by | Set date, six months from last review |
That structure lets the agent answer correctly for each case, say what it cannot promise, and know when to hand over.
Does the agent need a knowledge graph instead?
Not to start. Well-structured articles get you most of the way for support. A knowledge graph helps when answers depend on relationships between many facts, such as which product version works with which plan in which country. The trade-offs are covered in what a knowledge graph is and whether AI agents need a knowledge graph.
An illustrative example
Take a regional water company with one long article on bills, covering estimated readings, direct debits, payment plans and disputes. The agent kept mixing them: a customer asking about an estimated bill was told how to set up a payment plan.
The team split the article into six, each with conditions and a hand-over line. Payment plans got a "do not agree plans; hand over" note, because plans needed an affordability conversation with a person. In replay, the mix-ups stopped, and the payment-plan questions now reached people with the reason already stated.
What controls keep it usable?
- Owner sign-off on every change, with a version number the agent's filed answers can reference.
- A gap log from refusals. Every time the agent says it cannot confirm something, the question goes to the article owner.
- Channel notes. Some answers differ by channel, such as what can be discussed by email versus in the app; see which channels a support agent may use.
- Case notes feeding back. What staff write after contacts often shows a missing article; see writing case notes after every contact.
Where Pryme fits
In Pryme, approved articles reach the agent through the Pryme Context Protocol with their owner and version attached, so a filed answer shows exactly which text it relied on. Attest's grounded gate fails answers that go beyond the article. More is in the AI support agent that knows when to say no.
Questions people ask
Can the agent write knowledge base articles?
It can draft them from resolved cases for an owner to review and publish. It should never publish to its own sources.
How long should an article be?
As long as one topic needs and no longer. Short, single-topic articles retrieve more reliably than long ones.
Should customers and the agent read the same articles?
Ideally yes, with internal notes hidden from customers. One source means the agent and the help centre cannot disagree.