A website AI agent knowledge base should contain the current public information needed to answer a defined set of visitor questions. Give every source an owner and scope, keep internal material out unless the workflow explicitly needs it, and test what happens when the site cannot support an answer.
Fictional example: Blue Quay Solar asks its website agent to answer whether it installs battery storage in Northport, what a visitor should prepare for an assessment, and how to request an appointment. The approved sources are the public service-area page, the battery installation page, and the assessment checklist. The agent can explain these details and link to the request form; it cannot promise an installation date or quote for a particular property.
The example shows why public source content and a clear visitor task belong together.
Start with visitor questions and decisions
Review actual inquiry categories, support notes, and website search terms that your team is authorized to use. Use them to choose a small set of questions for the agent to answer, such as service coverage, preparation, public pricing, eligibility, or next steps. For each category, identify what the visitor needs to know and whether the answer is fully public. Avoid starting with a document dump and expecting the agent to discover which questions it should answer.
For Blue Quay, the fictional service-area page lists Northport for home battery installation, the installation page confirms that the company offers the service, and the assessment checklist asks visitors to have their inverter model and typical evening electricity use ready. The request form accepts an inquiry; it does not confirm a date or price. A draft answer based on those sources could read:
“Blue Quay’s site lists home battery installation in Northport. For an assessment, have your inverter model and typical evening electricity use ready. You can use the request form to ask about next steps; the team will confirm property-specific details and availability.”
An appointment request remains a request until the team checks capacity and confirms it.
Build a small, maintainable source set
Prefer clear, current pages that the organization already approves for public use. Assign an owner to each one and record its audience, location or service scope, effective date, review trigger, and next step. Make headings say what a section covers. Keep separate services or regions distinct when their rules differ. Remove obsolete duplicate pages from the agent’s search scope or label them so a retrieval system can tell them apart.
Do not add private operating notes just because they could help answer more questions. Internal staffing schedules, account records, unpublished prices, and technician notes may have a different audience and access rule. If an answer needs one of those sources, define that job and access path separately; a public-site conversation should not silently inherit internal permissions.
Set rules for gaps and conflicts
Decide which source controls if a service page and a location page disagree. Define how the agent reports a missing or stale answer, when it asks one clarifying question, and when it offers a person’s help. It should not infer a service from a neighboring region or combine unrelated pages into an unsupported promise.
Use separate test cases for missing and conflicting information:
- Missing: If the location page says nothing about Northport, no approved page establishes coverage. The agent should say that the site does not confirm service there and offer the request form or a team check; it should neither promise service nor interpret silence as a denial.
- Conflicting: If the service page lists Northport but the location page excludes it, the agent should identify both pages and pause the coverage answer. Unless an approved source rule resolves the conflict, send the two details to the source owner to reconcile them; do not choose one page or promise service while the conflict remains.
Test the content before relying on it
Create a question set from the scope. Include direct questions, paraphrases, misspellings, ambiguous places, unsupported services, a page with an expired review date, and a conflict between sources. For each question, note the expected answer, approved source, and safe fallback. Check both whether the right passage is retrieved and whether the answer stays within it. Retrieval quality and answer quality are related but separate checks.
Ask a source owner to confirm the test answers. Repeat affected questions after page updates, changes to service scope, or a retrieval configuration change. Keep a route for visitors who need a commitment the public pages cannot make.
See how to ground an agent in approved context for source ownership and conflict handling. Continue with website agent design and permissions and boundaries before connecting additional sources.