Dois armazenamentos, uma espinha, uma superfície contratual.

A plataforma é construída em torno de uma arquitetura de armazenamento duplo que você, como operador, não precisa gerenciar diretamente. Um armazenamento em grafo lida com descoberta e causalidade entre conversas. Um armazenamento Postgres lida com pivôs, agregações e séries temporais. Os dois armazenamentos são unidos por um identificador de chunk imutável que liga cada fato ao momento exato na entrevista exata que o produziu. Uma superfície de ferramentas MCP fica sobre os dois e apresenta um conjunto pequeno e preciso de consultas a cada consumidor. Uma espinha, três pontos de acesso.

Esta página descreve a forma operacional do sistema. Ela cobre para que serve cada armazenamento, por que ambos existem, como a espinha de chunk-ID funciona e como a superfície MCP se apresenta do lado do agente. A referência de engenharia detalhada (esquema, particionamento, modelo de embedding, JSONSchemas MCP exatos) está na referência de engenharia, disponível sob solicitação. Esse é o documento que seus engenheiros de plataforma leem. Esta página é para você.

Perguntas de descoberta têm forma de grafo. "Por que a taxa de rejeição de base aumenta para clientes com menos de 25 anos?" requer uma travessia por arestas de substituição, relações de causalidade e menções de concorrentes, identificando o evento upstream que os conecta. Um índice vetorial plano não consegue fazer isso. Cadeias de causalidade entre conversas são objetos de grafo de primeira classe. A recuperação por K-vizinhos-mais-próximos os encontra apenas por coincidência.

Perguntas de agregação são tabulares. "Quantos fatos de percepção de marca se tornaram negativos esta semana, por loja, por região, por nível?" é um GROUP BY no Postgres, não uma travessia de grafo. Tentar fazer um único armazenamento responder aos dois tipos de perguntas é o que faz a maioria dos produtos de conhecimento entrar em colapso em escala. A plataforma os separa e os une pelo identificador de chunk.

Para a implementação em grafo, a plataforma usa Apache AGE no Postgres, com o modelo bi-temporal baseado nas convenções Zep e mem0. Para o armazenamento de fatos, a mesma instância Postgres contém as tabelas de linhas, com pgvector para embeddings. Um banco de dados, dois padrões de consulta, unidos pelo chunk-ID.

Cada chunk de cada entrevista recebe um identificador imutável da forma transcript_id / turn_id / sentence_id. Esse identificador é a espinha. Cada fato de enriquecimento o referencia. Cada linha no armazenamento de fatos Postgres o referencia. Cada nó no grafo o referencia. Quando uma célula do painel pergunta "qual é a fonte desse número", a resposta é um ou mais chunk-IDs. A citação é estrutural.

Um parceiro de marca pergunta "por que você afirma que meu produto perde para o substituto X". A resposta são três chunk-IDs, três enunciados de consultores, três carimbos de data/hora, em três armazenamentos nomeados. A camada de exibição formata. O substrato garante. A cadeia de proveniência é descrita em detalhe em a Cadeia de Proveniência Literal.

A superfície MCP é o contrato entre o corpus e cada consumidor: painéis, APIs de parceiros de marca, agentes de IA. As ferramentas são deliberadamente poucas. query_facts retorna linhas estruturadas filtradas por dimensão, segmento e janela temporal. traverse_relations percorre o grafo em busca de cadeias de causalidade e substituição. pivot_dimension agrega sobre um eixo de segmento. replay_as_of executa qualquer consulta contra o corpus como estava em uma data passada. cite resolve um chunk-ID no seu verbatim de origem.

Cada chamada passa pela mesma verificação de escopo. O ticket de sessão do chamador carrega um escopo; esse escopo filtra quais ferramentas se resolvem, quais nós do grafo são percorríveis, quais linhas Postgres são legíveis e quais chunks se resolvem quando citados. Uma chave de parceiro pode chamar cite; os chunks que ela recebe de volta estão dentro de sua fatia. Ela não tem caminho para nada fora. A cascata de segurança completa está em Confiança e Segurança.

Os JSONSchemas exatos para cada ferramenta estão na referência de engenharia, disponível sob solicitação para os engenheiros que conectam um agente à plataforma. No console do operador, você vê quais agentes estão conectados, qual escopo eles têm e o que consultaram esta semana.

O substrato padrão é Cloudflare, dentro da sua própria conta Cloudflare. O Cloud Harness instala a plataforma lá. AWS, Azure e on-premise seguem a mesma forma em um substrato diferente. Os dois armazenamentos ficam na sua conta. A computação que roda o agente de entrevista fica na sua conta. Os workers de enriquecimento, o servidor MCP e o console do operador rodam todos dentro do seu tenant. Os dados não saem do seu perímetro para serem processados.

O contrato LLM com Anthropic e o contrato de voz com ElevenLabs são as duas chamadas de fronteira. Ambos rodam sob acordos de não-retenção (sem treinamento em todos os planos LLM, sem retenção no Enterprise; sem retenção em todos os planos de voz). A descrição completa desses contratos e do tratamento de dados na fronteira está em o hub de Confiança.

Em 100 entrevistas (um piloto de nível Pulse), o grafo é esparso, as consultas com escopo por segmento são úteis em termos de direção mas não estatisticamente significativas, e o armazenamento de fatos contém alguns milhares de linhas. O painel funciona. A superfície de replay funciona. O modelo bi-temporal carrega principalmente learned_at; o decaimento ainda não entrou em ação.

Em 2.000 entrevistas, o grafo se densifica, as arestas de substituição e causalidade formam cadeias de três ou quatro saltos com peso de evidência real, o armazenamento de fatos contém cerca de 200.000 linhas, e as consultas com escopo por segmento se tornam estatisticamente significativas. As primeiras 500 conversas saem do status recente. A economia de atualização começa a importar. A API para parceiros de marca vale a pena ser cobrada em escopo de região única.

Em 50.000 entrevistas com atualização semanal, o corpus suporta as maiores implantações em qualquer vertical. O benchmarking entre mercados é em tempo real e estatisticamente significativo por mercado. A validade por segmento é o que torna tratável ter centenas de tenants de parceiros de marca em um único corpus. A arquitetura foi construída para esse caso já na implantação de 100 conversas. O armazenamento não é reconstruído conforme o corpus cresce.