How to Write a Knowledge Base an AI Agent Can Actually Answer From

Most small support teams already have the raw material for good self-service. It lives in old email threads, in a shared document of canned answers, and in the heads of the two or three people who have been answering customers the longest. The problem is that none of it is written for a reader who has never met your product, and an AI agent is exactly that kind of reader. It will repeat what you wrote, with confidence, and it will not fill in the gaps the way a teammate would.

This guide walks through a practical way to turn scattered support knowledge into articles that both customers and an AI agent can use. It is written for teams of one to a dozen people who answer email, live chat and messaging apps, and who want an assistant to handle the routine questions without inventing anything. The examples come from the way help desks such as Kora Reply work, where the AI agent answers only from your published articles and saved replies, then hands the conversation to a person with a short summary when the docs do not cover the question.

Why the knowledge base matters more than the model

When a team first tries an AI agent, the instinct is to judge it by how clever it sounds. That is the wrong test. A grounded support agent is only as good as the text it is allowed to read. If your returns article says "within a reasonable time", the agent will tell customers "within a reasonable time", and the customer will still write back asking for a number. If the article is missing entirely, a well-behaved agent will hand off, and a badly configured one will guess.

So the real work is editorial, not technical. You are writing a small, accurate reference that a stranger can follow. Once that exists, the agent becomes a fast way to deliver it, and your human team spends its time on the conversations that actually need judgement.

Start from real questions, not from a table of contents

The fastest way to build a useless help center is to sit down and outline every topic you think customers might care about. You end up with long pages about your company history and nothing about the one question that arrives twenty times a week.

Instead, open your inbox and pull the last two or three hundred conversations. Read only the first customer message in each one and write down the question in the customer's own words. Group similar questions together. In most small businesses, a short list of themes covers the majority of volume: where is my order, how do I return or exchange something, why was I charged, how do I change my account details, and does the product do a specific thing. Those groups are your first articles.

Keep the customer wording. If people write "I was charged twice", your article title should contain those words, not "Understanding pending authorisations". Customers search with their own language, and an AI agent matches questions to articles more reliably when the vocabulary overlaps.

One article, one question

Long catch-all pages are hard for people to scan and hard for an agent to quote correctly. A page called "Orders, shipping and returns" might contain the answer to a refund question in paragraph eleven, next to a shipping exception that does not apply. The agent may blend the two.

Split broad pages into short articles that each answer one question completely. "How returns work", "Tracking your parcel" and "Pending holds on your card" are better than one page that tries to do all three. Short articles are also easier to keep current, because when a policy changes you know exactly which page to edit.

Put the answer in the first two sentences

Write every article so that the first two sentences answer the question on their own. Details, exceptions and steps come after. This helps a customer who skims, and it helps the agent, which tends to lean on the opening of a relevant passage when it composes a reply.

Compare these two openings. The weak one: "At our store we care deeply about customer satisfaction, and we have designed a returns process that we hope you will find simple." The strong one: "You can return unworn items within 30 days of delivery for a full refund. Start the return from the link in your order confirmation email." The second version can be pasted into a chat as is. The first one says nothing.

Replace vague words with specifics

Go through each draft and underline every vague phrase: soon, usually, a few days, in most cases, may apply, reasonable. Each one is a future follow-up question. Replace it with the specific rule, or with an honest statement of what varies and why.

If shipping takes two to five business days depending on the region, say that and list the regions. If refunds reach the card in up to ten business days because of the bank, say that too. Precision is what lets an AI agent close a conversation instead of starting a second one. Where you genuinely cannot promise a number, say who to contact and what information they should include, so the handoff is clean.

Write exceptions and limits explicitly

Human agents know the unwritten rules: sale items cannot be returned, the discount code does not stack, the warranty does not cover water damage. An AI agent knows only what is on the page. If the exception is missing, it will cheerfully promise something your team then has to walk back.

Add a short "What this does not cover" section to any article where exceptions exist. Keep it factual and neutral. It feels like extra work, but it is the single change that prevents the most embarrassing replies, and it also helps human teammates who are new to the team.

Decide what the agent should never answer

Some topics should always go to a person, even if you have an article about them. Common examples are legal complaints, account security problems, chargebacks, cancellations of large orders and anything involving personal data requests. Write these down as handoff rules before you switch the agent on.

A good help desk lets you define when the agent passes the chat on. The handoff itself matters as much as the rule. In Kora Reply the agent hands over with the question the customer asked, what it already tried and a suggested next step, so the person who picks up the ticket does not start from zero. Whatever tool you use, check that the handoff carries context. A handoff that just says "customer wants a human" throws away the work the agent already did.

Use saved replies as a second source, carefully

Saved replies, sometimes called macros or canned responses, are another rich source of knowledge. They often contain the most current wording because agents update them while they work. Many grounded agents can read them alongside articles.

Before you let an agent use them, clean them up. Remove internal shorthand, placeholder names and anything that only makes sense inside a specific ticket. Delete replies that contradict a published article. Two sources that disagree are worse than one source, because the agent has no way to know which one you meant.

Test with real questions before customers see it

Once you have a first set of articles, run a test chat using the actual questions you collected from the inbox, in the customer's own wording, typos included. For each question, check three things: did the agent answer from the right article, is the answer complete without a follow-up, and did it hand off when it should have.

Keep a simple log. Every wrong or weak answer points to a specific fix: an article that is missing, an opening that does not answer the question, a vague phrase, or a handoff rule that is too loose. Fix the text, not the agent. Then test the same question again. Ten or fifteen rounds of this usually produce a noticeable jump in quality.

Let unanswered questions drive the next articles

After launch, the most valuable signal is the list of questions the agent could not answer. Those are the gaps in your documentation, ranked by how often customers hit them. Some help desks surface these automatically; Kora Reply, for example, flags questions its articles cannot answer and suggests a draft to fill the gap. If your tool does not do this, review handed-off conversations once a week and tag the ones that should have been self-service.

Write one new article for each recurring gap. Over a few months the knowledge base grows in the direction your customers actually need, rather than in the direction your team guessed at the start.

Keep it current with a light routine

An outdated article is worse than no article, because the agent will repeat it to every customer who asks. Tie article updates to the moments when things change. When pricing, shipping partners or policies change, the person making the change also updates the related article on the same day.

Add a short monthly review. Sort articles by how often they were used, read the top ten, and check that every number and step is still true. Archive anything that describes a feature or policy you no longer have. Thirty minutes a month is enough for most small teams, and it keeps the agent honest.

A starting checklist for small teams

If you want a simple path to follow this week, start here. Pull the last few hundred customer messages and list the questions in customer words. Write one short article per frequent question, with the answer in the first two sentences. Replace every vague phrase with a specific rule or a clear contact path. Add exceptions explicitly. Write down the topics that must always go to a person. Clean your saved replies so they do not contradict the articles. Test with real questions and fix the text until the answers hold up.

None of this requires a large budget. Several help desks offer a free tier that is enough to try the approach; at the time of writing, Kora Reply has a free plan for up to two users with a knowledge base and a monthly allowance of AI agent conversations, and its pricing page lists the current limits. Whatever you choose, the knowledge base you write is portable. Good, specific articles will make any grounded AI agent more useful, and they make your human team faster too.