Deux stockages, une colonne vertébrale, une surface contractuelle.

La plateforme est construite autour d'une architecture à double stockage que vous, en tant qu'opérateur, n'avez pas à gérer directement. Un stockage graphe gère la découverte et la causalité entre conversations. Un stockage Postgres gère les pivots, les agrégats et les séries temporelles. Les deux stockages sont joints sur un identifiant de chunk immuable qui relie chaque fait au moment exact dans l'entrevue exacte qui l'a produit. Une surface d'outils MCP se pose au-dessus des deux et présente un ensemble restreint et précis de requêtes à chaque consommateur. Une colonne vertébrale, trois points de terminaison.

Cette page décrit la forme opérationnelle du système. Elle couvre l'usage de chaque stockage, la raison de leur coexistence, le fonctionnement de la colonne vertébrale des identifiants de chunk et l'apparence de la surface MCP du côté de l'agent. La référence d'ingénierie approfondie (schéma, partitionnement, modèle d'embedding, JSONSchemas MCP exacts) se trouve dans la référence d'ingénierie, disponible sur demande. C'est le document que lisent vos ingénieurs plateforme. Cette page est pour vous.

Les questions de découverte ont une forme de graphe. « Pourquoi le taux de rejet de fond de teint augmente-t-il pour les clients de moins de 25 ans ? » demande une traversée à travers des arêtes de substitution, des relations de causalité et des mentions de concurrents, faisant remonter l'événement en amont qui les relie. Un index vectoriel plat ne peut pas faire cela. Les chaînes de causalité entre conversations sont des objets graphes de première classe. La récupération par K plus proches voisins ne les fait remonter que par coïncidence.

Les questions d'agrégation sont tabulaires. « Combien de faits de perception de marque sont devenus négatifs cette semaine, par magasin, par région, par niveau ? » est un GROUP BY Postgres, pas une traversée de graphe. Essayer de faire répondre un seul stockage aux deux types de questions, c'est ce qui fait s'effondrer la plupart des produits de connaissance à grande échelle. La plateforme les sépare et les joint sur l'identifiant de chunk.

Pour l'implémentation graphe, la plateforme utilise Apache AGE sur Postgres, avec le modèle bitemporel basé sur les conventions Zep et mem0. Pour le stockage de faits, la même instance Postgres contient les tables de lignes, avec pgvector pour les embeddings. Une seule base de données, deux modèles de requêtes, joints sur l'identifiant de chunk.

Chaque chunk de chaque entrevue reçoit un identifiant immuable de la forme transcript_id / turn_id / sentence_id. Cet identifiant est la colonne vertébrale. Chaque fait d'enrichissement y fait référence. Chaque ligne dans le stockage de faits Postgres y fait référence. Chaque nœud dans le graphe y fait référence. Lorsqu'une cellule de tableau de bord demande « quelle est la source de ce nombre », la réponse est un ou plusieurs identifiants de chunk. La citation est structurelle.

Un partenaire de marque demande « pourquoi affirmez-vous que mon produit perd face au substitut X ». La réponse est trois identifiants de chunk, trois énoncés de conseillers, trois horodatages, dans trois stockages nommés. La couche d'affichage la formate. Le substrat la garantit. La chaîne de provenance est décrite en détail sous la chaîne de provenance verbatim.

La surface MCP est le contrat entre le corpus et chaque consommateur : tableaux de bord, API de partenaires de marque, agents IA. Les outils sont délibérément peu nombreux. query_facts retourne des lignes structurées filtrées par dimension, segment et fenêtre temporelle. traverse_relations parcourt le graphe pour les chaînes de causalité et de substitution. pivot_dimension agrège sur un axe de segment. replay_as_of exécute n'importe quelle requête contre le corpus tel qu'il existait à une date passée. cite résout un identifiant de chunk en son verbatim source.

Chaque appel passe par la même vérification de périmètre. Le ticket de session de l'appelant porte un périmètre ; ce périmètre filtre quels outils se résolvent, quels nœuds du graphe sont traversables, quelles lignes Postgres sont lisibles et quels chunks se résolvent lors d'une citation. Une clé partenaire peut appeler cite ; les chunks qu'elle obtient en retour sont dans sa tranche. Elle n'a aucun chemin vers quoi que ce soit en dehors. La cascade de sécurité complète se trouve sous Confiance et sécurité.

Les JSONSchemas exacts pour chaque outil se trouvent dans la référence d'ingénierie, disponible sur demande pour les ingénieurs qui connectent un agent à la plateforme. Depuis la console opérateur, vous voyez quels agents sont connectés, quel périmètre ils détiennent et ce qu'ils ont interrogé cette semaine.

Le substrat par défaut est Cloudflare, dans votre propre compte Cloudflare. Le Cloud Harness y installe la plateforme. AWS, Azure et sur site suivent la même forme sur un substrat différent. Les deux stockages vivent dans votre compte. Le calcul qui fait fonctionner l'agent d'entrevue vit dans votre compte. Les workers d'enrichissement, le serveur MCP et la console opérateur s'exécutent tous à l'intérieur de votre tenant. Les données ne quittent pas votre périmètre pour être traitées.

Le contrat LLM avec Anthropic et le contrat vocal avec ElevenLabs sont les deux appels aux frontières. Les deux s'exécutent sous des accords de non-rétention (pas d'entraînement sur tous les plans LLM, pas de rétention sur Enterprise ; pas de rétention sur tous les plans vocaux). La description complète de ces contrats et du traitement des données à la frontière se trouve sur le hub Confiance.

À 100 entrevues (un pilote de niveau Pulse), le graphe est peu dense, les requêtes délimitées par segment sont directionnellement utiles mais pas statistiquement significatives, et le stockage de faits contient quelques milliers de lignes. Le tableau de bord fonctionne. La surface de rejeu fonctionne. Le modèle bitemporel porte essentiellement learned_at ; la décroissance n'a pas encore commencé.

À 2 000 entrevues, le graphe se densifie, les arêtes de substitution et de causalité forment des chaînes de trois ou quatre sauts avec un poids de preuve réel, le stockage de faits contient environ 200 000 lignes, et les requêtes délimitées par segment deviennent statistiquement significatives. Les 500 premières conversations sortent du statut « récent ». L'économie du rafraîchissement commence à compter. L'API de partenaires de marque vaut la peine d'être facturée à portée d'une seule région.

À 50 000 entrevues sur rafraîchissement hebdomadaire, le corpus soutient les déploiements les plus importants dans n'importe quel vertical. La comparaison entre marchés est en temps réel et statistiquement significative par marché. La validité par segment est ce qui rend tractables des centaines de tenants de partenaires de marque sur un seul corpus. L'architecture a été conçue pour ce cas dès le déploiement à 100 conversations. Le stockage n'est pas reconstruit à mesure que le corpus croît.