A vector store is a named, queryable view over your dashboard’s indexed documents. Every dashboard starts with a single platform-managed store called All Documents that covers every indexed file; you create additional stores when different agents — or different audiences — should be looking at different slices of your content.
Stores are how you keep a Customer Contracts agent from accidentally answering a question about engineering practices, and how you let a generalist search across everything while a Support agent only sees your published FAQs.
What a store is and isn’t
A store is a membership policy, not a copy of your data. The semantic index lives once, alongside your documents — a store just declares “include these docs” and Delphi uses that membership to constrain its search when an agent reaches for one.
Two membership modes today:
- All documents — the store always matches every indexed document on the dashboard. The platform-managed All Documents store works this way.
- Selected — the store lists specific documents. Adding or removing one is an update on the store itself; the underlying document is untouched.
Documents are the members today; connector data, URL feeds, and other source types are part of the roadmap for the same membership surface.
Membership is soft: when a document is deleted, the store simply filters it out. A store never blocks document deletion, and a deletion never breaks a store.
The “All Documents” store
Every dashboard gets an All Documents store the moment it’s created. It always matches every indexed document on the command center. RAG queries that don’t name a specific store fall back to it, so the agent has something to search even when you haven’t curated anything yet.
You can rename its display name but you can’t delete it — the agent depends on it as a fallback. If you want a curated default, leave All Documents alone and create additional named stores for the curated views.
When to create a custom store
Three patterns come up most often:
- Audience scoping — your public-dashboard Q&A agent should only see published FAQs and policy docs, not your internal engineering wiki. Build a “Public-facing docs” store and scope that agent to it.
- Domain scoping — a Finance specialist should answer from your finance binders, contracts, and board packs, not your operational runbooks. Build a “Finance” store and scope the agent to it.
- Classification segregation — a store’s effective classification is the maximum of its members. Building a store that’s deliberately internal-only — no confidential or restricted members — lets you give analyst-scope users a knowledge surface without ever showing them HR-grade material.
If everyone’s looking at the same set of documents, you don’t need extra stores. All Documents covers it.
Classification inheritance
Each store carries a classification computed from the maximum of its member docs. Add a single confidential document to a store and the whole store becomes confidential — agent queries against it are then role-checked at that level, so a viewer-scope user can’t suddenly read confidential content through a store membership trick.
The recomputation happens whenever the store is updated or a member’s classification changes. There’s no way to demote a store below its highest member; if you want a public-only view, build a public-only store.
Curating store membership
The Data tab’s Vector Stores sub-tab is where you create, edit, and inspect stores on a dashboard. Each store card shows the name, description, member document count, total embedded passage count, and current classification. Editing a Selected-mode store lets you check or uncheck individual documents; saving recomputes the stats and classification atomically.
Editor scope or above can create and edit stores. Viewers and analysts can see the catalog but not modify it.
Scoping an agent to a store
Stores only matter when an agent is configured to use them. On the Agents tab, each chat agent carries a knowledge sources list:
- All — the agent can query every store on the dashboard. Delphi picks based on the user’s question (open-ended questions hit All Documents; questions matching a store’s name or description hit that store).
- A specific list — the agent can only query the listed stores. This is how you keep a Support agent inside the FAQ store and out of internal HR material.
The shipped Delphi generalist sees all stores (gated by your role and document classification). The visualization specialist sees all stores too — it uses the same retrieval path. Custom specialists typically carry a tight list.
How a query actually runs
When an agent looks up a document, it can either name a store or let Delphi pick. Two patterns:
- No store named — falls back to All Documents. Searches every document the agent can see.
- A specific store — search is scoped to that store’s members. Faster and more focused, but also constrained to what’s actually in the store.
Either way, each retrieved passage carries provenance: which document it came from, which section, the document’s authority level. The answer cites sources with the same machinery Documents describes.
Putting it together
Two quick recipes:
- One dashboard, one knowledge surface. Don’t create custom stores. The default All Documents store is enough. Every agent sees every indexed document, gated by your role and the document’s classification. This is the right default for most internal command centers.
- One dashboard, multiple audiences or specialists. Build a store per audience (Public, Internal, Finance, Engineering) and scope each chat agent to the right one. The chat router will still pick agents correctly because each agent’s pitch already implies its scope.
For per-document classification, PII handling, and authority levels, see Documents. For how the chat router picks an agent, see Agents.