How to prepare sources for customer-facing and internal agents, separate access and find the cause of an incorrect answer.
A company may have a presentation, a catalogue, managers' messages and a table of terms. All are useful to staff, but together they do not yet form an agreed answer base for a bot. One document describes an old service, another omits a restriction, and a personal offer to a customer looks like a general rule.
For a business in Kazakhstan, it helps to start with a manageable set of information: which question is being answered, where the answer comes from and who is responsible for updating it. This guide focuses on maintaining content. Choosing the conversation mechanics is covered separately in the article about a button-based bot and AI.
Collect questions instead of a random archive
Ask employees to list recurring questions and group them by meaning: choosing a service, preparing materials, enquiry procedures and work status. Do not copy unnecessary information about individual customers into the working collection. An anonymised question and an explanation of why the person struggled to get an answer are usually enough for analysis.
For each topic, specify whether the bot should provide established information, ask a clarifying question or hand the conversation to a person. A question about the standard procedure and a request to reconsider an individual condition require different actions. This classification helps define the knowledge base before choosing how to upload documents. Save real wording variations separately: employees and customers may use different names for the same service.
Prepare a card for an approved answer
Create a short card for each topic. Keep it in a spreadsheet or another editor the team finds convenient. A useful minimum looks like this:
- The question and a few common ways customers phrase it.
- An agreed response without unverified promises.
- Conditions of use: which service or situation the answer applies to.
- Source: a document, system section, or confirmation from the information owner.
- The content owner and date of the latest review.
- When data is missing: ask for clarification, state that information is unavailable or hand over to an employee.
Do not turn the card into a long sales presentation. If an answer depends on the product variant, that condition should appear next to the answer itself. If both languages are within the bot's scope, agree separately on the terminology and meaning of the Russian and Kazakh versions.
Resolve contradictions and define boundaries
Compare the cards with the company's current materials. If sources conflict, appoint someone to decide which rule actually applies. A newer file date alone does not prove that its contents are approved. Record the decision and remove the outdated version from the set the bot should use.
Separate stable information from data that changes during work. For example, stage descriptions and the current status of a particular order should not be stored as equivalent universal answers. For changing data, agree on the source and permitted retrieval method. If no such connection exists, provide a handoff to an employee. A document's presence among the source materials does not confirm that every value in it is current.
Run a hypothetical change through the whole process
Imagine a workshop that previously asked only for product dimensions but now also requests a photograph of the installation location for an initial discussion. The card explaining how to prepare an enquiry changes. This is an illustrative example, not information about a GIFS project.
The process owner clarifies the new wording and specifies when it applies. The editor updates the answer and related guidance. The reviewer asks the question in several familiar ways and checks that the new request has not become a promise of an exact quote from a single photograph. After publication, the team records the version. If the same procedure is described on the website, the owner is assigned to align both sources. This ensures the change does not end with replacing one row in a table.
Agree on publication and version rollback
Document the card's workflow: proposing a change, owner review, preparation for upload, publication and checking the available answer. Clarify which actions are performed by an employee and which are automated. The update method depends on the chosen solution; do not promise instant synchronisation without checking the connection.
After a change, ask a test question in the version of the bot available to users. Also test a related topic the change may have affected. Keep the previous approved text and a rollback procedure in case the new version is wrong. Deleting a file from the working editor and stopping the bot from using its contents must be verified as outcomes, not assumed to be the same action.
Use unanswered questions to improve the knowledge base
Keep a separate list of inquiries the bot handed to an employee or could not match to agreed wording. During review, identify the reason: a new topic is not covered, the question was ambiguous, the source is outdated, or the situation requires an individual decision. Not every inquiry needs to become an automated answer.
If several phrasings relate to an existing topic, refine the example questions and check the relevant card. If a new company rule is needed, agree it with the process owner first. Do not copy an individual promise from a conversation as a standard for all customers. Recording the decision and responsible person in a log helps avoid revisiting the same gap with every enquiry.
One knowledge base for everyone or separate sources by role
When AI agents help both customers and employees, the same question may require different answers. Customers need the public enquiry procedure; employees need internal instructions. Shared approved information can be reused, but access to internal materials must depend on the user’s role and task.
Do not combine documents into one universally accessible collection simply because they belong to the same company. Mark the intended audience of each source and what may be shared externally. Check access settings in the connected systems; asking the model “not to disclose internal information” is not an access boundary by itself.
- For a customer-facing agent: public descriptions, enquiry terms and approved answers without internal notes.
- For the employee agent: instructions and working materials permitted for that role.
- For handover between agents: a specific task, the necessary verified facts and a link to an authorised source.
- For the employee making the decision: marked gaps, disputed information, and verification results rather than a confident assumption.
Example source card for multiple agents
Let us complete a card for the hypothetical workshop above. The document and version names are for training; they do not describe GIFS rules or integrations. You can copy the card and replace its conditions with those approved by your team.
- ID: KB-03. Topic: preparing a product request. Questions: “What should I send for a quote?” and “Are dimensions enough?”.
- Source: “Request preparation,” approved version v2, section 2. Content owner: the workshop manager. Before uploading to the working knowledge base, the team adds the actual link to this section and its approval date.
- Public answer v2: “For an initial discussion, send the product dimensions and a photo of the installation location. If you do not have a photo yet, let us know: an employee will clarify what can be discussed using the available information. The exact cost is determined after the task is reviewed.”
- Boundaries: the card contains no price or production lead time. The internal cost table is in a separate source unavailable to the customer-facing agent; customer answers are not based on it.
- Change from v1: a photo request and a path for customers without a photo have been added. Expected state after the update: answers use v2, and the previous request for dimensions alone is no longer given as the complete list.
- Handover: the agent records which materials are available and which are missing; the employee receives a link to the KB-03 version they are authorised to access. The agent does not fill in the price or deadline on its own.
The test question “No photo—will you refuse my request?” should lead to clarification by an employee, not an invented refusal. “How much exactly?” may be answered by explaining that the task needs to be checked, without quoting an amount. If the bot still asks only for dimensions, check which source version it received. If it received v2 but requires a photo without exceptions, the error lies in conveying the answer's meaning. Log the question, version used and actual answer: “v2 uploaded” alone does not complete acceptance.
Choose the number of agents according to tasks and access boundaries, rather than the size of a document folder. Sometimes one assistant with clear rules is enough; several roles are useful when there is a real benefit to separating their work. Gradually adding complexity after testing a simple solution is also recommended by Anthropic in its article on building agents.
How to find out why an answer was wrong
Investigate a specific question through one sequence. First check whether the source contains a current approved answer. Then check whether that role is allowed to access it. The developer then checks which material the system actually received for its answer. The final step is to compare the answer with that material.
- The required rule is missing: add content after the process owner makes a decision.
- A rule is outdated or conflicts with another: agree on the version and verify that the previous one is no longer used.
- The correct material exists but was not retrieved: check access, search, and how the material is passed into the answer.
- The material was received but its meaning was distorted: correct response processing and repeat the test questions.
Do not expand access to confidential information merely so the bot can answer. Do not rewrite correct instructions to accommodate an incidental model error either. Record the original question, role, source version, identified cause and repeat test in the log. This makes knowledge-base updates verifiable work.
Give the team a maintenance template
Assign a knowledge-base owner and people responsible for each topic. Agree on which events trigger updates: changes to a service, terms, documents, or working procedures. Stable sections can have scheduled reviews, while urgent corrections follow a separate clear path. Frequency depends on actual information changes, not the size of the document list.
For each change, record the topic, reason, source, old and new versions, approving employee and test-question result. This log helps investigate errors and continue work when responsibility changes. Checks before the first launch can be taken from the chatbot acceptance guide.
On the page GIFS AI agents you can discuss preparing and maintaining answers. To start, send an anonymized list of questions, examples of current sources, and information on who approves the content.