Multi-Library Management enables a single 📝MythOS creator to operate across multiple MythOS libraries from one connection. This is the infrastructure layer for 📝Adaptive AI as a Service (AaaaS) — where an 📝Oracle-tier creator manages libraries on behalf of clients, each library maintaining its own augmentation context, memos, and knowledge graph.

How It Works

Every 📝MythOS MCP tool now accepts an optional library parameter — a username string that targets a different library. Without it, tools default to the caller's own library. The server validates every cross-library operation against a library_grants collection before allowing access.

search_memos({ query: "onboarding", library: "clientname" })
create_memo({ title: "Q2 Strategy", content: "...", library: "clientname" })
read_daily_memo({ date: "2026-04-06", library: "clientname" })

One API key. One MCP connection. Multiple libraries. Each library keeps its own 📝Augmentation System — its own Soul, Style, Human, and Memory — so the AI adapts its behavior to the library it's operating in, not the person holding the key.

Authorization Model

Access is explicit, not role-based. No blanket admin access exists.

Own library — always authorized, no grant needed
Granted library — requires an approved record in the library_grants collection
Everything else — 403

Grants are requested through the Settings UI at /settings/libraries or via the API. When the requester owns both libraries (same uid), the grant auto-approves. When the target library belongs to a different person, the owner receives the request and must approve it.

The Agency Model

An Oracle subscriber building an AaaaS practice manages client libraries as a service. The workflow:

Client creates a MythOS library — their own account, their own content, their own augmentation context
Client grants the agency access — approves the management request from Settings
Agency operates across all client libraries from a single MCP connection — creating memos, managing tasks, running knowledge operations
Each library stays sovereign — the client's augmentation memos define how AI behaves in their library. The agency manages content and structure; the client defines voice and values
Client can revoke access at any time — removing the grant immediately blocks cross-library operations

This is not delegation. It's scoped collaboration — the agency works within the client's world, shaped by the client's rules.

What's Supported

All library-scoped MCP tools accept the library parameter:

Memos: search, read, create, update, delete
Tags: list tags across any granted library
Tasks: list, create, complete, update
Daily memos: read, add tasks, add entries
Sync: delta sync, memo index

Tools that are inherently cross-library or connection-scoped do not accept the parameter:

get_context — loads the MCP connection owner's augmentation, not the target library's
chat_with_library — already accepts a username parameter (separate from library)
list_communities / search_community_posts — not library-scoped

Settings UI

Available at Settings > Developer > Libraries. Creators see:

Your Libraries — own library (always present) plus any granted libraries with status badges
Request Access — enter a library username to request management access
Incoming Requests — pending requests from others wanting to manage your library, with approve/deny actions

API Endpoints

Full reference in 📝MythOS v3 API — Complete Route Reference under the Settings section:

GET /api/settings/libraries — list own + granted libraries + incoming requests
POST /api/settings/libraries — request access (auto-approves if same owner)
PATCH /api/settings/libraries — approve or deny incoming request
DELETE /api/settings/libraries?id={grantId} — remove a grant

Future: Oracle Tier Gating

Multi-library management is currently available to any creator with a library_grants record. When Oracle-tier gating ships, the request flow will check membershipTier === "oracle" before allowing cross-library grant requests. The underlying authorization model won't change — grants are grants regardless of how they were earned.

This is the first feature where MythOS stops being a single-player tool and becomes infrastructure for collaborative knowledge work. The sovereignty model matters — clients define the rules of their library, agencies operate within those rules. No one gets blanket access. Every grant is explicit, revocable, and scoped.

The AaaaS vision lands here. An Oracle creator doesn't just use MythOS — they offer MythOS as a managed service, each client library a living system with its own memory, voice, and knowledge graph, all orchestrated from one seat.

Contexts

🏷️#mythos-feature