## Confirming access to agent knowledge and published documentation
Before you connect published content to a support agent in Atloria, make sure you are working with a project that already has documentation available in its published view. Draft pages in the document editor are not enough for this workflow. Open the project and check the documentation area that shows the customer-facing published pages, not just the editing workspace. If you only see in-progress content, review your publishing workflow first in [Publishing a Project from Setup to Public Release](doc:publishing-a-project-from-setup-to-public-release).

You also need access to the project area where support agent knowledge is managed. In Atloria, this is part of the project’s support agent setup and knowledge configuration. If you can open the project but cannot reach the support agent settings or knowledge source list, ask a Project Administrator to complete the connection step or adjust your access. For a fuller setup flow, see [Managing Support Agent Knowledge Sources and Project Linking](doc:managing-support-agent-knowledge-sources-and-project-linking).

When you review the source that will be connected, confirm it points to the published documentation for that project. The goal is to use the same pages your customers read, not unpublished drafts, internal notes, or editing-only content. This keeps support answers aligned with public guidance and reduces the chance of the agent responding with instructions that have not been released.

This workflow usually involves three roles:

- **Project Administrator**: opens the support agent settings and connects the documentation source
- **Documentation Manager**: reviews published pages and republishes updates when content changes
- **Support Team Lead**: tests sample questions and checks whether answers match the published documentation

[SCREENSHOT: Project view showing published documentation area and support agent knowledge settings]

## Preparing published pages for agent knowledge use
Published pages work best as support agent knowledge when each page is clearly written, final, and easy for the agent to match to a user question. Start by opening the published documentation for the project and reviewing the pages you want the agent to use. Focus on page titles, section headings, and the final published wording. A page with a clear title and well-structured headings is much easier for the agent to use than a long page that mixes setup steps, troubleshooting, release notes, and policy details together.

As you review the published content, look for outdated articles that are still live. If an older page contains instructions that have been replaced, update that page or remove it from the published set before you test the agent. Otherwise, the agent may answer from the older page because it is still available in the published documentation. This is especially important after product changes, renamed menu items, or revised workflows.

It also helps to break broad topics into focused pages. For example, one page for signing in, another for project setup, and another for support agent configuration will usually produce better answers than one large article covering all three. Smaller, topic-specific pages give the agent a cleaner source to draw from and make your validation easier because you can tell which page should support each answer.

Most importantly, republish your changes before testing. Editing a page in Atloria does not help the support agent if the updated version has not been published yet. The agent should be tested against the current published version, not the draft in the editor.

Useful checks before linking:

- Confirm each page has a stable, descriptive title
- Use clear section headings for major tasks
- Remove or revise outdated published pages
- Split mixed-topic pages into focused articles where needed
- Republish changes before running support agent tests

[SCREENSHOT: Published documentation page with clear title and section headings]

## Linking the project documentation to support agents
1. Open the project in Atloria and go to the support agent configuration area for that project. If you have already linked other knowledge sources, look for the section that lists the current knowledge sources attached to the agent.

2. Find the knowledge source settings where documentation can be added. In this area, choose the project documentation source that represents the published documentation you want the agent to use. Be careful to select the published documentation location for the project, not an internal editing view or any source meant only for internal teams.

3. Select the documentation source and confirm the project or documentation label matches the content you reviewed earlier. This is your chance to verify that the source belongs to the correct project and reflects the customer-facing documentation set you intend to use for support answers.

4. Save the knowledge settings. After saving, Atloria should show the connected documentation source in the support agent’s knowledge list. Check the label carefully so you can confirm the right project documentation has been attached.

5. Review the saved knowledge list one more time. If the support agent uses multiple sources, make sure the published documentation appears alongside any other approved sources and is not confused with older or unrelated documentation.

A successful connection should leave you with a visible entry in the knowledge source list that clearly identifies the project documentation now available to the support agent. If the source label is unclear, return to the project documentation and verify you selected the correct published content set before moving on to testing.

If you need the broader setup process for adding or organizing knowledge sources, use [Managing Support Agent Knowledge Sources and Project Linking](doc:managing-support-agent-knowledge-sources-and-project-linking).

[SCREENSHOT: Support agent knowledge source list showing connected project documentation]

## Controlling which published content agents can answer from
Connecting only published documentation gives you a useful boundary: the support agent answers from customer-facing guidance instead of unpublished notes or internal working material. In Atloria, that boundary matters because support answers should reflect what customers are expected to see and follow. If the agent is limited to published pages, it is less likely to introduce internal-only wording, unfinished instructions, or steps that have not been approved for release.

Scope also affects answer quality. A broad connection that includes all published project documentation may work well when your published site is tightly organized and consistently maintained. If your published content includes many unrelated topics, however, broad scope can make answers less precise. In that case, a narrower documentation set is often better. The more focused the connected content is, the easier it is for the support agent to stay on-topic.

Some published pages should not drive support responses even if they are technically live. Review the connected content and consider excluding pages such as:

- Release notes that describe older behavior
- Temporary announcements
- Internal process pages that were published for limited audiences
- Broad update pages that mention many topics without clear task steps

Ownership should stay clear after the initial setup. Documentation teams are responsible for keeping the published pages accurate, current, and well structured. Support leads should regularly test whether the connected knowledge still reflects real support scenarios. When a page is updated, removed, or replaced, the connected knowledge set may need review as well.

If your team also manages audience-specific published content, make sure the pages included in the support agent’s knowledge match the audience you expect the agent to serve. Related guidance is available in [Publishing Documentation for Specific Audiences](doc:publishing-documentation-for-specific-audiences) and [Reviewing Audience Specific Pages in Public Documentation](doc:reviewing-audience-specific-pages-in-public-documentation).

## Testing agent responses against the intended documentation source
1. Open the support agent chat experience in Atloria and prepare a short list of questions tied to specific published pages. Choose questions where you already know which page should provide the answer. This makes it much easier to tell whether the agent is using the intended documentation source.

2. Ask direct questions based on published task pages. For example, if you have a published page about signing in, ask the support agent how to sign in or what to do after an invalid password message. Then open the matching published page and compare the response to the page title, headings, wording, and step order.

3. Check whether the response stays inside the published guidance. The answer should use the same terminology and should not introduce extra steps that do not appear on the published page. Small wording differences are normal, but the substance should match the customer-facing instructions.

4. Repeat the process with a few edge-case questions. Ask about topics that are only partially covered or not covered at all in the published documentation. In those cases, the support agent should respond cautiously or give a limited answer rather than inventing unsupported instructions.

5. Test across several page types, such as setup pages, troubleshooting pages, and policy-style pages. This helps you see whether the connected documentation set is balanced or whether some content areas are overpowering others.

A simple validation table can help during testing:

| Test question | Expected published page | What to check |
|---|---|---|
| Sign-in question | Sign-in page | Terminology and steps match the page |
| Setup question | Setup page | Answer uses the correct published workflow |
| Unsupported question | No matching page | Agent stays limited and does not invent details |

[SCREENSHOT: Support agent chat beside a published documentation page for answer comparison]

## Fixing mismatched answers and stale documentation results
When a support agent gives the wrong answer, start with the published page itself. If the answer reflects old instructions, open the page you expected the agent to use and confirm the corrected content is actually published. Updating a draft in the editor is not enough. The support agent should be connected to the published documentation, so the fix must be visible in the published view before you test again.

If the answer points to the wrong topic, the connected documentation may be too broad or the page structure may be too vague. Large pages with mixed subjects often cause this problem. Split those pages into smaller articles with clear titles and headings so each support question maps to one obvious source. If needed, narrow the connected documentation set so the support agent is not searching across unrelated published content.

When the support agent cannot answer a question that is already documented, verify three things:

- The page is publicly published in the project’s documentation
- The page is part of the connected knowledge source
- The page title and headings clearly describe the topic users are asking about

Another common issue is mixed public and internal guidance. If the support agent responds with language that sounds like internal process notes rather than customer instructions, review the knowledge source list and remove any source that is not meant for customer-facing support. The connected sources should be limited to approved published documentation for this workflow.

After each change, rerun the same test questions you used before. That gives you a clean before-and-after comparison and helps confirm whether the issue came from page content, source selection, or documentation scope. If the problem continues, revisit the broader source setup in [Managing Support Agent Knowledge Sources and Project Linking](doc:managing-support-agent-knowledge-sources-and-project-linking).

## Overview
Using published documentation as support agent knowledge in Atloria is the best fit when you want the agent to answer from the same guidance customers already see. Instead of relying on draft content or internal working notes, you connect the support agent to the project’s published documentation and then validate that its answers stay aligned with those live pages. This approach is especially useful for customer support teams that need consistency between self-service documentation and agent-assisted answers.

The workflow has four main parts:

- Confirm the project has published documentation available
- Prepare the published pages so they are current, focused, and clearly structured
- Connect that published documentation in the support agent’s knowledge settings
- Test real questions to confirm the answers match the intended source

This document focuses specifically on published documentation as a knowledge source. If you still need to set up the support agent workspace, organize knowledge sources, or link a project at a broader level, use [Managing Support Agent Knowledge Sources and Project Linking](doc:managing-support-agent-knowledge-sources-and-project-linking).

In practice, the quality of support answers depends heavily on the quality of the published pages. Clear page titles, strong headings, and current published content make it easier for the support agent to return accurate, customer-facing responses. Poorly organized or outdated published pages usually lead to vague, stale, or mismatched answers.

You should use this workflow when the support agent is expected to mirror your public documentation experience. If your goal is to answer only from internal team knowledge, this document is not the right setup path. For teams using public docs as the source of truth, though, this is the cleanest way to keep support responses aligned with what readers can already find in Atloria’s published documentation.

## Prerequisites
Before you start, make sure these items are already in place in Atloria:

- A project with documentation that has been published, not just saved in the editor
- Access to the project’s support agent settings and knowledge source configuration
- A support agent already created for the project, or an existing agent you can edit
- Published pages that are intended for customer-facing support use
- Permission to review and update published documentation if changes are needed

It also helps to have the right people involved before testing begins:

| Role | What they handle |
|---|---|
| Project Administrator | Connects the published documentation in the support agent settings |
| Documentation Manager | Reviews page titles, headings, and published accuracy |
| Support Team Lead | Tests questions and checks whether answers match published guidance |

Before linking the source, confirm these content conditions:

- The pages you want the agent to use are visible in the published documentation view
- Outdated or superseded pages have been updated, removed, or clearly separated
- Important support topics are not buried inside long mixed-topic articles
- Recent edits have been republished so the published view reflects the latest approved content

If you need help getting into Atloria, creating an account, or signing in before reaching the project workspace, see [Accessing and Registering Your Atloria Account](doc:accessing-and-registering-your-atloria-account), [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems), and [Understanding Project Navigation and Linked Workspaces](doc:understanding-project-navigation-and-linked-workspaces).

From here, the next useful step is usually [Configuring Support Agent Behavior and Availability](doc:configuring-support-agent-behavior-and-availability) so the agent not only uses the right knowledge, but also behaves the way your support team expects.