Featured image: AI-generated conceptual illustration. Sources checked 26 October 2026.
A knowledge base can grow while becoming less useful. New articles duplicate old ones, product changes leave contradictory instructions behind and search results reward familiar wording rather than the correct answer. An agent tasked only with producing more content can accelerate that problem.
A better maintenance workflow starts with unanswered questions. It asks whether the problem is missing guidance, stale guidance, unclear writing or failed retrieval. Only one of those problems necessarily requires a new article. The agent's first product should be a diagnosis and a review queue, not automatic publication.
Capture the unanswered question accurately
Log the question that could not be answered, the product context and the sources searched. Avoid retaining the customer's entire conversation when a deidentified question is sufficient. Record whether the failure occurred in customer self-service, an internal support search or an assisted reply workflow.
These channels reveal different problems. A support specialist may know terminology that a customer does not. An article that is easy for staff to find can still be invisible to a customer using everyday language. Keep the original wording where appropriate, but strip unrelated personal information.
Include questions that received low-confidence answers, not just questions with no search results. A retrieval system can return several plausible articles while still failing to identify applicable guidance. “Results found” is not the same as “question answered.”
Diagnose before drafting
For each question, inspect the existing knowledge base. Does an authoritative answer already exist? Is it current for the relevant product version? Can the intended audience understand and access it? Does another page contradict it?
Classify the problem into missing content, outdated content, unclear content, discoverability or unresolved product behavior. The last category is important. Documentation cannot responsibly settle a question the product team has not answered.
The maintenance agent should show the evidence behind its diagnosis. If it proposes a new article, it should identify the nearest existing pages and explain why an amendment or navigation change would not solve the problem. This discourages a growing collection of near-duplicate pages.
Define ownership and authoritative inputs
Every proposed change needs an owner who can validate its subject matter. Product behavior belongs with a qualified product or engineering owner; policy belongs with the policy owner. A communications reviewer can improve clarity without being the authority on the underlying facts.
Use current approved specifications, release notes and verified support resolutions as inputs. A single ticket response is not automatically an authoritative general rule. It may describe an exception, an old version or a workaround that is no longer appropriate.
When documents live in Google Drive, the changes collection can support detection of updated files. The official guidance describes saved page tokens and current file state. Treat a detected change as a reason to inspect a source, not proof that every dependent article requires rewriting.
Draft the smallest useful change
Prefer a targeted amendment when a current article is mostly correct. Show the old passage, proposed passage, supporting evidence and affected audience. A reviewer should be able to understand the change without comparing two long documents manually.
If a new article is justified, define its specific user task. Include prerequisites, a clear procedure, expected results and what to do when the result differs. Avoid adding broad explanatory sections merely to make the article longer.
Separate facts from editorial suggestions. “The button moved to a new menu” requires product evidence. “Move the prerequisite above the steps” is a readability proposal. Keeping these categories distinct helps the right reviewer focus on the right decisions.
Handle contradictions openly
When two sources disagree, create a conflict item rather than blending the passages. Identify the conflicting claims, source owners, dates and affected articles. The agent can propose questions that would resolve the conflict, but it should not silently choose the more recent document if applicability remains uncertain.
Likewise, do not retire an article solely because it appears old. Some stable procedures remain correct for years, while a recently edited page can still contain obsolete guidance. Age is a useful review signal, not a definitive quality judgment.
Keep source versions or other appropriate provenance so reviewers can understand why a change was proposed. If the source changes again before publication, revalidate the draft. A maintenance system that publishes yesterday's correction after today's release can create a new inconsistency.
Make publication a separate step
The draft should remain unpublished until the subject-matter owner approves its facts and an editor approves its presentation. Check links and access from the intended reader's perspective. An internal source can support a public article, but the public article should not expose restricted information or inaccessible dependencies.
After an approved publication, verify the actual rendered page and search behavior. Confirm the right version is visible, links resolve and superseded content is handled according to the organization's publishing process. A successful write call does not establish that customers can find the answer.
If an existing article is replaced, preserve the appropriate redirect or reference path. Avoid deleting useful history without authorization. Maintenance includes managing the transition, not only creating the replacement text.
Measure whether questions become answerable
Evaluate a representative set of previously unanswered questions before and after the change. Have reviewers assess correctness, applicability and ease of finding the answer. Count unsupported statements and new contradictions as failures even if search coverage improves.
Track repeated gaps, reviewer turnaround and the number of proposed changes rejected because the answer already existed. A high duplicate-proposal rate suggests a retrieval problem in the maintenance agent itself.
The costs include source monitoring, model calls, expert review and publishing work. Limit the queue to changes with a clear user need and an identifiable owner. If owners cannot review the work, generating more drafts only creates debt.
The strongest outcome is not a larger knowledge base. It is a smaller set of unresolved questions, clearer authoritative guidance and a maintenance process that can explain every change. An agent can help sustain that process, provided it is rewarded for diagnosing the right problem rather than producing the most text.
Sources and research notes
developers.google.com — primary documentation: The changes collection returns current file state; save start/page tokens and process removed/shared-item parameters deliberately.
developer.zendesk.com — primary documentation: The official ticket resource reference documents reading and updating ticket records.
Documentation checked October 26, 2026. Workflow recommendations are design guidance, not reported customer outcomes. Verify current permissions, product behavior and pricing before implementation.
Leave a Reply