Publishing is not one permission. Give the agent separate grants for drafting, for publishing small corrections to existing articles, and for publishing new articles, and set each at its own depth. Drafts are depth 2. Corrections below a size limit can be depth 3. New articles, and any change to fees, eligibility or complaint routes, are held for the article's named owner.
What does publishing involve, and who owns it?
A help centre article is a public statement by your organisation. Customers act on it, staff quote it, and if it says the wrong thing about a fee or a deadline, you may be held to it. Publishing is therefore an act with consequences, even though it feels like editing a web page.
Every article should have a named owner: the product, policy or operations lead who answers for what it says. The help centre editor owns structure, style and the publishing system. Where articles come from, and how resolved tickets reveal gaps, is covered in maintaining help centre articles from resolved tickets. This piece is about the system grants. For the wider set of support limits, see the AI support agent that knows when to say no.
Which capabilities should you grant, and at what depth?
| Capability in the help centre system | Depth | Bound | Stays with a person |
|---|---|---|---|
| Read published and draft articles | 1 | None | Nothing |
| Create and edit drafts | 2 | Drafts only | Deciding whether to publish |
| Publish a correction to an existing article | 3 | Change below a size limit; no protected fields | Anything larger |
| Publish a new article | 2, held | Always held | Article owner approves |
| Change a sensitive article | 2, held | Always held | Article owner and compliance |
| Change article address or category | 2, held | Always held | Help centre editor |
| Unpublish or archive | 2, held | Always held | Article owner |
| Delete an article or its history | None | Refused by your limits | Help centre editor |
A "correction" needs a definition the platform can check, not a judgement the agent makes. A workable one: fewer than a set number of words changed, no change to any figure, date, fee, time limit or eligibility condition, and no change to an article tagged sensitive. Anything that fails the test is held, whatever the agent thinks of it.
Sensitive articles deserve a tag of their own: complaints, bereavement, financial difficulty, fraud, accessibility, and anything aimed at customers in vulnerable circumstances. Wording on those pages affects people at their worst moments; see whether an AI agent can help a vulnerable customer.
How do you set it up, step by step?
- Person, help centre editor: tags every article with an owner and a sensitivity flag. Untagged articles are treated as sensitive until someone tags them.
- Person: creates an integration account for the agent with draft rights and publish rights on the article types you allow. The connection itself follows connecting an AI agent to your help centre.
- Agent, depth 1: reads the source of the change. The policy library, product terms or a resolved ticket. Each fact is stamped with its provenance; only a sealed source, such as the current policy, can justify changing a rule on the page.
- Agent, depth 2: drafts the change with a short note: what changed, why, and which source supports each changed sentence.
- Platform: tests the change against the correction bounds. The verdict names the bound that decided: size, protected field, sensitive tag or article type.
- Agent, depth 3: publishes allowed corrections. The previous version is kept and linked.
- Person, article owner: approves or rejects held changes from the queue, with the diff and sources in front of them.
What are held actions, and how are they worked?
A held change sits as a draft with the full diff, the sources and the reason it was held. The owner sees exactly what will change on the live page. They can approve, edit and approve, or reject with a reason that goes back to the agent's record.
Set a service level for the queue. A correction about an outage or a changed phone number that waits a week does more harm than good. If owners cannot keep up, the answer is fewer held categories that are clearly defined, not looser bounds.
How do you revoke the access?
Revocation should work at four levels, and you should test each one:
- One change: roll the article back to the previous version. Because every publish keeps the prior version, this takes one action.
- One capability: withdraw the correction grant and the agent falls back to drafting everything.
- One section: remove publish rights on a category, for example while a product is being relaunched.
- The whole agent: disable its integration account.
A certification run that clears no depth drops the agent to depth 1 the same day, which here means it can read articles but not draft them.
What does the audit trail record?
Every publish, every held change and every refused attempt is filed as a verdict in an append-only record, alongside the publishing system's own version history. For each one: the article, the diff, the sources and their provenance class, the bounds checked, the bound that decided, the verdict, and for held changes the person who released or rejected it.
That record answers the question you will eventually be asked: "who changed this page, when, and on what basis?" A version history alone tells you what changed; the verdict tells you why it was allowed.
Where does it usually go wrong?
The size limit is gamed by splitting. The agent publishes five small corrections that together rewrite a page. Count the changes per article per day against the same limit.
Search snippets change too. A one-word correction to an article title alters what customers see in search results. Treat titles and summaries as protected fields.
Sources disagree. A resolved ticket says one thing, the policy library another. The agent should hold and name the conflict, not pick the more recent one.
Translated versions drift. The English page is corrected and the other languages are not. Either publish all language versions together or hold the change.
Questions people ask
Can the agent write a brand new article from scratch?
It can draft one, and that is often useful when tickets show a repeated question with no article. Publishing it stays with the owner, because a new page is a new public commitment.
How small should the correction limit be?
Small enough that a reviewer would not need to read the article again to understand the change. Start narrow, such as fixing broken internal links and typos, and widen it only on Attest evidence.
Who answers if a published correction turns out wrong?
The article owner remains accountable for the page. The verdict record shows which bound allowed the change, so the fix is usually to tighten that bound.