Your product ships weekly. Your knowledge base gets a pass quarterly, when someone finally defends the afternoon. The gap compounds: 300 articles, four authors, two renames ago, and your support team now spends part of every day correcting answers the docs give wrong. You know roughly which articles are stale. What you do not have is a way to fix them that is not 300 editor tabs, because Intercom's bulk actions move tags and folders, and body text is one article at a time.
AI can do the reading and the rewriting; that part is now cheap. What it cannot be allowed to do, on pages your customers are reading right now, is publish unsupervised. The version of this job that works has a strict order: every article becomes a local file, your own agent runs the whole consistency pass at once, and each change comes back as a diff you read before anything returns to Intercom. What separates the options below is not the AI. It is whether that order survives.
Your options
Editing one article at a time
Intercom's editor takes good care of a single article. You can save a draft version of a published article, version history never expires, changes show highlighted against past versions, and restoring an old version hands you a fresh draft. Knowledge Hub adds bulk actions for the wrapper: tags, audience, language, folder, status. The wall is body text. There is no bulk edit for content and no search and replace, so a feature rename means opening every affected article yourself. Five minutes an article is an optimistic budget once you are checking steps against the current product, and 300 articles at that pace is 25 hours. That is why the pass happens quarterly.
A script on the Articles API
This is Intercom's own answer. Asked how to rename a feature across more than 180 articles, their support team recommended a script: list every article, find the matches, write each one back individually. The mechanics hold up at this scale; listing 300 articles is 2 paginated calls at the API's maximum page size, and the rate limits are generous. The failures are judgment and timing. A regex matches strings, not meaning, so it hits the sentence the rename should not touch and misses the paraphrase it should. And every write lands on the live article the moment it runs. The API keeps no staged draft of a published article, and flipping one back to draft takes its live URL down. No diff, no dry run, unless you build both.
A migration tool
Help-center migration tools are good at the job they were built for: moving articles between platforms faithfully, translations and inline images included, with internal links rewritten to match the destination and per-record pricing visible up front. None of that is this job. They copy content, they do not transform it; a rewrite step with a review workflow is not what any of them are built for. If you are leaving Intercom, this is the right shelf. If you are staying and the articles need to change, it is the wrong shape entirely.
An AI agent wired to the API
Intercom ships an official MCP server, currently for US-hosted workspaces, with tools to list, search, and update articles. Point an agent at it and the judgment problem is solved: it reads real sentences and rewrites them with the brief in mind, no script to author. The workflow problem is not solved. The agent works the API one call at a time, and a pass that reads, cross-checks, and updates 300 articles runs to around 1,000 round trips. Each update inherits the API's behavior too: a write to a published article is live the moment it lands. The judgment is real. So is the absence of anyone reading it first.
Scratch
Scratch gives the same agent the same reach, on files. Your knowledge base comes down as a folder: one file per article with title, description, body, draft or published state, and placement, plus collections and translated content. Whole-center questions get cheap. One grep lists every article still using the old name, about a second of work, and a short script indexes every plan reference across all 300 bodies at once. Every change returns as a word-level diff next to the original, drafts stay drafts until you flip the state field, and a shipped change reverts per article. The cost is stated up front: the review is you, reading. On docs your support team stands behind, that reading is the point.
| Option | Whole knowledge base | AI judgment | Review before live | Undo after publish |
|---|---|---|---|---|
| One article at a time | No | Bring your own, per article | You are the editor | Version history, per article |
| Script on the Articles API | Yes | No, patterns only | No | No |
| Migration tool | Yes, to another platform | No | No | No |
| Agent on the API | Yes | Yes | Only if you build it | No |
| Scratch | Yes | Yes, your agent | Every change, as a diff | Per article, even after publish |
How the loop works on your knowledge base
- Scratch pulls your knowledge base into files. Every article lands as its own file: title, description, body, draft or published state, and parent collection, with translated content alongside for each language you maintain. Collections come down too, name, description, and icon. Conversations can come along read-only, so the agent can compare what customers keep asking against what the articles actually say. Your live help center does not know any of this happened yet.
- Your AI runs the consistency pass. Point Claude, Codex, Cursor, or Copilot at the folder with the brief. We renamed Workspaces to Projects in March. Update every article that still says Workspaces, fix the surrounding steps where the flow changed, and flag any article whose plan names or prices do not match the current pricing page. The agent greps for the stale terms, lists every affected article, and rewrites each one with judgment, not substitution. That is 99% of the job, done without an Intercom credential anywhere in reach.
- You review every diff and publish. Each changed article shows as a word-level diff against the original. If you set validators, they gate the queue first: a length cap, the fields an article cannot publish without. What you approve is what Scratch writes back through the Intercom API; nothing else moves. Drafts stay drafts unless you flip the state field, published articles update in place, and any shipped change reverts per article. The remaining 1%, deciding what 300 articles tell your customers, is yours.
Run the rename pass first; it is the easiest to judge. Tone is the second loop through the same folder, once you trust the first.
What people use it for
- Carry a product rename through every article that mentions it, including the paraphrases a search-and-replace never finds.
- Make the whole help center read like one team wrote it this quarter, not four authors over three years.
- Update every plan name and pricing reference in one reviewed pass, instead of as customers report them.
- Restructure long articles so the answer arrives before the backstory.
- Run the same pass through every language you maintain, each version reviewed as its own diff.
Questions people ask
Can Intercom bulk edit article content on its own?
No. Knowledge Hub's bulk actions cover the wrapper around an article: tags, audience, language, folder, status. Body text is not on the list, and there is no search and replace. When users ask for a faster way to update many articles, Intercom's staff point them to the Articles API and a custom script, which is the second option above, edges included.
How do I get 300 articles out of Intercom in the first place?
Through the API. There is no export button for article content; Intercom's own guide to exporting articles is a walkthrough of the Articles API, and the community fills the gap with scripts that convert articles to Markdown or CSV. With Scratch, the pull is the first step of the loop: connect Intercom and the knowledge base arrives as a folder, one file per article, drafts and published alike.
Can the changes land as drafts so I publish on my schedule?
Partly. The boundary is worth knowing. Draft or published is a field on every article, so a rewritten draft stays a draft until you flip it. Published articles work differently: Intercom keeps no staged revision behind the API, an update to a published article goes live as it is written, and moving one back to draft takes its live URL down. For published articles, the review has to come before the write. That is the order Scratch runs in anyway.
Will customers see a half-finished pass?
No. The agent works on files, so the live help center does not move while the pass runs. Scratch writes back only what you approved, in batches you choose. An article you have not approved stays exactly as your customers last saw it.
Can I undo an article after it publishes?
Yes. Two ways. In Scratch, the original sits next to every shipped change, and rejecting it puts the old version back, per article. Intercom's editor keeps its own version history too, with restore as a new draft, which is a good second net. The difference is scale: one is a screen of reversible rows, the other is a visit to each article.
Will the AI read or write customer conversations?
Read, at most. And only if you pull them. Conversations are useful context: they show which questions keep arriving and which articles failed to answer them. They come down read-only. Nothing writes to the inbox, ever.
Does the pass cover translated articles?
Yes. Translated content is editable in the same loop, so the rename or the tone pass carries through each language you maintain, and every language version shows as its own diff before it ships.
Can it write the articles that are missing?
No. Scratch edits what the knowledge base already holds: article title, body, description, state, placement, plus collection names, descriptions, and icons. Creating new articles is not supported. If the missing articles are the bigger half of your problem, tell Curtis. What people ask for shapes what gets built next.
Do I need to be technical?
No. The grep and the indexing scripts run inside the agent you already use. What you write is the brief, in plain English; what you read is a tracked-changes view with an approve button per article. Setup is a desktop app and an Intercom connection, once.
See it on your own knowledge base
Drift is easiest to see on your own articles. See it run on your knowledge base →, or download Scratch free, pull your help center today, and ask your agent one question to start: which articles still mention the old name.