A Library is a knowledge base scoped to a project, team, or product area. As your organization grows, you will run several Libraries side by side. This page covers when to split knowledge into multiple Libraries, how Sources are shared across them, how to choose which Library you are talking to, and how access works at scale. Manage your Libraries at Libraries.
When to use more than one Library#
A single Library can hold many Sources, so you do not need a separate one for every repository. Add another Library when a set of knowledge has a distinct audience, owner, or boundary. Common ways teams split:
- By team. Platform, infrastructure, payments, and growth each get a Library so answers and Documents stay scoped to what that team owns.
- By product or service. A Library per product area keeps generated Documents and Topics from blurring together across unrelated codebases.
- By visibility. Keep internal knowledge in a private Library and put a public-facing project in its own Library so you can open it to unauthenticated readers without exposing everything else. See Public Libraries.
A good rule for a large engineering org: one Library per durable team or product boundary, not one per repo and not one giant Library for the whole company. Tight Libraries give cleaner answers and a clearer sense of who owns what.
Sharing Sources across Libraries#
A Source can belong to more than one Library at the same time. The same GitHub repository or Slack workspace can be read by your platform Library and your payments Library without being connected twice. Two things to keep in mind about shared Sources:
- Source-level settings are global. Some settings are stored on the Source itself, not in the Library. For example, Web URL patterns and the GitHub toggles for issues, pull requests, and discussions apply everywhere that Source is used. Changing them affects every Library already using that Source, so review the impact before you save.
- Read and Monitor are per Library. Each Library decides how it uses a shared Source. Read lets the Library reference the Source when answering questions and writing Documents. Monitor watches the Source for changes worth documenting and flags stale knowledge. You can read a Source in one Library and monitor it in another.
Deleting a Source removes it from every Library that uses it and drops its indexed content, so prefer detaching it from a single Library when you only want to stop using it in one place.
Choosing a Library when you ask Dosu#
Chat in Dosu is scoped to one Library at a time, so answers come from that Library's Sources and Documents. The chat sidebar shows which Library you are in and lets you switch to another. Pick the Library that owns the knowledge you are asking about, then ask in Chat.
Agents work the same way. An Agent is grounded in the Libraries it belongs to, and an Agent can belong to more than one Library. When you configure an Agent, you can switch which Library it draws from, so the same GitHub or Slack Agent can serve answers from different knowledge sources depending on where it is used.
Managing Library Access#
Libraries support individual membership management. Each Library has its own set of members with specific roles (Owner, Admin, Member). This allows you to:
- Grant specific users access to individual Libraries without adding them to your organization
- Control who can view, edit, and manage each Library independently
- Assign different permission levels per Library
Library members can be managed through the Members tab in each Library's settings. A user's permissions in a Library are determined by their Library role, which is independent of their organization role.
For organization-wide access patterns, organization roles still apply: organization Owners and Admins can access all Libraries within the organization by default.
Each Library still has its own controls in its settings:
- Visibility. A Library is private by default. Switch it to public so unauthenticated users can ask questions and read its Documents. Treat public visibility as a deliberate choice, since everything in that Library becomes readable by anyone with the link.
- Knowledge behavior. Auto-Accept Review, auto-publish, Topic assignment, and style guidelines are set per Library, so a high-trust internal Library and a carefully reviewed public one can behave differently.
One guardrail to keep in mind is that you cannot delete the last Library in an organization, so there is always at least one knowledge base to fall back on.