What is the Knowledge Base?

The Knowledge Base is two things at once: a public help center your customers can browse and search, and the corpus your AI agents read from when they answer questions on chat, voice, and email. The same articles do both jobs. Write something well once, and a customer reading it on the help site, a Web Chat agent answering at 2am, and a voice agent on the phone all reach the same answer.

This is the difference between a help center that exists and one that earns its keep. Most help centers are written, shipped, then quietly drift. In Atender, every article is embedded into a vector index the moment it’s published — your AI agents start using it within seconds. When customers ask questions you haven’t documented yet, the Self-Learning engine watches and proposes new article drafts.

The shape of a Knowledge Base

Every Knowledge Base has the same shape, regardless of size:

• Categories — The top-level groupings on the public site — “Getting started”, “Billing”, “Returns”
• Subcategories — Optional second level inside a category — Inside Billing: “Invoices”, “Payment methods”
• Articles — The unit of content — a concept, a how-to, a reference, a recipe, a FAQ — “How do I update my payment method?”
• Sections — An alternative grouping that cuts across categories — “Most popular”, “Recently updated”, “For developers”
• Tags — Cross-cutting labels for filtering and search — getting-started, troubleshooting
• Roles — Optional browsing-visibility filter — admin, agent, end-user, etc. — A “developer” role hides admin-only articles from end users

Categories and subcategories are the structural skeleton. Sections, tags, and roles are different ways to slice the same articles for different audiences.

What lives inside an article

An article is more than a title and a body. Each one carries:

• A summary — one sentence shown in search results and category listings.
• A status — draft, published, needs-review, or archived. Drafts and needs-review are invisible to the public.
• A difficulty — beginner, intermediate, or advanced.
• An estimated reading time in minutes.
• Keywords — extra terms the search uses but that aren’t visible to readers.
• Tags and role assignments — for filtering and browsing visibility.
• Translations — for any language you’ve enabled.
• Embeddings — the vector representation your AI agents retrieve against.

The visible parts (title, summary, body) are what your customers read. The invisible parts (keywords, embeddings, status) are what makes the help center fast, accurate, and AI-ready.

Where the Knowledge Base shows up

• The public help center — at your custom domain, or under prod.atender.dev/knowledge/<your-tenant-slug>. This is what customers browse and search.
• AI agents — every published article is embedded and available to the Capabilities, Sidekick, and Web Chat / voice agents that answer for you.
• Sidekick — when an agent is handling a conversation, Sidekick surfaces relevant Knowledge Base articles in real time.
• Search shortcuts — agents can use snippets that link to specific articles for quick reference.

What the Knowledge Base is not

The Knowledge Base is for customer-facing content — things you’d happily show to anyone who lands on your help site. Internal procedures, escalation scripts, “how we actually handle this” guides, and policies the AI should follow but never quote belong in the Handbook instead.

If you find yourself writing something like “If a customer says X, transfer to billing and apply a 10% courtesy credit” — that’s a Handbook procedure, not a Knowledge Base article. Customers shouldn’t see it; agents and AI should.

Where to go next

• Write your first article: Create an article
• Set up the public site: Help center layout, Customize the public portal
• Make it multilingual: Multi-language Knowledge Base
• Push articles from your own pipeline: External KB API