Publicado · Actualizado
Cómo diseñé Cerebro para compartir contexto entre developers y agentes de IA
El enfoque conceptual detrás de Cerebro: pasar de conocimiento disperso a contexto especializado, con validación humana y límites explícitos.
Ver caso de estudio de CerebroEste artículo describe el enfoque y la arquitectura conceptual de una herramienta interna desarrollada en Bigbuda. Los ejemplos se han recreado con datos ficticios para explicar el funcionamiento sin exponer información privada. Las funcionalidades implementadas se distinguen de las exploraciones posteriores.
Entre 2025 y 2026 participé en el concepto, diseño y desarrollo de Cerebro en Bigbuda. El punto de partida no fue una fascinación abstracta por la IA. Fue una situación bastante cotidiana: el conocimiento útil de un proyecto rara vez vive en un solo lugar. Parte queda en sus reglas y convenciones, parte en decisiones tomadas durante el desarrollo, parte en el estado y la estructura actual, y otra parte aparece después de resolver problemas o encontrar algo en QA.
Mientras más proyectos se mueven en paralelo, más fácil es que ese conocimiento se fragmente. Una persona puede recordar por qué se resolvió algo de cierta forma; otra puede tener la referencia de una decisión; una tercera entra después y necesita reconstruir el recorrido. La documentación ayuda, pero no elimina por sí sola el trabajo de encontrar, interpretar y decidir qué es relevante para la tarea que se tiene enfrente.
Cerebro nació de esa necesidad: centralizar conocimiento disperso de proyectos para convertirlo en contexto compartido. No como una promesa de que una herramienta pueda reemplazar el criterio de un developer, sino como una forma de que developers, agentes y skills partan de una base más consistente al trabajar.
El problema no era guardar información
Al principio, es tentador pensar que el desafío consiste en reunir documentos. Pero reunirlos no garantiza que una persona o un agente tenga lo necesario para continuar un proyecto. El contexto de trabajo incluye relaciones: qué reglas se respetan, qué decisiones ya condicionan el presente, qué parte del proyecto está resuelta, qué funcionalidad existe y qué incidentes o hallazgos de QA cambiaron el camino.
Por eso entendí Cerebro como infraestructura de contexto. La palabra “infraestructura” importa: su rol conceptual no es publicar una pieza final ni reemplazar una conversación, sino sostener continuidad entre momentos de trabajo. Si alguien debe volver a un proyecto, investigar una funcionalidad o validar un cambio, puede partir de conocimiento organizado en vez de depender exclusivamente de memoria individual.
También importaba no confundir centralización con acumulación indiscriminada. Un sistema puede contener mucha información y, aun así, entregar poco contexto útil. Cuando el volumen crece sin una forma clara de distinguir lo relevante, aparecen respuestas vagas, referencias que no aplican y más carga para quien debe discernirlas. Esa fue una de las lecciones que guió la evolución del enfoque.
Tres conceptos que conviene separar
La conversación sobre IA suele mezclar capas distintas bajo una misma palabra. Para explicar Cerebro sin atribuirle mecanismos que no corresponden, me resulta útil separarlas conceptualmente.
Un modelo es la capacidad que interpreta lenguaje y produce una respuesta. Puede ayudar a sintetizar, proponer o transformar información, pero por sí mismo no conoce las particularidades de un proyecto. Que un modelo sea capaz no significa que tenga el contexto correcto para una tarea concreta.
La infraestructura de contexto es la capa conceptual que organiza el conocimiento que un proyecto necesita conservar: reglas y convenciones, decisiones, estado y estructura, funcionalidades, problemas resueltos y hallazgos de QA. Cerebro se diseñó alrededor de esta pregunta: ¿cómo hacer que ese conocimiento deje de estar disperso y pueda ser compartido de manera más útil?
El agent harness, dicho de forma simple, es el entorno o flujo desde el que una persona usa un agente para realizar una tarea. Es donde se articulan el developer, el agente, las skills y el contexto disponible. No lo uso aquí como el nombre de un servicio específico ni como una afirmación sobre la implementación de Cerebro; es una distinción conceptual. Separar estas capas evita atribuir al modelo lo que depende del contexto, o presentar el uso de un agente como si fuera una decisión autónoma.
En esa relación, el developer sigue teniendo un rol central. Decide qué problema abordar, revisa si el contexto aplica, valida el resultado y determina qué conocimiento merece incorporarse. El objetivo no era construir una autoridad automática, sino reducir el costo de volver a entender un proyecto sin sacar a las personas del proceso.
Cuando un Cerebro amplio empezó a ser demasiado amplio
La primera aproximación centralizaba el conocimiento de manera más general. Ayudaba porque hacía visible que había información dispersa y que podía organizarse. Sin embargo, aparecía una contradicción: un contexto que intenta cubrir demasiados dominios puede incluir información irrelevante para la tarea actual.
Una regla o una decisión relevante para un proyecto Webflow no necesariamente ayuda cuando se trabaja en Shopify. Incluirla por defecto puede distraer, inducir analogías equivocadas o hacer que el developer pierda tiempo filtrando. La centralización inicial mostró el problema con claridad: no bastaba con tener un lugar compartido; el contexto debía estar especializado.
Así evolucionó la idea hacia Cerebro Webflow y Cerebro Shopify. Cada uno responde a un dominio distinto y reúne el contexto de sus grupos de proyectos. La especialización no pretende convertir los dominios en silos aislados ni negar que existan aprendizajes comunes. Busca que el trabajo operativo se apoye primero en lo que tiene más probabilidad de ser pertinente.
Esta separación también cambió la manera de pensar la escala. En vez de hacer crecer un único cerebro hasta que contenga todo, se puede incorporar un nuevo dominio sin diluir los ya existentes. Es una decisión de foco: menos contexto irrelevante es tan importante como más conocimiento disponible.
Qué significa compartir contexto
Compartir contexto no significa que todas las personas reciban el mismo bloque de información en cualquier situación. Significa que developers, agentes y skills pueden acceder a una base especializada común sobre el proyecto que están tratando. De esa manera, la conversación no parte solamente de una interpretación individual o de un resumen improvisado.
El tipo de conocimiento que importa puede incluir reglas y convenciones, decisiones previas, estado y estructura del proyecto, funcionalidades existentes, problemas ya resueltos y hallazgos de QA. Cada elemento responde a una pregunta diferente. Las reglas orientan consistencia; las decisiones explican límites; el estado evita asumir que algo sigue igual; los hallazgos ayudan a no repetir errores que ya costaron tiempo.
Hay una diferencia importante entre reutilizar contexto y copiar soluciones. Que un proyecto haya resuelto algo de una manera no convierte esa solución en una receta universal. El valor está en recuperar antecedentes para que el developer pueda evaluar semejanzas y diferencias antes de decidir. La decisión final y la validación siguen siendo humanas.
MCP entra en este relato únicamente como una capa de conexión. Es útil para describir cómo el contexto y las herramientas pueden relacionarse en un flujo de trabajo, pero no es la explicación completa de Cerebro ni una garantía de resultados. No describo aquí conectores activos, capacidades de herramientas ni detalles de operación porque no forman parte de la información pública que quiero compartir.
Un ejemplo ficticio para bajar la idea
Imaginemos Proyecto A y Proyecto B. Ambos son nombres ficticios y no representan proyectos reales ni datos de clientes. En Proyecto A aparece una tarea que requiere entender una funcionalidad existente. El developer consulta el contexto especializado asociado a ese proyecto: qué reglas aplican, qué decisiones condicionan la tarea y qué estado conviene revisar.
El agente y las skills pueden participar dentro del flujo del developer usando ese contexto compartido. Eso no transforma la propuesta del agente en una respuesta correcta por defecto. El developer decide qué investigar, contrasta el resultado con el proyecto y valida antes de continuar. Si durante el trabajo surge una corrección, una decisión o un hallazgo relevante, las personas pueden incorporarlo, validarlo y organizarlo como conocimiento para el futuro.
Proyecto B conserva su propio contexto especializado. No se asume que lo válido en A sea válido en B solo porque ambos pertenezcan a una misma organización o porque una tarea tenga un nombre similar. La distinción parece obvia, pero es justamente la que se pierde cuando se trata el conocimiento como un inventario genérico.
Lo que vuelve al sistema no es entrenamiento automático
Una parte esencial del enfoque es cómo se incorpora el conocimiento nuevo. Durante desarrollo y QA se producen decisiones, correcciones, preguntas respondidas y hallazgos. Si se quedan en una conversación efímera o en la memoria de una persona, el siguiente proyecto puede volver a empezar desde cero.
En Cerebro, el conocimiento nuevo se incorpora, valida y organiza por personas. No se presenta como entrenamiento automático del modelo ni como una modificación autónoma de su comportamiento. Esa diferencia es importante tanto por precisión como por responsabilidad: una observación de trabajo no debería convertirse en conocimiento compartido simplemente por existir.
La validación humana también evita una falsa sensación de certeza. Un hallazgo puede requerir contexto adicional; una decisión puede estar limitada a una versión o a un proyecto concreto; una regla puede dejar de aplicar. Organizar conocimiento es también decidir su alcance y reconocer cuándo todavía no hay una conclusión suficiente.
Cerebro Global como exploración transversal
Además de los cerebros especializados, Cerebro Global es una capa exploratoria y transversal. Su propósito conceptual es consultar conocimiento resumido entre dominios, sin mezclar el contexto operativo de Webflow y Shopify en un único bloque indiscriminado.
Lo entiendo como una exploración para conversaciones donde hace falta orientar una consulta más amplia: identificar antecedentes, preparar una reunión o reconocer qué preguntas conviene resolver antes de una decisión. No sustituye el contexto especializado del proyecto ni convierte una consulta transversal en una instrucción de ejecución.
Esta distinción entre Global y los cerebros especializados es deliberada. Lo transversal puede ser útil para explorar; lo especializado es lo que ayuda a concentrarse durante el trabajo sobre un dominio. Son necesidades relacionadas, pero no equivalentes.
El límite que no quiero ocultar
La centralización amplia produjo irrelevancia. La especialización ayudó a reducirla, pero no garantiza respuestas correctas. Un contexto mejor organizado puede hacer que una consulta sea más pertinente, pero no sustituye la lectura crítica, las pruebas ni la validación del developer.
Ese límite no es una nota al pie. Es parte del diseño. Los agentes pueden apoyar el trabajo y las skills pueden participar en tareas concretas, pero una persona debe decidir y validar. Presentar una herramienta de contexto como si resolviera automáticamente la verdad de un proyecto sería confundir disponibilidad de información con criterio técnico.
También hay preguntas operativas que este artículo deja intencionalmente fuera: cómo se almacena o recupera información, qué permisos existen, qué fuentes están activas, cómo se conectan herramientas, qué aprobaciones ocurren o qué capacidades concretas tiene cada flujo. No están ausentes por vaguedad; no las incluyo porque son detalles internos que no necesito exponer para explicar el enfoque público y conceptual.
Lo que aprendí al diseñarlo
Mi principal aprendizaje fue que el valor no está solo en el modelo. Depende de la calidad y pertinencia del contexto, de las herramientas adecuadas para una tarea y de mantener a una persona responsable dentro del flujo. La IA puede acelerar una exploración o ayudar a formular una propuesta, pero no reemplaza el trabajo de entender qué información aplica y cuál no.
También aprendí que la documentación cambia de carácter cuando participa en el trabajo diario. Deja de ser un archivo que se visita al inicio de un proyecto y se convierte en una pieza de continuidad: ayuda a retomar, comparar, revisar y explicar. Para lograrlo, debe ser suficientemente específica para un dominio y suficientemente cuidada para no convertir rumores o excepciones en reglas generales.
Cerebro sigue siendo, para mí, una manera de nombrar esa intención: que la experiencia acumulada no dependa únicamente de quién estaba presente cuando se tomó una decisión. Su aporte no es prometer automatización total. Es diseñar un punto de partida más informado para que developers, agentes y skills compartan contexto, mientras las personas conservan el criterio de decidir qué hacer con él.
Si quieres ver una síntesis del caso, puedes revisar el caso de estudio de Cerebro.
Contexto especializado, consulta transversal
- Grupo ficticio: Proyecto A
- Grupo ficticio: Proyecto C
- Grupo ficticio: Proyecto B
- Grupo ficticio: Proyecto D
Fuentes conceptuales: reglas, convenciones, decisiones, estado, estructura, funcionalidad y hallazgos de QA.
Una tarea con contexto por proyecto
- Tarea en Proyecto AEl developer plantea una necesidad y consulta reglas, decisiones y estado relevantes del contexto especializado.
- Antecedente en Proyecto BSe considera como referencia ficticia, no como una receta: el developer evalúa qué corresponde adaptar.
- Developer + agente + skillsTrabajan con ese contexto compartido. El developer decide qué continuar y qué validar.
- Desarrollo y QALa implementación y sus comprobaciones forman parte del trabajo; el resultado no se acepta solo por una propuesta del agente.
- Entrega y aprendizaje validadoLas decisiones, correcciones o hallazgos que correspondan se incorporan, validan y organizan por personas para la próxima tarea.