> ## Documentation Index > Fetch the complete documentation index at: https://docs.strattum.ai/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. ![Grafo de entidades do Memory conectando pessoa, empresa, contrato, ticket, produto e pagamento](https://mintcdn.com/strattumai/_Up8bxNlvkhKDeA-/images/illustrations/memory-graph.svg?fit=max\&auto=format\&n=_Up8bxNlvkhKDeA-\&q=85\&s=4ba0e9f8a51764f4ebb40f98e45f6859) No grafo, cada nó é uma entidade e cada aresta é uma relação. Um agente navega o contexto — da pessoa ao contrato, ao ticket, ao pagamento — como um humano faria. > [!NOTE] > > 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: **1. Visualize entidades** Em **Memory → Entities**, veja todas as entidades consolidadas com status de completude do perfil. **2. Inspecione um perfil** Clique em qualquer entidade para ver o perfil completo: atributos consolidados de todas as fontes, timeline de eventos e rede de relacionamentos. **3. Explore o grafo visual** Use o **Graph Explorer** para navegar pelas relações entre entidades — quais empresas estão conectadas, quais contratos pertencem a quais clientes. **4. Revise entidades na fila** 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 > **Fintech — Visão 360° para renegociação de crédito** > > 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. > **SaaS B2B — Customer Success sem perda de contexto** > > 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. > **Cooperativa de Crédito — Defesa de crédito automatizada** > > 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. > **Telecom — Atendimento omnichannel** > > 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 > **[Configurar ontologia](https://docs.strattum.ai/getting-started/configuration.md#passo-3--ontologia-do-memory)** > > Defina quais tipos de entidades e atributos o Memory deve rastrear. > **[NER Review](https://docs.strattum.ai/memory/ner-review.md)** > > Revise e aprove entidades extraídas automaticamente pelo pipeline de NER. > **[Memory API](https://docs.strattum.ai/api-reference/memory/introduction.md)** > > Consulte entidades programaticamente via API REST. > **[MCP Server](https://docs.strattum.ai/mcp-server/index.md)** > > Exponha a Memory para agentes externos via Model Context Protocol. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.