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

Lo que me hizo detenerme en Hyper no fue la expresión company brain. Fue cómo nombra un problema en el que muchos equipos ya están cayendo: los agentes IA ya pueden editar código durante varios turnos, escribir correos y ejecutar scripts, pero a menudo no tienen idea de qué plan rechazó el equipo ayer. Pídele a Codex que cambie una página de checkout y quizá se apoye en lenguaje de producto de un PR antiguo. Pídele a Claude Code que inspeccione una restricción de API y quizá reabra Drive y se pierda la decisión más reciente en Slack. Una compañera humana añade de forma natural: «Ya no uses ese plan.» Un agente no desarrolla esa memoria compartida por sí solo.

Trataría a Hyper primero como un caso de estudio de arquitectura. Es temprano, y los materiales públicos no equivalen a una validación de terceros. Aun así, los detalles de su página de YC y de la discusión de Launch HN ayudan a aclarar qué necesita hacer de verdad una base de conocimiento de empresa para agentes IA: no es solo búsqueda de documentos ni solo un conector MCP. Es una forma de dejar que los agentes actúen dentro del contexto de empresa correcto, actual y consciente de permisos.

Dónde se atasca el RAG normal

El RAG normal es bueno para encontrar chunks en documentos. Divides Markdown, PDF y páginas web en chunks, los embeddeas, recuperas contenido similar a la consulta y dejas que el modelo componga una respuesta. BetterLink ha cubierto esa vía en la arquitectura RAG + agente, y basta para Q&A de conocimiento, FAQ de soporte y explicación de codebase.

El contexto de empresa es más desordenado. El agente no solo necesita encontrar contenido similar. También necesita saber si el contenido sigue siendo válido, quién puede verlo y por qué se tomó la decisión.

La información antigua y la nueva chocan

Toma una pequeña decisión de release. La reunión del lunes dice: «Lanzar el viernes.» El miércoles cambia el feedback del cliente y el product owner mueve el lanzamiento al lunes siguiente. Una base vectorial puede almacenar ambas afirmaciones. Cuál va primero depende de la consulta, el embedding, el chunking y el ranking. Si el agente recupera la nota antigua de «viernes», seguirá escribiendo el anuncio equivocado y planificando el trabajo equivocado.

Un diseño más seguro conserva ambos hechos pero marca el nuevo como reemplazo del antiguo: quién lo dijo, cuándo, qué alcance afecta y por qué la conclusión previa quedó inválida. Así, cuando el agente responde «¿Por qué se retrasó?», puede rastrear el historial de decisión en vez de perder el contexto antiguo.

Los permisos deben actuar antes de la respuesta

En cuanto una base de conocimiento de empresa alimenta a un agente capaz de actuar, los permisos dejan de ser un detalle. Ventas, soporte, ingeniería y dirección pueden preguntar por el mismo cliente y deberían recibir distintos alcances de información. La guía de conectores de equipo de OpenAI hace un punto similar: ChatGPT solo ve contenido al que el usuario ya tiene acceso, y los conectores respetan los límites de permisos existentes.

Esa comprobación debe ocurrir antes del retrieval, no después de que el modelo ya vio el contexto y se le pide que se porte bien. Filtra primero los datos invisibles; luego recupera, ordena e inyecta. Si no, el agente puede filtrar información sensible por logs, borradores o llamadas a herramientas.

Los agentes también necesitan el porqué

Muchos documentos de empresa registran resultados, no razones. Un plan de diseño pudo rechazarse porque el encaje de marca era malo, ventas oyó resistencia de clientes, la deuda técnica era demasiado alta, o el equipo simplemente no tenía capacidad en ese momento. Si el agente solo ve el resultado, puede repetir el mismo error en un contexto ligeramente distinto.

La actualización de memoria de OpenAI encuadra la memoria útil en torno a llevar el contexto adelante, seguir las preferencias y mantenerse al día con el tiempo. A nivel de empresa, yo añadiría un requisito: el sistema debería explicar las restricciones detrás de una decisión. Sin esa capa, un agente solo busca más rápido, no entiende mejor la empresa.

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

Empezar ahora →Anuncio

Qué revelan los materiales públicos de Hyper

Hay unos pocos detalles en el lanzamiento público de Hyper que me importan. No prueban que el producto sea perfecto, pero son más concretos que «meter Slack y Drive en una base vectorial».

El primer detalle es la separación entre episodes y facts. En el hilo de lanzamiento de HN, los fundadores describen las fuentes en bruto como episodes: documentos, correos, calendarios, Slack, notas de Granola, etc. Los facts son el significado extraído de esos episodes. Tienen forma de registros subject-predicate-object, con un plain summary más marcas de tiempo de cuándo se introdujo y cuándo se invalidó el hecho. El material en bruto sigue disponible como source of truth, mientras los facts extraídos apoyan un razonamiento y un retrieval más rápidos.

El segundo detalle son las aristas de relación entre facts. La discusión pública menciona facts en tensión entre sí, derivados unos de otros, o reemplazados (superseded) por un hecho más nuevo. Eso importa para los agentes porque el contexto de empresa no es una carpeta plana de notas. Es un historial de decisiones cambiantes.

El tercer detalle es el retrieval híbrido. Hyper mencionó query expansion, búsqueda semántica por embedding, Postgres full-text search y reciprocal rank fusion. Nada de esto es místico, pero es práctico. El retrieval semántico es bueno para el significado. La búsqueda full-text es mejor para nombres de clientes exactos, IDs de tickets, nombres de funciones y números de contrato. La fusión reduce la dependencia de una sola vía de retrieval.

El cuarto detalle es el etiquetado de permisos. Cada hecho lleva procedencia y access-control tags, y el retrieval solo se evalúa contra facts y episodes a los que el usuario tiene acceso. Sin esto, un company brain se convierte rápido en un riesgo de seguridad.

El quinto detalle es la división entre hooks y MCP. La documentación de MCP describe MCP como un estándar abierto para conectar aplicaciones IA con sistemas externos, y el OpenAI Agents SDK también admite varias integraciones MCP. MCP es útil cuando un agente consulta activamente una herramienta, pero depende de que el agente reconozca cuándo debe llamarla. Hyper dijo en el hilo de HN que, para herramientas como Claude Code, Codex y Cursor, también usa lifecycle hooks para inyectar o extraer contexto cuando una sesión empieza, se envía un prompt o termina un turno de agente. Esa concesión es polémica, sobre todo en la transparencia de instalación, pero señala un problema real: cierto contexto no puede depender de que el agente recuerde pedirlo.

Construir un company brain como piezas verificables

Si tu equipo aún no quiere introducir un nuevo proveedor, igual puedes construir una versión pequeña. No empieces conectando cada fuente de datos. Empieza separando el sistema en piezas que de verdad puedas revisar.

Source: los inputs en bruto deben ser reproducibles

La capa de fuentes no necesita cobertura total el primer día. Mejores puntos de partida son los Markdown de decisiones de producto, los resúmenes de PR recientes, las issues públicas y los artículos de base de conocimiento de soporte. Los datos de Slack, correo y CRM son densos, pero también ruidosos y cargados de permisos. Añádelos después.

Cada elemento de fuente debe llevar metadatos básicos: tipo de fuente, URL o ruta de archivo original, hora de creación, hora de actualización, autor, alcance de visibilidad y un hash. Si un hecho se extrae mal después, el equipo debe poder volver al texto original.

Fact: un hecho debería ser más que un resumen

Un hecho usable necesita campos como subject, predicate, object, summary, source, hora de introducción, hora de invalidación, tags de permiso, confianza y registros de corrección humana. Esto no es acumular campos. Le da límites al agente cuando responde.

Por ejemplo:

La extracción de hechos no será perfecta al primer intento, así que necesitas una vía de corrección humana. En la discusión de HN, cuando alguien preguntó por los datos desordenados y contradictorios de empresas maduras, el fundador de Hyper mencionó correcciones duras mediante un skill de MCP como /correct. Esa dirección vale la pena copiarla: deja que un humano diga explícitamente «Esto está mal; usa esto en su lugar» y conserva el rastro de corrección.

Retrieval: la búsqueda híbrida es más fiable que una sola vía

El retrieval vectorial es útil para el significado difuso, pero los nombres de clientes, SKU, IDs de tickets, nombres de funciones y números de contrato suelen necesitar coincidencias por palabra clave. Yo dividiría el retrieval en tres pasos:

1. Filtrar por identidad, proyecto, fuente de datos y permisos del usuario.
2. Ejecutar en paralelo búsqueda semántica, búsqueda full-text y expansión de vecindario de grafo.
3. Fusionar o reordenar los resultados, y luego inyectar solo un pequeño conjunto de hechos muy relevantes.

Más contexto no siempre es mejor. Si el contexto es demasiado amplio, el modelo tratará hechos no relacionados como pistas. Un mejor valor por defecto es inyectar 5-15 hechos estrechos con procedencia y confianza. Si falta la información, el agente debe preguntar o revisar la fuente original.

Injection: MCP, hooks y contexto manual tienen límites distintos

MCP es un punto de entrada, no un sistema de memoria completo. Permite a los agentes acceder a herramientas y fuentes de datos, y puede exponer capacidades como search_company_facts, correct_fact o get_decision_history. Puedes extender el patrón de la llamada a herramientas por los agentes y exponer la base de conocimiento de empresa como una herramienta.

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

Obtener 15% dto. →Anuncio

Los hooks son más estables porque pueden inyectar contexto automáticamente al iniciar una sesión o al enviar un prompt, sin esperar a que el modelo llame a una herramienta. También conllevan riesgo. Los usuarios deben saber qué se instaló, cuándo se ejecuta, qué lee y cómo desactivarlo. Este punto generó rechazo en los comentarios de HN, y los equipos pequeños deberían hacer visibles avisos, logs e interruptores.

El contexto manual sigue siendo útil. Para tareas de alto riesgo, dejar que un humano elija qué conocimiento de proyecto se permite en este run puede ser más seguro que la automatización total. AI-first no significa que cada paso deba ser sin supervisión.

Governance: corrección, exportación y auditoría deben llegar temprano

Cuanto más útil se vuelve un company brain, más caro es migrar fuera de él. En HN se plantearon preocupaciones de vendor lock-in, y son razonables. Si cada agente depende de la misma capa de conocimiento, exportación, borrado, copia de seguridad y auditoría no son funciones extra.

Yo haría estas preguntas durante el piloto: ¿se pueden exportar los facts como JSON o CSV? ¿Se pueden borrar los episodes en bruto? ¿Un cambio de permiso dispara un refiltrado? ¿Hay un log de qué hecho usó un agente en qué tarea? ¿Una corrección humana sobrescribe un hecho antiguo o conserva una cadena de historial? Preguntar temprano ahorra deuda después.

Cómo elegir entre las opciones

Estas opciones resuelven problemas distintos, así que los nombres pueden engañar.

Si los empleados solo necesitan preguntar «¿Dónde está la política de gastos?», la búsqueda empresarial o el RAG normal basta. Si un agente va a editar código, enviar correos, escribir seguimientos de ventas o resumir el riesgo del cliente, el sistema necesita más: ¿este hecho sigue siendo válido? ¿La fuente es fiable? ¿El usuario tiene permiso para verlo? ¿La acción necesita confirmación?

Los conectores de equipo de OpenAI ya llevan contenido de las herramientas del equipo a las conversaciones. El ecosistema MCP facilita que los agentes se conecten a más herramientas. Un company brain se sitúa entre esas capas: convierte contenido disperso en contexto de empresa continuamente actualizado, trazable, filtrado por permisos y reutilizable por distintos agentes.

Un piloto de 7 días: empieza con un workflow estrecho

No necesitas conectar toda la empresa para probar un company brain. Elige un workflow de agente de bajo riesgo y alta frecuencia, y hazlo correr una semana.

Días 1-2: elegir el workflow y las fuentes

Elige un escenario claramente acotado, como «pedir a Codex que actualice una funcionalidad pequeña según las últimas restricciones de producto» o «pedir a un agente de soporte que redacte una respuesta a partir de notas de bugs recientes». Conecta solo tres tipos de fuentes: docs de decisiones de producto, resúmenes de PR recientes e issues públicas. No empieces con todos los datos de Slack, correo y CRM.

Escribe el alcance prohibido: nada de correos reales, nada de cambios en configuración de producción, nada de datos de finanzas o RR.HH., y nada de hechos sin fuente tratados como conclusiones.

Días 3-4: extraer hechos y relaciones de conflicto

Extrae 50-100 hechos de esas fuentes. Haz parte manualmente y luego con ayuda de un modelo. Cada hecho debe incluir fuente, tiempo, permisos y confianza. Cuando los hechos entren en conflicto, no borres el antiguo a la carrera. Marca la relación: supersedes, supplements, conflicts with o needs confirmation.

Puedes empezar con un esquema simple. Una base de datos de grafo compleja no es necesaria para un piloto. Tablas de Postgres, JSONB, índices full-text y extensiones vectoriales pueden sostener un experimento pequeño. La discusión pública de Hyper también mencionó que Postgres sigue siendo cómodo en este tipo de sistema, porque los metadatos estructurados y las relaciones tipo grafo pueden convivir.

Días 5-6: inyectar contexto y reproducir tareas

Añade una herramienta o un hook al agente: dada la tarea actual, devuelve 5-15 hechos relevantes con procedencia. Luego reproduce 20 tareas reales y sigue tres números:

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

Empezar →Anuncio

• ¿Cuántas veces los humanos aún deben añadir contexto de fondo?
• ¿Cuántas veces el agente cita hechos obsoletos o erróneos?
• ¿Aparece algún hecho no autorizado, o un contexto demasiado amplio hace que el agente se desvíe?

No juzgues solo si la salida se ve pulida. El valor de un company brain está en reducir explicaciones repetidas, bajar los errores por hechos obsoletos y hacer al agente más cauto cuando la evidencia es incompleta.

Día 7: ampliar, pausar o cambiar de dirección

Si solo unas pocas de las 20 tareas se benefician, no amplíes a toda la empresa todavía. Quizá el workflow no encaja, o la extracción de hechos es demasiado gruesa. Si bajan las repreguntas, bajan las citas obsoletas y no aparecen hechos no autorizados, añade una fuente más, como notas de reunión o un canal de Slack seleccionado.

El siguiente paso es combinar esto con el monitoreo y recuperación de agentes IA: cuando el agente use un hecho de baja confianza, un hecho contradictorio o una acción de alto riesgo, enrútalo a confirmación humana.

Haz explícitos los riesgos antes de adoptarlo

En cuanto una base de conocimiento de empresa se conecta a agentes, deja de ser un simple proyecto de retrieval de información. Algunos riesgos deben escribirse en el plan desde temprano.

El primero es la privacidad y los límites de entrenamiento. El fundador de Hyper dijo en los comentarios de HN que no entrenan con datos alojados ni los venden, y remitió a la FAQ y la política de privacidad. Como la página oficial de privacidad no era legible por mi crawler, no inferiría los detalles. Los equipos deberían revisar contratos, términos de tratamiento de datos, plazos de retención y workflows de borrado en vez de fiarse de un post de lanzamiento.

El segundo es la transparencia de los hooks. La inyección automática de contexto es más fiable que esperar que un agente recuerde llamar a MCP, pero los usuarios deben saber qué está instalado en sus máquinas. Avisos de instalación, logs de ejecución, interruptores de desactivación y configuración visible deberían ser obvios.

El tercero es el historial contaminado. Las empresas maduras suelen tener documentos antiguos que se contradicen, y lo más nuevo no siempre es más autoritativo. En workflows legales, financieros, religiosos o gubernamentales, un documento más antiguo puede ser la fuente que rige. El sistema no puede ordenar todo por recencia. Distintas fuentes y roles necesitan pesos distintos.

El cuarto es el vendor lock-in. Cuanto más se usa un company brain, más se parece a parte del sistema operativo de la empresa. Formatos de exportación, estrategia de copia de seguridad, opciones de autoalojamiento y planes de salida de emergencia deben verificarse temprano. Sin ellos, el flujo a corto plazo puede volverse una trampa a largo plazo.

Deja que el sistema diga que no está seguro

Me gusta la dirección que empuja Hyper: si los agentes van a meterse más profundo en los workflows de equipo, necesitan un contexto de empresa más estable del que puede ofrecer el retrieval de documentos normal. Pero la implementación debe mantenerse aterrizada. Antes de llamarlo un cerebro de toda la empresa, asegúrate de que el sistema pueda distinguir hechos antiguos y nuevos, volver a las fuentes, filtrar por permisos, aceptar correcciones humanas y decir «No estoy seguro» cuando la evidencia es escasa.

Un equipo pequeño puede empezar con un workflow estrecho: tres tipos de fuentes de bajo riesgo, unas pocas decenas de hechos y 20 tareas reales. Haz eso primero, luego decide si ampliar. Es menos vistoso, pero para agentes que deben entregar trabajo real, está mucho más cerca de lo usable.