Hyper Company Brain: cómo diseñar una base de conocimiento para agentes de IA

Cuando le pides a Claude Code que cambie código, no sabe por qué el equipo eliminó aquella rama hace tres meses. Cuando le preguntas a ChatGPT por una decisión de proyecto, tiene que volver a leer todos los documentos para responder. Tener que explicar la historia del proyecto en cada llamada marca una diferencia real entre un agente y un RAG normal: el segundo es bueno recuperando documentos estáticos, pero el conocimiento de empresa tiene tres dimensiones que no maneja de forma nativa: validez de facts, alcance de permisos y cadena de razonamiento de las decisiones.

En Hacker News, Hyper dijo que quería construir un “cerebro de empresa”. Suena a marketing, pero los detalles de arquitectura que compartió su fundador en el hilo de lanzamiento tienen valor técnico: memoria en dos capas, episodes + facts, typed edges, modelo de timestamps, y dos rutas de inyección con hooks y MCP. Esto no es una reseña del producto. Uso esa información pública para desarmar el problema de diseño de la memoria empresarial: una checklist de cinco capas, un piloto de 7 días y una tabla de riesgos para decidir.

Tres tipos de contexto que el RAG normal no alcanza a manejar

RAG busca documentos, devuelve fragmentos y deja que el modelo responda. Ese flujo funciona para una base de conocimiento estática, pero el conocimiento de empresa tiene tres dimensiones que RAG no trata por defecto.

El RAG tradicional ordena por recency o relevance. No puede saber si una información fue reemplazada por un newer fact que la supersedes. Hyper asigna dos timestamps a cada fact: introduced_at registra cuándo apareció por primera vez, e invalidated_at cuándo dejó de ser válido. Durante el retrieval, filtra los facts invalidados en vez de depender de la fecha de actualización del documento.

El alcance de permisos es más delicado en organizaciones con varias personas. Una llamada de agente puede representar a un miembro específico del equipo, y no debería leer contenido fuera de su proyecto. Hyper usa access-control tags para marcar la visibilidad de cada fact, y la capa de retrieval filtra resultados según la identidad del llamador antes de devolverlos. Esto es más fino que la “búsqueda empresarial”, que normalmente llega solo a permisos de documento. Un company brain necesita recorte a nivel de fact.

El motivo de la decisión es lo que peor atrapa el RAG normal. Si preguntas “¿por qué elegimos PostgreSQL y no MongoDB?”, RAG quizá devuelva el párrafo de conclusión de un documento de arquitectura. Pero ese texto puede no incluir la discusión técnica de hace tres meses, los trade-offs y la lógica de la decisión final. La capa episodes de Hyper conserva nodos de conversación originales, y la capa facts apunta al episode fuente mediante un typed edge derived from. Así, el retrieval puede seguir la relación hasta la cadena de razonamiento, no solo hasta el resultado.

Desglose de la arquitectura de memoria en dos capas de Hyper

Hyper organiza la memoria en dos capas: Episodes como almacenamiento bruto y Facts como capa estructurada. Encima, usa un knowledge graph para conectarlas.

Capa Episodes: conserva los nodos de conversación originales y no descarta el contexto. Funciona como ancla de procedencia para los facts. Cuando un agente necesita rastrear un proceso de decisión, puede seguir un edge derived from desde el fact hasta el fragmento original de conversación, no solo leer una conclusión resumida.

Capa Facts: usa una estructura subject-predicate-object. Cada fact contiene sujeto, relación y objeto, además de timestamps y typed edges. El fundador compartió tres tipos de typed edges:

Railway - Plataforma de despliegue moderna, sin ops complejas, en producción en minutos

Empezar ahora →Anuncio

Modelo de timestamps: cada fact tiene dos líneas temporales. La línea T registra cuándo ocurrió el evento, por ejemplo “la decisión se tomó en marzo”. La línea T’ registra cuándo el sistema ingirió el fact, por ejemplo “este fact se escribió en la base de conocimiento en junio”. Separarlas importa porque el conocimiento de empresa suele entrar con retraso. Una conclusión de reunión puede cargarse una semana después, y el sistema necesita distinguir cuándo ocurrió el hecho de cuándo lo conoció.

Puntos clave de la arquitectura:

• Episodes no se resumen y descartan; conservan los nodos de conversación originales, según lo dicho por el fundador en HN y el contexto del paper de Zep.
• Facts se estructuran como triples, cada uno con timestamps y typed edges, según los detalles publicados en HN.
• introduced_at / invalidated_at marcan el ciclo de vida del fact, y la capa de retrieval filtra contenido inválido.
• El knowledge graph usa typed edges para resolver “relaciones”, no solo para guardar “facts”. Esa es la diferencia clave frente a una base vectorial normal.

El objetivo de esta arquitectura no es almacenar más datos. Es permitir que el agente encuentre contexto siguiendo relaciones. Una base vectorial normal devuelve fragmentos similares, pero no conoce dependencias lógicas, relaciones de reemplazo ni puntos de conflicto entre fragmentos. Typed edges + timestamps permiten que los resultados de retrieval lleven metadatos: de dónde viene este fact, si sigue siendo válido y si fue reemplazado.

Dos rutas: retrieval e inyección

Después de escribir el conocimiento, el agente puede usarlo por dos vías: retrieval, cuando consulta activamente, e inyección, cuando recibe contexto de forma pasiva.

Mecanismo de retrieval según lo compartido por el fundador en HN:

• Búsqueda full-text en Postgres: coincidencia por palabras clave, útil para consultas exactas como “la definición de un API endpoint”.
• Búsqueda semántica con embedding: similitud vectorial, útil para consultas difusas como “cuál fue la conclusión sobre optimización de rendimiento”.
• Reciprocal Rank Fusion (RRF): fusiona los resultados de full-text y semánticos, y devuelve un ranking combinado.
• Filtrado por access-control tags: recorta resultados según la identidad del llamador y preserva límites de permisos.

Esta combinación difiere de una base vectorial pura. La segunda solo hace recall semántico y puede perder resultados en consultas exactas. Hyper usa RRF para fusionar las dos rutas y considerar tanto coincidencia de palabras clave como similitud semántica en el ranking.

Comparación de rutas de inyección: hooks y MCP son canales de datos distintos.

Las dos rutas pueden coexistir. El fundador de Hyper dijo que hooks se usan para inyectar contexto en tiempo real al agente, por ejemplo cargar documentos del proyecto cuando abres Claude Code. MCP se usa para que el agente llame herramientas externas activamente, como consultar Notion o Gmail. Pero algunos comentarios en HN cuestionaron la transparencia de hooks: ¿el usuario sabe con claridad qué datos se inyectan automáticamente en la conversación del agente?

Al evaluar, revisa dos cosas: si hooks tiene avisos de instalación claros y si el alcance de permisos del MCP server lo controla un administrador. La documentación de developer mode de OpenAI menciona que las MCP apps requieren verificación de seguridad, y los planes Enterprise pueden usar RBAC para controlar acceso. Eso hace que el marco de gobierno de MCP sea relativamente maduro, mientras que la transparencia de hooks depende del diseño del producto.

Checklist de cinco capas para un company brain

Si vas a construir o elegir una solución, revisa si estas cinco capas tienen respuesta. La ausencia de cualquiera de ellas aparece en uso real.

Primera capa: conexión de fuentes de datos

• Selección de herramientas: Notion, Gmail, Slack, GitHub, Linear, Jira, según el workflow del equipo.
• Modo de conexión: webhooks en tiempo real o polling periódico; los webhooks responden rápido, pero requieren soporte del sistema fuente.
• Limpieza de datos: filtrar ruido, como canales de charla en Slack; marcar información sensible; unificar codificación.
• Importación inicial: historial completo o solo datos nuevos. El histórico puede contener muchos facts obsoletos.

Segunda capa: Fact Schema

Alibaba Cloud - Opción preferida para desarrolladores, 15 % de descuento exclusivo en Lighthouse

Obtener 15% dto. →Anuncio

• Estructura de fact: triples subject-predicate-object con formato uniforme.
• Timestamps: introduced_at para primera aparición + invalidated_at para invalidación. Sin ambos, es difícil juzgar el ciclo de vida.
• Typed edges: al menos derived from para procedencia, supersedes para reemplazo y tension para conflicto.
• Estrategia de conflicto: marcar tension automáticamente para revisión humana, o elegir el newer fact según timestamp.

Tercera capa: retrieval

• Combinación de recall: full-text (palabras clave) + semántico (embedding) + fusión RRF; el recall puramente semántico puede fallar en consultas exactas.
• Filtrado de permisos: access-control tags a nivel de fact, recortados según identidad del llamador.
• Estrategia de ranking: combinar recency, relevance y fact validity, y filtrar facts inválidos.
• Objetivo de latencia: respuesta de retrieval < 500 ms en pruebas reales; si no, las llamadas del agente se sienten lentas.

Cuarta capa: inyección

• Elección de ruta: hooks para inyección de contexto en tiempo real vs MCP para llamadas activas del agente. Pueden convivir.
• Compatibilidad de agentes: Claude Code, Cursor, ChatGPT, Codex deben soportar la ruta elegida.
• Marco de gobierno: hooks debe tener avisos de instalación transparentes, MCP debe permitir control administrativo del server.
• Control de volumen: limitar longitud del contexto inyectado para evitar desbordar tokens, priorizando facts de alta relevance.

Quinta capa: gobierno

• Herencia de permisos: mapear permisos de fuente a visibilidad a nivel fact. Un fact de un canal privado de Slack no debería volverse visible para todos.
• Logs de auditoría: quién inyectó qué fact y cuándo, qué facts leyó el agente. Si algo sale mal, debe poder rastrearse.
• Corrección humana: marcar facts incorrectos, diseñar un flujo invalidated, permitir añadir facts aclaratorios manuales.
• Exportación de datos: confirmar si el fact store completo puede exportarse como JSON/CSV para evaluar riesgo de lock-in.

La lógica de esta checklist es simple. La capa de fuentes decide “de dónde viene”. La capa de facts decide “qué estructura se guarda”. La capa de retrieval decide “cómo se encuentra”. La capa de inyección decide “cómo se entrega”. La capa de gobierno decide “quién lo gestiona y cómo se corrige”. Si falta una capa, la base de conocimiento empresarial se atasca.

Ruta piloto de 7 días

Un equipo pequeño no debería conectar todo Slack, email o CRM en la primera semana. Los permisos son complejos y el ruido es alto; es fácil que el piloto se convierta en un problema de gobierno antes de validar valor. Empieza con fuentes de bajo riesgo, valida recall y corrección, y después amplía.

Day 1-2: elegir fuentes de bajo riesgo

• Documentos públicos de Notion, como roadmaps de producto y especificaciones técnicas.
• GitHub README y Wiki, como arquitectura del proyecto y documentación de API.
• Excluir: canales privados de Slack, emails históricos y datos de clientes en CRM, porque son sensibles en permisos y ruidosos.

Day 3: diseñar el Fact Schema

• 3-5 campos: subject, predicate, object, introduced_at, source.
• No perseguir la perfección: en el piloto importa validar el camino de retrieval; el Schema puede iterar después.
• Acordar nombres: subject con formato uniforme, como ProjectX, y predicate como verbo, por ejemplo uses.

Day 4-5: probar retrieval e inyección

• Prueba de retrieval: preparar 5-10 queries y revisar si aparecen los facts clave.
• Prueba de inyección: elegir un agente, como Claude Code o Cursor, y validar si puede leer el contexto inyectado.
• Registrar latencia: si la respuesta de retrieval está por debajo de 500 ms y si el agente cita correctamente facts tras la inyección.

Day 6-7: replay y corrección humana

• Reproducir queries históricas y revisar si los resultados contienen facts incorrectos u obsoletos.
• Registrar errores: listar facts que deben invalidarse y diseñar el flujo de marcado.
• Diseñar corrección: añadir facts aclaratorios manuales + marcar facts erróneos con timestamp invalidated_at.

Prohibido en la primera semana:

• No conectar Slack, email ni CRM: permisos y ruido son demasiado complejos.
• No buscar un Schema perfecto: primero valida el camino de retrieval, luego itera.
• No conectar fuentes de producción: usa datos de prueba o documentos públicos para validar el flujo.

Al final del piloto deberías tener tres cosas: un flujo retrieval + inyección que funcione, 5-10 facts verificados y un proceso de corrección. Son las condiciones previas para ampliar fuentes: primero valida que el sistema pueda encontrar, leer y corregir; después conecta más herramientas.

KiloClaw - OpenClaw gestionado para empresas: orquestación de agentes IA y enrutamiento inteligente

Empezar →Anuncio

Tabla de riesgos para decidir

Antes de decidir, revisa siete dimensiones de riesgo. Cada dimensión debería tener fuente y nivel de confianza.

De esas siete dimensiones, exportación de datos y lock-in proveedor son las más importantes al decidir. En los comentarios, el fundador dijo que la exportación está soportada, pero no hay un compromiso oficial completo verificable. Eso significa confirmar si el formato es estructurado, como JSON/CSV; si puede exportar todo el fact store, incluidos typed edges y timestamps; y si migrar a otro sistema exigiría limpieza adicional.

La transparencia de hooks es otro riesgo fácil de pasar por alto. Los hooks inyectan contexto en el cliente, y el usuario puede no saber qué datos se cargaron automáticamente en la conversación del agente. Al evaluar, confirma si el producto muestra avisos de instalación claros y si el usuario puede ver y controlar el alcance de datos inyectados.

La herencia de permisos tiene una dirección técnica pública con access-control tags, pero no reglas públicas de herencia. Las preguntas reales son concretas: ¿cómo se mapea un fact de un canal privado de Slack a visibilidad por fact? ¿Cómo se recortan datos de clientes en CRM por equipo? Compres o construyas, esta lógica de mapeo necesita diseño.

Siguientes pasos y lecturas relacionadas

Si quieres profundizar en la combinación de agentes y bases de conocimiento, estos artículos de BetterLink son buenas continuaciones:

• RAG + Agent: arquitectura de aplicaciones de IA de próxima generación — cómo los resultados de retrieval pueden impulsar decisiones de agentes.
• Sistemas de memoria para agentes de IA: ayudar a los agentes a recordar contexto — arquitectura de memoria personal de agentes y diferencias frente a memoria compartida empresarial.
• Tutorial Workers AI + Vectorize RAG — detalles prácticos de Cloudflare Vectorize para construir un RAG pequeño.
• Monitorización y autorrecuperación de agentes de IA — cómo conectar memoria y ejecución para detectar y reintentar fallos.
• Agent tool calling en la práctica — detalles de MCP y tool calling que complementan la ruta de inyección.

Conclusión

Hyper sigue siendo un producto temprano. Aun así, sus detalles de arquitectura pública — memoria en dos capas, typed edges, modelo de timestamps y doble ruta hooks/MCP — son un buen caso para aprender a diseñar “memoria de empresa”. Para equipos pequeños que evalúan o construyen algo parecido, las tres comprobaciones principales son exportación de datos, transparencia de hooks y manejo de conflictos.

En fase piloto, empieza por un workflow estrecho: documentos públicos de Notion o un README de GitHub. Valida recall de retrieval y corrección antes de conectar Slack o email. No empieces buscando un Schema perfecto: el ciclo de vida de facts, la herencia de permisos y la corrección humana necesitan iterar con pruebas reales.

Si ya usas Claude Code o Cursor, puedes probar primero hooks para inyectar documentos del proyecto y observar si el agente cita facts correctamente. El siguiente paso es cerrar el ciclo entre memoria y ejecución: monitorización y autorrecuperación de agentes, para que los fallos se detecten y se reintenten en vez de repetirse en silencio.