How to build an AI that answers from your documents

This page may contain affiliate links from which Blur Studio earns commissions.

Most "repeat question" problems have an answer that already exists somewhere, a policy doc, a price sheet, an FAQ page, it's just not in front of whoever's answering the phone or chat, and relying on staff memory means the answer varies slightly depending on who picks up. A knowledge-base-backed AI agent fixes that gap directly: it reads your actual documents and answers from them, rather than from a script someone wrote once and never updated. The customer-facing side is covered in stopping the same customer questions all day.

Start with a shared FAQ document, it's free

Before building anything automated, write down your most repeated questions with clear, current answers in one place your team can find quickly. This alone fixes a meaningful share of the problem, since a lot of the delay on a repeat question is finding the answer, not giving it. It stops being enough once volume is high, or once you want something that can answer visitors or callers directly without a person in the loop. The staff side of this problem is covered in making answers easy to find for staff.

How the knowledge base actually works

ElevenLabs' agent platform lets you upload documents directly into an agent's knowledge base: PDF, Word (DOCX), plain text, Markdown, HTML, EPUB, or straight URLs, with a 20MB limit per file. Small documents get used directly in the agent's working context when it answers a question. Larger ones get broken into chunks and retrieved as needed through a retrieval system (RAG), rather than being read in full every time, which is how the agent can draw on far more material than would otherwise fit in a single conversation. Documents smaller than 500 bytes skip retrieval entirely and go straight into the prompt.

How much you can index this way depends on your plan: roughly 1MB total on Free, 2MB on Starter, 20MB on Creator, 100MB on Pro, 500MB on Scale, and up to 1GB on Business and Enterprise. For most single-business FAQ and policy use cases, Creator or Pro's limit is more than enough; it starts to matter once you're loading in large catalogs or extensive documentation. Check ElevenLabs' current plans to see which tier's limit fits how much documentation you actually have.

Plan	Knowledge base limit
Free	~1MB total
Starter	~2MB total
Creator	~20MB total
Pro	~100MB total
Scale	~500MB total
Business/Enterprise	up to ~1GB total

To put that in perspective: a typical small business's full set of policies, pricing sheets and FAQs, even a fairly thorough one covering every service line, usually runs well under 5MB as plain text or PDF, which fits comfortably inside Creator's limit with room to add a lot more before you'd ever need to think about the cap. The limit becomes a real constraint mainly for businesses loading in large product catalogs with hundreds or thousands of SKUs, extensive technical documentation, or years of accumulated policy history that was never trimmed down.

Step by step

1. Gather your current documents: policies, pricing sheets, hours, FAQs, anything your team answers from regularly.
2. Check that they're actually current before uploading. An agent answering confidently from an outdated price sheet is worse than it saying it will check and get back to you.
3. Load them into the agent's knowledge base and test with the real questions you know come up often, plus a few edge cases.
4. Watch for wrong or outdated answers in testing, and trace them back to whichever document is stale or unclear.
5. Set a recurring reminder to review and update the knowledge base whenever a policy, price or fact actually changes, not just once at setup.

Practical tips

• Stale documents are the number one cause of bad answers, not the AI itself. Most "the AI got it wrong" complaints trace back to an outdated document still sitting in the knowledge base, not a limitation of the model.
• Keep documents narrowly scoped where possible. A clean, specific FAQ document retrieves more reliably than one giant file mixing policies, pricing and unrelated content, since retrieval works by finding the most relevant chunk, and a focused document gives it less to sort through.
• Don't load information that changes constantly, like live prices or stock levels, as a static document. That kind of data needs a live connection to your actual system, not a knowledge base file that goes stale the day after you upload it. A live lookup example is setting up an order status phone line.

A detail worth knowing before you upload everything at once

Documents under 500 bytes never go through retrieval at all, they get inserted directly into the agent's working context every time. That's rarely a problem on its own, but if you've got a lot of tiny reference snippets alongside your larger documents, it's worth knowing they're being handled differently under the hood, since a large pile of small always-included snippets can crowd out the context space that should be going toward the actual conversation. If an agent's answers start feeling oddly generic once you've loaded a lot of content, check whether too much of your knowledge base is made up of small, always-included pieces rather than content being retrieved only when relevant.

A worked example: a dental clinic's knowledge base

Say a dental practice gets the same calls repeatedly: hours, whether they take a specific insurance plan, what a routine cleaning costs without insurance, and what to do for a dental emergency after hours. Instead of one giant "clinic info" document, the better structure is several focused files: an hours-and-location document, an insurance-accepted document (updated whenever a new plan gets added or dropped), a pricing document for common procedures, and an emergency-guidance document. Each one answers a narrow set of questions well, and updating the insurance list doesn't risk introducing an error into the pricing document the way one combined file would. When a patient calls asking "do you take Delta Dental," the agent retrieves from the insurance document specifically, not from a 40-page combined file where that one line is buried among pricing tables and office policies. To put the same agent on your website, see adding a voice assistant to your website.

Keeping multiple documents in sync as you scale up

Once you've got more than a handful of documents, the real risk shifts from "the AI can't find the answer" to "two documents disagree with each other." A price appears in both a general FAQ and a dedicated pricing sheet, someone updates one and not the other, and now the agent gives an inconsistent answer depending on which document retrieval happens to pull from. The fix isn't more AI, it's ordinary document discipline: decide which document is the single source of truth for each type of fact (one place for prices, one place for hours, one place for policies), and have everything else link or refer to it rather than repeating the number. Review the full set on a fixed schedule, not just when someone remembers to, and treat a retrieval disagreement the agent surfaces in testing as a signal that your documents themselves are inconsistent, not that the AI is confused.

What I'd tell someone setting this up for the first time

This is genuinely one of the more forgiving parts of building an AI agent, since you're mostly doing document housekeeping rather than anything technical. The honest limitation is that it's only ever as good as what you give it. If your documents are outdated, incomplete, or contradictory, the agent will confidently reflect that back. Spend more time getting the documents right than tuning the agent itself. I'd also say don't aim for perfect coverage on day one. Load your most-asked questions first, watch what the agent actually gets asked once it's live (most platforms log unanswered or low-confidence questions), and add documents to fill the real gaps that show up rather than trying to anticipate every possible question in advance. The real question list from live usage is almost always different from the list you'd guess at beforehand.

How I'd approach this

Loading static documents is something you can do entirely yourself on ElevenLabs' own dashboard. Where I get involved is when a business needs the agent answering from data that changes constantly, live inventory, real-time pricing, current job or order status, which needs a direct connection to your actual system instead of a document someone has to remember to update. I'd also set up the single-source-of-truth structure described above from day one on any multi-document build, since untangling a knowledge base where five documents have quietly drifted out of agreement with each other is a far more annoying job after the fact than designing it cleanly up front.