Managing Support Agent Knowledge Sources and Project Linking

Understanding how agents use project-linked knowledge

In Atloria, a support agent answers questions based on the knowledge you make available in its setup. The most important part of that setup is the connection between the agent and a project. When you link an agent to a project, you are telling Atloria which project workspace the agent should look to for documentation context. This is different from adding extra knowledge sources in the agent’s settings. The linked project identifies the main project the agent belongs to, while the knowledge sources list lets you control exactly which documentation collections the agent can use.

This distinction matters when teams manage several projects with similar names or overlapping content. If the wrong project is linked, the agent may pull answers from the wrong documentation set. If the project is correct but unrelated knowledge sources are also attached, the agent may mix content that should stay separate. For that reason, you should always review both the Linked Project field and the Knowledge Sources section together.

Published documentation is what support agents are expected to use. If a page is still a draft, under review, or otherwise not published, you should not expect the agent to answer from it. When a team updates documentation, the agent’s response quality depends on whether the final, published version is actually available in the project content the agent can access.

Teams usually split responsibility across roles:

• Support Team Lead sets up the support agent and reviews its knowledge sources.
• Project Administrator makes sure the correct project is linked.
• Documentation Manager controls which pages and articles are published and ready for agent use.

Preparing projects and published documentation before linking an agent

Before you link a support agent to a project in Atloria, confirm that the project already exists and contains the documentation your team wants the agent to use. Start from your project list or project workspace and open the intended project. Check that the documentation space includes the pages, articles, or structured content your support team expects the agent to answer from. If the project is incomplete or still being set up, linking the agent too early can lead to weak or misleading responses.

Next, review the publication status of the content. Support agents should rely on published documentation, not drafts or unfinished edits. If your team has recently updated a page, open that page and make sure the published version reflects the latest approved content. If a page is archived or not available in the live documentation set, it should not be treated as a reliable source for the agent. This is especially important when support teams expect answers for newly released features.

You should also confirm that the person doing the setup can access both sides of the workflow:

• The project workspace that contains the documentation
• The support agent settings where project links and knowledge sources are managed

If someone can open the agent but cannot view the project content, they may not be able to verify whether the right material is available. If they can view the project but cannot edit the agent, they will not be able to finish the setup.

Before saving anything, decide what should be included and what should stay out. Customer-facing help articles, published setup guides, and approved troubleshooting pages are good candidates. Internal notes, draft procedures, and team-only working documents should remain excluded.

Linking a support agent to the correct project

1. Open the support agent you want to configure in Atloria. On the agent’s settings or configuration page, look for the project linking area. This is usually the place where you choose which project the agent belongs to.

2. Find the Linked Project field or project picker. Open the list and select the correct project carefully. If your team uses similar project names, pause and double-check before choosing. It helps to confirm the project name against the project workspace your documentation team maintains, rather than selecting the first close match.

3. After selecting the project, review the rest of the page briefly to make sure you are editing the intended agent. This is useful when teams manage multiple support agents for different products, audiences, or documentation sets.

4. Click Save to store the project connection on the agent record. Do not leave the page before saving, or the selected project may not be kept.

5. Re-open the same support agent settings after saving. Check the Linked Project field again and confirm the same project still appears. This quick re-check helps catch accidental changes, unsaved edits, or cases where the wrong project was selected from the list.

6. If the linked project does not look right, update it immediately and save again before moving on to knowledge source setup. It is much easier to fix the project link first than to troubleshoot mixed answers later.

A correct project link gives the agent a clear home base. Once that is in place, you can move to the Knowledge Sources section and refine exactly which published documentation collections the agent should use.

Organizing the agent's knowledge sources

After linking the project, open the Knowledge Sources section in the same support agent settings. This area is where you review what the agent can actually use when answering questions. Some sources may come from the linked project, while others may have been added separately. Read each source name carefully so you can tell whether it belongs to the correct documentation set.

Use this section to keep the agent focused. If the agent supports one product area, keep only the documentation collections that match that scope. Remove unrelated sources that could introduce conflicting instructions or answers from another project. For example, if an agent is meant to answer only from one team’s published help content, avoid mixing in sources from another product line or internal documentation set.

A simple organization approach makes ongoing maintenance easier:

• Group sources by product area when one team supports multiple products
• Group sources by team ownership when different documentation teams maintain separate collections
• Group sources by documentation set when you want one agent to answer from a specific published library only

Consistent naming also helps. If source names are clear and recognizable, support leads and documentation managers can quickly confirm whether the right material is attached. If Atloria shows sources in a list, review the order as well. A tidy, predictable order makes future audits faster, especially when several people share responsibility for agent upkeep.

As you edit the list, save changes and return to the source list to confirm it still matches your plan. The goal is not to attach as many sources as possible. The goal is to give the agent a clean, relevant set of published documentation that matches its support role.

Confirming the right published content is available to agents

Once the project link and knowledge sources are in place, verify that the agent can use the published content you expect. Start by opening the linked project and reviewing a sample of the pages or articles your support team relies on most. Focus on content that is already published, especially recently updated pages, because these are often the first places where teams notice gaps.

Then return to the support agent settings and compare the configured knowledge sources with the published documentation you just reviewed. Make sure the source names line up with the correct project content. If a key documentation collection is missing from the Knowledge Sources section, the agent may not be able to answer from it even if the page is published elsewhere in Atloria.

A practical way to validate the setup is to test the agent with real support questions. Use representative questions that should clearly be answered from the linked project’s published documentation. For each test:

1. Ask a question tied to a known published page.
2. Read the agent’s answer carefully.
3. Open the matching published page in the project.
4. Compare the wording, instructions, and topic coverage.

You are looking for alignment, not necessarily identical wording. The answer should reflect the same published guidance, product area, and scope. If the response sounds like it came from another project, or if it ignores a recently published page, review the project link and source list again.

This check is especially useful after a documentation release, a project rename, or a change in agent ownership. Small configuration mistakes are easier to catch with a few targeted questions than with a broad review of every page.

Fixing missing or incorrect knowledge in agent responses

If a support agent in Atloria cannot find content you expected it to use, start with the page itself. Open the relevant article or documentation page and confirm it is published. If it is still a draft, pending review, or otherwise not part of the published documentation set, the agent may not use it as expected. This is the most common reason a newly written page does not appear in answers.

If the agent gives answers from the wrong documentation, go back to the agent settings and inspect the Linked Project field first. A similar project name can easily cause confusion, especially in organizations with multiple related workspaces. If the wrong project is selected, correct it, click Save, and then review the Knowledge Sources section for any leftover sources that no longer belong.

When newly published content still does not seem available, check whether the correct source was actually added to the agent’s knowledge configuration. Publishing content in a project does not help if the agent is limited to a different documentation collection. Open the source list and verify that the expected collection is present and that unrelated sources are removed.

If only some team members can validate the setup, compare access levels. The people involved may need permission to:

• Open the project and view its published documentation
• Open the support agent settings
• Edit the agent’s project link and knowledge sources

Without both project visibility and agent management access, a team member may see only part of the workflow and assume something is missing when it is actually hidden by permissions. For broader admin-side navigation and workspace access, see Using the Admin Workspace and Managing User Access and Administrative Permissions.

Overview

Managing support agent knowledge in Atloria comes down to three connected decisions: which project the agent belongs to, which knowledge sources are attached to that agent, and whether the needed documentation is actually published. The Linked Project field gives the agent its primary project context. The Knowledge Sources section narrows or expands what documentation collections the agent can use. Published content is what makes those sources useful in practice.

This workflow is easiest to manage when each role handles a clear part of the process:

• Support Team Lead reviews the agent’s scope and keeps the source list focused
• Project Administrator confirms the correct project is linked
• Documentation Manager publishes the pages that should be available for support answers

A clean setup usually follows this pattern:

If you are still setting up the agent itself, pair this guide with Creating and Managing AI Support Agents and Managing Support Agent Workspaces and Knowledge Setup. If your team is reviewing how project navigation affects documentation access, Understanding Project Navigation and Linked Workspaces is also useful.

The next step is learning how agents use published documentation directly in day-to-day support workflows: Using Published Documentation as Support Agent Knowledge.

Prerequisites

Before you start linking a support agent to project knowledge in Atloria, make sure these basics are already in place:

• You can sign in and open the main Atloria workspace
• The support agent already exists and you can open its settings
• The target project already exists in Atloria
• The project contains the documentation space or content the agent should use
• The pages or articles you want the agent to rely on are published
• You can view the project and edit the agent’s knowledge setup

It also helps to prepare a short list of the exact documentation collections the agent should use. This prevents guesswork when you reach the Knowledge Sources section. If your organization has several projects with similar names, note the exact project title before opening the agent settings so you can choose the right one in the project picker.

Use this guide when you are in one of these situations:

• You are setting up a new support agent for an existing project
• You need to move an agent from one project to another
• You want to clean up an agent that is using too many unrelated sources
• You need to confirm whether published documentation is available to the agent

If you still need help getting into Atloria or creating your account, start with Accessing and Registering Your Atloria Account or Signing In to Atloria and Solving Access Problems. If your access depends on admin approval, Managing User Access and Administrative Permissions explains how teams typically control workspace access.