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

Personal agent

A single container tag 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 containers: one shared container the whole org reads from, and one personal container per employee that nobody else can see.
Inside the shared container, use metadata to scope queries to a team rather than creating a container tag per team:
An employee’s agent typically queries both containers — their personal one plus the shared one — and merges the results, since the container tag boundary is per-request rather than per-user.

Email assistant

One container tag 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 container tag, and metadata tracks ticket-level fields like status and priority — so “open, high-priority tickets” is a filter, not a new tag, and it can never accidentally include another customer’s tickets.

Next steps

Multi-tenancy Overview

Why container tags and metadata are separate mechanisms.

Container Tags

How isolation works, naming rules, and access control.

Organizing & Filtering

Metadata filter types, combining AND/OR, and query limits.