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#
Library access depends on whether a Library is open (internal or public) or private:
Open Libraries (internal or public) inherit access from organization membership. Everyone in your organization can read an open Library, including people who join later. Organization Owners and Admins automatically hold the Admin role in every open Library, and organization Members hold the Member role, without needing an explicit assignment.
You can still assign explicit Library roles in an open Library. Explicit assignments record who is deliberately responsible for that Library, and they persist if the Library becomes private or if the user's organization role changes.
Private Libraries require explicit Library-level role assignments. Organization membership and organization roles have no effect. Even organization Owners and Admins must be added as Library members to gain access. Each private Library has its own set of members with specific roles (Owner, Admin, Member).
Library members are managed from the Library's Members tab (the Admins tab for internal and public Libraries).
Switching from open to private. When you make an open Library private, inherited organization access is removed. The user making the change keeps an Admin role in the Library, and anyone with an existing Library-level role assignment keeps their access. Everyone else in the organization, including organization Admins, loses access unless you add them back explicitly. Switching a private Library to internal or public gives organization members inherited access based on their organization role, without explicit assignments.
Each Library still has its own controls in its settings:
- Visibility. A Library is internal by default, so everyone in your organization can access it. Switch it to private to restrict it to assigned members, or 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.