Hyper Company Brain: engenharia de uma base de conhecimento para agentes de IA

Quando você pede ao Claude Code para alterar código, ele não sabe por que sua equipe apagou aquele branch três meses atrás. Quando você pergunta ao ChatGPT sobre uma decisão de produto, ele precisa reler todos os documentos antes de responder. Reexplicar o histórico do projeto a cada chamada é uma das diferenças reais entre agentes e RAG comum: RAG é bom em recuperar documentos estáticos, mas conhecimento corporativo tem três dimensões que ele não trata de forma nativa: validade dos fatos, escopo de permissões e a cadeia de raciocínio por trás das decisões.

No Hacker News, a Hyper se descreveu como um “company brain”. Isso pode soar como linguagem de marketing, mas os detalhes de arquitetura que o fundador compartilhou no thread de lançamento são úteis: memória em duas camadas com episodes e facts, typed edges, um modelo de timestamps e dois caminhos de injeção por hooks e MCP. Isto não é uma avaliação de produto. Estou usando esses detalhes públicos para destrinchar o problema de design por trás da memória corporativa: um checklist em cinco camadas, um piloto de 7 dias e uma tabela de riscos para avaliação.

Três tipos de contexto que o RAG comum não consegue tratar

RAG recupera documentos, retorna chunks e deixa o modelo responder. Esse fluxo funciona para uma base de conhecimento estática, mas o conhecimento corporativo tem três dimensões que o RAG comum não trata por padrão.

O RAG tradicional ranqueia por recência ou relevância. Ele não consegue dizer se uma informação foi substituída por um fato mais novo. A Hyper atribui dois timestamps a cada fato: introduced_at registra quando ele apareceu pela primeira vez, e invalidated_at registra quando deixou de ser válido. O retrieval filtra fatos inválidos em vez de depender da data de atualização do documento.

Escopo de permissões é mais sensível em uma organização com várias pessoas. Uma chamada de agente pode representar um membro específico da equipe, e esse agente não deve ler conteúdo fora do escopo daquele membro. A Hyper usa access-control tags para marcar a visibilidade de cada fato, e a camada de retrieval filtra resultados pela identidade do chamador antes de retorná-los. Isso é mais granular que a busca corporativa comum, que muitas vezes para em permissões no nível do documento. Um company brain precisa de filtragem no nível do fato.

Raciocínio da decisão é onde o RAG comum mais sofre. Se você pergunta “Por que escolhemos PostgreSQL em vez de MongoDB?”, o RAG pode devolver o parágrafo de conclusão de um documento de arquitetura. Esse parágrafo talvez não inclua o debate técnico de três meses antes, os trade-offs ou a lógica da decisão final. A camada de episodes da Hyper mantém os nós originais de conversa, enquanto a camada de facts aponta para os episodes de origem por meio de typed edges derived from. O retrieval consegue então seguir a relação de volta até a cadeia de raciocínio, não apenas até o resultado.

A arquitetura de memoria em duas camadas da Hyper

A Hyper organiza memória em duas camadas: Episodes como armazenamento bruto, e Facts como camada estruturada, conectadas por um knowledge graph.

Camada de Episodes: Episodes preservam os nós originais da conversa e não descartam contexto. Eles funcionam como âncoras de proveniência para facts. Quando um agente precisa rastrear o processo de decisão, ele pode seguir uma edge derived from de um fact de volta ao trecho original da conversa, em vez de ler apenas uma conclusão resumida.

Camada de Facts: Facts usam uma estrutura subject-predicate-object. Cada fact tem subject, relação e object, além de timestamps e typed edges. O fundador descreveu publicamente três tipos de typed edges:

🔥 Não perca meses em produtos sem demanda! Valide as propostas do seu SaaS com a Adsterra e pouco orçamento →

Testar agora →Anúncio

Modelo de timestamps: Cada fact tem duas linhas do tempo. A linha T registra quando o evento aconteceu, como “a decisão foi tomada em março”. A linha T’ registra quando o sistema ingeriu o fact, como “este fact foi gravado na base de conhecimento em junho”. A distinção importa porque conhecimento corporativo muitas vezes chega atrasado. Conclusões de reunião podem ser registradas uma semana depois, então o sistema precisa separar quando algo aconteceu de quando o sistema soube disso.

Pontos centrais da arquitetura:

• Episodes não são resumidos até desaparecer; eles preservam os nós originais de conversa, segundo os comentários do fundador no HN e o contexto do paper da Zep.
• Facts são estruturados como triplas, cada um com timestamps e typed edges, com base nos detalhes públicos do HN.
• introduced_at / invalidated_at marcam ciclos de vida dos facts, e a camada de retrieval filtra conteúdo inválido.
• Typed edges deixam o grafo armazenar relações, não apenas fatos, que é a principal diferença em relação a um banco vetorial simples.

O objetivo dessa arquitetura não é armazenar mais dados. É permitir que agentes encontrem contexto seguindo relações. Um banco vetorial comum retorna chunks similares, mas não conhece dependências lógicas, relações de substituição ou conflitos entre chunks. Typed edges mais timestamps deixam os resultados de retrieval carregar metadados como de onde este fato veio, se ainda é válido e se foi substituído.

Os dois caminhos: retrieval e injecao

Depois que o conhecimento é escrito, agentes podem usá-lo por dois caminhos: retrieval, quando o agente consulta ativamente, e injeção, quando o agente recebe contexto passivamente.

Mecanismo de retrieval com base nos comentários do fundador no HN:

• Postgres full-text search: correspondência por palavras-chave para consultas exatas, como a definição de um endpoint específico de API.
• Embedding semantic search: busca por similaridade vetorial para perguntas vagas, como “o que decidimos da última vez sobre otimização de desempenho?”.
• Reciprocal Rank Fusion (RRF): combina recall full-text e semântico e retorna resultados por um ranking agregado.
• Filtragem por access-control tag: corta resultados pela identidade do chamador para preservar limites de permissão.

Isso difere de um banco puramente vetorial. Recall semântico puro pode perder resultados em consultas de palavra-chave exata. A Hyper usa RRF para combinar os dois caminhos de recall e considerar tanto correspondências de palavra-chave quanto similaridade semântica no ranqueamento.

Comparação de caminhos de injeção: hooks e MCP são canais de dados diferentes.

Os dois caminhos podem coexistir. O fundador da Hyper disse que hooks são usados para injeção de contexto em tempo real em agentes, como carregar docs do projeto quando você abre Claude Code, enquanto MCP é usado quando um agente chama ativamente ferramentas externas, como consultar Notion ou Gmail. Mas alguns comentários no HN questionaram a transparência dos hooks: o usuário sabe claramente quais dados são injetados automaticamente na conversa do agente?

Durante a avaliação, confira duas coisas: se hooks têm prompts explícitos de instalação e se o escopo de permissão do MCP server é controlado por um administrador. A documentação de developer mode da OpenAI diz que MCP apps exigem verificação de segurança, e planos Enterprise podem usar RBAC para controlar acesso. Isso torna o modelo de governança de MCP relativamente maduro, enquanto a transparência de hooks depende do design do produto.

Checklist de company brain em cinco camadas

Se você construir ou avaliar um company brain, confira se as cinco camadas têm uma resposta concreta. A falta de qualquer camada aparece no uso real.

A camada 1 é ingestão de fontes de dados.

• Seleção de ferramentas: Notion, Gmail, Slack, GitHub, Linear, Jira, dependendo do workflow da equipe.
• Método de ingestão: webhooks para atualizações em tempo real ou polling para verificações agendadas; webhooks são mais rápidos, mas exigem suporte do sistema de origem.
• Limpeza de dados: filtrar ruído, como canais casuais do Slack; marcar informações sensíveis; normalizar codificação.
• Importação inicial: todo o histórico versus apenas dados novos. Dados históricos podem conter muitos fatos obsoletos.

A camada 2 é o schema de fatos.

KiloClaw - OpenClaw gerenciado para empresas: orquestração de agentes IA e roteamento inteligente

Começar →Anúncio

• Formato do fact: triplas subject-predicate-object armazenadas em um formato consistente.
• Timestamps: introduced_at para primeira aparição e invalidated_at para invalidação. Sem os dois, julgar ciclo de vida fica fraco.
• Typed edges: pelo menos derived from para proveniência, supersedes para substituição e tension para conflito.
• Tratamento de conflitos: marcar automaticamente tension para revisão humana ou escolher o fact mais novo por timestamp quando fizer sentido.

A camada 3 é retrieval.

• Mix de recall: busca full-text por palavras-chave mais embeddings semânticos mais fusão RRF. Recall puramente semântico pode perder consultas exatas.
• Filtragem por permissões: access-control tags no nível do fact que cortam resultados pela identidade do chamador.
• Ranqueamento: combinar recência, relevância e validade do fact, filtrando fatos inválidos.
• Meta de latência: resposta de retrieval abaixo de 500 ms na prática; caso contrário, chamadas de agente começam a parecer lentas.

A camada 4 é injeção.

• Escolha de caminho: hooks para injeção de contexto em tempo real e MCP para acesso iniciado pelo agente. Os dois podem coexistir.
• Compatibilidade de agentes: se Claude Code, Cursor, ChatGPT e Codex suportam o caminho escolhido.
• Modelo de governança: se hooks têm prompts de instalação transparentes e se admins controlam permissões de MCP server.
• Controle de tamanho de contexto: limitar o comprimento do contexto injetado para evitar estouro de tokens e priorizar facts de alta relevância.

A camada 5 é governança.

• Herança de permissões: mapear permissões da fonte para visibilidade no nível do fact. Facts de um canal privado do Slack não devem ficar visíveis para todos.
• Logs de auditoria: quem injetou qual fact e quando, e quais facts um agente leu. Incidentes precisam de rastreabilidade.
• Correção humana: marcar fatos errados, desenhar um fluxo invalidated e permitir facts de esclarecimento manual.
• Exportação de dados: verificar se o armazenamento completo de facts pode ser exportado como JSON ou CSV para avaliar risco de lock-in.

A lógica do checklist é simples. A camada de fontes decide de onde vêm os dados. A camada de facts decide qual estrutura é armazenada. A camada de retrieval decide como o sistema encontra informação. A camada de injeção decide como o contexto chega ao agente. A camada de governança decide quem controla, corrige e audita. Se alguma camada faltar, a base de conhecimento vai travar na prática.

Um caminho piloto de 7 dias

Um time pequeno não deve conectar todo o Slack, e-mail ou CRM na primeira semana. Permissões são complexas, e o ruído é alto o bastante para expor problemas de governança cedo demais. Comece com fontes de baixo risco, depois valide recall e correção antes de expandir.

Dias 1-2: escolha fontes de baixo risco

• Docs públicos no Notion, como roadmaps de produto e especificações técnicas.
• Arquivos README e Wikis do GitHub, como arquitetura de projeto e docs de API.
• Exclua canais privados do Slack, e-mail histórico e dados de clientes no CRM, porque são sensíveis em permissões e ruidosos.

Dia 3: desenhe o schema de fatos

• Use 3-5 campos: subject, predicate, object, introduced_at, source.
• Não mire um schema perfeito. O piloto serve para validar o caminho de retrieval; o schema pode evoluir.
• Defina convenções de nomes. Use um formato consistente de subject, como ProjectX, e predicates como verbos, por exemplo uses.

Dias 4-5: teste retrieval e injeção

• Teste de retrieval: prepare 5-10 consultas e confira se fatos principais são encontrados.
• Teste de injeção: escolha um agente, como Claude Code ou Cursor, e verifique se ele consegue ler o contexto injetado.
• Registre a latência: confira se o retrieval fica abaixo de 500 ms e se o agente cita facts corretamente após a injeção.

Dias 6-7: reprodução e correção humana

• Reproduza consultas históricas e verifique se os resultados incluem fatos errados ou obsoletos.
• Registre erros: liste facts que precisam ser invalidados e desenhe o fluxo de marcação.
• Desenhe a correção: permita que humanos adicionem facts de esclarecimento e marquem facts errados com timestamp invalidated_at.

Não faça isso na primeira semana:

• Não conecte Slack, e-mail ou CRM, porque permissões e ruído são complexos demais.
• Não persiga um schema perfeito; valide o caminho de retrieval primeiro e itere depois.
• Não conecte fontes de dados de produção; use dados de teste ou docs públicos para validar o fluxo.

Ao fim do piloto, você deve ter um fluxo de retrieval mais injeção funcionando, 5-10 facts verificados e um processo de correção. Esses são os pré-requisitos para expandir fontes de dados: primeiro verifique se o sistema consegue encontrar, ler e corrigir facts, depois conecte mais ferramentas.

Alibaba Cloud - Escolha dos desenvolvedores, 15% de desconto exclusivo em Lighthouse

Ganhar 15% off →Anúncio

Tabela de riscos para avaliação

Confira sete dimensões de risco antes de tomar uma decisão. Cada uma deve carregar fonte e nível de confiança.

Dessas sete dimensões, exportação de dados e vendor lock-in pedem mais atenção na avaliação. O fundador disse em comentários no HN que exportação é suportada, mas não consegui verificar um compromisso oficial completo. Isso significa que você precisa confirmar se o formato de exportação é estruturado, como JSON ou CSV; se inclui o armazenamento completo de facts, typed edges e timestamps; e quanto trabalho de limpeza seria necessário para migrar para outro sistema.

Transparência de hooks é outro risco fácil de ignorar. Hooks injetam contexto no lado do cliente, e usuários podem não saber quais dados foram carregados automaticamente na conversa do agente. Durante a avaliação, confirme se o produto oferece prompts claros de instalação e se usuários conseguem inspecionar ou controlar o escopo dos dados injetados.

Herança de permissões tem uma direção técnica pública por access-control tags, mas as regras de herança não são públicas. As perguntas práticas são concretas: como um fact vindo de um canal privado do Slack mapeia para visibilidade no nível do fact, e como dados de clientes do CRM são recortados por equipe? Comprando ou construindo, essa lógica de mapeamento precisa de desenho.

Próximos passos e leituras relacionadas

Se você quer ir mais fundo em agentes e bases de conhecimento, estes posts relacionados da BetterLink são bons próximos passos:

• RAG + Agent: arquitetura de aplicações de IA de próxima geração — como resultados de retrieval podem orientar decisões de agentes.
• Sistemas de memória para AI Agents: ajudando agentes a lembrar contexto — arquitetura de memória pessoal de agentes e como ela difere da memória compartilhada no nível da empresa.
• Tutorial de RAG com Workers AI + Vectorize — detalhes práticos do Cloudflare Vectorize para criar um sistema RAG pequeno.
• Monitoramento e autorrecuperação de AI Agents — como conectar memória com execução para detectar falhas e tentar novamente.
• Tool calling de agentes na prática — detalhes de MCP e tool calling que complementam o caminho de injeção.

Conclusão

A Hyper ainda é um produto inicial. Seus detalhes públicos de arquitetura, incluindo memória em duas camadas, typed edges, modelo de timestamps e o caminho duplo hooks/MCP, ainda são um caso útil para aprender como a memória corporativa deve ser desenhada. Para times pequenos avaliando ou construindo esse tipo de sistema, as três verificações principais são exportação de dados, transparência de hooks e tratamento de conflitos.

Comece com um workflow estreito: docs públicos no Notion ou um README do GitHub, depois valide recall de retrieval e correção antes de conectar Slack ou e-mail. Não comece perseguindo um schema perfeito. Ciclos de vida de facts, herança de permissões e fluxos de correção humana precisam de teste real.

Se sua equipe já usa Claude Code ou Cursor, um próximo passo pequeno é tentar injetar docs de projeto por hooks e observar se o agente cita fatos corretamente. Depois disso, conecte memória com execução por monitoramento e recuperação, para que falhas sejam detectadas e tentadas novamente em vez de repetidas em silêncio.