Managing Support Agent Setup and Availability

Opening the support agent workspace and understanding what each area controls

In Atloria, open the main workspace for support agents from the signed-in area of the product. This workspace is where you review existing agents, start a new one, and check whether each agent is ready for use. The screen is organized around a few practical areas that help you move from setup to launch without leaving the workspace.

The first area to look for is the agent list. This is the main list of all support agents already created in Atloria. Team leads can use this list to scan agent names, identify which agent they want to work on, and quickly spot whether an agent is still being prepared or is already available. When you click an agent in the list, Atloria opens that agent’s details so you can continue setup.

Next is the agent detail panel. This is where you review the selected agent’s setup information, including its intended use, whether it is available, and which project knowledge it is connected to. If you need to adjust setup, this is the area you return to most often.

You should also expect to see availability controls in the workspace. These controls show whether an agent can currently be used. An unavailable agent is still in setup. An available agent is ready for the audience it was prepared for.

Another key area is project knowledge connections. This part of the workspace shows which project or documentation source the agent will use when answering questions. Before marking an agent available, confirm the correct knowledge source appears here.

Primary actions in this workspace include:

• Create a new support agent
• Open an existing agent from the list
• Edit setup details in the detail view
• Review connected knowledge sources
• Check status and availability before sharing

If you already worked through embedding and day-to-day operation in Embedding and Operating Support Agents in Documentation Experiences, this screen is the place where you control whether those experiences are actually ready to be used.

Creating a new support agent

Use the support agent workspace when you need to add a new agent for a team or a reader-facing documentation experience. Start by clicking the create-agent action shown in the workspace. Atloria opens a setup form for the new agent so you can enter the basic details that identify how it will be used.

1. In the support agent workspace, click the option to create a new agent.
2. Enter the agent name exactly as you want it to appear in the agent list.
3. Complete any role or usage designation shown in the setup form. This helps distinguish whether the agent is being prepared for internal team support or for readers using published documentation.
4. Review the information you entered before saving.
5. Click Save to create the new agent.

After you save, Atloria adds the new agent to the agent list. At this point, it should appear with an initial setup state rather than as fully available. That early state is useful because it lets you confirm the agent record exists before you connect knowledge or change availability.

Once the new agent appears in the list, click its name to open the detail view. This is where the rest of the setup happens. From there, you can review the audience designation, connect the right project knowledge, and decide whether the agent should remain unavailable while you finish configuration.

A good way to confirm the creation step worked is to check for these signs in the workspace:

• The new agent appears in the list immediately after saving
• The name matches what you entered
• The agent opens correctly in the detail panel
• The setup still shows as incomplete or not yet available until you finish the remaining steps

If you need broader setup guidance for agent records and conversation use, see Creating and Managing AI Support Agents.

Configuring when the agent is available

Availability controls determine whether people can actually use the support agent. In Atloria, you manage this from the selected agent’s detail view. This is one of the most important parts of setup because an agent can exist in the workspace without being ready for access.

1. Open the support agent from the agent list.
2. In the agent detail view, find the availability setting or status control.
3. Change the agent to the state you want for the current stage of setup.
4. Save the change if Atloria prompts you to confirm it.
5. Return to the list and verify the updated status appears there as well.

When an agent is marked as unavailable, it stays in a preparation state. This is the right choice while you are still checking the agent name, audience, or connected project knowledge. Keeping it unavailable helps prevent the wrong people from using an unfinished agent.

When you are satisfied with the setup, change the availability state so the agent is ready for active use. Atloria reflects that change in two places:

• In the agent list, where you can quickly scan readiness across all agents
• In the detail panel, where the current status is shown for the selected agent

This makes it easier for team leads to review multiple agents and see which ones are still being prepared.

Use availability carefully based on the audience:

• Keep the agent unavailable if its knowledge source is missing or still being reviewed
• Keep the agent unavailable if the audience designation is not final
• Mark the agent available only after the setup matches the intended use
• Recheck the list after saving so you can confirm the status changed as expected

If you need deeper guidance on audience and access planning, refer to Configuring Support Agent Behavior and Availability.

Connecting project knowledge to the agent

A support agent is only useful when it is connected to the right project knowledge. In Atloria, the support agent workspace shows these knowledge connections in the selected agent’s setup area. This is where you confirm what source material the agent will rely on when answering questions.

1. Open the agent you want to review from the agent list.
2. In the detail view, locate the section that shows project knowledge connections.
3. Check which project or documentation source is currently attached.
4. Compare that connection with the content the agent is supposed to answer from.
5. If the wrong source is shown, update the connection before making the agent available.

The connected project knowledge acts as the agent’s answer source. In practical terms, that means the quality and relevance of responses depend on whether the correct project or documentation set is attached. If the agent is meant to help an internal team with one project, make sure that project is the one shown in the connection area. If the agent is meant for readers, confirm the linked documentation matches what readers will be asking about.

There is an important difference between these two setup states:

• Agent with project knowledge connected: the workspace shows a specific project or documentation source attached, and the agent is much closer to being ready
• Agent without project knowledge connected: no source is attached yet, so the agent should stay unavailable until this is completed

Before you enable the agent, review the connection carefully. A correctly named agent can still give unhelpful answers if it points to the wrong project knowledge.

Helpful checks in this section include:

• The connected source name matches the intended project
• The agent’s audience matches the attached knowledge
• No empty or missing knowledge connection is shown
• The connection is reviewed before changing availability

For more detailed guidance on linking knowledge and project sources, see Managing Support Agent Workspaces and Knowledge Setup and Managing Support Agent Knowledge Sources and Project Linking.

Preparing the agent for team use or reader use

In Atloria, support agents are not all prepared for the same audience. Some are intended for internal team use, while others are meant for readers in documentation experiences. The support agent workspace includes labels, audience choices, or usage designations that help you tell these apart. Review this setting early, because it affects the rest of the setup.

1. Open the agent in the support agent workspace.
2. Find the audience, role, or usage designation shown in the setup details.
3. Confirm whether the agent is intended for team use or reader use.
4. Review the connected project knowledge to make sure it fits that audience.
5. Check availability only after the audience and knowledge source both match the intended use.

For team use, the main goal is to support internal users working inside Atloria. Before sharing the agent with a support team, confirm:

• The agent name clearly identifies its purpose
• The audience or usage label points to internal team use
• The connected project knowledge matches the team’s working documentation
• The availability status is set only after setup is complete

For reader use, the setup needs extra care because the agent may be exposed in a documentation experience. Before making it available for readers, confirm:

• The audience or usage label is set for reader-facing use
• The connected knowledge source matches the published or intended reader content
• The availability state is correct for public or reader access
• The agent is not still carrying an internal-only setup

Audience choice affects nearly every decision in this workspace. A team-facing agent can be confusing if it is connected to reader documentation, and a reader-facing agent should not go live if it was prepared with the wrong audience in mind.

If you are planning how the agent appears in documentation, pair this setup work with Embedding and Operating Support Agents in Documentation Experiences.

Verifying your setup before the agent goes live

Before you treat a support agent as ready, use the workspace to verify the full setup from top to bottom. This final check helps you catch the most common issues: the wrong audience, missing project knowledge, or an agent that still shows as unavailable.

1. In the agent list, confirm the agent appears with the expected name.
2. Open the agent and verify its audience designation or usage label.
3. Check the availability state in the detail view.
4. Review the project knowledge connection and confirm it matches the content the agent should answer from.
5. Use the same workspace preview or access point your team uses to test whether the agent is reachable by the intended audience only.

When you run this review, compare what you see in the list with what you see in the detail panel. The list gives you a quick summary, but the detail view is where you confirm the full setup. If those two views do not match your expectations, stop and correct the setup before sharing the agent.

Common setup gaps to look for include:

• The agent is still unavailable
• No project knowledge connection is shown
• The wrong project or documentation source is attached
• The audience is set for team use when it should be for readers
• The audience is set for reader use when it should remain internal

A short test from the same entry point used by your team is especially useful. If the agent should be internal, make sure it is not being exposed more broadly. If it is intended for readers, confirm the experience matches the correct documentation context.

The next step after this readiness check is refining how the agent behaves in its final experience. Continue with Configuring Support Agent Behavior and Embedded Experiences.

Overview

Managing support agent setup and availability in Atloria centers on four decisions: which agent you are working on, who it is for, what knowledge it can use, and whether it is currently available. The support agent workspace brings those decisions together so you can review them from one place instead of checking separate areas.

The most important screen elements in this workflow are the agent list and the agent detail view. The list helps you scan all existing agents and spot their current readiness. The detail view lets you inspect one agent closely and confirm its name, audience designation, availability state, and connected project knowledge. If you are responsible for several agents, these two areas are the fastest way to see what still needs attention.

Availability should always be treated as the last major setup decision, not the first. An agent can be created and saved before it is ready for use, and that is often the safest approach. Leave the agent unavailable while you confirm the audience and knowledge connection. Once those pieces are correct, you can update the availability state and verify that the list reflects the change.

This document focuses on setup and readiness. It does not repeat the broader creation workflow from Creating and Managing AI Support Agents or the knowledge-planning guidance in Managing Support Agent Workspaces and Knowledge Setup. Instead, use this guide when you need to answer practical questions such as:

• Is the agent created and visible in the workspace?
• Is it meant for team use or reader use?
• Is the right project knowledge connected?
• Is the availability state correct for launch?

When those answers are clear in the workspace, the agent is much easier to manage confidently.

Prerequisites

Before you work through support agent setup in Atloria, make sure you can access the signed-in workspace where support agents are managed. You do not need every related feature configured in advance, but you do need enough information to complete the setup without guessing.

You should have the following ready:

• Access to the support agent workspace in Atloria
• A clear decision about whether the agent is for internal team use or reader-facing use
• The agent name you want to use in the workspace
• The correct project or documentation knowledge source the agent should be connected to
• Permission to review or update the agent’s availability setting

It also helps if you have already completed the earlier support agent documents, especially:

• Creating and Managing AI Support Agents
• Managing Support Agent Workspaces and Knowledge Setup
• Configuring Support Agent Behavior and Availability

If your team plans to use the agent in a documentation experience, you should also be familiar with:

• Embedding and Operating Support Agents in Documentation Experiences

Before you begin, confirm these practical points with your team:

• Which audience should be able to use the agent first
• Which project knowledge should be attached at launch
• Whether the agent should remain unavailable until a final review
• Who will verify the setup from the workspace before it goes live

Having these answers in place makes the setup process much smoother, because every field and status you review in the workspace can be checked against a clear plan rather than adjusted later.