Dos almacenamientos, una columna vertebral, una superficie contractual.

La plataforma está construida sobre una arquitectura de almacenamiento dual que usted, como operador, no tiene que gestionar directamente. Un almacenamiento en grafo maneja el descubrimiento y la causalidad entre conversaciones. Un almacenamiento Postgres maneja los pivotes, los agregados y las series de tiempo. Los dos almacenamientos están unidos en un identificador de chunk inmutable que vincula cada hecho al momento exacto de la entrevista exacta que lo produjo. Una superficie de herramientas MCP se sitúa encima de ambos y presenta un conjunto reducido y preciso de consultas a cada consumidor. Una columna vertebral, tres puntos de acceso.

Esta página describe la forma operacional del sistema. Cubre el uso de cada almacenamiento, la razón de su coexistencia, el funcionamiento de la columna vertebral de identificadores de chunk y el aspecto de la superficie MCP desde el lado del agente. La referencia de ingeniería detallada (esquema, particionamiento, modelo de embedding, JSONSchemas MCP exactos) se encuentra en la referencia de ingeniería, . Ese es el documento que leen sus ingenieros de plataforma. Esta página es para usted.

[ 01 ]  ·  NAMED: POR QUÉ DOS ALMACENAMIENTOS

El descubrimiento y la agregación son consultas distintas.

Las preguntas de descubrimiento tienen forma de grafo. «¿Por qué aumenta la tasa de rechazo de la base de maquillaje en clientes menores de 25 años?» requiere un recorrido a través de aristas de sustitución, relaciones de causalidad y menciones de competidores, para identificar el evento anterior que los conecta. Un índice vectorial plano no puede hacer eso. Las cadenas de causalidad entre conversaciones son objetos de grafo de primera clase. La recuperación por K vecinos más próximos los encuentra solo por coincidencia.

Las preguntas de agregación son tabulares. «¿Cuántos hechos de percepción de marca se volvieron negativos esta semana, por tienda, por región, por nivel?» es un GROUP BY de Postgres, no un recorrido de grafo. Intentar que un solo almacenamiento responda ambos tipos de preguntas es lo que hace colapsar a la mayoría de los productos de conocimiento a escala. La plataforma los separa y los une en el identificador de chunk.

Para la implementación del grafo, la plataforma utiliza Apache AGE sobre Postgres, con el modelo bi-temporal basado en las convenciones de Zep y mem0. Para el almacenamiento de hechos, la misma instancia de Postgres contiene las tablas de filas, con pgvector para los embeddings. Una sola base de datos, dos patrones de consulta, unidos en el identificador de chunk.

Dos formas de consulta. Una columna vertebral. Una superficie contractual.

[ 02 ]  ·  NAMED: LA COLUMNA VERTEBRAL DE IDENTIFICADORES DE CHUNK

Cada hecho es a la vez un nodo de grafo y una fila SQL.

Cada chunk de cada entrevista recibe un identificador inmutable de la forma transcript_id / turn_id / sentence_id. Ese identificador es la columna vertebral. Cada hecho de enriquecimiento lo referencia. Cada fila en el almacenamiento de hechos de Postgres lo referencia. Cada nodo en el grafo lo referencia. Cuando una celda del tablero pregunta «¿cuál es la fuente de este número?», la respuesta es uno o más identificadores de chunk. La cita es estructural.

Un socio de marca pregunta «¿por qué afirman que mi producto pierde frente al sustituto X?». La respuesta son tres identificadores de chunk, tres declaraciones de asesores, tres marcas de tiempo, en tres almacenamientos nombrados. La capa de presentación los formatea. El sustrato los garantiza. La cadena de procedencia se describe en detalle en la cadena de procedencia textual.

[ 03 ]  ·  NAMED: LA SUPERFICIE CONTRACTUAL MCP

El conjunto reducido y preciso de herramientas que utiliza cada consumidor.

La superficie MCP es el contrato entre el corpus y cada consumidor: tableros, APIs de socios de marca, agentes de IA. Las herramientas son deliberadamente pocas. query_facts retorna filas estructuradas filtradas por dimensión, segmento y ventana temporal. traverse_relations recorre el grafo para cadenas de causalidad y sustitución. pivot_dimension agrega sobre un eje de segmento. replay_as_of ejecuta cualquier consulta contra el corpus tal como existía en una fecha pasada. cite resuelve un identificador de chunk en su verbatim de origen.

Cada llamada pasa por la misma verificación de alcance. El ticket de sesión del llamante lleva un alcance; ese alcance filtra qué herramientas se resuelven, qué nodos del grafo son transitables, qué filas de Postgres son legibles y qué chunks se resuelven al citar. Una clave de socio puede llamar a cite; los chunks que recibe de vuelta están dentro de su porción. No tiene ningún camino hacia nada que esté fuera. La cascada de seguridad completa se encuentra en Confianza y seguridad.

Los JSONSchemas exactos de cada herramienta se encuentran en la referencia de ingeniería, para los ingenieros que conectan un agente a la plataforma. Desde la consola de operador, puede ver qué agentes están conectados, qué alcance tienen y qué consultaron esta semana.

[ 04 ]  ·  NAMED: EN SU CLOUD, BAJO SU CONTROL

La plataforma se ejecuta donde usted decidió que se ejecutaría.

El sustrato por defecto es Cloudflare, dentro de su propia cuenta de Cloudflare. El Cloud Harness instala la plataforma allí. AWS, Azure y en sitio siguen la misma forma sobre un sustrato diferente. Los dos almacenamientos viven en su cuenta. El cómputo que ejecuta el agente de entrevista vive en su cuenta. Los workers de enriquecimiento, el servidor MCP y la consola de operador se ejecutan todos dentro de su tenant. Los datos no salen de su perímetro para ser procesados.

El contrato LLM con Anthropic y el contrato de voz con ElevenLabs son las dos llamadas a la frontera. Ambos se ejecutan bajo acuerdos de no retención (sin entrenamiento en todos los planes LLM, sin retención en Enterprise; sin retención en todos los planes de voz). La descripción completa de esos contratos y del manejo de datos en la frontera se encuentra en el hub de Confianza.

[ 05 ]  ·  NAMED: LO QUE CAMBIA A ESCALA

100 conversaciones y 50 000 conversaciones sobre la misma arquitectura.

Con 100 entrevistas (un piloto de nivel Pulse), el grafo es disperso, las consultas delimitadas por segmento son útiles en dirección pero no estadísticamente significativas, y el almacenamiento de hechos contiene unos pocos miles de filas. El tablero funciona. La superficie de repetición funciona. El modelo bi-temporal lleva esencialmente learned_at; la decaída aún no ha comenzado.

Con 2 000 entrevistas, el grafo se densifica, las aristas de sustitución y causalidad forman cadenas de tres o cuatro saltos con peso de evidencia real, el almacenamiento de hechos contiene alrededor de 200 000 filas, y las consultas delimitadas por segmento se vuelven estadísticamente significativas. Las primeras 500 conversaciones salen del estado «reciente». La economía de la actualización comienza a importar. La API de socios de marca vale la pena cobrar a nivel de una sola región.

Con 50 000 entrevistas en actualización semanal, el corpus soporta los despliegues más grandes en cualquier vertical. La comparación entre mercados es en tiempo real y estadísticamente significativa por mercado. La validez por segmento es lo que hace manejables cientos de tenants de socios de marca sobre un solo corpus. La arquitectura fue diseñada para este caso desde el despliegue de 100 conversaciones. El almacenamiento no se reconstruye a medida que crece el corpus.