How to build a knowledge base your AI support agent can actually use

Yuliia Demchyk opens with a figure that 95% of AI agent projects fail and lists the reasons. Data comes first: poor quality, insufficient volume and fragmentation across sources and channels. Then come companies that follow the trend without deciding what role the agent should play, cheap setups that hallucinate and cannot handle sensitive data, weak strategic planning and expectations set too high. She also notes that customers are no longer ready to read a knowledge base or FAQ. They want an answer in seconds, which is exactly where an agent helps, but only if the knowledge behind it is right.

A good knowledge base, in the speakers' view, is complete, relevant and regularly updated, structured, accessible, free of contradictions, flexible and ready for machine reading. Yuliia shares a case of a business that rushed to use its website as the knowledge base and complained that the agent answered wrongly. The check showed the website itself was outdated, so testing the agent exposed that customers had been misled by the site, and the site was fixed.

Oksana Budz then separates must-haves from good-to-haves. Start with purpose and audience: a customer knowledge base needs simple language, minimal jargon, short articles and screenshots with arrows, while an internal one for support reps holds troubleshooting paths and sensitive details. She never advises a hybrid. If you face a hundred-plus articles, pick about 20 of the most common, structure them well, train the agent, check the results and only then continue. Group articles into clear categories such as account, billing and product setup, keep a consistent layout (quick summary, steps, notes, related articles) and follow one topic per article: how to change your password, not how to change your password and update billing info.

Writing rules are concrete. If you say login, never switch to sign in. Explain jargon and abbreviations on first mention, because GA means general access to one person and Google Analytics to another. Use active voice and aim for 15-20 words per sentence: if you cannot log in, follow these steps. Formatting matters because the AI reads it too: H1 for titles, H2 and H3 for subsections, numbered steps, bold UI elements. Tables are tricky. Four columns and 15 rows are fine, but huge tables add more noise than value and may hide outdated rows. Keywords in titles help as well: reset password in mobile app works better than password issues.

A large part of the session covers chunking. When you train an agent, documents are split into small pieces, converted into vectors and stored in a vector database, and the AI searches those pieces instead of reading the whole file. With the older fixed-size approach, for example 500 tokens per piece, a paragraph or a guide can be cut between step three and step four, and the context is lost. Topic-based chunking cuts by meaning, keeping each idea or task together, and table-friendly chunking keeps headers, row context and values intact so the agent can find the exact cell.

The speakers also stress keeping a human in the loop, since AI cannot handle 100% of queries and some customers simply want a person, and tracking accuracy, self-service rate and article views. In the Q&A they explain that deleted data is forgotten right away, that only conversations a person approves should be used for training, that contradictions between sources must be fixed, and that ROI is measured by comparing escalations of typical questions before and after launch, usually over about a month, plus CSAT or NPS. Information that changes daily, like pricing or availability, should be fetched live rather than stored as static articles.