Xerum for support organisations

Let your agents improve the knowledge base — safely

Every ticket teaches somebody something the documentation does not say. Today that knowledge dies in a closed conversation, because the alternative — letting an agent write to the knowledge base — is not something any support lead will sign off on.

Get an instance See how it works

Sound familiar?

What the ticket taught you evaporates

An agent works out the actual cause of a recurring problem, resolves the ticket, and the finding is now inside a closed conversation nobody will search. The next agent finds it again from scratch.

Nobody will let a model write the KB

The obvious fix — have the agent update the article — is the one thing you cannot allow. An unreviewed edit to a support article is a wrong answer given at scale, to customers, in your name.

The KB drifts from the product

Articles describe last quarter's behaviour. The people who know it changed are on tickets all day, and filing a documentation request is a task that loses to the queue every time.

What changes

Agents propose, leads decide

An agent that learns something opens a proposal with a message saying why. A lead approves it into the history or rejects it. Nothing reaches customers unreviewed.

Review is a diff, not a meeting

Proposed state is revision-addressable, so reviewing a proposal is the same call as reading history. A lead sees exactly what would change, and nothing else.

Rejected leaves no residue

A rejected proposal vanishes without a trace — no draft state, no half-approved article, nothing for a future agent to find and mistake for the answer.

Every answer still cites

When an agent answers from the knowledge base, the answer carries the resource and revision it came from, so a supervisor can check what the customer was actually told.

What this industry buys

Proposals

The first big agent-write market — and the one place the curation loop is a daily feature rather than a safeguard you rarely touch.

  • Agents write only through proposals, never directly
  • A proposal is decided once, and only while pending
  • Approved changes join the same straight history as everything else
  • Attribution survives: the log says which person the agent acted for
Get an instance

The proposals UI is built and shipping in the tenant app.

The loop your support org already runs, made real

Built today, not on a roadmap. Every property above is already how the store works.