## Understanding How Support Agents Appear in Documentation
In Atloria, reader-facing support agents are presented as part of the documentation experience rather than as a separate workspace. Readers typically encounter the agent in one of three visible forms: a collapsed help launcher, an open chat panel, or an embedded conversation area attached to the documentation page. The collapsed state gives readers a lightweight entry point so they can continue reading without interruption. When they open it, the panel becomes the main place for asking questions, reviewing answers, and following documentation links.

The support agent experience should stay tied to the page the reader is already viewing. In practice, that means the conversation should reflect the current article, section, and documentation context instead of answering in a broad or disconnected way. If a reader opens the agent from a specific help article, the answers should stay grounded in that topic and point back to related documentation pages when possible. This is especially important in versioned documentation, where readers expect guidance that matches the version they are currently reading.

Readers may also see several status changes while using the chat experience:

- **Collapsed launcher** when the chat is available but not open
- **Open conversation panel** after the reader starts or resumes a chat
- **Loading state** while Atloria prepares a response
- **Escalation or handoff state** when the answer should move to a support route instead of chat
- **Unavailable state** when the support agent is not offered on that documentation surface

From the reader’s point of view, the most important actions are simple and direct:

- Type a question in free text
- Choose a suggested prompt or starter question
- Open linked articles from the response
- Continue the conversation with follow-up questions

[SCREENSHOT: Documentation page with collapsed help launcher and open support chat panel]

## Preparing the Documentation Experience for Reader-Facing Support
Before you make a support agent visible in Atloria documentation, decide exactly where readers should see it. This is a content and operations decision, not just a placement choice. Some teams want the agent available on article pages only, while others also expose it on landing pages or section home pages where readers are still deciding where to go next. You should also separate public documentation from authenticated documentation so the support experience matches what readers are actually allowed to access.

Use this checklist to prepare the experience:

1. **List the documentation surfaces where the agent will appear.** Include article pages, landing pages, and any authenticated documentation areas.
2. **Decide whether public readers and signed-in readers should see the same support experience.** If the content differs by audience, the chat experience should follow that same boundary.
3. **Confirm which knowledge sources are approved for reader-facing answers.** Limit the agent to published documentation, version-specific pages, and any support-approved knowledge collections already used by your team.
4. **Exclude draft or internal-only material.** If a page is not ready for readers, it should not shape the support answers they receive.
5. **Assign ownership.** The Documentation Manager should review article quality and freshness, while the Support Team Lead should review escalation coverage, answer tone, and reader impact.
6. **Define off-limits topics.** In a documentation context, the agent should not handle account-specific changes, billing updates, or requests that require a verified support workflow.

If you already set up the agent’s workspace and knowledge sources, use that work as your starting point rather than repeating it here. For setup details, refer to [Managing Support Agent Workspaces and Knowledge Setup](doc:managing-support-agent-workspaces-and-knowledge-setup). If you still need to refine tone, behavior, or availability rules, review [Configuring Support Agent Behavior and Availability](doc:configuring-support-agent-behavior-and-availability).

[SCREENSHOT: Documentation planning view showing public docs, authenticated docs, and approved knowledge sources]

## Configuring Reader Interactions and Escalation Paths
Once you know where the support agent will appear, shape the conversation so it feels relevant to the documentation section the reader is viewing. The first message matters: it should help the reader understand what kinds of questions they can ask and what will happen if the agent cannot answer directly. In Atloria, this usually means tailoring the welcome message, conversation starter text, and suggested questions to the current documentation area rather than using one generic message everywhere.

Follow these steps to configure the reader experience:

1. **Set the welcome message** so it matches the current documentation area. On a setup guide, the opening text should invite setup questions. On a troubleshooting page, it should encourage problem-focused questions.
2. **Add suggested questions** that reflect common reader needs. Good examples are task-based prompts that help readers start quickly and stay inside the published documentation flow.
3. **Review direct-answer rules.** The support agent should answer when the documentation clearly covers the topic and the response can point to the right article.
4. **Define escalation triggers.** Use escalation when the answer is uncertain, when the documentation does not fully cover the request, or when the reader clearly needs human review.
5. **Choose the escalation destination** shown in the chat. This may be a support form, a ticket submission step, or another reader-facing support option already used in your documentation workflow.
6. **Check how documentation links appear in answers.** Readers should be able to move from the chat response back into the relevant article without guessing which page to open.
7. **Review citations and recommended articles** to make sure they support the answer instead of distracting from it.

A strong embedded support experience does not try to solve every problem inside the panel. It should answer what the documentation supports, then guide the reader to the next best action when chat is not the right path.

[SCREENSHOT: Embedded support chat showing welcome message, suggested questions, and escalation option]

## Operating the Agent in a Live Documentation Environment
After launch, the support agent becomes part of your day-to-day documentation operations. The most useful signals come from the questions readers ask repeatedly from specific pages. If the same question appears on a setup article, release note, or troubleshooting page, that usually points to a documentation gap. In Atloria, use these conversation patterns to decide whether the article needs clearer steps, better headings, stronger cross-links, or updated version guidance.

Use this operating routine to keep the experience healthy:

1. **Review common questions by documentation area.** Focus on pages that trigger repeated support requests or long follow-up threads.
2. **Check answer quality regularly.** Look for responses that are accurate, easy to follow, and clearly tied to the article the reader opened.
3. **Verify citation usefulness.** A linked article should actually help the reader complete the task, not just mention the same topic.
4. **Flag unanswered or weakly answered topics.** These are strong candidates for new articles, article revisions, or improved support prompts.
5. **Coordinate updates between documentation and support owners.** When your team publishes new content, retires old workflows, or changes version coverage, the reader-facing support experience should reflect that change quickly.
6. **Watch escalation patterns.** A high escalation rate from one article often means the page is missing key instructions or the support boundary is too strict.
7. **Track repeated follow-up questions.** If readers keep asking for clarification after the first answer, the article may be technically correct but hard to use.

Operational review is most effective when you compare chat behavior with the actual reading experience. Open the same article, ask the same question a reader would ask, and confirm that the response truly helps someone move forward.

[SCREENSHOT: Support operations review showing common reader questions and linked documentation pages]

## Setting Reader Expectations and Safety Boundaries
Readers should understand from the start that they are interacting with an automated support experience inside Atloria documentation. The disclosure text near the launcher or at the top of the chat panel should make that clear in plain language. It should also set expectations about what the support agent can and cannot do. This is especially important in documentation, where readers may assume the chat can inspect their account, change settings, or confirm environment-specific details even when it cannot.

Use these boundaries when defining the reader-facing experience:

- The support agent may provide:
  - Product guidance based on published documentation
  - Troubleshooting steps already documented for readers
  - Links to canonical documentation articles
  - Suggested next reading when the current page is not enough

- The support agent should not provide:
  - Account-specific changes or access decisions
  - Billing changes or subscription actions
  - Legal advice or policy interpretation
  - Guidance for unsupported product versions
  - Confirmation of tenant-specific settings it cannot verify

The chat experience should also redirect or refuse requests in clearly defined cases. If a reader asks for help involving personal data, account ownership, permissions, or actions that require identity verification, the response should move them to the approved support route instead of continuing in chat. The same applies when a reader asks the support agent to perform an action on their behalf.

When the agent reaches a boundary, the wording should stay useful. Instead of stopping abruptly, it should explain the limitation and point the reader to the correct next step, such as a support form or documentation article that explains the supported process.

[SCREENSHOT: Chat header with automated support disclosure and response showing safe redirection]

## Validating the Experience Before Making It Available
Before you release the support agent in Atloria documentation, test it in the same places and conditions your readers will use. Validation should cover both the visible chat experience and the quality of the answers. Do not limit testing to one article type. A support agent that works well on a general overview page may behave differently on a version-specific article, a troubleshooting guide, or a public landing page.

Run this validation process before launch:

1. **Open representative documentation pages** across your planned surfaces, including article pages, landing pages, and any authenticated documentation areas.
2. **Confirm the launcher appears correctly** and that the chat panel opens without covering essential page content in a confusing way.
3. **Ask page-specific questions** to verify that responses stay tied to the current documentation topic.
4. **Test high-risk prompts** such as unsupported requests, account-specific questions, and topics that should trigger escalation.
5. **Check documentation links in responses.** Open each linked article and confirm it resolves the reader’s task or at least moves them meaningfully forward.
6. **Verify public and authenticated behavior separately.** Make sure the support experience does not point public readers to content they cannot access.
7. **Review escalation paths.** Confirm that each escalation option works and that the reader does not lose the documentation context that led them there.
8. **Capture failure cases** such as empty answers, irrelevant citations, repeated fallback wording, or unavailable support channels.

A short validation table can help your team review results consistently:

| Test area | What to confirm | What to flag |
|---|---|---|
| Launcher and panel | Opens correctly on target pages | Missing launcher, broken panel, blocked page content |
| Answer relevance | Response matches current article topic | Generic answer, wrong topic, weak context |
| Links and citations | Linked article supports the answer | Broken link, irrelevant article, access issue |
| Escalation | Correct route appears when needed | Missing handoff, wrong destination, lost context |

[SCREENSHOT: Pre-launch test session on multiple documentation page types]

## Overview
This document focuses on the reader-facing side of support agents in Atloria documentation. The goal is not to explain how to create a support agent from scratch, but how to place it into documentation experiences where readers can use it while browsing articles, landing pages, and other help content. In this context, the support agent becomes part of the documentation journey: readers open a launcher, ask a question, review an answer, and move back into the article flow through linked pages and recommended content.

The most important decisions in this stage are operational. You need to decide where the agent appears, what published content it can rely on, which questions it should answer directly, and when it should hand the reader off to another support path. You also need to define the visible boundaries of the experience so readers understand they are using an automated assistant and not a human support channel. That includes disclosure text, refusal rules, escalation routes, and answer quality review.

This guide also treats validation as part of setup. Before making the support agent available, test how it behaves on real documentation pages and with realistic reader questions. Confirm that the launcher and panel work correctly, that answers stay tied to the current article, and that links and citations lead readers to useful documentation rather than dead ends or unrelated pages.

If you need help with the earlier setup work behind the reader experience, refer back to [Creating and Managing AI Support Agents](doc:creating-and-managing-ai-support-agents), [Managing Support Agent Workspaces and Knowledge Setup](doc:managing-support-agent-workspaces-and-knowledge-setup), and [Configuring Support Agent Behavior and Availability](doc:configuring-support-agent-behavior-and-availability).

## Prerequisites
Before working through this document, make sure these pieces are already in place in Atloria:

- A support agent has already been created for your documentation use case
- The agent’s knowledge sources have already been reviewed and connected to the correct documentation content
- Behavior and availability settings have already been defined for the audiences and documentation surfaces you plan to support
- You know which documentation areas are public and which are only available to signed-in readers
- Your team has agreed on the approved escalation route for questions the support agent should not answer directly
- A Documentation Manager and Support Team Lead are both available to review the reader-facing experience before launch
- You have access to the documentation pages where the support agent will appear so you can test the launcher, chat panel, and linked articles
- You have representative reader questions ready for testing, including normal help requests, unclear questions, and out-of-scope requests

It is also helpful to prepare a small review set before testing:

- A general article page
- A task-based article with step-by-step instructions
- A troubleshooting article
- A version-specific documentation page
- One page in any authenticated documentation area you plan to support

If those earlier setup tasks are not complete, start with [Managing Support Agent Workspaces and Knowledge Setup](doc:managing-support-agent-workspaces-and-knowledge-setup) and [Configuring Support Agent Behavior and Availability](doc:configuring-support-agent-behavior-and-availability). After you finish the reader-facing work in this guide, continue with [Managing Support Agent Setup and Availability](doc:managing-support-agent-setup-and-availability).