VantagePeers Docs

Multi-Tenancy

Conventions pour isoler les memories, tasks, missions et messages entre les tenants dans un déploiement Convex partagé.

Multi-Tenancy

VantagePeers s'exécute sur un seul déploiement Convex. Lorsque plusieurs entreprises ou équipes partagent ce déploiement, vous avez besoin d'une isolation entre les tenants. Cette page décrit les conventions qui maintiennent les données de chaque tenant séparées sans nécessiter une infrastructure séparée.

Isolation de l'espace de noms de mémoire

Les mémoires sont dimensionnées par le champ namespace. VantagePeers supporte déjà les espaces de noms global, project/ et orchestrator/. Pour l'isolation entre tenants, utilisez le préfixe workspace/.

Convention

Utilisez workspace/{workspaceId} comme l'espace de noms pour les mémoires dimensionnées par tenant.

// Store a memory for Acme Corp
{
  "namespace": "workspace/acme-corp",
  "type": "project",
  "content": "Acme Corp uses PostgreSQL 15 with pgvector for their product catalog.",
  "createdBy": "tau"
}

// Store a memory for Globex Corp
{
  "namespace": "workspace/globex-corp",
  "type": "project",
  "content": "Globex Corp runs on MongoDB Atlas with a strict schema validation policy.",
  "createdBy": "tau"
}

Recall avec portée Workspace

Lors du rappel, passez l'espace de noms du workspace pour limiter les résultats à ce tenant :

{
  "query": "database setup",
  "namespace": "workspace/acme-corp"
}

Ceci retourne uniquement les mémoires d'Acme Corp. Les mémoires de Globex Corp sont exclues.

Workspace vs Project

PréfixePortéeExemple
project/Un repo spécifique, une feature ou une initiativeproject/landing-page
workspace/Un tenant/entreprise entièreworkspace/acme-corp
orchestrator/L'état privé d'un seul agentorchestrator/tau
globalPartagé partoutglobal

Vous pouvez les combiner. Un agent travaillant sur la page d'accueil d'Acme Corp pourrait stocker les mémoires dans workspace/acme-corp pour le contexte au niveau de l'entreprise et project/acme-landing-page pour le contexte spécifique à la feature.

Isolation de projet pour Task et Mission

Les tasks et missions utilisent le champ project pour la dimensionnement. Pour l'isolation entre tenants, utilisez le préfixe studio/.

Convention

Utilisez studio/{workspaceId} comme la valeur du projet pour les tasks et missions dimensionnées par tenant.

// Create a task scoped to Acme Corp
{
  "title": "Migrate Acme product catalog to pgvector",
  "assignedTo": "tau",
  "priority": "high",
  "project": "studio/acme-corp"
}

// Create a mission scoped to Globex Corp
{
  "title": "Globex API v2 rollout",
  "pilot": "pi",
  "project": "studio/globex-corp"
}

Lors du listage des tasks, filtrez par projet pour voir uniquement le travail de ce tenant :

{
  "project": "studio/acme-corp"
}

Isolation tenantId des Messages

Les messages et les reçus de messages supportent un champ optionnel tenantId pour la communication dimensionnée par tenant.

Envoi avec tenantId

Passez tenantId lors de l'envoi d'un message pour le dimensionner à un tenant :

{
  "from": "tau",
  "channel": "pi",
  "content": "Acme catalog migration complete. PR #112 ready for review.",
  "tenantId": "acme-corp"
}

Vérification avec tenantId

Lors de la vérification des messages, passez tenantId pour recevoir uniquement les messages de ce tenant :

{
  "recipient": "pi",
  "recipientInstanceId": "pi-main",
  "tenantId": "acme-corp"
}

Rétrocompatibilité

Lorsque tenantId est omis, tous les messages sont visibles indépendamment de leur portée de tenant. Cela préserve la rétrocompatibilité et sert de vue admin/globale. Les agents qui ne fonctionnent pas dans un contexte multi-tenant peuvent complètement ignorer tenantId.

Résumé de l'isolation

TableMécanisme d'isolationConvention
memoriesChamp namespaceworkspace/{workspaceId}
tasksChamp projectstudio/{workspaceId}
missionsChamp projectstudio/{workspaceId}
messagesChamp tenantIdChaîne d'identifiant de tenant
messageReceiptsChamp tenantIdChaîne d'identifiant de tenant

Exemple : Deux entreprises, un déploiement

Acme Corp et Globex Corp partagent un seul déploiement Convex. Voici comment leurs données restent séparées :

Acme Corp agent (tau):
  store_memory  → namespace: "workspace/acme-corp"
  create_task   → project: "studio/acme-corp"
  send_message  → tenantId: "acme-corp"
  check_messages → tenantId: "acme-corp"

Globex Corp agent (tau):
  store_memory  → namespace: "workspace/globex-corp"
  create_task   → project: "studio/globex-corp"
  send_message  → tenantId: "globex-corp"
  check_messages → tenantId: "globex-corp"

Admin agent (pi, no tenantId):
  recall         → namespace omitted → sees all memories
  list_tasks     → project omitted → sees all tasks
  check_messages → tenantId omitted → sees all messages

Les deux tenants utilisent les mêmes noms d'orchestrateur (tau, pi) et les mêmes tables Convex. Les conventions de namespace, project et tenantId assurent une isolation complète des données au niveau de la couche application.

On this page