Skip to content
D
Documentation

Managing Support Agent Workspaces and Knowledge Setup

11 min readUpdated

Opening the support agent workspace and understanding what appears there

In Atloria, you work with support agent setup from the authenticated workspace after signing in. If you need help getting into your account or moving around the signed-in areas, use Signing In to Atloria and Solving Access Problems and Understanding Account Entry Points and Session Navigation.

After you enter the main workspace, support-related setup is handled as part of your project and administration flow rather than from the public documentation view. Team leads and project administrators typically move through the signed-in dashboard, open the relevant project, and then use the support agent areas connected to that project’s documentation setup. From there, you can review the support agent workspace, open individual agent records, and move into behavior or knowledge-related settings without leaving the broader project context.

The workspace separates day-to-day support agent use from setup work. In practice, this means the people responsible for configuration open screens where they can inspect agent details, review linked documentation sources, and adjust how an agent should respond. The people who maintain documentation usually focus on the knowledge source side, while support team leads focus on the agent itself and project administrators handle access or broader project settings.

Look for these main workspace areas as you move through the support setup flow:

  • The project workspace where the support agent belongs
  • The agent list or agent management view
  • The individual agent details screen
  • The knowledge source area where documentation is connected
  • The behavior settings area for response configuration

This document focuses on organizing the workspace and connecting knowledge. If you still need to create the agent itself, start with Creating and Managing AI Support Agents.

Reviewing how support agents are organized

Support agents are easiest to manage when you start from the list view that shows the agents already available in a project. In Atloria, this management view is where support team leads check which agents exist before opening one to review its setup. Instead of changing behavior or knowledge sources from memory, use the list first so you are always working on the correct agent.

From the agent list, open each record to confirm the basics before making changes. The key details visible from this kind of screen are the agent name, the project it belongs to, and the entry points that take you into its settings. This helps you distinguish one support agent from another when a project has more than one agent or when several projects are being maintained at the same time.

A practical review flow looks like this:

  1. Open the signed-in workspace and go to the project that contains the support agent.
  2. Open the support agent management area for that project.
  3. Review the list of existing agents and identify the one you want to update by name.
  4. Select the agent to open its details.
  5. Use the available settings links or tabs to move into behavior or knowledge setup.

When you inspect an agent record, pay attention to whether you are editing the correct project context. This matters most for teams that maintain multiple documentation sets, because the wrong project selection can lead to the wrong knowledge being attached later.

Use the agent management view for these common tasks:

  • Add a new support agent
  • Open an existing agent
  • Check which project the agent belongs to
  • Move into behavior settings
  • Move into documentation knowledge settings

If you are cleaning up existing setup, review each agent one by one before changing its behavior. That makes it much easier to keep workspace ownership clear between team leads, documentation managers, and administrators.

Configuring agent behavior from the UI

Once you open an individual support agent, use its settings area to review how that agent is expected to respond in its assigned workspace. In Atloria, support team leads usually handle this part because behavior settings affect the quality and consistency of answers users receive.

Start from the selected agent’s details screen and open the behavior-related settings available there. These controls are where you adjust how the agent operates for that specific support setup. Because behavior settings are tied to the selected agent, always confirm the agent name before making changes.

A typical update flow is:

  1. Open the project’s support agent list.
  2. Select the agent you want to edit.
  3. Open the behavior settings area from the agent details screen.
  4. Review the available fields and switches that control how the agent responds.
  5. Update the settings that need to change.
  6. Click Save to apply the new behavior configuration.

After you save, stay on the page long enough to confirm the change was accepted. If Atloria shows the updated values in the agent settings screen, that is your first check that the update was stored correctly. If you leave the page too quickly or switch to another tab without saving, your changes may not be applied.

Use individual agent settings when:

  • One agent needs a different response style from others
  • A specific project needs its own support approach
  • You are testing a change on a single agent before using it more broadly

Use project-level setup when:

  • Multiple agents in the same project should follow the same baseline behavior
  • A project administrator is maintaining shared support rules
  • You want consistency across the whole project workspace

For teams with shared ownership, let support team leads adjust the agent’s response setup, while project administrators manage broader defaults that affect the whole project. The next document, Configuring Support Agent Behavior and Availability, goes deeper into those behavior choices.

Connecting documentation knowledge sources for support agents

A support agent is only as useful as the documentation it can rely on. In Atloria, documentation managers usually maintain this part of the setup by opening the knowledge source area connected to the support agent or project workspace and selecting the documentation that should be available to that agent.

Begin from the support agent workspace or the selected agent’s details screen, then open the knowledge or documentation source section. This is the area where you connect approved documentation so the agent can answer questions using the right project content. If your team manages several documentation sets, review the project name carefully before attaching anything.

Use this process to connect documentation knowledge:

  1. Open the correct project and select the support agent you want to update.
  2. Go to the knowledge source or documentation source area.
  3. Review the documentation currently attached to the agent or workspace.
  4. Add or select the documentation sources that should be used.
  5. Remove any sources that are outdated or no longer approved.
  6. Click Save to keep the updated knowledge configuration.

Documentation managers should include sources that are current, reviewed, and relevant to the support experience. If a source is old, incomplete, or tied to the wrong project, it can lead to poor answers. For that reason, it is better to keep the source list focused than to attach every available document without review.

When deciding what to include, check whether the source is:

  • Part of the correct project
  • Current enough for active support use
  • Intended for the same audience the agent serves
  • Still approved for team use

After saving, reopen the knowledge source area and confirm the selected documentation is still listed. That quick check helps catch cases where a source was not actually attached.

If your team also manages project documentation structure, related guidance in Managing Support Agent Knowledge Sources and Project Linking can help you keep source selection consistent.

Managing access and ownership for workspace configuration

Support agent setup works best when each person owns a clear part of the workflow. In Atloria, the most common split is simple: support team leads manage agent behavior, documentation managers maintain knowledge sources, and project administrators control access and project-wide setup.

This division matters because not every signed-in user should be changing every part of the support workspace. Some tasks affect only one agent, while others affect the whole project. If too many people edit the same settings without coordination, it becomes difficult to tell why an agent’s answers changed or why a documentation source disappeared.

Use the following ownership model as a working guide:

RoleTypical responsibilities
Support Team LeadOpen agent records, review assigned agents, update behavior settings, verify agent responses
Documentation ManagerCurate documentation sources, add or remove approved knowledge, keep source content current
Project AdministratorControl project access, manage broader project setup, handle higher-level support configuration

Tasks that usually require elevated access include:

  • Editing project-level support setup
  • Changing broader workspace settings
  • Managing who can access the project
  • Updating configuration that affects more than one agent

Tasks that are often handled as routine maintenance include:

  • Opening an existing agent
  • Reviewing its current settings
  • Updating the attached documentation sources
  • Testing whether the agent uses the expected content

To avoid conflicting changes, agree on a simple handoff. For example, the documentation manager updates the source list first, then the support team lead tests the agent, and the project administrator only steps in when access or project-wide settings need to change.

If you need a broader view of project ownership and workspace responsibilities, see Managing Project Administration from the Project Home.

Verifying the workspace and knowledge configuration

After you save changes, verify the setup before your team relies on the support agent. In Atloria, this means checking three things in the workspace: the correct agent is selected, the latest settings are visible, and the right documentation sources are attached.

Start by reopening the agent details screen. Confirm that the agent name matches the one you intended to update and that the behavior settings still show your latest changes. Then move to the knowledge source area and make sure the selected documentation is listed there. If the source list looks incomplete, return to the previous screen and check whether the last update was saved.

Use this verification flow:

  1. Reopen the support agent from the project’s agent list.
  2. Review the behavior settings and confirm the latest values are visible.
  3. Open the knowledge source area and check that the expected documentation is attached.
  4. Test the agent from the workspace using a question that should be answered from the selected documentation.
  5. Compare the response with the documentation you intended the agent to use.

If the answer looks wrong, check these common causes:

  • You edited the wrong support agent
  • The latest changes were not saved
  • The documentation source was not attached
  • The source belongs to a different project
  • You do not have permission to complete the update

A quick test question is often the fastest way to catch a setup problem. Ask about a topic that appears clearly in the attached documentation. If the answer does not reflect that content, return to the knowledge source settings and review the attached sources again.

Once the workspace and knowledge setup look correct, continue with Configuring Support Agent Behavior and Availability to refine when the agent is available and how it should respond in live use.

Overview

This document covers the day-to-day setup work that happens after a support agent has already been created in Atloria. The focus here is the workspace used to manage that agent inside a project: where to find the agent, how to review its settings, how to connect documentation knowledge, and how to confirm the setup is working as expected.

The most important idea is that support agent management in Atloria is tied to project context. Team leads, documentation managers, and project administrators all work from the signed-in workspace, but they do not usually change the same things. Support team leads focus on the selected agent and its behavior settings. Documentation managers decide which documentation sources should be available to the agent. Project administrators handle access and broader project-level setup.

You will use the support workspace to:

  • Open the correct project
  • Review the list of existing support agents
  • Open an individual agent’s details
  • Adjust behavior settings for that agent
  • Attach or remove documentation knowledge sources
  • Verify that the agent uses the expected content

This guide does not repeat the steps for creating a support agent from scratch. If you still need to add the agent itself, go back to Creating and Managing AI Support Agents. It also does not go deeply into advanced behavior options or availability rules, because those are covered next in Configuring Support Agent Behavior and Availability.

Use this guide when you need to keep an existing support agent aligned with the right project content and make sure the people responsible for setup are working in the correct part of Atloria.

Prerequisites

Before you work on support agent workspaces and knowledge setup in Atloria, make sure the basic project and account pieces are already in place. This helps you avoid getting partway through the setup only to find that the agent, project, or documentation source is missing.

You should have the following ready:

  • An Atloria account that can sign in to the authenticated workspace
  • Access to the project where the support agent belongs
  • At least one existing support agent to review or update
  • Documentation content already available in the project
  • The appropriate role for the task you need to complete

The role split matters:

  • Support Team Lead: updates agent behavior and verifies responses
  • Documentation Manager: maintains the documentation sources used by the agent
  • Project Administrator: manages project access and broader project-level setup

It also helps to confirm these conditions before you begin:

  • You can open the project workspace without access errors
  • You can see the support agent management area for that project
  • The documentation you want to attach is already present in Atloria
  • You know which agent should use which documentation set

If any of those pieces are missing, use these related guides first:

With those items in place, you can move through the support workspace confidently and make changes without guessing which project, agent, or documentation source should be connected.

Was this page helpful?

Download as PDF