## Reviewing the settings that shape agent replies
In Atloria, start from the support agent area for the project or workspace where the agent is already set up. If you still need to connect the agent to the right workspace or knowledge sources, use [Managing Support Agent Workspaces and Knowledge Setup](doc:managing-support-agent-workspaces-and-knowledge-setup) before changing reply behavior.

Open the agent’s settings and look for the behavior options that control how the agent answers. These settings are the ones to review before you change anything customer-facing, because they affect the style and confidence of every reply the agent gives in the places where it is enabled.

Focus on these kinds of behavior choices when you review the current setup:

- Whether replies should be brief and direct or more detailed and explanatory
- Whether the agent should stay tightly grounded in your documentation
- Whether the agent should answer broadly or defer when the available documentation is limited
- Whether the reply style matches your support team’s tone

Before you make changes, compare the current settings as a group instead of adjusting one option in isolation. A concise reply style can work well when your documentation is strong and easy to search, but it can feel abrupt if customers usually need step-by-step help. A more detailed style can be useful for onboarding or troubleshooting, but only if the linked documentation is complete enough to support those answers.

[SCREENSHOT: Support agent settings screen showing behavior options for reply style, answer scope, and documentation-backed responses]

As you review the screen, check whether the current behavior matches the support experience you want customers to have. If the team expects the agent to answer only from published guidance, keep the documentation-focused settings tighter. If the team wants more conversational help in mature documentation areas, you can allow a broader answer style, but only after confirming the content is accurate and current.

## Setting where agents are available to customers
After reviewing reply behavior, decide exactly where the support agent should appear. In Atloria, availability should be limited to the support surfaces where the agent has the right documentation and the right audience. This prevents customers from seeing the agent in places where it cannot help confidently.

1. Open the support agent settings for the agent you want to update.
2. Find the availability or placement section that controls where the agent is shown.
3. Select the support surfaces where the agent should be active, such as documentation-assisted entry points, support-facing areas, or other enabled customer help locations in Atloria.
4. Review any workspace, project, or team assignment options and make sure the agent is only attached to the intended areas.
5. Check any routing or visibility choices that affect whether customers go directly to the agent, directly to a human team, or through a mixed handoff flow.
6. Click **Save** and return to the relevant support areas to confirm the agent appears only where you selected.

Use narrow availability when you are testing a new agent or when the documentation only covers one product area. Use broader availability only when the support content is mature across all assigned projects or teams.

A few checks help prevent accidental overexposure:

- Confirm the correct workspace is selected before saving
- Review project assignments if multiple documentation sets exist
- Check team-level visibility if different support groups handle different topics
- Reopen the settings after saving to verify the selected locations stayed in place

[SCREENSHOT: Availability settings showing selected support surfaces and project or workspace assignments]

If customers should still be able to reach a person quickly, review the handoff choices carefully. The best setup is usually one where the agent appears in the right places, answers within documented scope, and leaves a clear path to human support when needed.

## Aligning agent behavior with your documentation
The most important rule when configuring a support agent in Atloria is simple: the agent should only be as confident as your documentation allows. If your help content is detailed, current, and well organized, the agent can usually answer more directly. If your content is incomplete, outdated, or still being reorganized, the agent should be more cautious.

Start by comparing the agent’s behavior settings with the actual state of the documentation it uses. Ask whether the linked content covers the topics customers are most likely to ask about. If the answer is no, tighten the behavior settings so the agent stays closer to documented guidance and defers more often when the answer is unclear.

This alignment matters most in these situations:

- **Strong documentation coverage:** You can allow more complete and confident answers because the agent has reliable material to work from.
- **Partial documentation coverage:** Keep replies narrower and encourage deferral when the answer is not clearly supported.
- **Outdated documentation:** Reduce answer scope until the content is reviewed and updated.
- **New product areas:** Limit the agent to basic, documented questions until the knowledge base matures.

A practical review process works better than one-time setup. After a major documentation update, support leads and project administrators should revisit the agent settings and ask:

- Did new pages expand the topics the agent can safely answer?
- Were any old pages removed or replaced?
- Do current replies still match the published guidance?
- Should the agent be more detailed, or more cautious, than before?

[SCREENSHOT: Agent settings beside project documentation pages used to review answer scope]

If the documentation changes significantly, treat behavior settings as part of the release work. Review them after major edits, version updates, or audience changes. That keeps the support experience aligned with what customers can actually read in Atloria, instead of letting the agent drift beyond the documented truth.

## Configuring team-level rules for support goals
Different support teams often need different agent behavior. In Atloria, the settings for a support agent should reflect the kind of conversations that team handles. A team focused on onboarding may want more guided, explanatory replies. A team handling sensitive account or billing questions may want faster escalation and less agent-led interpretation. A technical support team may need the agent to stay tightly tied to documentation and defer quickly when the answer is uncertain.

1. Open the support agent settings for the team, workspace, or assigned support area you want to review.
2. Identify the behavior choices that affect reply style, answer scope, and fallback handling.
3. Match those settings to the team’s support goal. For example, use more guided replies for onboarding and stricter documentation-backed replies for technical troubleshooting.
4. Review the escalation or fallback options and decide when the agent should stop answering and hand the conversation to a person.
5. Apply the same standards across similar projects or queues so customers get a consistent experience.
6. Save the changes and document who approved them if the update affects live customer support.

A simple way to keep teams aligned is to define shared rules such as:

| Support area | Preferred behavior | Fallback approach |
|---|---|---|
| Onboarding | More detailed, guided answers | Hand off when questions go beyond setup guidance |
| Technical support | Documentation-first answers | Defer when the answer is not clearly documented |
| Billing or account help | Narrower, cautious answers | Route to a human team quickly |

[SCREENSHOT: Team-specific support agent settings showing behavior and fallback choices]

It is also important to decide who can change these settings. In many teams, project administrators review documentation fit, while support leads approve customer-facing behavior changes. Keeping that approval path clear helps prevent one team from changing reply style or escalation behavior in ways that affect customers unexpectedly.

## Testing how agents respond after configuration changes
After you change behavior or availability settings, test the agent before leaving the new configuration in place for customers. In Atloria, testing should happen in every support surface where the agent is enabled, not just in one location. An agent can appear correctly in one area and still be misconfigured in another if assignments or routing were set too broadly.

1. Open each support surface where the agent is supposed to appear.
2. Confirm the agent is visible only in those selected locations and does not appear in unrelated projects, workspaces, or support areas.
3. Start a few test conversations using common customer questions.
4. Check whether the replies match the selected behavior, including tone, level of detail, and how closely the answer stays tied to documentation.
5. Ask at least one question that is outside the documented scope.
6. Confirm the agent defers, stops short, or routes the conversation according to the fallback settings you chose.
7. Share the test results with support leads and project administrators before treating the updated setup as ready for customers.

Use a mix of test questions:

- A straightforward question covered clearly in your documentation
- A question that needs a step-by-step answer
- A question from a weak or incomplete documentation area
- A question that should trigger a handoff to a human team

[SCREENSHOT: Test conversation showing an in-scope answer and an out-of-scope fallback response]

When you review the results, look for consistency. The agent should sound like the support team, stay within documented guidance, and behave the same way across all enabled entry points. If one test surface behaves differently, go back to the availability and behavior settings before rolling the change out more broadly.

## Fixing common configuration problems
Most support agent issues in Atloria come from one of four areas: availability, reply behavior, documentation quality, or fallback setup. When something feels off, check those areas in that order instead of changing multiple settings at once.

If the agent is answering in the wrong channel, project, or workspace, reopen the availability settings first. Review every selected support surface and confirm the correct workspace, project, or team assignment is applied. If the agent appears somewhere unexpected, the availability scope is usually too broad.

If the replies do not match your support standards, go back to the behavior settings. Check whether the current setup is allowing answers that are too broad, too detailed, or not closely tied to documentation. A mismatch in tone or answer style usually means the reply behavior was configured for a different support goal than the one your team actually follows.

If the answers feel weak or inconsistent, inspect the documentation the agent depends on. The issue may not be the agent settings at all. If the linked documentation is outdated, incomplete, or uneven across topics, the agent will struggle to answer consistently. In that case, update the content first, then retest the same questions.

If customers are not being handed off correctly, review the fallback or escalation choices and test again with clearly out-of-scope questions. The agent should not continue improvising when the topic is outside documented guidance.

Use this quick troubleshooting view:

- **Wrong location:** Recheck availability selections and assignments
- **Wrong answer style:** Review tone, detail level, and answer scope settings
- **Weak answers:** Confirm the documentation is current and broad enough
- **No proper handoff:** Recheck fallback behavior and retest outside documented topics

[SCREENSHOT: Support agent settings screen highlighting availability, behavior, and fallback sections]

If the problem started after a recent documentation update, compare the current setup with the latest published content before making more changes. That often reveals whether the issue is configuration drift or documentation drift.

## Overview
This document focuses on the settings in Atloria that control how support agents behave and where they are available. The goal is not just to turn an agent on, but to make sure it answers in a way that fits your documentation, your support model, and the customer experience you want to provide.

The key areas you should review are:

- Reply behavior, including tone, level of detail, and how tightly answers stay grounded in documentation
- Availability, including which support surfaces, projects, workspaces, or teams can use the agent
- Fallback handling, including when the agent should defer or hand the conversation to a person
- Ongoing review, especially after documentation updates or support workflow changes

This guide assumes the support agent already exists and has been connected to the right workspace and knowledge sources. If that setup is still in progress, use [Creating and Managing AI Support Agents](doc:creating-and-managing-ai-support-agents) and [Managing Support Agent Workspaces and Knowledge Setup](doc:managing-support-agent-workspaces-and-knowledge-setup) first.

[SCREENSHOT: Support agent configuration area in Atloria]

Use this guide when you need to tighten an agent that is answering too broadly, expand an agent into the right support areas, or standardize behavior across teams. The most effective configurations are the ones that reflect the real quality of your documentation and the real handoff expectations of your support organization.

## Prerequisites
Before you change support agent behavior or availability in Atloria, make sure the basic setup is already in place. This helps you avoid testing behavior settings on an agent that is missing the documentation or assignments it needs.

You should have:

- Access to the support agent settings for the relevant project, workspace, or support area
- An existing support agent that has already been created in Atloria
- The correct documentation or knowledge sources already linked to that agent
- A clear understanding of which team, project, or customer-facing area the agent is meant to support
- Agreement from the relevant support lead or project administrator if the change affects live customer interactions

It also helps to prepare a short set of test questions before you begin. Include a few questions that are clearly covered by your documentation and at least one that is outside the documented scope. That makes it easier to confirm whether the updated behavior and fallback settings are working as expected.

If you still need to set up the agent itself or connect its knowledge sources, start with:

- [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)

After you finish configuring behavior and availability, the next step is [Embedding and Operating Support Agents in Documentation Experiences](doc:embedding-and-operating-support-agents-in-documentation-experiences), which covers how the agent is presented and used in customer-facing documentation flows.