Skip to main content

Shared files and memory

A workspace is more than a folder of conversations. It's also a shared file pool that's automatically searchable from chat, and a shared AI memory the team writes into and reads from. This page covers both, including what crosses the boundary between personal and workspace.

Files: one workspace = one RAG context​

Every file uploaded into a workspace is automatically indexed into the workspace's RAG context (Retrieval-Augmented Generation). Conversations in the workspace can recall content from those files at query time without you having to attach anything.

Concretely:

  • One workspace = one RAG context. Files added are indexed; files removed are de-indexed. There's no "build context" step.
  • Indexing is asynchronous. A small file finishes within seconds. Multi-MB PDFs / decks can take a minute or more. You see an Indexing badge on the file row while it's in progress.
  • Indexing respects the workspace's embedding type. Workspaces that index multimodal content (PDFs with images, screenshots) use the multimodal embedding model; text-only workspaces use the text embedding. Cannot mix types within a single workspace context — a database constraint enforces this. See the Dual Embedding System reference.

Adding a file​

In the workspace, open the Files tab and drag-drop a file (or click Upload). Supported types: CSV, Excel, JSON, Parquet, PDF, plain text, Markdown, common image formats.

Removing a file​

Click the file row and choose Remove. The file is deleted from storage and de-indexed; existing conversations that referenced it still show their captured answers, but new queries no longer surface its content.

Storage backends​

Workspace files are stored on the backend your admin configured per workspace at creation time:

  • Local — on the application server's disk. Cheapest, no extra config.
  • S3 / GCS — durable, cross-region, billable. Best for shared production workspaces.

You don't see the difference as a user; it only matters at admin / cost level.

Memory: shared vs. personal​

QRY has a unified memory tool the AI uses to remember facts across conversations. Memory entries have a scope:

  • Personal — visible only to you, across all your conversations (in any workspace or none).
  • Workspace — visible to every member of the workspace.

A memory entry is either personal or workspace-scoped, never both. The database constraint is XOR, which keeps the boundary explicit and prevents accidental data leaks.

What gets written to workspace memory​

The AI writes to workspace memory when something is clearly a team-level fact:

"Our fiscal year ends June 30."

"The customers_v2 table replaces customers from 2026-Q2 onwards — always use customers_v2."

"Internal naming convention: dim_* for dimensions, fct_* for facts."

What stays personal​

Personal preferences, scratch facts, conversation-specific reminders:

"Sergio prefers concise answers, no exhaustive caveats."

"When I say 'the dashboard', I mean the Customers Analytics one."

Reading and writing manually​

The Memory page (≡ → Settings → Memory) lets you see, edit, or delete entries directly. Workspace memory entries are visible to every workspace member with edit rights.

Limits​

  • 100 KB per memory entry. Memory is for facts, not for storing whole documents — that's what files are for.
  • Workspace files share the workspace's quota. Per-workspace storage limits depend on your tenant plan; admins can override.

Common issues​

A file uploaded an hour ago still shows Indexing. Indexing failed silently and the badge is stuck. Re-uploading usually fixes it. If not, an admin can check the embedding worker logs.

Workspace memory wasn't recalled in a conversation. The conversation isn't in the workspace. Workspace memory is only readable from conversations bound to the workspace. See Moving conversations to bring it in.

Memory entry scope was wrong. Open the Memory page, click the entry, and switch the scope. Existing conversations that recalled it under the old scope have their answers cached, so you may need to re-ask for the new scope to apply.

The same file is uploaded by two members but only one copy appears. Workspace files are deduped by content hash. Both members can see it; "ownership" is the first uploader.

See also​

QRYA product of IXEN.