Choose what your AI agent learns from
The agent learns from your knowledge base: the articles your help center shows. You add to it from GitHub repositories, from your code, from customer questions the agent couldn't answer, or by writing in HelpWell.
A product is one help center, however many repositories it is built from (an app, its API, its agent).
#The sources
| Source | How it adds articles |
|---|---|
| A docs folder in a connected repository | A push to the tracked branch queues a sync. The worker fetches changed files, removes the ones gone from the branch, and re-indexes the product, usually within a minute. |
| Code changes in a repository | A push or release is checked. If customers would see a difference, affected articles are updated and new features get new draft articles. |
| A build of the whole knowledge base from your code | Outlines up to 150 articles, then writes them three at a time. |
| Unanswered questions | Draft writes an article for a question the agent couldn't answer. |
| Articles you write or edit in HelpWell | Live at once. |
#Add a GitHub repository
#Connect the repository
Go to Settings → GitHub repositories and choose Connect GitHub. You can connect several repositories at once, with defaults.
#Choose what it contributes
Choose Edit on the repository and set:
- Sync docs from this repo: its docs folder becomes part of the knowledge base. If the repository has no docs folder, HelpWell connects it for its code changes instead.
- Update articles from code changes: on by default for a repository without a docs folder. Docs repositories start with it off.
- Use releases for changelog drafts: feeds the changelog, not the knowledge base.
#Set when and what to check
Under When and what to check, choose pushes, releases or both. Set how long pushes are batched (Batch pushes for, 15 minutes by default). Optionally, list the only paths to watch under Watch only these paths, one per line, like
src/billing/orapp/**/*.tsx. A line starting with!leaves a path out.#Pick a folder
Under Folder in the knowledge base, set where its collections go. The first docs repository keeps its collections at the top level. Every other one gets a folder, by default its repository name. For example,
docs/guides/start.mdinacme/apibecomes the collectionapi-guides.
Each repository's changes are checked against every article in the product, not just its own.
#Build the knowledge base from your code
When you connect a code repository to a product with no articles, Build the knowledge base when a repository is connected builds it for you. It is on by default.
- It shows the planned articles for review before writing, so you can remove some. Turn off Show me the planned articles before writing to skip this.
- It runs until it is done or reaches the build's spending limit.
To run it yourself, choose Build the knowledge base and add an optional focus, such as "billing and team settings". It reads each connected repository through GitHub. It never reads anything that could hold a secret. Articles that already exist or wait for review are left out.
Watch progress under Knowledge base → Code updates.
#Review code-driven updates
By default, Publish code-driven updates automatically is off. Updates wait in the review queue under Knowledge base → Code updates. There you can Approve (or Publish for a new article), Edit, Discard, or act on all at once. Owners and admins get an Article updates from code notification.
If you turn it on, updates publish at once. Each is saved like an editor edit, so Restore in the editor brings back the earlier version.
#Limits per product
Set these under Code updates → Limits.
| Limit | Default |
|---|---|
| Articles checked per change | 20 |
| New articles per change | 5 |
| Model spend per change | $2 |
| Model spend per build | $10 |
A check says when it stopped at a limit.
#Add from unanswered questions
Open Knowledge base → Unanswered questions. Choose Draft on a question. The draft opens in the editor with [TODO] wherever a fact is missing. Fill those in and save.
Note
Code-driven checks use the workspace's model on its own OpenRouter key, within its monthly cap. If a check fails, for example because GitHub refused access or the cap was reached, it is marked failed with the reason and owners and admins are told.
Was this article helpful?
Still stuck?