## Preparing Atloria Documentation for Agent Training Before you create a support agent in Atloria, confirm exactly which documentation it should answer from. The most reliable setup starts with a clearly defined source, such as a specific docs space, a selected category, or a set of published articles that already cover your support topics. If your team manages several projects or documentation areas, narrow the source before you begin so the agent does not pull answers from unrelated content. Focus on published content only. Review the articles you plan to use and make sure they are current, complete, and written for the audience the agent will support. If an article is still being edited, missing steps, or based on an older workflow, update it before adding it to the agent’s knowledge source. This matters most for setup instructions, troubleshooting guides, and account-access articles, where even a small change can lead to incorrect answers. It also helps to define the first support scenarios the agent should cover. Common starting points include: - product how-to questions already documented in Atloria - account setup guidance - troubleshooting flows with clear step-by-step articles - common “where do I find…” questions tied to published documentation Keep ownership clear from the start so the agent stays accurate over time: - **Support Team Lead**: defines how the agent should respond, when it should hand off to a person, and which support situations it should handle - **Documentation Manager**: checks article quality, publishing status, and content coverage - **Project Administrator**: manages workspace access and makes sure the right people can update the agent and its sources [SCREENSHOT: published documentation list showing approved articles or categories selected for agent use] ## Creating a Support Agent 1. In Atloria, open the area where AI support agents are managed, then start the **Create** flow for a new agent. If your team already has several agents, look for the option to add a new one rather than editing an existing entry. 2. Enter a clear **Name** and **Description**. Use wording that helps your team tell agents apart at a glance. For example, your name might reflect the audience or product area, while the description can explain whether the agent is meant for internal support staff or customer-facing help. This becomes especially useful when multiple agents cover different documentation sets. 3. Choose the setup option that uses Atloria documentation as the agent’s main answer source. This is the best choice when you want the agent to respond from your existing articles instead of relying on general-purpose answers. If Atloria asks you to select a documentation collection, space, category, or article group, choose the source you reviewed earlier. 4. Select the documentation set the agent should use. Be deliberate here. If you choose too broad a source, the agent may return answers from unrelated articles. If you choose too narrow a source, it may miss valid answers that exist elsewhere in your published docs. 5. Save the new agent. After saving, review the agent’s status on its details screen or list entry. You should see that the agent has been created and is available for further setup. At this stage, the agent exists, but you should still review its behavior and test its answers before using it in live support work. [SCREENSHOT: create support agent screen with Name, Description, documentation source selection, and Save button] ## Configuring How the Agent Responds 1. Open the new agent’s settings and find the instructions or behavior area. This is where you define how the agent should answer. Write guidance that matches your support style, such as whether responses should be concise, step-based, formal, or friendly. If your team wants the agent to stay tightly aligned to Atloria documentation, make that explicit in the instructions. 2. Decide how strict the agent should be about source material. For support teams, a documentation-first approach usually works best. Configure the agent so it answers from Atloria documentation, avoids unsupported guesses, and declines questions when no matching article exists. If there is a setting for fallback behavior, use it to direct people to human support when the documentation does not cover the issue. 3. Define the response format for common support cases. For example, you may want the agent to: - summarize the steps from a help article - present troubleshooting steps in order - point users to the source article for full details - keep answers focused on documented actions only 4. Review any audience or channel-related settings that affect how the agent is used. An internal support agent may use a more operational tone and assume staff know Atloria navigation. A customer-facing agent should usually be clearer, more guided, and less dependent on internal shorthand. Make sure the selected behavior matches the people who will read the answers. 5. Save your changes and read through the settings one more time. Small wording changes in the instructions can make a noticeable difference in how the agent handles unsupported questions, article summaries, and troubleshooting flows. [SCREENSHOT: agent behavior settings showing instructions, fallback behavior, and response rules] ## Managing Agent Settings and Documentation Sources After the agent is created, return to its settings whenever your support process changes. The most common updates are to the **Name**, **Description**, and behavior instructions. For example, if an agent that started as an internal tool is later used in a customer self-service experience, update its description and response guidance so the purpose is obvious to everyone managing it. Documentation sources also need regular attention. As your team publishes new articles, reorganizes categories, or retires older guidance, review the source list connected to the agent. Add new documentation when a product area expands, remove articles that no longer reflect current workflows, and replace outdated source groups with newer published content. This keeps the agent aligned with what users should actually see in Atloria today. When major article updates are published, refresh the agent’s knowledge source so recent edits are reflected in future answers. This is especially important after: - rewriting setup or onboarding instructions - changing troubleshooting steps - publishing new support articles for recurring issues - removing outdated guidance from a docs space or category Also review who can manage the agent. Access settings should match your team’s responsibilities. In most cases, only the people responsible for support operations, documentation quality, or project administration should be able to change behavior settings or swap documentation sources. Limiting editing access helps prevent accidental changes that could affect live support answers. If your team manages several agents, keep each one clearly scoped. A well-maintained agent usually has a focused purpose, a reviewed source list, and a clear owner who checks it after documentation changes. [SCREENSHOT: support agent settings screen with editable details and documentation source management] ## Using the Agent in Support Workflows Support teams get the most value from an Atloria support agent when they use it for repeatable, documented questions. Instead of rewriting the same answer for every ticket or chat, staff can use the agent to pull from existing Atloria documentation and return a consistent response. This works well for setup steps, navigation questions, standard troubleshooting, and other issues already covered in published articles. Use the agent when the answer should come directly from documentation. Good examples include: - showing a user how to complete a known setup task - walking through a documented troubleshooting sequence - pointing someone to the correct article for a common question - summarizing published instructions in a shorter reply Do not rely on the agent for account-specific decisions, exceptions, or undocumented issues. If a question depends on customer data, special permissions, billing details, or a problem that is not covered in Atloria documentation, route it to a human support person. The agent is strongest when it stays within documented guidance and weakest when it is expected to improvise. Support conversations can also improve your documentation. When the same question appears repeatedly, or when the agent struggles to answer clearly, review the related article. Documentation Managers can use these patterns to spot missing articles, unclear steps, or content gaps. After the article is improved and published, refresh the agent’s source so future answers reflect the update. A simple maintenance loop works well: - support team notices repeated or weak answers - documentation team updates the article - the source is refreshed in the agent settings - support team tests the question again That cycle keeps the agent useful without turning it into a separate knowledge base. ## Testing the Agent Before Rolling It Out 1. Start with real support questions. Use examples from recent tickets, chat transcripts, or common help requests, then ask the agent those same questions. Compare the answers to the published Atloria articles you selected earlier. The response should match the documented steps, stay within scope, and reflect the correct article content rather than adding unsupported guidance. 2. Test questions with different wording. Users rarely ask the same question the same way twice, so try short questions, full-sentence questions, and troubleshooting-style questions. This helps you confirm whether the selected documentation source is broad enough and whether the behavior instructions produce clear, usable replies. 3. Check what happens when no answer exists in the documentation. Ask about an undocumented issue and review the fallback response. The agent should avoid guessing and should instead decline the question or direct the user to human support, depending on how you configured it. 4. Confirm that recent article edits appear after you refresh the source. If you updated a published article, run a before-and-after test using the same question. If the answer still reflects the older content, review whether the correct source was selected and whether the refresh completed. 5. Fix common setup problems before rollout: - wrong docs space, category, or article set selected - outdated published articles still included in the source - behavior instructions too vague or too broad - fallback guidance missing for unsupported questions [SCREENSHOT: test conversation view showing a support question, the agent answer, and the related published article] ## Overview Atloria support agents help teams answer questions from existing documentation instead of writing every response manually. In practice, this means you create an agent, connect it to published documentation, define how it should respond, and test it before using it in support work. The agent is most effective when its knowledge source is limited to current, approved content and its behavior is clearly scoped around documented answers. This guide focuses on the core setup flow for a documentation-backed support agent in Atloria. You prepare the source content, create the agent, configure its response style, manage the connected documentation, and test it with realistic support questions. It also covers how support teams and documentation teams work together so the agent improves over time rather than drifting away from current guidance. Use this guide when you need to: - create a new support agent for internal or customer-facing use - connect an agent to Atloria documentation - control how the agent handles unsupported questions - update the agent after documentation changes - validate the agent before broader rollout A few related areas in Atloria are referenced throughout this process. If you need help with account access before starting, see [Signing In to Atloria and Solving Access Problems](doc:signing-in-to-atloria-and-solving-access-problems). If you need to review project or workspace access before assigning ownership, see [Managing User Access and Administrative Permissions](doc:managing-user-access-and-administrative-permissions). For broader AI setup decisions, see [Configuring AI Settings for Your Organization](doc:configuring-ai-settings-for-your-organization). The next document in this section is [Managing Support Agent Workspaces and Knowledge Setup](doc:managing-support-agent-workspaces-and-knowledge-setup), which goes deeper into organizing sources and maintaining the content behind your agents. ## Prerequisites Before you create a support agent in Atloria, make sure the people involved can access the right areas and that the documentation source is ready to use. You do not need every possible support article in place, but you should have a stable set of published content for the first questions the agent is expected to answer. Check these items before you begin: - You can sign in to Atloria and reach the authenticated workspace. - You have access to the area where support agents are created and managed. - The documentation you want the agent to use is already published. - The selected docs space, category, or article set contains current information. - Someone on the team is responsible for documentation quality. - Someone on the team is responsible for agent behavior and escalation decisions. - Someone with workspace or project administration access can manage permissions if needed. It also helps to prepare a short test set before setup begins. Gather a few real support questions that are already answered in your documentation, along with one or two questions that should not be answered by the agent. These will help you confirm both the normal response behavior and the fallback behavior after setup. If you are still preparing the underlying project documentation, complete that work first so the agent has reliable source material. Depending on your workflow, these guides may help: - [Creating Projects and Completing Onboarding](doc:creating-projects-and-completing-onboarding) - [Creating and Editing Documentation Pages](doc:creating-and-editing-documentation-pages) - [Organizing and Reviewing Document Content](doc:organizing-and-reviewing-document-content) If your team is ready to move from basic creation into source organization and workspace-level setup, continue with [Managing Support Agent Workspaces and Knowledge Setup](doc:managing-support-agent-workspaces-and-knowledge-setup).