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 access at scale#
Access is governed at the organization level, not Library-by-Library. Org Members and their roles determine who can view and change Libraries. Only admins and owners can create a Library. See User Management for inviting and removing people.
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.
