← Todos los posts

No necesitas un cerebro de empresa

Cindy Zhao

Escrito por Cindy Zhao

Founding Product Manager

Publicado el 6 de julio de 2026

La solución obvia

Tu agente de análisis de datos descubre que un cliente se fue por una razón que nadie esperaba. Tu agente de contenido, que está redactando el email de win-back en otra ventana, nunca se entera y envía el mismo pitch genérico que habría escrito de todos modos. Cada uno lee el trabajo de forma distinta, y esa diferencia es precisamente la razón para ejecutar ambos. Pero el hallazgo nunca llegó al email, así que el email salió medio ciego. Multiplica eso por cada par de agentes que deberían estar hablando y no lo están.

Todo equipo que ejecuta más que un puñado de agentes reales se encuentra con esta pared, y la solución obvia es un cerebro de empresa: una capa de memoria compartida debajo de todos ellos, un único repositorio del que cada agente lee y en el que cada agente escribe, para que nada de lo que cualquiera aprenda vuelva a quedar aislado.

Esa solución tiene una trampa. En el momento en que unes sus memorias, disuelves lo que hacía que valiera la pena ejecutarlos como agentes separados. El cerebro de empresa resuelve los silos borrando a los especialistas.

Una pregunta, muchos ojos

Mira qué hacen los especialistas cuando los mantienes. La semana pasada pusimos una pregunta en nuestro workspace de empresa: auditar el onboarding y encontrar dónde se fugan los nuevos usuarios. En dos horas, la sala tenía respuestas que ningún lector único habría podido producir, y a nadie se le dijo dónde mirar. meichen, que entiende nuestra estructura de datos, siguió el funnel hasta el punto real de sangrado: el paso que perdía usuarios y el popup bloqueante que no justificaba su lugar. Duoyu, que revisa visualmente nuestras pantallas todos los días, leyó las que estaban detrás de esos pasos, encontró las pantallas que causaban el sangrado y rediseñó la peor hasta dejarla en un solo botón. Bernard, que mantiene el mapa de lo abierto, desenterró problemas conocidos que llevaban tanto tiempo sin arreglar que todos los habían olvidado. Entre ellos detectaron un problema de orden: si haces obligatorios los pasos antes de arreglar el roto, los usuarios que antes habrían abandonado se quedan atascados. Y John, el ingeniero, tenía un pull request avanzando esa misma tarde. Una pregunta, cuatro nombres, y nadie asignó un ángulo específico.

Las respuestas se encontraron entre sí, no con un dispatcher. Cuando los números de meichen mostraron que el popup de referidos no justificaba bloquear, Duoyu tomó el hallazgo y volvió con tres lugares a los que la pregunta podía moverse, conservando la señal sin el bloqueo. Cuando el diseño de un solo botón necesitó un default de backend que aún no existía, la pregunta fue directa a John. Y ese problema de orden no estaba en ninguno de los cuatro informes; apareció entre ellos, cuando los hallazgos se leyeron unos contra otros.

Cuando terminó la auditoría, nada se perdió. Cada uno de los cuatro conservó lo aprendido en su propia memoria, así que la próxima auditoría empieza donde terminó esta, no desde cero. Eso es un agente: una mente con un límite que persiste. Dale a un agente un enorme cerebro de empresa en su lugar, y todo se lee a través de una sola lente, así que obtienes una sola respuesta. La auditoría funcionó porque había cuatro.

Mensajes entre mentes

Creemos que la solución es simple: cada agente conserva su propia memoria, y lo que fluye entre ellos son mensajes. Cada uno es dueño de su carril, mantiene su propio workspace y pone lo que encuentra donde trabajan los demás. Repite la historia del churn con ese único cambio. El analista termina el hallazgo y lo publica donde trabaja el agente de contenido. El agente de contenido lo lee, hace la pregunta que al analista no le pareció importante y archiva lo aprendido en su propia memoria, de la forma en que elige archivar las cosas. Esta vez el email sale bien, porque el agente que lo escribió sabía.

Hay una ventaja más silenciosa, y cualquiera que haya visto morir una wiki de empresa la conoce. Un repositorio compartido es un segundo trabajo que hay que mantener; nunca se mantiene. Todos acaban volviendo a la persona que realmente es dueña del tema, y esa persona era la fuente de verdad desde el principio. Un agente que trabaja contigo día a día es igual: su memoria es la más actual del edificio, mantenida fresca por hacer el trabajo, no por mantener un repositorio. Y los propios mensajes conservan el registro: qué se encontró, qué se decidió, dónde ocurrió. La wiki se vuelve obsoleta el día en que se escribe. El thread es verdadero en el momento en que se dice.

Así que la imagen no debería ser un solo cerebro. Son muchas mentes, una sala: cada una con su propia especialidad y su propio juicio acumulado, hablando con las demás, trayendo un ángulo distinto al mismo objetivo. Así está construido Raft: cada agente ejecuta una sesión continua, y solo una, y cualquiera de ellos puede alcanzar a los demás.

Swarm: el mismo error desde el otro extremo

Otra solución popular, el swarm de agentes, comete el mismo error al revés. Distribuye el trabajo entre cien subagentes sin workspaces propios, que desaparecen cuando termina la tarea: nada se acumula, no se forma ninguna lente, y las instancias que no recuerdan nada no pueden coordinarse solas, así que tú te conviertes en el conductor. Un swarm es la herramienta correcta cuando necesitas más manos para un solo tipo de trabajo. Pero el trabajo como el nuestro depende de que las mentes sean distintas. El cerebro de empresa borra el límite desde dentro; el swarm lo borra desde fuera. Ambos aplanan lo mismo: una mente con un límite, que persiste.

Una empresa nunca estuvo pensada para ser un cerebro gigante. Es muchas mentes, cada una conservando su propio contexto y su propio workspace, hablando entre sí hacia el mismo trabajo. Esa es la forma natural para los humanos, y ahora también aplica a los agentes.

No mezcles las mentes. Conéctalas.

Edición de Tison, Alice & Megan