> ## Documentation Index
> Fetch the complete documentation index at: https://strattumai.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Memory — Enterprise Knowledge Graph
> Tudo que se sabe sobre uma entidade, em um único lugar. O grafo de contexto que transforma agentes genéricos em especialistas no seu negócio.
O **Memory** armazena e consolida tudo que se sabe sobre uma entidade — cliente, empresa, associado, projeto — em um único perfil conectado. Resolve a fragmentação de identidade ao combinar dados de CRM, ERP, tickets, contratos, WhatsApp e email em uma visão unificada, acessível por qualquer agente.
Memory é o produto de entrada mais natural para novos clientes. A dor de não ter visão unificada do cliente é universal — todo gestor entende o problema em 30 segundos.
***
## Por que Memory existe
Agentes de AI sem memória tomam decisões no escuro. O problema não é o modelo de linguagem — é o contexto que o agente recebe.
Sem Memory:
* O agente "esquece" o que foi acordado na última interação
* Cada atendimento começa do zero, sem histórico
* Dados sobre o mesmo cliente estão espalhados em 3, 4, 5 sistemas
* O analista passa 30–45 minutos montando contexto manualmente antes de cada interação
Com Memory:
* O agente conhece profundamente cada entidade antes de qualquer decisão
* Contexto completo: histórico de interações, contratos, transações, alertas
* Dados de múltiplas fontes consolidados em um único perfil
* Zero alucinação sobre fatos da entidade — o contexto é factual
***
## Como funciona: Entity Resolution + Grafo
A Memory é sustentada por dois componentes:
### 1. Entity Resolution (ER)
Descobre que "M. Silva" na tabela de leads, "Maria Silva ([mari@emp.com](mailto:mari@emp.com))" no CRM e o `+552199990000` no WhatsApp são a mesma pessoa.
* **Matching determinístico:** CPF, CNPJ, email normalizado, telefone padronizado. Resolve 60–80% dos casos.
* **Matching probabilístico:** Comparação fuzzy de nome (Jaro-Winkler), endereço (TF-IDF) e razão social para os restantes.
* **Bypass via `external_id`:** Se sua empresa já tem um ID unificado nos sistemas, a Memory usa essa chave diretamente e pula o ER — onboarding mais rápido.
### 2. Grafo de Entidades (FalkorDB)
Após a resolução de identidade, os perfis são armazenados como **grafo** no FalkorDB:
* **Nós:** Entidades (cliente, empresa, contrato, produto)
* **Arestas:** Relacionamentos (Maria `TRABALHA_NA` TechCorp, TechCorp `TEM_CONTRATO` Growth)
* **Timeline:** Eventos conectados à entidade (tickets, interações, transações, reuniões) em ordem cronológica
***
## GraphRAG — Contexto expandido por relações
O diferencial da Memory não é saber tudo sobre **uma** entidade — é saber tudo sobre o **ecossistema** dessa entidade.
**Sem GraphRAG (lookup simples):**
> "Maria Silva, plano Growth, 3 tickets nos últimos 30 dias."
**Com GraphRAG (traversal de relacionamentos):**
> "Maria Silva, CTO da TechCorp (12 funcionários na plataforma). TechCorp tem 3 contratos ativos. Nos últimos 30 dias: Maria abriu 3 tickets, colegas dela abriram 7 — 4 sobre o mesmo módulo. A empresa está no Q4 de renovação."
A profundidade de expansão é configurável por request:
| Profundidade | Contexto retornado | Latência típica |
| ------------------- | ------------------------------------------- | --------------- |
| `none` (0 hop) | Apenas perfil + timeline | 10–20ms |
| `immediate` (1 hop) | Entidade + vizinhos diretos | 50–150ms |
| `extended` (2 hops) | Entidade + vizinhos + vizinhos dos vizinhos | 200–500ms |
***
## Como os dados chegam ao grafo
```
Fonte de dados (CRM, ERP, Tickets)
↓
Data Pipelines (ingestão via dlt + Prefect)
↓
Data Catalog — camada clean/
↓
Memory Worker (Entity Resolution)
↓
FalkorDB — grafo de entidades
↓
Memory API → MCP Server, Skills, Console UI
```
O Memory Worker executa em ciclos configuráveis (padrão: a cada 5 minutos), lê as tabelas normalizadas da camada `clean/` do Catalog e atualiza os nós e arestas no FalkorDB.
***
## Como explorar o grafo no Console
Acesse **Memory** no menu lateral para visualizar e explorar as entidades:
Em **Memory → Entities**, veja todas as entidades consolidadas com status de completude do perfil.
Clique em qualquer entidade para ver o perfil completo: atributos consolidados de todas as fontes, timeline de eventos e rede de relacionamentos.
Use o **Graph Explorer** para navegar pelas relações entre entidades — quais empresas estão conectadas, quais contratos pertencem a quais clientes.
Em **Memory → Review Queue**, aprove, edite ou rejeite entidades extraídas com confiança abaixo do threshold configurado.
***
## Formas de consumo
| Canal | Caso de uso |
| ------------------ | --------------------------------------------------------------------------------------------------------------------- |
| **Skills** | Automações e relatórios — uma Skill consulta a Memory para consolidar o perfil da entidade e gerar saídas recorrentes |
| **API Standalone** | Customer 360, dashboards — sistemas do cliente batem diretamente no `GET /v1/memory/entity/{id}/context` |
| **MCP Server** | Microsoft Copilot, Claude Code, Cursor — perguntas em linguagem natural sobre qualquer entidade |
***
## Templates de contexto
O contexto entregue ao agente é formatado via templates Jinja2 configuráveis por tipo de entidade e caso de uso, versionados no Workspace Git:
* **Template de vendas:** MRR, contratos ativos, data de renovação, pipeline aberto
* **Template de suporte:** Tickets recentes, SLA, histórico de incidentes, sentimento
* **Template financeiro:** Inadimplência, transações, limites de crédito
Isso evita enviar contexto desnecessário ao LLM, controlando custos de tokens.
***
## Capacidades enterprise
Além da resolução de identidade e do grafo, o Memory carrega propriedades que sustentam o uso em produção:
| Capacidade | O que entrega |
| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Ontology-first** | Você modela as entidades do negócio — Cliente, Contrato, Produto, Ticket — antes de conectar fontes. O grafo segue esse modelo, não o schema bruto de cada sistema. |
| **Atualização contínua** | O Memory Worker processa mudanças das fontes em ciclos curtos, sem depender de batch noturno. O grafo reflete o estado recente da operação. |
| **Cypher + MCP** | Analistas rodam queries em Cypher direto no grafo; agentes consomem as mesmas entidades via MCP Tools tipadas. |
| **Permission-aware** | Cada consulta respeita as ACLs do sistema-fonte. Quem não tem acesso a um dado na origem também não o vê no Memory. |
| **Lineage por entidade** | Cada atributo consolidado carrega de qual fonte veio e quando foi atualizado pela última vez. |
| **BYOC + LGPD** | Roda na nuvem do cliente. Anonimização, direito ao esquecimento e DPA disponíveis desde o Day 1. |
***
## Casos de uso validados
Analistas de crédito consultam 4 sistemas separados para montar o contexto de uma renegociação. Com Memory, o perfil consolidado (contratos + pagamentos + interações + alertas) está disponível antes de o agente atender.
Quando um CS assume uma conta, leva 1–2 semanas para entender o histórico. Com Memory, o perfil vivo da conta (reuniões passadas, NPS, compromissos assumidos, renovações) está acessível no primeiro dia.
Gerentes de agência montam defesas de crédito para aprovação na sede. Com Memory consolidando o histórico completo do associado, uma Skill monta automaticamente o checklist da defesa.
O cliente com múltiplos produtos existe em sistemas que não se comunicam. Memory cria uma camada de contexto unificado sobre todos os sistemas — cada ponto de atendimento acessa o relacionamento completo.
***
## Próximos passos
Defina quais tipos de entidades e atributos o Memory deve rastrear.
Revise e aprove entidades extraídas automaticamente pelo pipeline de NER.
Consulte entidades programaticamente via API REST.
Exponha a Memory para agentes externos via Model Context Protocol.