Configuring Support Agent Behavior and Embedded Experiences

Understanding Which Settings Control the Support Agent Experience

In Atloria, support agent setup usually spans more than one place, so it helps to separate how the agent answers from where readers see it. Start from the support agent area you already used in Managing Support Agent Setup and Availability, then open the settings tied to the documentation experience where the agent will appear. You are looking for groups of settings related to the agent’s behavior, its visible presentation, and its availability in published or in-project documentation views.

A practical way to review these settings is to think in two layers:

• Workspace-level settings

  • Control the support agent itself
  • Usually include the agent’s instructions, response scope, and supported topics
  • Affect how the agent behaves wherever that agent is used

• Documentation experience settings

  • Control how the agent appears to readers
  • Usually include placement, launcher visibility, welcome text, and page-level display choices
  • Affect the reader-facing experience in a specific documentation area

Before changing anything, confirm whether you are editing the shared support agent or the documentation experience that displays it. If you change the shared agent instructions, readers may notice different answers everywhere that agent is active. If you change the embedded experience settings, the answers may stay the same while the launcher, panel, or welcome message changes only in that documentation view.

Teams often split responsibility across roles:

Adjusting How the Support Agent Responds to Readers

To change how the support agent answers questions, open the agent’s behavior settings and look for the instruction fields that define tone, scope, and expected response style. This is where you shape the reader experience most directly. In Atloria, these settings are best used to keep the agent focused on documentation help rather than broad or open-ended support.

1. Open the support agent you want to update.
2. Go to the behavior or instruction section.
3. Edit the text that tells the agent how to respond to readers.
4. Save your changes.
5. Preview the agent in a documentation view and test a few questions.

When you update the instruction text, keep it tied to what readers should actually get from the documentation experience. For example, you may want the agent to:

• answer using project documentation first
• stay within approved support topics
• avoid guessing when the documentation does not cover a question
• direct readers to human support when the answer is unclear

You should also review any settings related to unsupported questions. If Atloria shows fields or options for fallback behavior, use them to define what the reader sees when the agent cannot answer confidently. That message should match the documentation experience and clearly redirect the reader instead of leaving the conversation open-ended.

Common behavior areas to review include:

• Tone and style: formal, concise, instructional, or friendly
• Topic boundaries: what the agent should and should not answer
• Fallback messaging: what appears when no reliable answer is available
• Handoff behavior: whether the agent should point readers to another support path

After saving, check whether the documentation experience reflects the change immediately or only after the documentation is republished. If the updated behavior does not appear in the embedded experience, test again after publishing the latest documentation changes.

Customizing the Embedded Agent's Presentation

Once the support agent is answering correctly, move to the reader-facing presentation settings. In Atloria, this is where you control what readers see on the page: the agent name, welcome message, launcher text, and the way the support panel appears inside documentation.

1. Open the documentation experience or site settings where the support agent is embedded.
2. Find the section for support agent display or embedded support settings.
3. Update the visible labels and branding elements.
4. Choose the placement style for the agent.
5. Save and preview the documentation page.

The most important presentation settings are the ones readers notice first:

• Agent name: the label shown in the support panel
• Welcome message: the opening text readers see before asking a question
• Launcher label: the text on the button or chat opener
• Branding elements: any visible avatar, icon, or theme-related styling

Placement matters just as much as wording. Depending on the documentation experience, the support agent may appear as:

• a floating launcher that follows the reader across pages
• an inline embed placed within page content
• a page-level support panel that stays in a fixed area of the layout

You should also review how the agent opens. Some experiences work best when the panel starts minimized so it does not interrupt reading. Others benefit from an open state on support-heavy pages where readers are expected to ask questions right away. If Atloria lets you choose whether the launcher appears on all pages or only in selected sections, match that choice to the purpose of the content.

Keep the support agent visually consistent with the rest of the documentation. If your documentation uses a specific theme or branded reader experience, confirm that the support panel feels like part of the same site rather than a separate tool.

Controlling When and Where Readers Can Access the Agent

Availability settings decide whether readers can actually use the support agent in the places you expect. In Atloria, these settings are especially important when your documentation includes different spaces, audience-specific content, or staged publishing workflows.

1. Open the documentation experience settings for the site or project area you want to control.
2. Find the availability or visibility section for the support agent.
3. Choose where the agent should appear.
4. Apply any audience or access restrictions.
5. Save the settings and test the affected pages.

Start by deciding the scope of availability. You may enable the support agent for:

• the full documentation site
• selected spaces or sections
• specific article collections only

Then review who should see it. If Atloria offers audience or access-based controls, use them to limit the support experience to the right readers, such as:

• signed-in users
• customers
• internal team members
• other permitted reader groups already defined in your documentation setup

Page-level visibility is useful when some content should stay distraction-free or should not invite support questions. For example, you may want to hide the agent on:

• landing pages
• release notes
• sensitive internal sections
• pages meant only for announcements or navigation

Availability also needs to match your publishing workflow. If you are preparing changes in a staged documentation version, confirm whether the support agent settings apply only to the draft experience or to the currently published one as well. A saved setting may not be visible to readers until the related documentation changes are published.

If your team uses separate environments for testing and live documentation, verify that you are editing the correct one before rollout. This prevents readers in the live documentation from seeing unfinished support behavior or incomplete placement changes.

Managing Reader Interaction Settings

Reader interaction settings shape how people actually use the support agent once it appears on the page. In Atloria, these choices affect whether the experience feels guided and helpful or too open-ended for the documentation you are publishing.

1. Open the embedded support settings for the documentation experience.
2. Review the conversation options available to readers.
3. Add or adjust prompts that guide the first question.
4. Check any escalation or contact options shown in the support panel.
5. Save the changes and test the conversation flow across multiple pages.

A good starting point is the first interaction. If Atloria provides suggested questions or conversation starters, use them to steer readers toward supported topics. These prompts work best when they match the actual documentation, such as setup steps, feature usage, or troubleshooting topics already covered in the project.

Helpful interaction settings often include:

• Starting a new conversation directly from the current documentation page
• Suggested questions that help readers ask about supported topics
• Prompt text that explains what the support agent can help with
• Escalation options that direct readers to another support path when needed

You should also review any visible contact or handoff options. If the support panel includes links or actions that send readers to human support, make sure those options appear only when they fit the documentation experience. For example, a customer-facing help center may benefit from a clear support path, while an internal draft documentation space may not need that option shown at all.

Finally, check how the conversation behaves as readers move through the documentation. If Atloria keeps the session visible across pages, readers can continue the same thread while browsing. If the conversation resets more often, the experience may feel cleaner but less continuous. Choose the setting that fits your documentation structure and the kind of help readers usually need.

Testing the Configuration in Your Documentation Experience

After updating behavior, presentation, and availability, test the support agent from the reader’s point of view. In Atloria, this step is where you confirm that the embedded experience matches the settings you saved and that the agent behaves correctly on real documentation pages.

1. Open the documentation experience where the support agent should appear.
2. Check the launcher, panel placement, agent name, and welcome message.
3. Ask several sample questions based on the documentation.
4. Visit pages where the agent should appear and pages where it should stay hidden.
5. Publish or refresh the documentation experience if the changes are not visible.

Start with the visual checks. Confirm that the launcher label, welcome text, and placement match the settings you selected. If the support agent should appear as a floating launcher, make sure it is visible in the expected corner or page area. If it should be inline or page-level, verify that it appears in the correct section of the layout.

Next, test behavior with realistic reader questions. Ask about topics clearly covered in the documentation and then try a question outside the approved scope. The agent should stay within the boundaries you set, use the expected tone, and show the fallback response when it cannot answer.

Then test visibility rules:

• open pages where the agent should be available
• open pages where it should be hidden
• switch between reader types or audience views if your team uses them
• compare draft and published views when rollout is staged

If changes do not appear, check these items:

• the settings were saved successfully
• the documentation experience was published if required
• you tested the correct environment
• an older cached page is not still showing the previous embedded setup

Overview

• This guide focuses on the reader-facing side of support agents in Atloria: how the agent answers, how it looks, where it appears, and how readers interact with it inside documentation.
• Use this document after the setup work covered in Managing Support Agent Setup and Availability. That earlier guide covers the broader setup path; this one focuses on fine-tuning the embedded experience.
• The main settings to review are:
  • Behavior settings for tone, scope, fallback responses, and handoff rules
  • Presentation settings for the agent name, welcome text, launcher label, and placement
  • Availability settings for site, section, page, and audience visibility
  • Interaction settings for suggested prompts, conversation flow, and escalation options
• In most teams, different people own different parts of this work:
  • Support Team Leads refine how the agent responds
  • Documentation Managers shape the embedded experience readers see
  • Project Administrators control rollout, visibility, and access conditions
• Test every change in the actual documentation experience before considering the update complete. A saved setting does not always mean readers can already see it in the published view.

Prerequisites

• You should already have a support agent created and connected to the correct documentation source. If not, start with Creating and Managing AI Support Agents and Managing Support Agent Workspaces and Knowledge Setup.
• You should already understand the basic setup and availability workflow covered in Managing Support Agent Setup and Availability.
• Make sure you can access:
  • the support agent settings
  • the documentation experience or site settings where the agent is embedded
  • the relevant project or published documentation view for testing
• Before editing behavior settings, prepare the decisions your team has already made about:
  • approved support topics
  • tone of voice
  • fallback messaging
  • when readers should be directed to human support
• Before editing presentation or visibility settings, confirm:
  • which documentation sections should show the agent
  • which audiences should see it
  • whether your team is updating a draft experience or a published one

If you are continuing the support agent documentation set, the next useful companion guide is Chatting with Support Agents and Managing Conversations.