Optimize Your Knowledge Base for AI Agents (12 Patterns)

Created time

May 26, 2026 06:10 PM

Title length (<60)

Author

Mike Heap

Ecomm?

How AI agents read your knowledge base differently from your team

⚡

TL;DR: An AI agent reads your KB one chunk at a time, with no memory between answers. Anything that assumed a reader would scroll, click around, or bring context from another article is invisible to the AI.

Here's the bit I think most teams underestimate.

When a human lands on your help center, they skim, then scroll. They click "see also" if a paragraph doesn't fit. They bring whatever they read three minutes ago into the next article.

An AI agent does none of that.

Most AI customer service agents on the market today work through some flavor of retrieval-augmented generation (RAG, the setup that grounds the answer in your actual documents). The agent splits each help article into chunks, indexes them, and at reply time pulls the chunk that best matches the customer's question.

The model then writes a reply grounded in that chunk and a couple of its neighbors. If you want the deeper version, our piece on what self-learning AI actually is covers the mechanics.

The important property of that pipeline is the one most people miss: the AI has no memory between answers. Every customer question is a cold lookup.

Anything you wrote assuming the reader would scroll, click "related articles", or bring context from the page above the heading is invisible to the AI.

A comparison table showing six reading behaviors a human reader does naturally (skim and scan, scroll past preamble, click see-also, infer context from headings, remember the previous article, bring context from the chunk above) and the AI agent column failing every one.

Andrej Karpathy (ex-OpenAI, ex-Tesla) made a similar point in a recent thread about why he runs his own personal LLM wiki. The LLM treats every lookup as fresh, so the structure of the underlying notes is doing almost all of the work.

That single property is what generates almost every retrieval failure I see. There are three flavors of failure, and they map cleanly onto the three layers in the framework below.

First, the chunk doesn't contain the answer at all. I call that an article-structure problem.

Second, the chunk contains the answer but the AI doesn't recognize it as such. That's a sentence-clarity problem.

Third, the chunk contains an answer but it's the wrong version of the truth, because the same fact lives in five articles and two are out of date (we see this constantly). That's a maintenance problem.

The twelve patterns below are organized into those three layers, in exactly that order.

The 12 writing patterns for a retrieval-ready knowledge base

⚡

TL;DR: Twelve patterns across three layers: how each article is structured (5), how each sentence is written (5), and how the whole KB is maintained (2). Each one closes a specific retrieval failure mode.

I'll credit the work up front. Intercom's knowledge base best practices post is the most thorough public list I've seen. Our own earlier piece, optimising your help center for AI agents, sketches the rules in seven points.

I've combined those with the patterns we keep seeing in our own rollouts, added a couple of our own, then grouped the whole set into three layers so you can think about which layer is failing you rather than ticking off a flat list.

We call it the Retrieval-Ready Knowledge Base. Twelve patterns, three layers. Each one closes a specific retrieval failure mode (and, as I'll cover in the human-vs-robots section below, each one also makes the article easier for the human who self-serves).

A breakdown showing the Retrieval-Ready Knowledge Base framework in three layers: Layer 1 Article Structure with 5 patterns, Layer 2 Sentence Clarity with 5 patterns, Layer 3 KB Maintenance with 2 patterns.

Layer 1: article structure (five patterns)

This layer is about making each article retrievable as a single chunk. If you fix nothing else in this list, fix these five.

2.1 One article, one question (atomic articles)

The failure mode is the multi-purpose article. A page titled "Returns, refunds and exchanges" gets indexed as one large chunk (or a few chunks split arbitrarily by character count).

When a customer asks "when will my refund arrive?", the AI may retrieve the chunk that covers exchanges instead. The article is technically relevant; the answer inside it isn't.

The fix is to split. Three atomic articles: "How do I return an item?", "When will my refund arrive?", "Can I exchange instead of refund?".

Each is titled with the literal customer question. Each has one job.

I see this so often that it's the first move I'd make on any audit. It also makes the human reader's life easier, since they don't need to scan past two sections to find the one they want.

2.2 Lead with the answer (front-loaded)

Most help articles open with a paragraph of brand voice: "At Acme, we believe a frictionless returns experience is part of every great customer relationship..."

That paragraph gets retrieved. The actual return window, three paragraphs down, often doesn't (I've watched this exact thing play out on retrieval logs).

Lead with the answer. The first paragraph IS the resolution. Context, brand voice and reassurance go after, if they go in at all.

Phrase it as if the AI is reading the first 150 characters and using only that, because most of the time, that's exactly what's happening.

2.3 Restate the customer question in the article body

Intercom's post calls this the most AI-specific tip on their list, and I'd agree.

If a customer types "can I return an item without the original packaging?" and your article only ever uses the phrase "return merchandise authorization", the retrieval layer may not rank your article highly, because none of the words in the customer's question appear in the chunk.

The fix is to include the customer's literal phrasing as a sub-heading or opening line. The article opens with the verbatim question, then answers it. You can keep the formal product terminology underneath; you just need the customer-language version to live in the chunk first.

A useful exercise (and a free one): pull the last 30 days of tickets and look at the exact wording customers use. That's the phrasing that goes into the article body and the sub-headings.

2.4 Name who, where and when the article applies

A US shipping article gets retrieved for an EU customer. A Pro-plan feature article gets retrieved for a Free-plan user. A v2.0 instruction gets retrieved for a v3.0 customer.

All of those happen because the article never told the retrieval layer who it was for.

The fix is a one-line preamble at the top of every article that names the scope. "This article applies to: US customers on the standard return policy." Same line, every article, no exceptions. If your product has plans, regions, versions or user types that change the answer, name them.

Intercom frames this as "specify intended user types". I'd extend it to anything that scopes the answer, including region, billing plan, product version and seasonal availability.

2.5 State what the article doesn't cover (negative bounds)

This is the other one we'd add.

An article about shipping that doesn't mention returns will sometimes get retrieved when a customer asks about returns. The retrieval layer judged the shipping article the closest match and there was no signal in the chunk saying "wrong article". The AI then confidently answers a returns question from a shipping article.

The fix is a short "what this article doesn't cover" line near the top, with a link to the article that does. "This article doesn't cover: subscription cancellations or B2B contract refunds, see Subscription cancellation and B2B refund policy." The negative bounds matter as much as the positive content.

This is the pattern I see the fewest help centers using, and it costs them more retrievals than they think.

Layer 2: sentence-level clarity (five patterns)

This layer is about making each chunk readable as a standalone answer. Layer one decides whether the right chunk gets retrieved; Layer two decides whether the chunk is usable when it does (and I'd say teams under-invest here most often).

2.6 Plain English, full sentences

A chunk that contains the word "Yes." or the phrase "Click here." can't be used as a standalone AI reply. The AI may try, and the customer gets a reply that reads "Yes." or "Click here to update your preferences." Both are useless.

Replace short answers with the full sentence. Instead of "Yes", write "Yes, you can use your own packaging when sending an item back, with no need to keep the original shipping box." Instead of "Click here", name what the link goes to and what happens when you click it.

The same rule applies to bullets. A bullet that reads "30 days" inside a heading called "Return window" makes sense to a human reading the page.

Out of context (and the AI always reads it out of context), it doesn't. Spell it out: "You can return any unused item within 30 days of delivery."

2.7 Customer vocabulary in headings and body

A heading that reads "Resetting Auth Tokens" doesn't match semantic search for "I can't log in". The article may have the answer; the chunk just won't rank highly enough to surface.

I'd write headings using the words your customers actually use. Drop internal product names from your H2s and put them in the body in brackets if you need to keep them. Repeat the key topic word two or three times across the article so the retrieval layer has multiple anchor points.

Use the same term throughout, too (fun fact: I see "subscription" and "membership" used interchangeably in the same KB more often than not). If you call it one thing in one article and another in the next, the AI may struggle to see them as the same thing.

Mining the last month of tickets for phrasing pays off here too. The words you'd see if you ran a word cloud over your subject lines are exactly the words I'd want to see in your H2s.

2.8 Define every acronym and product name on first use, every time

This one's a little dull but it matters.

The AI wasn't trained on your acronyms. It doesn't know that "RMA" expands to "Return Merchandise Authorization" in your product, or that "the Vault" is the name of your encrypted file store, or that "WISMO" is short for "where is my order".

When it generates a reply, it'll often leave the acronym in place, and the customer ends up more confused than before.

The fix is to spell out every acronym on first use in every article. Not just the first article where you ever used the term. Every article that uses it.

"Single Sign-On (SSO)". Same rule for internal product names: assume the reader has never seen them before.

It looks like noise when you write it. It's worth it.

2.9 Inline the condition, don't say "see related"

A common pattern: "If you're in the EU, see our EU returns policy."

That works for a human, who can click. For the AI, it's a coin flip whether the retrieval layer picks the right article when an EU customer asks the question.

Inline the conditional answer instead. "EU customers: refunds are processed within 14 days. US customers: 30 days. UK customers: 14 days statutory plus a 16-day goodwill window." The chunk now contains both branches.

This sits in mild tension with pattern 2.12 below (single source of truth). The reconciliation: conditions live inline so the chunk is self-contained; canonical facts live in one article so updates flow. The condition references the canonical fact-article when depth is needed.

2.10 Replace tables and images with text where you can; always text-describe visuals

The AI extracts table cells without their column structure, so a four-row, three-column pricing table can come out the other side (we've seen this in our own retrieval testing) as a flat list of numbers with no labels.

Images and screenshots can't be read at all by most retrieval pipelines today.

My fix has two parts.

First, avoid tables of more than two or three rows when prose with named values will do. "The basic plan is $19 per month and includes 100 API calls; the pro plan is $49 per month and includes 1,000 API calls" is more useful to the retrieval layer than the same numbers in a 2x3 grid.

Second, for every screenshot or diagram you keep, write the step-by-step text underneath. The AI uses the text; the human with a screen reader uses the text; only the sighted human in good light uses the image.

I'm not telling you to delete every table. I am saying that when in doubt, prose wins.

Layer 3: KB-wide maintenance (two patterns)

This layer is about stopping the retrieval layer from quoting the wrong version of the truth. Only two patterns here, but I'd put them as the difference between a help center the AI can trust and one it can't.

2.11 Date-stamp every fact that decays; flag deprecated content

When the AI quotes a price from 2023, a promo code that expired last year, or a beta-feature URL that's been retired, the model is faithfully reading what's still in your help center. The article needs updating; nothing's wrong with the AI itself.

I'd suggest being explicit about freshness. At a minimum, add a "Last verified: [today's date]" line at the top of every article that touches pricing, policies, time-sensitive features or anything else that turns over more than once a year.

Add explicit deprecation banners on retired SKUs or features. Where two product versions co-exist, label content as "v2.0 only" or "v3.0 only" in the heading so the retrieval layer can pick the right one.

The retrieval layer itself won't enforce freshness for you (we've watched this fail enough times to call it a rule). The article has to say it.

2.12 One fact, one home (consolidate duplicates)

I see this one in almost every KB we audit. The same refund window appears in six different articles. Two of them are out of date.

The retrieval layer doesn't know which one is canonical, so it retrieves the wrong one some percentage of the time, and a percentage of your customers get the wrong answer.

My rule is that every fact lives in exactly one article. Other articles that need to reference the fact link to it. Updates flow through one place.

If you also use the inline-conditions pattern (2.9), the conditions reference the canonical fact-article. Conditions inline, canonical facts in one place (that's the mental model I'd carry into the rewrite).

This is the pattern most painful to retrofit if your KB has years of accreted duplication. The audit playbook below bounds the scope: you don't need to consolidate everything, just the top twenty.

That's the framework. Twelve patterns, three layers, each one closing a specific retrieval failure mode.

Our own knowledge feature surfaces which patterns you're missing in priority order via the Self-Learning panel, but you don't need our tool to do this work. You can run the audit by hand against any AI vendor.

A worked example: auditing one article against the 12 patterns

⚡

TL;DR: A typical "before" return-policy article scores 1 out of 12 against the framework. The rewrite (split into three atomic articles, front-loaded, scoped, dated) takes about 25 minutes and pushes the score to 11 out of 12.

To make this concrete, here's what an audit looks like when you run it on a single article.

I'm using a plausible-but-anonymized return policy as the example, because every team has one of these and you can map it to your own KB quickly.

The "before" article

Returns and Refunds at Acme At Acme, we believe in keeping our customers happy. Returns are an important part of any great shopping experience, and we've designed our policy to be flexible. Return Window 30 days. How to Start an RMA Click here to begin your Return Merchandise Authorization process. You'll need your order number. EU Customers See our EU policy here. Refunds Refunds are processed back to the original payment method. Special promo: use code SPRING2024 for free return shipping.

Scoring against the twelve patterns

#	Pattern	Pass / Fix
2.1	One article, one question	Fix. Covers returns and refunds and (implicitly) exchanges in one article
2.2	Lead with the answer	Fix. Opens with brand-voice preamble before any fact
2.3	Restate the customer question	Fix. No verbatim customer phrasing anywhere
2.4	Name who/where/when applies	Fix. No scope line; EU vs US not flagged at top
2.5	Negative bounds	Fix. No mention of what's excluded
2.6	Plain English, full sentences	Fix. "30 days." and "Click here." both fail
2.7	Customer vocabulary in headings	Fix. "RMA" in heading; customers don't search that
2.8	Define acronyms	Fix. "RMA" never expanded
2.9	Inline conditions	Fix. EU branch is a cross-link, not inline
2.10	Text-described visuals	Pass. No images
2.11	Freshness anchors	Fix. No last-verified date; promo code is from 2024
2.12	Single source of truth	Fix. The 30-day window probably appears in five other articles

Score: 1 out of 12. Brutal, but typical.

The "after" rewrite

We split the original article into three atomic articles. The first one, for the most common question, reads like this:

How do I return an item? Applies to: US customers on the standard return policy. Last verified: 2026-05-26. You can return any unused item within 30 days of delivery for a full refund to your original payment method. EU customers: the window is 14 days under EU consumer law. UK customers: 14 days statutory plus a 16-day goodwill window. To start the return (also known as a Return Merchandise Authorization, or RMA), email returns@acme.com with your order number. You'll receive a prepaid shipping label within one business day. You can use your own packaging when sending the item back; there's no need to keep the original box. This article doesn't cover: subscription cancellations or B2B contract refunds. See Subscription cancellation and B2B refund policy for those.

Same scorecard, re-run, and the article now passes 11 of the 12 patterns. (Pattern 2.10 doesn't apply, because there are no images.) The other two atomic articles ("when will my refund arrive?" and "can I exchange instead of refund?") would be written to the same template.

Before and after scorecard for a sample refund policy article. The before column shows seven failures including multi-purpose article, brand preamble, missing scope, no negative bounds, bare yes/no, undefined acronyms, and a stale promo code. The after column shows the rewritten version passing eleven of twelve patterns.

The rewrite took a few minutes, once I had a clear before-and-after side by side. What changed:

Split into three atomic articles.

Front-loaded the answer.

Inlined the EU vs US vs UK condition.

Added a "Last verified" line and dropped the expired promo.

Removed the duplicate refund-window statement, which lived in five other articles.

Defined RMA on first use.

Added the negative-bounds line at the bottom.

If you want a public reference for what good looks like at scale, Intercom's own help center is a useful one. Atomic articles, plain headings written in the customer's vocabulary, front-loaded answers (which is no coincidence, since it's the same standard Intercom recommends in their own knowledge base best practices post, cited in the framework above).

Run the audit on your own article (copy-paste prompt)

If you'd like to run the same scorecard on one of your own articles without doing the scoring by hand, paste the prompt below into ChatGPT, Claude, Gemini or whatever AI you use, then paste your article underneath. The output is the same shape of scorecard I ran above, with the specific changes called out per failing pattern.

You are a knowledge base auditor. Score the help article below against the 12 patterns of the Retrieval-Ready Knowledge Base framework. For each pattern return Pass / Fix / N/A, and for any Fix add one sentence on what's wrong and one sentence on the specific change to make.

LAYER 1 — Article structure
1. Atomic: does the article cover one customer question, or several?
2. Front-loaded: does the first paragraph contain the actual answer, or brand preamble?
3. Restate the question: does the customer's literal phrasing appear in the body or sub-headings?
4. Scope stated: is the region, plan, version or user type the article applies to named at the top?
5. Negative bounds: does it state what the article doesn't cover, with cross-links?

LAYER 2 — Sentence-level clarity
6. Plain English: no bare "yes/no", no "click here", no out-of-context bullets ("30 days")?
7. Customer vocabulary in headings: do the H2s use the words customers use, not internal product names?
8. Acronyms defined on first use, every time?
9. Inline conditions: are branches (EU/US, v1/v2, Pro/Free) inlined, not cross-linked?
10. Text-described visuals: tables under 3 rows or rewritten as prose; images explained in text?

LAYER 3 — Maintenance
11. Freshness anchor: last-verified date, deprecation flags, version labels present?
12. Single source of truth: flag any fact in this article likely to be restated in other articles.

End with a Layer 1 / Layer 2 / Layer 3 summary (e.g. "Layer 1: 2 of 5 pass").

Article:
[PASTE YOUR ARTICLE HERE]

The one-week knowledge base optimization playbook

⚡

TL;DR: Audit your top 20 ticket subjects against the 12 patterns, rewrite the bottom 5 first. About a day of work, then 30 minutes per week to maintain. Most teams see a real resolution-rate lift inside one quarter.

If you're now looking at your help center wondering whether you have to rewrite 400 articles, the answer is no.

I've seen most teams find that 60-80% of their articles need no change, and the 20% that does is where 90% of the resolution-rate lift comes from. The playbook below is what I'd run against your top twenty articles in a week.

Three stats summarizing the 80/20 of a KB audit: 60 to 80 percent of articles need no change, the top 20 articles drive 90 percent of the resolution-rate lift, and most teams see a meaningful lift inside one quarter.

Step 1. Pull your top 20 ticket subjects from the last 30 days.

Use whatever your helpdesk gives you (Zendesk Explore, Intercom Reports, Freshdesk Analytics, Gorgias Statistics, HubSpot Service Hub reports). About 30 minutes. You now have the only twenty help articles that matter for resolution rate this quarter.

Step 2. Build a one-page audit template.

A spreadsheet with twelve columns (one per pattern) and twenty rows (one per article), with a Pass / Fix / N/A in each cell. About 15 minutes. We use one ourselves on these audits and it stops the scoring from drifting halfway through.

Step 3. Score each of your top 20 articles.

Open each article, then score it against the twelve patterns. Don't fix yet, just score (I find scoring before fixing keeps me from rabbit-holing on the first article and skipping the rest).

About two hours for twenty articles. You now know which five articles are worst, and those are your first rewrites.

Step 4. Rewrite the bottom 5 first.

Focus on the five lowest-scoring articles. Within each article, focus on Layer 1 patterns first (atomic, front-loaded, scoped, negative-bounds).

Those four moves alone fix most retrieval misses. Plan on roughly a day, then republish.

If you'd rather hand the first pass to an AI and edit from there, the prompt below works in ChatGPT, Claude, Gemini or your own agent. It applies all 12 patterns in one go, splits the article if it covers more than one question, and lists any facts likely duplicated elsewhere in your KB so you can consolidate them in the same sitting.

You are a technical writer rewriting a help article for an AI customer service agent that retrieves chunks of help content and answers from them. Apply the Retrieval-Ready Knowledge Base framework to the article below.

LAYER 1 — Article structure
- If the article covers more than one distinct customer question, split it into separate articles, one per question.
- Lead with the answer in the first paragraph. Brand voice goes after, if at all.
- Add a top-line "Applies to: [region / plan / version / user type]" scope line.
- Use the customer's literal question phrasing in sub-headings where it doesn't already appear.
- Add a "This article doesn't cover: [X], see [Y]" line near the top.

LAYER 2 — Sentence-level clarity
- Replace bare "yes" / "no" / "click here" with full sentences that have context.
- Rewrite headings in customer vocabulary, not internal product names. Repeat the key topic word two or three times across the article.
- Spell out every acronym and internal product name on first use.
- Inline any branching answers (e.g. EU vs US vs UK) rather than cross-linking to another article.
- Rewrite tables of more than 3 rows as prose with named values. For every image or screenshot, add step-by-step text underneath.

LAYER 3 — Maintenance
- Add a "Last verified: [today's date]" line at the top.
- Flag any deprecated content (expired promos, retired SKUs, outdated version numbers) for removal.
- At the end, list any facts in this article likely to be duplicated in other KB articles so I can consolidate them into a single source of truth.

Return the rewritten article (or split articles) in clean Markdown. End with two short sections: "What changed and why" and "Facts to consolidate from other articles".

Original article:
[PASTE YOUR ARTICLE HERE]

Both prompts work better if you give the AI two or three of your existing well-written articles as examples first ("here's the style and structure I want"). It picks up your house style and you get less generic output.

Step 5. Make it a recurring loop.

Add a 30-minute weekly review to your team standup. Re-score five articles per week on rotation, and track resolution rate over four weeks.

Most teams we work with see a real lift inside one quarter, and the slope is steepest in the first six weeks (because the audit naturally surfaces the highest-leverage articles first).

A five-step process: pull the top 20 ticket subjects, build a 12-pattern audit template, score every article, rewrite the bottom 5, and make it a weekly loop.

If you don't have a CS analyst, the optional move is to ask your AI agent itself once a week which questions it failed to answer. Most modern agents surface this as a list of unanswered queries.

In our own product, the Self-Learning panel does this automatically and proposes new articles drafted from the patterns it noticed. Whatever your vendor calls it, that list is your audit shortlist for next week.

If you don't yet have help articles for some of your most-asked questions, our Train on Historic Tickets feature drafts them from past ticket transcripts. It's the fastest path from "we have no article" to "we have a first draft to edit".

One more note (on collaboration). Your sales team and your CS team know which articles customers ask them to find, because they get those questions in conversation.

Asking each team once a month for the three articles they wish existed is a five-minute meeting that improves the next month's audit. Intercom's post makes the same point and I'd echo it.

"Isn't this just writing for robots?" The answer is no

⚡

TL;DR: Every one of the 12 patterns also makes your KB better for the human who self-serves. Plain English, atomic articles, dated facts: the same things technical writers have asked for since the 1990s. AI just made them mandatory.

The single most common reaction I get from CS leads when I walk them through the twelve patterns is this: "We've spent years building our brand voice in the help center. All these tips sound like we're dumbing things down for an AI."

My honest answer is the same one I'd give over a coffee. While it might seem like these tips are forcing you to write for AI, they also produce better content and docs for people too.

Clear, unambiguous, simple language makes your docs easier to digest for anyone. Not everyone will ask their AI agent a question; some still self-serve and read for themselves, and any update you make benefits them too.

Let me walk you through the three layers, because the human win shows up at every level.

Layer 1 wins for the self-server

Atomic articles mean the customer who lands on your help center via Google finds the one-article answer to the one question they had, in ten seconds. Not after scrolling past three sections that don't apply to them.

Front-loaded answers mean the answer is at the top, instead of buried under brand preamble. Scope lines and negative bounds mean a US customer doesn't read three paragraphs of EU policy before realizing they're on the wrong page.

Every Layer 1 pattern is a thing technical writers have been asking for since the 1990s. AI just made them mandatory (I'd argue we should have been doing this all along).

Layer 2 wins for the human with friction in reading

Plain English in full sentences helps the customer reading on mobile in poor signal (which, in my experience, is more of them than you'd guess). Customer vocabulary in headings helps the customer who never learned what "RMA" means.

Defined acronyms help the new hire on your own team who's reading the same docs in onboarding. Text-described visuals help the customer using a screen reader, and that work is the bulk of what you'd do for accessibility compliance anyway.

Inline conditions help anyone for whom clicking through three "see also" links would be the difference between getting the answer and giving up.

Layer 3 wins for everyone in the support loop

Dated facts mean fewer "I read on your site that..." support tickets caused by a stale article nobody updated.

A single source of truth means your team doesn't get six contradicting answers when they search internally (and when you do update something, you update it once). Both layers cost you tickets when they're missing.

What the twelve patterns don't ask you to give up is brand voice. They ask you to put it in the right place.

Brand voice belongs on your landing pages, your launch posts, your About page, your in-product tone. It doesn't belong in the first sentence of a refund policy article (we like brand-led copy too, just not in the docs the AI reads).

A customer who needs to know whether they can return something doesn't want to hear about how customer trust is at the heart of everything you do. They want to know if they can return the thing.

I'd be remiss not to flag two cases where the whole framework genuinely doesn't apply, and it's worth being honest about both.

Case one: your vendor's retrieval layer is broken.

No amount of KB rewriting fixes a retrieval pipeline that returns the wrong articles. The diagnostic is simple. If you write a clean, atomic, front-loaded article and the AI still doesn't retrieve it for the obvious question, the chunking or the embedding model is the problem, and you should switch vendors.

I see this less often than the KB-writing problem, but I do see it.

Case two: you're under 100 tickets a month.

The fixed cost of a week-long KB rewrite outweighs the lift you'll see at that volume. Stick with canned macros and human review until your ticket volume justifies the work. (And if your handoff between AI and human matters at that scale, our AI to human handover feature is worth a look, but that's a separate post.)

Everywhere else, the patterns hold. Write for the AI; you'll have written for the human at the same time.

The takeaway

⚡

TL;DR: I'd say KB shape drives resolution rate more than your AI vendor does. Twelve patterns, three layers, twenty articles, a week of work. Start with the bottom five.

Your AI's resolution rate is mostly the shape of your knowledge base. The brand on the model matters far less. Twelve writing patterns, twenty articles, about a week of work (and I'd argue it's the highest-leverage week your CS team will spend this year).

Layer 1 is the article-structure work: atomic, front-loaded, scoped, negative-bounded, with the customer's verbatim question in the body. Layer 2 is the sentence-level work: plain English, customer vocabulary, defined acronyms, inline conditions, text-described visuals. Layer 3 is the maintenance work: dated facts and a single source of truth.

The single highest-leverage move I'd nudge you toward this week is to rewrite your bottom five articles using the Layer 1 patterns. Pick the five highest-traffic articles that score worst. Republish. Watch resolution rate over the next four weeks.

If you want a head start on the audit shortlist, our knowledge feature surfaces which articles the AI keeps failing to answer from, so you can skip Step 1 of the playbook and go straight to the rewrite. Either way, the work is yours; the framework is just where to start.

FAQs

What's the difference between writing a knowledge base for humans and for AI?

In practice, less than you'd think. The patterns AI retrieval rewards (atomic articles, front-loaded answers, plain English, customer vocabulary in headings, scoped context, dated facts) are the same patterns technical writers and accessibility advocates have argued for since the 1990s. AI didn't change the rules of good writing; it made them mandatory, because the AI has none of the workarounds (skim, click, infer) that a human reader has.

How do I know if my knowledge base is hurting my AI agent's resolution rate?

The fastest diagnostic I'd suggest is to ask your AI agent itself which questions it failed to answer in the last week.

If you see a cluster of questions where the answer is genuinely in your help center and the AI still failed, the problem is retrieval-side (either your KB writing or the vendor's chunking pipeline). If the questions are ones your KB doesn't cover at all, the problem is content-side, and you need new articles in that case rather than rewrites. The playbook above works for both.

How do I keep my knowledge base in sync with the AI agent automatically?

Pick an AI agent that surfaces unanswered questions and proposes article drafts for them.

In our own product, the Self-Learning panel watches every reply and flags the gaps; our Train on Historic Tickets feature drafts the actual article from past ticket transcripts so you start with a first pass rather than a blank page. Most other modern agents (Fin, Decagon, Sierra, Freddy) have some version of unanswered-question monitoring; the quality of the auto-draft varies and I'd recommend trying yours before relying on it.

As a fintech startup handling 10k support tickets monthly, how can we deploy an AI knowledge base that actually performs?

At 10k tickets a month, the work in this guide pays back inside a quarter.

Run the one-week playbook against your top twenty ticket types first, because in fintech they concentrate heavily on a small number of repetitive questions (KYC status, payment timing, transfer limits, fee schedules). Add scope lines and negative bounds aggressively, because fintech help articles almost always vary by region, plan tier, account status and product version. Layer 3 freshness anchors matter more than usual, because fee and limit changes are frequent.

Can an AI knowledge manager generate help articles from my resolved support tickets?

Yes, and we built one. Train on Historic Tickets reads your past ticket transcripts (including the resolutions a human agent typed at the end) and drafts help articles from the patterns it sees. Most other modern AI customer service vendors have a version of this; the quality difference comes down to whether the auto-draft is good enough that your team will actually publish it, or just edit and re-edit it.

What's the best AI-powered knowledge base for self-service customer support?

Honestly, this is the wrong question to ask first.

The right question is whether your knowledge base content is in shape for any AI to answer from, because the gap between a great vendor and an average one is much smaller than the gap between a well-written KB and a badly-written one. Once your content is in shape, look for an AI that's actually integrated into your existing helpdesk (Intercom, Zendesk, Freshdesk, Gorgias, HubSpot, Help Scout, Re:amaze, Kustomer), grounds every reply in your verified sources, and surfaces unanswered questions back to you each week.

I obviously think our knowledge feature fits that bill, but the content work comes first either way.

How long does it take to optimize a knowledge base for AI agents?

Roughly a day per twenty articles for the rewrite, with the audit and scoring adding another half-day on top. Most of the resolution-rate lift comes from the bottom five articles in the top twenty, so if you only have a day to spend, spend it on those five. After that, a 30-minute weekly review on rotation keeps the rest of the top twenty maintained.

Do I have to rewrite my entire knowledge base?

No. The top twenty articles by ticket volume are usually responsible for 60-80% of the AI's answer opportunities; the long tail of articles is read less often by humans and retrieved less often by the AI.

I'd start with the top twenty, rewrite the worst five, and treat the rest as a backlog to chip away at over the next quarter. The math rarely justifies rewriting articles in the bottom half of the long tail at all.

How to Optimize Your Knowledge Base for AI Agents (12 Writing Patterns That Lift Resolution Rate)

How AI agents read your knowledge base differently from your team

The 12 writing patterns for a retrieval-ready knowledge base