El segundo cerebro de la empresa: del wiki a las habilidades, todo es cuestión de contexto9 min read

He estado pensando mucho en todo el revuelo que rodea al «segundo cerebro». Hablé de esto con otros en el campo y con mis colegas que están construyendo un segundo cerebro o tienen una versión del mismo.

Para aquellos que no están familiarizados, el segundo movimiento cerebral comenzó con la idea «Wiki» de Andrej Karpathy: organizar el conocimiento personal del agente en una especie de estructura Wiki interconectada de archivos MD locales. Posteriormente, esto se expandió para organizar datos personales en un formato mucho más amplio, y los usuarios a menudo usaban Obsidian para organizar y visualizar notas y agregar datos de reuniones (transcripciones Granola/Whisperflow/Zoom) en la Wiki.

bases-de-conocimiento-de-cohetes-karpatía: inicio

bases-de-conocimiento-de-cohetes-karpatía:fin

A medida que esa «Wiki» se expandió, se hizo evidente que compartir la información que contiene tiene un valor real. Así comenzaron a florecer los proyectos del «segundo cerebro de la empresa». La versión utópica de un segundo cerebro consiste en transcribir todo lo posible: llamadas de zoom, reuniones cara a cara, incluso interacciones casuales, correos electrónicos, mensajes flojos, documentos, todo en una enorme base de datos de datos como Snowflake. Imagine que cualquier miembro de la empresa puede preguntarle a esta instancia de Snowflake lo que quiera y obtener respuestas instantáneas a todas sus preguntas.

Vaya, no es una buena idea. Primero, esto es muy caro. La cantidad de datos que se incluyen en algo como esto es una locura y recuperarlos se vuelve extremadamente difícil, lento y costoso. La seguridad y la segregación de datos se convierten en un problema. ¿Cómo se puede evitar que datos personales 1:1, datos financieros, decisiones de gestión, datos de recursos humanos o incluso decisiones para despedir a alguien se cuelan en las transcripciones y sean accesibles? No todos debería saberlo todo…

Además, ¿quién necesita esto? ¿Qué nos ahorra? ¿Es incluso una buena idea?

Yo diría que, en general, una versión contenida de esto es una buena idea. Gran parte de la razón por la que existen los mandos intermedios es para plantear cuestiones en sentido ascendente y aclarar decisiones en sentido descendente. Gran parte de esto se puede hacer ahora con un segundo cerebro.

Segundo cerebro para los equipos técnicos

Un segundo cerebro técnico puede ser mucho más fácil de mantener. Muchas empresas simplemente utilizan un directorio de Dropbox/Google Drive/OneDrive que contiene conocimientos compartidos que Claude/Codex pueden compartir. La automatización para enviar esto a un repositorio de Git es bastante simple, o realmente puedes usar Github para administrar esto también (supongo que es un esfuerzo muy pequeño para que OpenAI/Anthropic admita este escenario sin tener que instalar habilidades personalizadas para administrar este tipo de cosas). La fuente de la verdad ahora se convierte en el repositorio de Github y las copias locales son repositorios de git locales.

Esto puede agregar conocimientos y capacidades como habilidades compartidas, decisiones compartidas, diseños arquitectónicos, diseños visuales (decisiones de sistemas de diseño, por ejemplo) y otras decisiones de productos de la empresa.

Los equipos pequeños realmente no necesitan mucho más que una simple sincronización en el repositorio, pero las empresas más grandes con numerosos equipos más grandes se encontrarán con graves limitaciones muy rápidamente. Los problemas más graves implican el envenenamiento del contexto en el que un usuario en particular puede tomar decisiones locales que entran en conflicto con los datos del segundo cerebro, ya sea introduciendo datos contradictorios o anulando decisiones de la empresa sin darse cuenta (¿en algunos casos tal vez intencionalmente?).

Mantenerlo en git y fusionarlo se puede hacer usando un agente dedicado que busca conflictos y puede alertar a un usuario si sus cambios están en conflicto, resolver conflictos y fusionar los resultados.

Tenga en cuenta que este no es un buen método para mantener la documentación del proyecto. Para ello, la mejor manera es incluir la wiki como parte integral del propio proyecto. Es bastante fácil de crear. Simplemente reserve un agente de codificación y pídale que revise el proyecto, lo documente minuciosamente en una carpeta de documentos, dividido por arquitectura, errores, decisiones de producto, decisiones técnicas y otras cosas que, según concluya, podrían ser útiles en pequeños archivos md que se puedan contener. La clave es decirle que se asegure de que el código y readme.md apunten al directorio de documentos para garantizar que se haga referencia a él en todas partes y se considere parte del proyecto y no un recurso externo. La pieza clave que el agente debe saber es que la intención aquí es permitir una rápida incorporación de otro agente al proyecto para evitar obstáculos, baches y sumideros técnicos…

Una vez que esté integrado en la estructura del proyecto de repositorio, el agente de codificación lo mantendrá como si fuera código. Lo leerá como si fuera parte del código y, si algo cambia, adaptará o modificará la documentación (recuerde que «la documentación es que el código sea fácil de leer y borrar» o «la documentación se vuelve obsoleta en el momento en que sale de su teclado»; confíe en la IA para mantenerlas, por lo que ya no son ciertas).

Segundo cerebro para equipos de producto, marketing y no técnicos.

Este tipo de segundo cerebro puede ser realmente interesante para los equipos técnicos, pero hacer lo mismo para equipos no técnicos será extremadamente difícil.

Tomemos como ejemplo un equipo de abogados, tienen conjuntos de conocimientos muy específicos que abarcan el correo electrónico, Slack, archivos de Word y otros documentos. Lo mismo se aplica a los contables, las ventas, el éxito de los clientes, etc. Cada uno de ellos tiene su propio segundo conocimiento cerebral.

Además de esto, la gerencia probablemente quiera que los datos surjan (sin filtrar a través de la gerencia intermedia) y el equipo podría necesitar información que generó la gerencia. ¿Cómo producir un gráfico de conocimiento escalable que esté seguro y separado?

Hay algunos enfoques que podrían facilitar las cosas, al menos hasta que los grandes resuelvan este problema, con suerte de manera abierta, pero más probablemente a través de una costosa solución cerrada.

1. Segundo cerebro personal – Cada persona que quiera esto, puede transcribir sus propias reuniones y mantener su propio segundo cerebro. La obsidiana es bastante útil para esto, cualquier agente básicamente puede clasificarla y limpiarla. Utilice el mecanismo de sueño REM para optimizarlo: un agente debe despertarse por la noche, identificar toda la información que recopiló durante el día, encontrar cualquier información que sea crítica e importante para conservar para el futuro y organizarla de una manera fácilmente recuperable en carpetas y archivos MD. Esto significa que si habló con un cliente en particular, ese cliente tendrá un archivo md actualizado que reflejará información que es importante recordar sobre él, en qué están trabajando juntos, etc. Lo mismo ocurre con los proyectos. Habrá superposición: la superposición es buena; está bien que la información sobre un proyecto en particular se encuentre tanto en el archivo de la persona con la que habló, como en la empresa y en los archivos del proyecto. Deje que el agente se encargue de esto por usted. Cuando tenga preguntas, haga de esta su fuente de datos principal para su agente. Puede exponer a su agente a su correo electrónico/conversaciones/etc. – solo asegúrate de no transcribir cosas que no quieras que se documenten (no hagamos de esto un reality show o una telenovela).

2. Segundo cerebro a nivel de equipo – una segunda capa de datos incluye datos que se encuentran en el segundo cerebro personal y que el agente está 100% seguro de que son relevantes para todo el equipo o datos que se originaron en reuniones a nivel de equipo que, por su naturaleza, se basan en el equipo. Un agente también puede recopilar datos para este segundo cerebro de los canales flojos de su equipo; no deberían estar en sus canales 1:1 ni en sus llamadas de zoom. Una vez que recupera los datos, un agente puede organizarlos en tiempo real o cada noche y señalar inconsistencias en las que las decisiones fueron anuladas o no corresponden a decisiones personales o de gestión. Estos deben resaltarse y alertarse a la persona que toma la decisión incompatible para que pueda tomar sus decisiones de manera informada.

3. Nivel de gestión segundo cerebro – Este es básicamente un segundo cerebro a nivel de equipo, pero debido a la sensibilidad de los datos y las decisiones que se toman, debería manejarse de una manera mucho más matizada. Aquí solo se deben compartir decisiones finales y datos públicos para evitar posibles filtraciones al resto de la empresa. Podría ser una buena idea que un humano revise algunos de los datos, al menos al principio, para garantizar la seguridad de los datos. También es una buena idea dejar el cerebro directivo fuera del segundo cerebro de la empresa.

4. Segundo cerebro para toda la empresa – Este es el más difícil y debe contener sólo datos concretos e informativos que puedan ser relevantes para toda la empresa. Se informan únicamente resultados financieros, por ejemplo, información sobre el personal (quién ocupa qué puesto).

Esto deja fuera una gran cantidad de datos, incluidos los datos de opinión, por ejemplo, que la dirección quiere escuchar de todo el equipo. Esto se puede recolectar por separado o recolectar de sobras y otras fuentes. No es una buena idea recopilar este tipo de datos directamente del cerebro de la empresa.

Entonces, ¿qué busca en un segundo cerebro o en un cerebro de empresa? ¿Intentó construir uno? ¿Cuáles fueron sus conclusiones?