How to keep an AI knowledge base up to date after launch

To keep an AI knowledge base up to date after launch, give every source a named owner, run a scheduled audit that flags stale and duplicate entries, capture answers people give that nobody wrote down, and route every proposed change to that owner for approval. An agent can do the finding and drafting. A person still decides what gets published.

The assistant on top is the easy part. The knowledge underneath starts going stale the week it launches, and nobody notices until a customer gets last quarter’s price. This post covers the upkeep job as we run it across our own companies, as of October 2026, including the parts that are not finished.

Why knowledge bases go stale after launch

A knowledge base goes stale because launch is treated as the finish line. The content was right on day one, then prices, policies and products moved, and nothing in the system had the job of noticing. The assistant keeps answering confidently from whatever it was given.

The cost of bad internal information is already high without AI on top. Atlassian’s State of Teams 2025 report (published June 2025, 12,000 knowledge workers and 200 executives surveyed) found teams spend over 25% of their workweek searching for information. An assistant grounded in stale content does not fix that. It gives the wrong answer faster.

Data readiness is where AI projects fail. In February 2025, Gartner predicted that through 2026, organisations will abandon 60% of AI projects not supported by AI-ready data. The same release cited a Gartner survey of 1,203 data management leaders (July 2024) in which 63% said they did not have, or were unsure whether they had, the right data management practices for AI. A knowledge base nobody maintains is the most common version of that problem in a small company.

Ownership comes before any cleanup

Every knowledge source needs one named owner before an agent touches it. Without an owner, a stale-entry flag has nowhere to go, and a proposed fix has nobody who can approve it. Ownership is the first control, not the last.

Microsoft’s own readiness guidance for its workplace assistant (Microsoft Learn, SharePoint Advanced Management) puts it in the same order: confirm every site has a valid owner first, then clean up inactive sites, then tighten access. The stated reason is that the assistant can pull content from inactive sites into its answers, which makes results inaccurate and cluttered.

We follow the same rule. Each knowledge base our companies run is registered separately: a customer-facing product advisor, a support bot’s FAQs, a sales assistant, a factory compliance library and an internal playbook set. Each has a named person as owner. They are never merged into one pile, and a change proposed for one can only ever be published back to that same source. A source with no owner is skipped and logged. The agent does not guess who should own it.

What the curator agent does, step by step

The upkeep job is owned by a tomte, our word for one production agent with one defined job. Its job is narrow: find what is missing or out of date, draft a fix, and hand it to the owner. It never publishes on its own.

1. It audits each source on a weekly schedule. It flags clusters of near-duplicate entries and entries that look out of date, and suggests a refresh for each. Today that staleness judgment is a model review of the text, not an expiry date on each entry. That is a known gap, covered below.
2. It captures answers nobody wrote down. When a staff member resolves a question the knowledge base could not answer, that resolution is the best new entry you will ever get. The agent turns it into a draft: the question, the answer, which source it belongs to, and where it came from.
3. It answers staff questions from the knowledge base text only. If nothing covers the question, it says so. That “not covered” answer is itself a signal that an entry is missing.
4. It routes every draft to the source’s owner as a task in the same task system the rest of our agents use. The owner approves or rejects it in a staff console behind single sign-on.
5. Nothing publishes without approval. A pending or rejected proposal cannot be published. The agent never invents an answer and never deletes an entry without sign-off. We decided in August 2026 that this holds even for internal-only content.

Where ours stops today

Here is the honest status as of October 2026. The weekly audit runs unattended and reports. The capture step still runs in report-only mode: it shows what it would propose, and writes nothing. Publishing back is switched off on every source.

The reasons are worth knowing, because you will meet the same ones:

• Attribution has to exist before publishing. Most of our sources have no field that records where an entry came from. Each of those needs a structural change by the team that owns it before an approved fix can be written back with its source attached.
• Closed is not the same as answered. One system recorded that an escalation was closed, but not what was decided. A dry run found no usable answer text to capture, so every candidate still needed a person to write the answer. We fixed it at the source for new closures; older ones were not backfilled.
• Customer conversations carry personal data. Capture from customer consultations is paused. A dry run picked up personal details the redaction step did not cover, so that feed stays off until the redaction does.
• Schedules fail too. The weekly schedule itself failed for a stretch in early October 2026, until a manual run recovered it and the next scheduled run succeeded. We check run history the same way we describe in our post on freshness checks, because a green status label is not evidence.

Curation compared with the usual alternatives

Approach	Who notices staleness	Who writes the fix	Risk
Launch and leave	A customer, eventually	Whoever gets the complaint	Confident wrong answers
Quarterly manual review	A person, every 3 months	The reviewer	Drift between reviews; reviews slip
Auto-publish from chats	Nobody	The model	Unreviewed errors and leaked personal data go live
Curator agent with owner approval	The agent, weekly	Agent drafts, owner approves	Approval queue can back up if owners ignore it

The last row is slower than auto-publishing on purpose. The owner queue is the control, and it only works if owners clear it, which is why every task the agent raises carries a named person, not a team.

What this costs to set up

Knowledge base upkeep is an ongoing job, so it fits a Fractional AI Officer engagement at $2,900 per month: one new automation shipped each month, monitoring of what is already running, and a weekly written brief. A typical order is ownership and the audit in the first month, then answer capture in the second, with publishing turned on per source only once attribution and redaction hold. Cancel monthly. Everything runs on your accounts, and you own the delivered code, data and documentation.

If you do not have the assistant yet, start with how an internal knowledge assistant is built. Upkeep is the job that comes after it.

The curator runs inside the same governance layer as the rest of our agents: an owner, a scope and a kill switch per agent. Our agent fleet case study shows that layer, with 41 agents registered and 5,450 runs at zero failures over 13 days measured to July 2026.

Start async

If your assistant is answering from content nobody has reviewed since launch, start async. Tell us in writing which knowledge sources it reads and who owns each one today, and we reply within one business day. No calls.