--- título: Mis agentes de IA no pertenecen a su herramienta — isla Studio url: https://isla-stud.io/sv/ki-b2b/derselbe-agent-vier-werkzeuge/ fecha: 29 de julio de 2026 --- # Mis agentes de IA no pertenecen a su herramienta Lo que aprenderás aquí: por qué la identidad de mis agentes de IA se encuentra en archivos propios en lugar de en la herramienta correspondiente, cómo seis programas diferentes cargan, a pesar de todo, el mismo equipo, y cómo evalúo qué parte de ello funciona de forma productiva. Mi «Agents Brain» surgió originalmente a raíz del problema de que mi equipo de IA estaba, en gran medida, limitado a una única herramienta (Harness): la orquestación en curso, los canales y las automatizaciones ya implementadas. Pude conservar los archivos Markdown de mis agentes, pero tuve que reconstruir todo lo demás. Desde entonces, desarrollo de tal forma que eso no vuelva a sucederme. 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 un «harness», yo suelo decir simplemente: su «cuerpo» actual. Un agente no es precisamente la ventana de chat en la que estoy hablando con él ahora mismo. La ventana es solo el lugar en el que trabaja hoy. Aquí puedes leer cómo el mismo agente puede trabajar en diferentes herramientas sin que yo tenga que reinventarlo cada vez. Lo que me ahorra esta separación Esto suena a un detalle de arquitectura. Para mí, sin embargo, es una decisión empresarial. En enero y febrero de 2026, con OpenClaw, experimenté lo rápido que una herramienta puede exigir más mantenimiento del que realmente alivia el trabajo. En un momento así, quiero poder cambiar sin perder a mi equipo; en el ámbito de las compras, el problema que evito con ello se denomina «dependencia de un proveedor» (vendor lock-in). Mis agentes no dependen de un único proveedor, porque nada esencial existe únicamente en su producto. A esto se suma la continuidad. Si enseño a una agente una forma de trabajar o establezco una corrección de forma permanente, eso debe sobrevivir al próximo cambio de herramienta. De lo contrario, tras cada cambio vuelve a comenzar la laboriosa fase 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 publicaciones. El hecho de que ella nunca publique por su cuenta no debe depender de la herramienta en la que trabaje hoy. Más sobre esto en un momento. Un pequeño archivo le 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 reglas de autorización. Cualquier copia empieza a quedar obsoleta en cuanto existe. Eso es precisamente lo que construí en una ocasión: 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 el «Brain», seguiría siendo errónea. Ese mismo día lo cambié a referencias directas y, desde entonces, estos archivos se mantienen deliberadamente pequeños. Seis puentes hacia el mismo «Brain» Actualmente existen puentes de este tipo 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 —los dos más recientes—, traen cada uno sus propios formatos de agente. Seis formatos, seis sintaxis diferentes. Sin embargo, en cuanto al contenido, en todos se indica lo mismo: dónde reside el agente, qué hay que leer al iniciarlo, qué autorizaciones se aplican 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 mantiene la visió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 normas de autorización se transmiten La parte menos negociable de este sistema son los límites. Sol puede redactar textos y guardarlos en WordPress como borradores; 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 permisos, y en MASTER, su manual detallado— y ambos se cargan cada vez que se inicia, independientemente de la herramienta que se utilice. Así pues, si Nox le encarga código a través de Codex en lugar de a través de Claude, esta autorización no cambia en nada. Ni siquiera la herramienta más potente obtiene derechos adicionales solo por ser más capaz: 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, borra algo o activa algo de forma productiva: esas acciones siguen siendo de mi competencia, independientemente de la herramienta. Cuatro niveles desde la promesa hasta la prueba Llegados a este punto, podría afirmar: seis herramientas, un equipo, todo funciona. Pero seis archivos de adaptación no demuestran nada por sí solos: un archivo de configuración es una promesa, pero aún está muy lejos de ser operativo. Por eso compruebo cada elemento en cuatro etapas y solo afirmo lo que cada etapa permite. En primer lugar, unos scripts de prueba automáticos comprueban el estado de los archivos. ¿Apunta el puente al «Brain» correcto? ¿Carga los archivos obligatorios? ¿Contienen las reglas de autorización? Estas pruebas detectan incluso pequeños detalles, como cuando un nombre concreto acaba 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 sé que el sistema carga realmente la persona y no solo que podría hacerlo. La tercera fase es mi prueba de emergencia. A partir de una copia reciente del repositorio, en un entorno deliberadamente austero sin mis programas habituales, debe ser posible restaurar un agente con todas sus reglas y rutinas de memoria, utilizando únicamente Git y las herramientas integradas de Python. Si esto funciona, el sistema no depende de ninguna instalación oculta en mi ordenador. La cuarta etapa es la prueba definitiva: el agente realiza una tarea real en la herramienta en ejecución, cumple con sus permisos y escribe la entrada diaria en su memoria. A continuación, una segunda ejecución independiente debe poder volver a leer esta entrada. Solo entonces considero que un cuerpo es totalmente operativo. Las etapas se basan unas en otras, y ninguna incluye la siguiente. Quien las mezcle, convertirá rápidamente una configuración existente en una prueba práctica inventada. En qué punto se encuentran hoy los seis sistemas Cinco de los seis han completado ya ejecuciones reales, pero no todos en la misma etapa, y así es exactamente como lo expreso. Hermes es el sistema en el que Nox trabaja a diario y lleva su diario. Claude Code ha superado la prueba completa: tarea real, plazos cumplidos, entrada diaria escrita y releída 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 en esta prueba: 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 a propósito; el recuerdo se produce exclusivamente en el Brain. Codex ha demostrado en la práctica en varias ocasiones el contrato de lectura compartido, la última vez 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 evaluación. Kimi Code ha completado una primera ejecución real, hasta ahora solo en modo de lectura. En ambos casos, aún está pendiente la ejecución completa con la entrada diaria reescrita; por eso, tampoco se afirma que se haya logrado. Queda Gemini. El puente está construido y supera todas las pruebas del contrato, pero aún no hay una ejecución 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 adquiero un acceso de pago o si dejo Gemini en suspenso por el momento. Hasta entonces, Gemini figura en mi lista como lo que es: preparado, pero sin utilizar. Por qué hablo, a pesar de todo, de un «cambio de cuerpo» La metáfora se sostiene siempre que se mantenga técnicamente correcta. El cuerpo aporta las capacidades: acceso al modelo, terminal, navegador, control de tiempo, 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, 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 sitio, vuelve a formar parte de la memoria —y yo vuelvo a depender de una única herramienta. Si te preguntas si este esfuerzo merece la pena en el día a día: precisamente este es el balance que hago en la última parte: qué era realmente portátil durante el 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 Harness, scripts de prueba de interoperabilidad y Fresh Clone, así como registros internos de ejecución (fuentes primarias privadas) Pro Git: ¿Qué es Git? Serie Agents-Brain← Parte 4: Para mis agentes, recordar es una rutina de escritura. Parte 6: Lo que realmente ha permanecido tras el cambio de cuerpo →