Skip to main content
A few common shapes multi-tenancy takes in practice, combining namespaces for isolation with metadata filters for organization within a boundary.

Personal agent

A single namespace per user is enough — there’s no shared data to leak, so metadata is optional.

Company agent (shared + personal memory)

A company-wide assistant usually needs two kinds of namespaces: one shared namespace the whole org reads from, and one personal namespace per employee that nobody else can see.
Inside the shared namespace, use metadata to scope queries to a team rather than creating a namespace per team:
An employee’s agent typically queries both namespaces — their personal one plus the shared one — and merges the results, since a request is scoped to exactly one namespace.

Email assistant

One namespace per user, with metadata carrying email-specific properties like label, sender, or folder — so the assistant can answer things like “find the Spotify email tagged Promotional”.

Multi-tenant support platform

Each customer gets their own namespace, and metadata tracks ticket-level fields like status and priority — so “open, high-priority tickets” is a filter, not a new namespace, and it can never accidentally include another customer’s tickets.

Next steps

Multi-tenancy Overview

Why namespaces and metadata are separate mechanisms.

Namespaces

How isolation works, naming rules, and access control.

Organizing & Filtering

Metadata filter operators, combining and/or, and query limits.