Can I control which articles the AI uses?
Yes — three places, in decreasing order of bluntness.
1. Article status — the kill switch
Only articles with status published are retrievable by any AI agent.
draft→ invisible to retrieval. Use this for new articles you’re still writing or AI-generated drafts you haven’t approved.needs-review→ invisible to retrieval. Use this for published articles you’ve spotted as wrong; the AI stops using them until you re-approve.archived→ invisible to retrieval. Use this for articles whose feature is gone.published→ live in retrieval.
Changing status is the fastest, most surgical control. An article you want pulled from the AI immediately: set to needs-review, save. Within a minute the retrieval engine drops it.
2. Capability scope — narrow what each agent can see
When you configure a Capability (the building block inside an Agent Stack), you can scope its KB access:
- Full access — The Capability retrieves from your entire published KB.
- Selected categories — The Capability only retrieves from the categories you check. Articles outside those categories are invisible to this agent, even though they’re still public on the help center.
This is the right lever when you want different agents to specialize. A billing agent gets the Billing category; a shipping agent gets the Shipping category. The KB stays whole, but each agent retrieves only from its scoped slice.
Scope is set when you build or edit a Capability. See the Capabilities docs for the configuration walkthrough.
3. Sections — group articles for the public help center, not for AI
Sections are an alternative grouping for the public help center — a way to surface “Top articles” or “Getting started” boxes on the home page. They don’t change retrieval. The AI doesn’t know about sections; it sees the same article whether or not it belongs to a section.
If you wanted sections to affect retrieval, the right answer is Capability scope on a category that maps to the same content.
What does not control AI retrieval
Two things that sound like they should but don’t:
- Roles — KB roles are browsing-visibility tags for the public help center. They control who sees what when browsing. The retrieval engine ignores them — it treats every published article as a candidate regardless of role tags.
- Tags — Tags filter articles in the in-app editor and on the public help center. They don’t change retrieval scores.
These can feel like missing levers. The framing fix is: status and Capability scope are the levers, and they’re enough. If you find yourself wanting role-bias on retrieval, the better answer is usually a Capability scoped to the right category.
Edge cases worth knowing
- A drafted article that was previously published. When you flip status from
publishedtodraft, the article drops from retrieval within a minute. In-flight conversations finish with whatever they already retrieved. - A category renamed mid-conversation. Doesn’t affect retrieval; rename freely.
- An article moved between categories. The article stays retrievable; its category scope changes for any Capability scoped to “Selected categories”.
- Unpublishing and republishing. Triggers a fresh embedding pass. Allow a minute before re-checking.
What about per-article overrides for specific agents?
There’s no per-article “exclude from agent X” toggle. The two levers above — status and Capability scope — are the design. If you need finer-grained control than “scope this Capability to category Y”, consider:
- Splitting the article into two so each part lives in a category that maps cleanly to its agent.
- Using the Handbook for internal procedures the AI follows but never quotes. Handbook entries are agent-readable but never customer-facing.