Memory for a multi-tenant SaaS agent

Map each application concept to one durable boundary. The Aether API key identifies a tenant. An optional partition can divide work inside that tenant, and a Memory handle carries an entity ID. A common mapping uses a partition for a customer workspace and an entity for a user, project, or agent within it, but the correct shape depends on who shares context and who must never see it.

Keep the mapping explicit in code and design documentation. If a user belongs to two workspaces, the same human may need distinct memory scopes because the surrounding business context and permissions differ. Stable opaque identifiers are safer than email addresses or display names, which can change and may expose personal information in logs.

A scoped memory request is not proof that the caller was entitled to make it. Resolve the authenticated user, organization membership, role, and permitted project before constructing the partition or entity identifier. Browser input can describe the requested resource, but a trusted server should derive the final Aether scope from verified application state.

Test negative paths as first-class product behavior. A user removed from a workspace should lose the ability to recall its memory immediately, even if retained data follows a separate deletion schedule. A guessed entity ID, a stale session, or a support impersonation flow should all exercise deliberate authorization rules rather than reaching the memory API with ambient credentials.

Tenant systems change. Users leave, projects move, workspaces merge, and customers request exports or deletion. Decide whether memory follows the person, remains with the workspace, or is copied only after an explicit workflow. Avoid changing a scope identifier in place without a migration plan, because the old and new identities can otherwise create partial histories.

Keep enough application metadata to locate the relevant memory scope during offboarding, but do not rely on a display label as the only index. Document what deletion means for source documents and derived indexes, how retries are handled, and how completion is verified. If legal or contractual retention controls apply, they belong in the product’s broader data-governance design.

Estimate documents, stored vectors, monthly queries, storage, and named partitions from a representative tenant rather than a best-case demo. The Aether pricing page publishes those units for each plan and lists overage rates where they exist. Enterprise quantities are contract-specific. Keep the estimate tied to the same plan data the product uses so marketing copy and the purchasing decision do not drift.

Use two or more representative workspaces in automated tests. Store similar facts in each, recall them through the application’s real authentication path, and confirm the results never cross. Add membership changes, deleted users, partition limits, retries, and empty histories. A direct SDK test is useful, but an end-to-end test through the product boundary is what verifies the scope mapping users actually depend on.