Prepare an AI agent knowledge base with a question-first review

Define the answers you are willing to approve

Begin with an answer contract: a short document describing what your agent should answer, which evidence you will accept, and what it should say when that evidence is incomplete. Our proposed workflow starts with questions rather than a folder upload. Treat every checklist, status, example, and acceptance rule below as an editorial proposal to adapt to your team.

Write ten representative questions for one bounded area, such as workspace administration. Include straightforward requests, questions that need a condition, and requests outside the intended scope. For each, draft the expected answer boundary: what may be stated, what requires clarification, and what must remain unanswered until an owner supplies evidence.

Google's guidance on AI-generated website content says that outputs may contain inaccuracies and calls for manual checking before publication. Its guidance also includes reviewing titles, descriptions, and image alternative text. These are recommendations for web publishing, which we use here as a reference for editorial review rather than as agent implementation documentation. Google's generative AI content guidance.

Our proposed deliverable for this opening stage is a question sheet with an owner and an approval field for every expected answer. Leave the approval field empty until the evidence review is complete. Do not treat a plausible draft as an approved answer.

Build an evidence packet for each question

For each question, assemble a small evidence packet. Our proposed packet contains the source location, document identifier, relevant section, author or responsible team, language, applicable product variant, and review status. Record the document's stated date separately from the date your reviewer examined it. Add an effective date only when the responsible owner confirms one.

Use the packet to make an explicit editorial decision: accept this source for this question, request clarification, or exclude it from the intended answer. Avoid approving a whole collection merely because one page has been reviewed. Where one document supports several questions, reference its identifier from each packet and record the relevant passage separately.

As a proposed naming convention, use a stable identifier such as KB-ACCOUNT-014 and keep the reader-facing title descriptive. Put version details in designated fields. For a hypothetical account-setting article, list prerequisites, the requested action, the completion condition, and exceptions as separate entries. Mark any unspecified entry as an open editorial task.

Google's helpful-content guidance asks creators to assess whether material offers a complete description, makes its sourcing clear, and contains readily verifiable factual errors. Those questions provide a reference for the review checklist proposed here. Google's helpful-content assessment.

Ask the reviewer to approve the answer and its evidence together. Our suggested sign-off statement is: “Approved for the question and scope recorded in this packet.” Keep broader approval outside that statement unless the reviewer explicitly grants it.

Give documents a deliberate maintenance state

We propose three maintenance states: candidate, approved, and retired. A candidate awaits review. An approved document may support the questions and conditions recorded in its packets. A retired document remains available for editorial history but should be excluded from the approved answer set under this convention.

Create a maintenance card for each approved source. Include a named owner, last review date, next review date, and a change note. Choose the review interval as a team decision rather than presenting a universal number. You might schedule one review around a planned product change and another at a regular editorial meeting.

When reviewing a document, ask the owner to confirm its scope and applicable version. Do not use the file's timestamp as your sole approval criterion. Under our proposed process, a changed timestamp triggers inspection; it does not itself settle whether the answer should change. Record the actual decision, even when the decision is to retain the existing wording.

For multilingual material, create separate approval fields for each language. Link corresponding documents through a shared topic identifier, but ask a reviewer to confirm each language's terminology, conditions, and examples. In this workflow, approving the English packet does not automatically approve the Polish packet. Treat that as an explicit organizational rule.

Resolve contradictions through a decision record

Consider a hypothetical test question: “Who may change this workspace setting?” Suppose one draft names an owner and another names an administrator. Our proposed response is to open a contradiction record, not to select whichever wording appears more frequently. Record both passages and ask the responsible team to specify the applicable rule.

First, have the reviewer check whether the passages address different versions, account types, languages, or stages of the task. If different conditions are confirmed, write separate conditional answers. If one document replaces another, identify the replacement and retire the superseded passage under your maintenance convention.

If the reviewer cannot settle the conflict, mark the question as unresolved. Our proposed answer instruction is: “The approved material does not establish which rule applies. Ask for clarification or refer the question to the designated owner.” Adapt that wording to your service and available contact route.

Close the record only after adding the decision maker, decision date, explanation, and affected question identifiers. Then review each affected expected answer. Do not quietly edit the final sentence while leaving the evidence packet and acceptance example unchanged. Make those updates part of the same editorial task.

Turn missing information into assigned work

Our proposed gap register distinguishes three work items: no supporting source, a source that leaves a required condition unspecified, and a test in which the intended passage was not found. Assign each item a concrete next action. Request a document for the first, an owner decision for the second, and an inspection of the material and test result for the third.

Write gaps as answerable requests. Replace “Improve onboarding knowledge” with “Confirm the prerequisite for inviting a workspace member and identify the approved instruction.” Include an owner, target review point, and completion condition. Close the item when the required evidence and expected answer have both been approved.

For prioritization, choose your own rubric. One proposed rubric asks whether the question belongs in the initial release, whether its answer is blocked, and whether an accountable reviewer is available. Use those answers to select work at your editorial meeting. Avoid assigning invented frequency or impact scores when you have no supporting records.

Allow “outside the agreed scope” as a deliberate outcome. Record the reason and proposed response boundary instead of filling every gap with a speculative answer. Reconsider the scope through a separate decision when the team wants to expand the agent's responsibilities.

Rehearse the release and keep a review trail

Our proposed release rehearsal uses four groups: supported questions, conditional questions, unresolved contradictions, and questions without approved evidence. For each example, record the expected answer boundary, acceptable source references, actual result, and reviewer decision. Add an informal paraphrase of selected questions as another editorial test case.

Set acceptance rules before running the rehearsal. For example, require approved evidence for every accepted answer and an explicit unresolved response for a blocked question. These are proposed project criteria, not claims about guaranteed agent behavior. Assign failures to a document task, a decision task, or further inspection rather than closing them with a general note.

Finish by naming the owner of the released collection and scheduling its next review. Preserve the question sheet, decision records, and gap register alongside the approved material according to your team's storage convention.

The Max AI registration page describes the service as an operating system for AI agents. Max AI registration. If you choose it for your next step, our proposed starting package is one approved topic, its question sheet, and a clearly assigned list of unresolved items.