Skip to content
Tigy AI
Tigy AIVoice agentsBuild conversations for phone and webIntegrationsConnect agents to your systemsControl and reliabilityTest, monitor, and refine agents
Explore the platformSupport agentsAnswer common questions and route requestsLead qualificationUnderstand each contact's needsHow it worksGo from setup to live callsPricingFind a plan to get startedDocsLearn how to configure your agent
Areas of focus
TelecommunicationsFinancial servicesHealthcareTechnologyRetail and e-commerceMedia and entertainmentTravel and hospitality
Use cases
Customer supportLead qualificationAI receptionist
Business profiles
EnterpriseStartups
DocsBlogPricing
Platform
Voice agentsIntegrationsControl and reliability
Solutions
TelecommunicationsFinancial servicesHealthcareTechnologyRetail and e-commerceMedia and entertainmentTravel and hospitalityCustomer supportLead qualificationAI receptionistEnterpriseStartups
PricingDocsBlog
SIGN IN
Blog/Guides

How to prepare documents for an agent's knowledge base

Organize headings, conditions and exceptions before processing sources and attaching them to the agent.

Author
Tigy AI team
Published
Sep 3, 2026
Updated
Oct 4, 2026
Explore voice agentsCreate an agent
Soft contours over light and shadow fields.
Preparing knowledge documents

In this article

  • Give each section a clear subject
  • Check tables and visual information
  • Process and select the correct source
  • Test rules together with exceptions
  • How should a passage work when retrieved on its own?
  • Start with an inventory of approved answers
  • Rewrite while preserving conditions and exceptions
  • Check what the file makes available to consultation
  • Validate association with the intended agent
  • Create questions distinguishing quality from coincidence
  • Treat updates as part of service operations
In this article
  • Give each section a clear subject
  • Check tables and visual information
  • Process and select the correct source
  • Test rules together with exceptions
  • How should a passage work when retrieved on its own?
  • Start with an inventory of approved answers
  • Rewrite while preserving conditions and exceptions
  • Check what the file makes available to consultation
  • Validate association with the intended agent
  • Create questions distinguishing quality from coincidence
  • Treat updates as part of service operations

Preparing documents for a voice-agent knowledge base means making each rule understandable with its conditions, exceptions and validity. In Tigy AI, documents need completed processing and selection among the agent’s sources. Uploading a file to a workspace does not automatically make it available to every agent. Test questions answered by the material, exceptions and missing information before publishing.

Key takeawayUseful sources connect answers with their conditions. Organize passages and test exception questions alongside straightforward cases.

Give each section a clear subject

Use headings naming the service and question, such as accessory exchange deadlines. Explain internal terminology and place conditions beside the rules they modify.

Avoid relying on references to earlier passages when sections may be retrieved separately. Identify the location, product or audience covered by the guidance, preserving the context needed to apply each rule.

Check tables and visual information

Tables should make each service's values explicit. In a prepared text version, retain column names, units and applicable conditions in relevant records.

Prepare approved textual descriptions for essential information contained only in images. Test corresponding questions after processing. Completed status establishes processing; correct conversational answers still need verification.

Process and select the correct source

Use a supported knowledge-base format and check the product's file limit. Wait for completed processing, then select the document among the answering agent's sources.

Workspace upload and agent attachment are separate steps. Check selection before testing. Deselect conflicting versions and unrelated service documents outside that agent's support scope.

Test rules together with exceptions

Prepare a common case, an exception and an unanswered question. For exchanges, vary products, dates and conditions rather than testing only a general deadline question.

For mixed-up answers, review headings, passages and selected sources. Changing information such as available stock should come from the responsible system through a configured tool rather than a static manual copy.

How should a passage work when retrieved on its own?

Useful passages identify the service or product, rule and condition together. In a fictional example: “The Central branch receives rescheduling requests through channel X; confirmed bookings need staff review.” This preserves a limit lost in “rescheduling through channel X”, without establishing a real policy.

Replace vague references such as “as above” with explicit names. When converting tables, retain headings, units and exceptions with their corresponding values. After processing, ask about that condition; a completed file status does not establish that retrieved answers preserve its meaning.

Start with an inventory of approved answers

Before editing files, list questions the agent must answer. For each question, identify an approved source, an owner and conditions changing the answer. This inventory exposes gaps that a large collection of PDFs may conceal. Include questions people actually ask rather than only headings from an internal manual.

Classify materials by purpose. Policies explain conditions, procedures describe sequences and commercial pages present offers. When different sources discuss the same service with different goals, staff must decide which source supports operational answers. Promotional language is not sufficient evidence for exceptions, eligibility or commitments.

Separate general information from individual records. Opening hours and required documents may belong in shared material. Order status and contract details require authorized queries to appropriate systems. Knowledge files should not become indiscriminate copies of customer records or substitutes for current account information.

Select a small set for the initial scope. Verify coverage of common requests and relevant exceptions, then expand when real questions expose gaps. This sequence makes incorrect answers easier to trace and preserves clear ownership. Record excluded topics too, so reviewers know when the expected response is clarification or referral rather than an answer from the available documents.

Rewrite while preserving conditions and exceptions

In a fictional manual, collection happens during business hours, while a distant note limits one service to the central branch. Bringing these facts together prevents a superficially correct answer sending someone to the wrong location. Editing should preserve the decision someone needs to make, not merely shorten the source.

Each useful passage should name the service and relevant condition. Avoid phrases such as “in these cases” without nearby antecedents, unexplained abbreviations and headings understandable only to meeting participants. Information must remain intelligible when consulted outside its original sequence. Where two services share a name, add the distinction needed to select the right rule.

Convert difficult tables into clear descriptions when necessary, preserving relationships between columns and values. Never merge rows belonging to different branches. If eligibility depends on category, explain which category controls the decision and what to do while that category is unknown. Keep essential exceptions next to the rule they qualify.

Ask the service owner to review edits before upload. More readable wording can unintentionally change meaning. Compare the revision with approved policy and test at least one qualifying case and one exception. Record reviewer decisions when ambiguity is resolved so future updates do not restore the original uncertainty.

Check what the file makes available to consultation

A PDF can look excellent on screen while containing scanned pages, unexpected text ordering or important information available only as an image. Accepted format does not prove that an agent can find a faithful answer. Visual appearance and usable textual content are different aspects of source quality.

Inspect the original file and the information available after processing. Ask questions about passages from the beginning, middle and end. Include a table, an exception and a term used by callers. Sampling only the opening page can miss material problems. Where a diagram carries a rule, provide an approved textual explanation rather than assuming the picture will be interpreted correctly.

When an answer fails, first check that the passage exists and its organization preserves meaning. Then verify processing and association with the agent. Changing instructions before these checks can conceal the actual cause and increase prompt complexity without improving the source. Keep reproduction cases small enough to distinguish missing material from ambiguous questions.

Record questions, expected answers and corresponding sources. This record supports repeat evaluation after replacement files. Treat inconsistencies as issues requiring investigation; a successful simple question does not establish that the entire document is usable. Reviewers should also confirm that answers do not combine unrelated entries into a new unsupported policy.

Validate association with the intended agent

In Tigy, uploading material to a workspace does not automatically make it available to every agent. The file must finish processing and be selected in the configuration of the agent intended to use it. Confirm this association before interpreting an unanswered question as a retrieval quality problem.

Perform a simple traceability check: approved filename, processing status and associated agent. Avoid labels such as “new final” that fail to distinguish service or revision. Use identifiers staff can find during review. Keep the approved original accessible to its owner so an unexpected answer can be compared against actual source wording.

Test one question clearly dependent on the selected material and another outside its coverage. The first checks usefulness; the second checks recognition of a gap. A knowledge collection need not answer everything, but conversations should handle its limits honestly. Include a misleading caller claim to ensure that unsupported statements do not become approved policy.

After replacing a file, inspect effective configuration before publishing agent changes. Saving, testing and publishing are distinct stages. Record which source and configuration revision were evaluated so another person can reproduce the outcome. Repeat relevant checks when switching agents, rather than assuming workspace membership gives them identical source access.

Create questions distinguishing quality from coincidence

Useful evaluation includes variations changing the decision. Asking opening hours in two similar ways helps, but does not replace asking about another branch, a holiday or a service with its own rule. Coverage should follow operational distinctions rather than superficial wording variety.

For each source, create a direct question, a natural reformulation and a question with incomplete context. Add an uncovered request. Define expected answers and what would constitute an unsupported claim. Missing information should lead to clarification or an appropriate referral. If location determines eligibility, a question lacking location should not silently receive the most common branch policy.

Review answer content as well as fluency. Compare conditions, values and next steps against approved sources. Pleasant speech may omit the restriction making advice useful. Where multiple facts are required, confirm that they remain connected correctly; accurate individual facts can still produce an incorrect combined recommendation.

Preserve representative failures and repeat them after changes. When staff correct a branch rule, test other branches to detect unintended effects. The collection need not be enormous: it needs to capture places where a plausible answer could change a person's decision. Document expected clarification behavior so different reviewers apply consistent criteria rather than personal stylistic preferences.

Treat updates as part of service operations

Assign responsibility for receiving policy changes and updating selected files. Without this route, service may continue repeating old guidance even after staff know the new rule. Source maintenance belongs to the operating process because callers act on information, not on the date a document was uploaded.

Revisions should state what changed, when it applies and which questions are affected. Preserve organizational history outside the active collection when needed. Avoid two competing versions without clear validity rules. Future policy should not be presented as current simply because its file has been added early.

Prioritize changes affecting decisions: requirements, availability, eligibility and procedures. Style corrections may wait for grouped review. This distinction directs effort toward outdated answers causing more rework. When a change only affects one service, identify its related questions rather than rerunning unrelated examples without a reason.

Set review intervals appropriate to the material and a response for urgent changes. Completion means the agent answers correctly using the current source, not merely that a file was replaced. Close the update with effective configuration checked, relevant scenarios tested and the owner informed. Keep the review record concise enough that the team will continue maintaining it as everyday operational evidence.

In the Tigy documentation

  • Knowledge Base
  • Testing your agent

Make every conversation count.

Create an agent

Keep the conversation going

Particle sphere over soft color fields.
Agent knowledge base

Knowledge bases for voice agents: documents and testing

Particle sphere over soft color fields.
Configuring a prompt agent

Preparing an agent in Tigy: prompts, knowledge and context

Soft contours over light and shadow fields.
Knowledge base review

How to update and test an agent's knowledge base

Soft light veils around a textured abstract background.
RAG: answers from documents

What is RAG in voice agents, and how do you review sources?

Soft color fields over a dark background.

How to choose a voice and test your AI agent's vocabulary

Soft light veils around a textured abstract background.

Voice agents without reliable answers: missing or conflicting sources

Particle sphere over soft color fields.

Context windows: what longer conversations require from your agent

Fine waves over a textured abstract composition.
Multilingual voice support

Multilingual voice agents: preparing and testing customer service

Tigy AI

PRODUCT

  • Voice agents
  • Integrations
  • Control and reliability
  • Demos
  • How it works
  • Pricing

Solutions

  • Telecommunications
  • Financial services
  • Healthcare
  • Technology
  • Retail and e-commerce
  • Media and entertainment
  • Travel and hospitality

Use cases

  • Customer support
  • Lead qualification
  • AI receptionist

Business profiles

  • Enterprise
  • Startups

Legal

  • Legal center
  • Terms of service
  • Privacy
  • Cookies

Resources

  • Blog
  • Documentation
  • AI documentation
  • Contact us

Social media

  • LinkedIn
  • Instagram