The knowledge pack behind a site agent: six files, and why you should not feed it your whole website

Published October 29, 2026 · Last reviewed October 29, 2026

A chatbot knowledge base is the material an AI agent on your website is allowed to answer from, and for a site agent that answers buyers it works best as a small published pack of six files with one job each: company overview, services and prices, FAQ, boundaries, booking options and assistant instructions. Most tools start from a pile instead: HubSpot’s customer agent, for example, can crawl and sync up to 5,000 URLs within a domain and re-sync them weekly.¹ For an agent whose answers carry prices and promises, that is the wrong starting point. A crawl puts last year’s price next to this year’s, and in the HoH benchmark (ACL 2025) an outdated passage in the context cut answer accuracy by at least 20%, even when the current fact was retrieved too.² When Salesforce set up Piper on salesforce.com, it connected approved product, FAQ, solution and event content and left its own blog out on purpose.³ Below we walk through the six files using a live public example, then cover what to keep out, how to keep the pack current, and why the same files should serve people and their AI agents.

One note on scope. This is about what your own agent knows and says. It does not reopen the question of whether files like llms.txt get a site cited by AI search; we looked at that separately, and the newer data since then (Ahrefs in June, Google in July 2026) points the same way.⁴

A knowledge base is a pack you publish, not a pile you upload

The usual setup flow for a website chatbot has three steps: point it at your domain, drop in a few documents, switch it on. Unless you narrow it, the crawler decides what counts as knowledge, and everything it finds carries the same weight: a pricing page updated last week, a 2023 blog post with old prices, a careers page, a press release about a product you retired.

Most tools now let you narrow it. HubSpot’s setup guide uses /blog/ as its example of a path to exclude, and Intercom tells owners to sync only relevant, up-to-date content and to avoid marketing pages and product listings.¹⁵ That advice is written for support bots. For an agent that sells, the pages buyers ask about are the product and pricing pages, which is why prices need a home of their own. A visitor asking “what does the Startup package cost” needs one current answer, the one you would put in a contract. If the crawler has picked up three versions of it, the model will blend them or pick one, and you will not know which until a customer quotes it back to you.

So the first decision is a change of frame. The knowledge base is not content you upload into a vendor. It is a pack you publish: a short, versioned set of files that states what the business wants its agent to know. Three properties follow:

• Curated. Each file exists because someone decided the agent needs it. The Piper deployment shows a large company making that call explicitly, approved pages in and the company blog out.³
• Owned. Each file has a person responsible for it and a date on it. When a fact changes, that person changes it in one place.
• Readable by people. The pack is written in plain Markdown that a colleague, a regulator or a customer could open and check. If you would be uncomfortable showing a file to a buyer, it should not be shaping what the agent tells that buyer.

Analysts point the same way from the support side: after Zendesk’s Relate conference in May 2026, Forrester’s Julie Mohr wrote that “knowledge engineering, not technology, is now the primary constraint” on scaling AI agents.⁶ A pack kept as files on your own domain also survives a change of vendor; the build vs buy piece covers the rest of that decision.

The six files, one job each

The example is relovisa.co. Relovisa is an immigration consultancy co-founded by Vlad Shipilov and Olia Nemirovski; Vlad also founded Tobira, and Olia works on growth at Tobira and is Relovisa’s COO and chief case manager, so read this as a worked example from people close to it, not an independent case study. We describe only its public files, as they read on 29 October 2026. Its llms.txt lists an Agent Knowledge Pack of six Markdown files under /agent/, and the site’s agent.json lists the same six in a knowledge_pack array.⁷⁸

Each file answers a different kind of question, so the agent always has an obvious place to look. Two more things stand out once the files sit side by side.

Numbers carry their conditions. The overview states a “99.2% completed-case success rate”, and the FAQ answer that repeats the figure adds that no individual visa, residency, citizenship or timeline can be guaranteed.⁹¹¹ The llms.txt goes one step further: it gives the period the rate covers and links it to a methodology page that defines it and names what is left out, such as investment programmes and routes delivered with partners in Germany, the UK and the US.⁷¹⁵ A number without its condition is exactly what an agent will repeat out of context.

The negative space is written down. The boundaries file runs under 300 words, among the shortest in the pack, and is probably the most important. It turns “be careful” into specific refusals: no passport scans or bank statements in chat, no “as your lawyer”, no invented thresholds.¹²

Your six files will contain different things. The jobs are what carry over: identity, offer, recurring questions, refusals, next steps and behaviour.

Why six files and not one big document

You could put all of this in one long document. Plenty of teams do. Splitting it pays off for three practical reasons.

Conflicting versions. If the same fact appears in four places, it will eventually appear in four versions, and that is the expensive failure. In HoH, one outdated passage lowered a large open model’s overall score by more than 24%, while six distracting passages, close to the question but without the answer, moved it by less than 2%; outdated text did more harm than no relevant text at all.² The pack works when each fact has one home and every other file points to it. Relovisa’s instructions file does this explicitly: route rules come from the landing pages, prices and package contents from the services file, with currency and “from” qualifiers intact.¹⁴ Even so, it shows how easily this slips. On 29 October the EUR 40 consultation terms sat in several pack files, which credit the fee toward a package if the client signs, and the boundaries file tells assistants not to promise any broader refund. The booking card a visiting assistant reads in the guest file offers a full refund within seven days and credits the fee only to a package paid for within two weeks.¹³¹²¹⁶ An assistant that follows the boundaries file and one that reads the card could tell a buyer different things about the same EUR 40. That is the cost of giving the same terms a second home.

Retrieval noise. Most site agents do not read the whole knowledge base on every question; they retrieve the passages that look most relevant and answer from those. The passages that hurt here are near misses: text that scores as relevant but does not hold the answer. A SIGIR 2024 study found they lower answer accuracy, though in HoH they cost a large model far less than one outdated passage did.¹⁷² A file that mixes prices, refusals, tone guidance and company history produces near misses for every question. When a visitor asks about price, the answer should come from the services file, not from an FAQ paragraph that happens to mention last year’s figure.

Different editors. The people who know each fact are rarely the same person. Pricing belongs to whoever signs contracts. Boundaries belong to whoever carries the legal and reputational risk. The FAQ belongs to whoever answers the inbox. Separate files let each of them edit their part, sign it off and date it without touching anyone else’s.

There is a fourth reason that is easy to miss: instructions and facts are different kinds of text. “Never promise a refund” is a rule about behaviour. “The strategy session costs EUR 40” is a fact. Mixing them makes both harder to maintain, and harder to tell which one the agent broke when an answer goes wrong. Platforms are moving the same way: from 12 March 2026 Intercom moved new Fin builds from Tasks to Procedures, one document-style editor for an agent’s instructions, rules and logic.¹⁸ A published pack keeps that text in files anyone can read, not in a dashboard only your team can see.

None of this needs special tooling. Six Markdown files, a Last updated line at the top of each and a note of who owns which file will get you most of the way. It is the same habit that keeps an agent profile specific and current.

What stays out of the pack

The harder discipline is exclusion. Every page you leave out is one less source of a wrong answer. Five kinds of material usually belong outside the pack.

The blog and the news archive. Blog posts are written for a moment: a law change, an opinion, a launch. They age, and they rarely say so. Salesforce’s stated reason for keeping its own blog out of Piper was focus, to keep responses on pipeline generation.³ Useful content and answerable content are different things. The agent can still link to a guide when a visitor wants depth; linking is not the same as answering from it. Relovisa draws a looser line: its llms.txt lists blog guides and its agent.json lists the blog feeds, while the instructions file says which sources win for prices and route rules.⁷⁸¹⁴ That is the part to copy: the files say which source wins for each kind of fact.

Anything with an old price or an old rule. Archived pricing pages, last year’s PDF brochure, a landing page for a package you no longer sell. If it is still on the site, a crawler will find it. If it is not in the pack, your agent will not quote it. Relovisa’s llms.txt states the principle in one line: “A fee not published for a route is not inferred.”⁷ Our piece on chatbot liability shows what the alternative costs: in both cases we looked at, the trouble was a bot stating a plausible fact that was false.

Judgments you would not sign. Eligibility decisions, legal or tax opinions, outcome promises. These belong to a person in a consultation, not to an agent in a chat window. Relovisa’s boundaries file rules out outcome promises and acting as a lawyer, and its instructions file describes the information the agent gives as “not a final legal or tax opinion.”¹²¹⁴

Internal documents. Margin notes, sales playbooks, objection-handling scripts, team pricing flexibility. An agent that has read “we can go 15% lower if they push” will, sooner or later, say so. Marking a source private does not settle it either: HubSpot’s documentation says private sources will not be cited but their content may still appear in responses, and tells owners to keep personal, confidential and sensitive information out.¹

Client data and documents. No case files, no CRM exports, no past conversations used as examples. Relovisa’s pack goes further and keeps sensitive documents out of the conversation itself: the agent must not request passport scans, bank statements, IDs, tax numbers, contracts or CVs in public chat,¹²¹⁴ and documents are “shared securely outside public chat, through a channel explained by the team.”¹³

A useful test for any candidate page: would you be comfortable if the agent quoted this paragraph, word for word, to a buyer today, with your name under it? If the answer is “it depends on the context,” leave it out and write the context into the right file instead. What remains is a pack one person can read end to end in an afternoon and vouch for. A 5,000-page crawl is not.

Keeping the pack current: dates, owners and visible changes

A pack is only as good as its last edit. Three habits keep it honest.

Put a date on every file, and on every fact that expires. Relovisa does this in part. Its llms.txt, services and booking files open with Last updated: 2026-10-01, and the agent.json carries the same date, but on 29 October the overview, FAQ, boundaries and instructions files had no date line, the easiest gap in the pack to close.⁷¹⁰¹³⁸ Inside the llms.txt, some fees carry the date they took effect: Portugal’s residence-permit fees are marked effective 1 March 2026.⁷ A date tells the reader, human or machine, how much to trust a line, and tells you what to check first when something changes.

Change facts at the source, then let everything else follow. Crawled knowledge lags, and it can stop updating without anyone noticing. HubSpot re-syncs sources other than its own knowledge base articles weekly, so a price changed on a crawled landing page can be quoted wrong for up to a week unless someone refreshes it by hand.¹ Intercom pauses scheduled syncs of a website that Fin has not used in an answer for 90 days, after which edits on that site are not picked up.⁵ With a pack, the person who changes the price edits the services file, and that file is the agent’s source for prices.

Let the changes show. Because the pack is public, edits are visible to anyone who reads it twice. Relovisa’s own pack is an example. By 29 October, conversion-goals.md was titled “Booking and Service Options” and led with a free written case check, which it did not on our first read on 23 September 2026, and the instructions file centred on citation, consent and languages.¹³¹⁴ Same six file names, same URLs, new rules; the dated files now read 1 October 2026. Whatever the reasons for the change, a buyer, a colleague or a visiting agent can see what the agent works from today.

A simple rhythm covers most businesses:

1. On every price, policy or offer change: edit the one file that owns the fact, update its date, and test the agent with the question a buyer would ask.
2. Monthly: read the whole pack end to end. It should take less than an hour. Anything you hesitate over goes back to its owner.
3. Quarterly: check the boundaries file against what the agent actually said. Read a sample of conversations and look for answers that drifted toward advice, promises or invented detail.

Keep a short changelog in each file or in your repository, so “why did the agent say that in August” has an answer on record.

One pack for people and for their AI agents

The last design choice is where the pack lives and who can read it. Relovisa publishes it on its own domain: the llms.txt lists the six files, and the agent.json lists them again as its knowledge_pack, next to the sitemap, two blog feeds and a consolidated llms-full.txt. Both point to the site agent at tobira.ai/@relovisa as the primary booking and contact path.⁷⁸ A separate guest file, guest-agent.json, tells a visiting assistant how to talk to that agent and repeats the consent rule: a booking is prepared, or contact details passed on, only with the person’s explicit authorization.¹⁶ Which of these files agents actually fetch is covered in which files AI agents actually read.

The aim is that two very different visitors get the same approved facts. A person typing into the chat on relovisa.co and an assistant sent by that person both reach the same agent, and both should hear the same price and the same answer about guarantees. That holds only if every place the terms are written, the booking card included, stays in step with the pack. Large platforms are building the same arrangement: Shopify’s Fall ‘26 Edition, announced on 28 October 2026, adds a knowledge base page where merchants publish the facts agents get about their store, and agents that ask Shopify about a store “only get facts the merchant has published.”¹⁹

Published files make the facts readable: a person or a program can fetch them. A live agent that answers from them and books the next step makes the site addressable: there is someone to ask. The files alone do not get a site cited or recommended by AI assistants; their value is one approved source for the agent you run, which anyone can check. The hub piece on agent-readable vs agent-addressable covers the distinction.

How this connects to Tobira. Relovisa’s agent runs on Tobira Site Agent, an AI agent for your website that answers and sells to people and their AI agents. Its product page sets the limits this guide argues for: the agent answers only from the owner’s materials and offers a call when the answer is not there, keeps internal documents private, “not to people and not to AI agents”, and follows rules the owner writes in plain words.²⁰ Tobira’s llms.txt adds that attached knowledge can be scoped as public or owner-only.²¹ The page also starts setup with a scan of your site and lists knowledge refreshed from the site monthly on Business and weekly on Premium.²⁰ So the curation in this guide is a choice you make in setup, with our product as with any other: review what the scan produces, take out what the agent should not answer from, keep each price in one place. As listed on tobira.ai/agentic-site/ on 29 October 2026, you can start free with your own AI key, and paid plans run from $49 to $799 a month (USD, excluding taxes).²⁰

What to remember

• A chatbot knowledge base is a pack you publish, not a pile you upload. Curated, owned, dated, readable by people.
• Six jobs, six files: identity, offer and prices, recurring questions, refusals, next steps, behaviour and citation.
• One home per fact. Outdated versions do more damage than missing ones.
• Exclusion does most of the work. Leave out the blog archive, old prices, judgments you would not sign, internal documents and client data. Link to depth, answer from the pack.
• Date every file and let changes show, with a monthly read-through and a short changelog.
• One pack can serve people and their AI agents, if every other place the same terms appear stays in step with it.

Relovisa’s blog and guides are still on its site. When an assistant asks what a package costs, the instructions send it to one file: services.md.

FAQ

What should a chatbot knowledge base include?

For a site agent that answers buyers, six kinds of content, ideally one file each: a company overview with the public facts, the services and published prices, a short FAQ, a boundaries file listing what the agent never does, a file describing the next steps you want (booking, purchase, follow-up), and instructions on behaviour and citation. Each fact should live in exactly one file.

Should I let my chatbot crawl my whole website?

Usually not, if the agent’s job is to sell or qualify. A crawl puts old prices, retired offers and dated posts next to current facts, and research on retrieval-augmented generation found that an outdated passage in the context cuts answer accuracy even when the current one is there too. When Salesforce set up its Piper agent on salesforce.com, it connected approved product pages, FAQs, solution content and event information and intentionally excluded sources such as its own blog. Link to deep content when a visitor wants it; answer from a curated pack.

How often should a site agent’s knowledge base be updated?

Whenever a price, policy or offer changes, in the one file that owns that fact, followed by a quick test question. Beyond that, a monthly read of the whole pack and a quarterly check of real conversations against the boundaries file cover most businesses. Crawled sources lag: HubSpot’s customer agent, for example, re-syncs sources other than its own knowledge base articles weekly.

How long should each file in a knowledge pack be?

Short enough for its owner to read in one sitting. On relovisa.co, an immigration consultancy that shares a founder with Tobira, five of the six files ran from about 250 to 500 words on 29 October 2026, and the services file, which holds the price tables, ran to about 2,900. Scope matters more than length: one job per file, and each fact in one place.

Can visiting AI agents use the same knowledge base as human visitors?

Yes, and they should get the same approved facts. On relovisa.co, an immigration consultancy that shares a founder with Tobira, the pack is published as six public files, a person in the site chat and an assistant acting for that person reach the same agent, and a separate guest file tells assistants how to ask questions and that bookings and contact sharing need the person’s explicit consent. Any other place where the same terms are written, such as a booking card, has to be kept in step with the pack.

Sources