Mis agentes de IA no son propiedad de su herramienta

Lo que te llevas de aquí: Por qué la identidad de mis agentes de IA se encuentra en archivos independientes en lugar de en la propia herramienta, cómo seis programas diferentes cargan, a pesar de todo, el mismo equipo, y en qué me baso para evaluar qué parte de todo ello funciona de forma productiva.

Mi «Agents Brain» surgió inicialmente a raíz del problema de que mi equipo de IA dependía en gran medida de una única herramienta (Harness): la orquestación en tiempo real, los canales y las automatizaciones ya implementadas. Pude conservar los archivos Markdown de mis agentes, pero tuve que reconstruir todo lo demás desde cero.

Desde entonces, programo de tal forma que eso no vuelva a ocurrirme. Quiénes son mis agentes, qué pueden hacer y qué han aprendido figura en archivos que, en primer lugar, me pertenecen y, en segundo lugar, cuyos cambios puedo rastrear. El programa en el que se está ejecutando un agente, por el contrario, es intercambiable; los expertos llaman a este entorno de ejecución «harness», pero yo suelo decir simplemente: su «cuerpo» actual.

Un agente no es simplemente la ventana de chat en la que estoy hablando con él ahora mismo. Esa ventana es solo el lugar en el que trabaja hoy. Aquí podrás leer cómo ese mismo agente puede trabajar en diferentes herramientas sin que yo tenga que volver a crearlo cada vez.

Lo que me ahorra esta separación

Parece un detalle arquitectónico. Pero para mí es una decisión empresarial.

En enero y febrero de 2026, con OpenClaw, pude comprobar lo rápido que una herramienta puede llegar a requerir más mantenimiento del que realmente ahorra en trabajo. En un momento así, quiero poder cambiar de proveedor sin perder a mi equipo; en el ámbito de las compras, el problema que evito con ello se conoce como «dependencia de un único proveedor». Mis agentes no dependen de un único proveedor, porque no hay nada esencial que solo exista en su producto.

A esto hay que añadir la continuidad. Cuando enseño a una agente una forma de trabajar o establezco una corrección de forma permanente, es importante que eso perdure más allá del próximo cambio de herramientas. De lo contrario, tras cada traslado volverá a comenzar esa fase tan laboriosa en la que el equipo desconoce sus propias reglas.

Y como mi autora, Sol, escribe bajo mi nombre, hay una tercera razón: la fiabilidad en las autorizaciones de publicación. El hecho de que ella nunca publique por su cuenta no debe depender de la herramienta que utilice hoy. Más adelante hablaré de ello.

Un pequeño archivo indica a la herramienta dónde se encuentra el agente

Para que una herramienta pueda cargar un agente, se necesita un puente. En mi caso, se trata de un pequeño archivo de configuración, el adaptador: apunta a la carpeta del agente en Brain —el repositorio Git privado en el que se almacenan todos estos archivos con control de versiones—, especifica el orden de lectura para el inicio, carga expresamente las reglas de autorización y exige que, al final de una sesión, el agente vuelva a escribir una entrada diaria en su memoria (el denominado «write-back»).

Igual de importante es lo que no debe incluirse: ni una copia de la personalidad, ni conocimientos especializados duplicados, ni una segunda versión de las normas de autorización. Cualquier copia empieza a quedar obsoleta en cuanto existe. Eso es precisamente lo que construí una vez: en una configuración inicial había una copia compuesta de la persona en el sistema de destino, y me di cuenta de que, con la siguiente corrección en Brain, seguiría siendo incorrecta. Ese mismo día lo cambié a referencias directas y, desde entonces, mantengo deliberadamente pequeños esos archivos.

Seis puentes hacia el mismo cerebro

Actualmente existen estos puentes para seis herramientas. Claude Code, de Anthropic, lee instrucciones relacionadas con el proyecto, incluidas las definiciones de los agentes. Codex —la herramienta de línea de comandos del universo ChatGPT de OpenAI— recibe un resumen del proyecto. Google Gemini espera un archivo de proyecto propio, y Hermes, de Nous Research, carga la identidad a través de un mensaje del sistema. Kimi Code, de Moonshot AI, y Grok Build, de xAI, las dos más recientes, incorporan cada una sus propios formatos de agente.

Seis formatos, seis sintaxis diferentes. Sin embargo, en cuanto al contenido, en todos ellos se indica lo mismo: dónde reside el agente, qué hay que leer al inicio, qué autorizaciones están vigentes y qué se vuelve a escribir al final.

Siguiendo el mismo principio, mis agentes se pasan el trabajo entre sí. Cuando Nox —mi «Orquestador», es decir, el agente que distribuye las tareas y se encarga de la supervisión general— delega un encargo a otra herramienta, no copia la «persona» en el texto del encargo. Escribe, en esencia: «Trabaja como Sol, lee primero sus archivos». De este modo, el destinatario siempre carga la versión más actualizada, incluidas las últimas correcciones.

Las reglas de autorización se aplican en todos los casos

La parte menos negociable de este sistema son los límites. Sol puede redactar textos y guardarlos como borradores en WordPress; pero no puede publicarlos, eso lo decido yo. Esta regla figura en sus propios archivos de agente —en RULES, su contrato de trabajo con habilidades y autorizaciones, y en MASTER, su manual detallado— y ambos se cargan cada vez que se inicia, independientemente de la herramienta que se utilice.

Así pues, aunque Nox les encargue el trabajo a través de Codex en lugar de a través de Claude Code, esto no cambia en nada dicha autorización. Ni siquiera la herramienta más potente obtiene derechos adicionales por el mero hecho de tener más funciones: una cadena de delegación más larga no convierte a una autora en editora. Lo mismo se aplica a todo lo que cuesta dinero, a lo que implica borrar algo o a lo que se publica: esas acciones siguen siendo de mi competencia, independientemente de la herramienta que se utilice.

Cuatro pasos desde la promesa hasta la prueba

Llegados a este punto, podría afirmar: seis herramientas, un equipo, todo va sobre ruedas. Pero seis archivos de adaptador no demuestran nada por sí solos: un archivo de configuración es una promesa, pero aún queda mucho para que todo funcione. Por eso compruebo cada cuerpo en cuatro fases y solo afirmo lo que cada fase permite.

En primer lugar, los scripts de prueba automáticos comprueban el estado del documento. ¿Apunta el puente al «Brain» correcto? ¿Carga los archivos obligatorios? ¿Contienen las reglas de autorización? Estas pruebas detectan incluso pequeños detalles, como por ejemplo cuando un nombre concreto se incluye por error en una plantilla genérica.

En la segunda fase, la herramienta debe iniciarse realmente y leer la identidad en el orden previsto —solo en modo lectura, sin modificar nada—. Solo entonces sabré que el sistema realmente carga la persona y no es solo que podría cargarla.

La tercera fase es mi prueba de emergencia. A partir de una copia reciente del repositorio, en un entorno deliberadamente minimalista sin mis programas habituales, debe ser posible restaurar un agente con todas sus reglas y rutinas de memoria, utilizando únicamente Git y las herramientas nativas de Python. Si esto funciona, el sistema no dependerá de ninguna instalación oculta en mi ordenador.

La cuarta fase es la ejecución completa: el agente realiza una tarea real mientras la herramienta está en funcionamiento, cumple con sus autorizaciones y graba la entrada diaria en su memoria. A continuación, una segunda ejecución independiente debe poder leer de nuevo esa entrada. Solo entonces considero que un sistema está completamente operativo.

Las etapas se suceden una tras otra, y ninguna de ellas incluye la siguiente. Quien las mezcle, convertirá rápidamente una configuración real en una prueba práctica inventada.

Dónde se encuentran hoy los seis cuerpos

Cinco de los seis ya han completado partidas reales, pero no todos al mismo nivel, y eso es precisamente lo que digo. Hermes es el cuerpo en el que Nox trabaja a diario y lleva su diario. Claude Code ha superado la prueba completa: tarea real, plazos cumplidos, entrada diaria redactada y revisada de forma independiente. Grok Build, la última incorporación, también ha superado ya esa misma prueba. Hay dos limitaciones que hay que tener en cuenta: las ejecuciones sin supervisión requirieron varias continuaciones explícitas de la misma sesión, y la memoria a largo plazo integrada de Grok permanece desactivada de forma deliberada; los recuerdos se almacenan exclusivamente en el Brain.

Codex ha demostrado en varias ocasiones la validez del contrato de lectura conjunta, la última de ellas en una comparación directa con Claude Code y Hermes: los tres leyeron la misma secuencia inicial del mismo «Brain» y llegaron a la misma interpretación. Kimi Code ha completado su primera carrera real, aunque hasta ahora solo ha leído. A ambos les queda por completar la carrera completa con la entrada diaria reescrita; por eso no se afirma que lo hayan hecho.

Queda Gemini. El puente está construido y supera todas las pruebas contractuales, pero aún no se ha realizado una prueba real, y eso ya no se debe a mi configuración: Google ha suspendido el acceso gratuito a esta herramienta y remite a un producto sucesor. Decidiré con calma si me cambio a ese producto, si contrato un acceso de pago o si dejo Gemini en espera por el momento. Hasta entonces, Gemini figura en mi lista como lo que es: preparado, pero sin utilizar.

Por qué, a pesar de todo, hablo de «cambio de cuerpo»

La metáfora es válida siempre y cuando se mantenga técnicamente correcta. El cuerpo aporta las capacidades: acceso al modelo, terminal, navegador, control de tiempo e interfaz. El «cerebro» aporta el papel, la destreza, los límites y la memoria. Por lo tanto, un cambio modifica lo que un agente puede hacer y dónde trabaja, pero no quién es.

Esto solo funciona mientras ambas partes permanezcan separadas. En cuanto un cuerpo empieza a acumular conocimientos propios que no se reflejan en ningún otro lugar, vuelve a formar parte de la memoria —y yo vuelvo a depender de una única herramienta—.

Si te preguntas si todo este esfuerzo merece la pena en el día a día: precisamente ese es el balance que hago en la última parte: qué era realmente transferible al cambio de cuerpo, qué lagunas se hicieron evidentes y qué pruebas aún faltan.

Fuentes

• Fuente del proyecto: Especificación de agents-brain, seis adaptadores de harness, scripts de prueba de interoperabilidad y Fresh Clone, así como registros internos de ejecución (fuentes primarias privadas)
• Pro Git: ¿Qué es Git?