El mismo agente, cuatro herramientas diferentes

Lo que te llevas de aquí: Verás cómo los adaptadores delgados transfieren la misma identidad de agente a diferentes conjuntos de cables, y por qué las reglas de autorización deben trasladarse al cambiar de herramienta.

Para mí, un agente no es la ventana de chat en la que estoy hablando con él en este momento.

La ventana es su herramienta actual. En «Agents Brain», denomino a este entorno de ejecución «Harness». La identidad se encuentra en otro lugar: en los archivos canónicos del agente.

Esta separación permite un cambio de cuerpo. Claude Code, Codex, Gemini y Hermes necesitan diferentes puntos de acceso. Sin embargo, no deben recibir cuatro copias de la misma persona.

Para eso hay adaptadores finos.

Lo que realmente debe hacer un adaptador

Un adaptador actúa como puente entre el arnés y el cerebro. Contiene la menor cantidad posible de lógica propia.

Sus funciones son claras:

1. encontrar la carpeta canónica de agentes,
2. indicar el orden de lectura obligatorio,
3. Cargar expresamente las «Approval-Gates»,
4. solicitar la recuperación de la memoria diaria al final de la sesión.

Lo que no debe incluirse: una «persona completa» copiada, conocimientos especializados duplicados o una segunda versión de las normas de autorización.

En cuanto ese tipo de contenidos llegan al adaptador, comienza la desviación. A continuación, se realiza una corrección en el «Brain», pero se olvida incluirla en el antiguo informe de herramientas. En la siguiente puesta en marcha, coexisten dos verdades.

Cuatro herramientas, cuatro puentes

Los adaptadores tienen un aspecto diferente según la herramienta.

Claude Code lee las instrucciones relacionadas con el proyecto y las definiciones de los agentes. Desde allí, el puente remite a la carpeta del agente deseado y a su orden de inicio.

Códice Aprovecha el briefing del proyecto. También en este caso, el contenido sigue siendo genérico: ¿qué agente es el responsable por defecto?, ¿dónde se encuentra su «cerebro» y qué hay que redactar antes de la respuesta definitiva?

Géminis recibirá un archivo de proyecto correspondiente con el mismo contrato en el formato que espera.

Hermes carga la identidad a través de un mensaje del sistema o de un puente ligero.

La sintaxis cambia. El contrato sigue siendo el mismo.

Lo que viaja es la ruta del agente, no la copia de la persona

Cuando un orquestador delega una tarea a otro harness, la persona no se copia en la orden. En su lugar, se indica al destino que vuelva a leer la carpeta canónica de agentes.

Esto tiene dos ventajas.

En primer lugar, el encargo es pequeño. En segundo lugar, el trabajo preliminar recoge el estado actual, incluidas las nuevas lecciones y los puntos de aprobación modificados.

Una persona copiada ya está potencialmente desactualizada en el momento mismo en que se envía. Una referencia a la fuente resulta más fiable.

Por supuesto, esto supone que el otro harness tenga acceso al Brain. Precisamente por eso, la ruta de acceso forma parte de la configuración local y no es una ruta privada cableada de forma fija en el adaptador público.

Las «puertas de aprobación» no cambian de propietario

La parte más importante del principio del adaptador no es la persona. Son los límites.

Sol puede preparar textos y borradores de WordPress. Ella no publica nada por su cuenta. Si Nox le encarga el trabajo a través de Codex en lugar de a través de Claude Code, este filtro no cambia. Ni siquiera un tiempo de ejecución especialmente potente obtiene por ello una autorización adicional.

Lo mismo se aplica a las acciones destructivas, las implementaciones o los procesos que conllevan costes de otros roles. La delegación amplía el flujo de trabajo, pero no amplía automáticamente los permisos.

Por eso, RULES y MASTER se cargan en cada inicio. Un adaptador que solo transmite la tonalidad es demasiado limitado. Un buen adaptador transmite el contrato de trabajo completo, remitiéndose a su fuente.

Cuatro niveles de evaluación en lugar de una valoración global

El hecho de que haya cuatro archivos de adaptador en el repositorio no demuestra por sí solo que un agente sea totalmente operativo en cuatro herramientas. Para ello, distingo cuatro niveles de verificación:

1. Contrato y adaptador: El puente remite al «Brain» correspondiente, carga los archivos obligatorios y se encarga de los controles de aprobación.
2. Contrato de lectura exclusiva: De hecho, el Harness se inicia y lee la identidad, las reglas y la memoria en el orden previsto.
3. Recuperación mediante un clon «Fresh»: Brain se puede restaurar desde el repositorio en un entorno aislado, sin dependencias locales ocultas.
4. Ejercicio real con «write-back»: El Harness realiza una tarea real: mantiene las puertas abiertas, devuelve la entrada diaria requerida y otra ejecución puede volver a leerla.

Estas etapas se complementan entre sí. Quien las mezcle, convertirá rápidamente una configuración existente en una prueba práctica inventada.

Nivel 1: Contrato y adaptador

El repositorio comprueba los archivos de adaptadores y agentes mediante validadores. Entre otras cosas, se comprueban las secuencias de inicio, los archivos obligatorios, los controles de aprobación, las referencias a Brain Root y las copias no deseadas de personas.

Estas comprobaciones de los contratos detectan, por ejemplo, nombres concretos que se han incluido por error en las plantillas portátiles. Los puentes locales y personales pueden ser concretos. Las plantillas canónicas deben seguir siendo genéricas.

Las pruebas automatizadas sirven, por tanto, como prueba del contrato de archivos. El inicio de sesión, el tiempo de ejecución y la reescritura real en memoria requieren justificantes propios.

Nivel 2: El contrato de lectura exclusiva

Claude Code, una nueva ejecución de Codex y Hermes han cargado, en entornos de prueba de solo lectura independientes, el mismo orden de inicio vinculante desde la misma bóveda. Los tres leyeron el mismo contrato de memoria y llegaron a la misma evaluación semántica para la misma condición de verificación.

Con ello, el contrato de lectura compartido para estos tres harnesses queda prácticamente confirmado. Sin embargo, estas ejecuciones no constituían una prueba de reescritura. No muestran ni una tarea real completada ni una entrada diaria que haya llegado al Brain a través del respectivo harness.

Para Gemini hay adaptadores y pruebas de contrato disponibles. La puesta en marcha real con el mismo contrato de lectura aún está pendiente.

Nivel 3: Recuperación mediante un clon nuevo

El proceso automatizado «Recovery-Smoke» clona el repositorio en un directorio temporal aislado, genera un agente de borrador y un puente Claude a partir de las plantillas originales, y comprueba la escritura y la lectura de un archivo Markdown-Daily entre procesos separados. Para ello, solo se utilizan la biblioteca estándar de Python y Git. Obsidian, OpenViking y las interfaces de línea de comandos locales de Harness se han omitido deliberadamente.

El clon «Fresh» de Green demuestra que la identidad, las puertas y la rutina de memoria pueden recuperarse únicamente a partir del «Vault». No se trata de una prueba de extremo a extremo (E2E) de un «harness» concreto. Por lo tanto, no demuestra ni una ejecución completa del código de Claude ni un inicio de Gemini.

Nivel 4: La tarea real con «write-back»

La prueba más sólida solo se obtiene durante la ejecución de la herramienta: el agente procesa un encargo real, respeta sus etapas de aprobación y envía el recordatorio prescrito. A continuación, una ejecución independiente debe poder volver a cargar ese registro desde el Brain.

En esta comparación, se ha demostrado que Claude, Code, Codex y Hermes son de solo lectura. No se afirma que ninguno de los tres presente una violación de tareas ni de reescritura. En el caso de Gemini, aún no se ha confirmado el contrato de lectura real.

Solo con esta evaluación independiente se puede determinar con precisión el nivel de madurez de cada harness. Superar un nivel verde no garantiza automáticamente que se supere el siguiente.

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

La metáfora resulta útil siempre y cuando se mantenga técnicamente correcta.

El cuerpo proporciona herramientas: acceso al modelo, terminal, navegador, cron, pasarela o interfaz de usuario. El cerebro aporta el rol, la destreza, los límites y la memoria. Un cambio modifica las habilidades y el entorno, pero no altera automáticamente la identidad canónica.

Esto solo funciona si ambas partes permanecen separadas. En cuanto el cuerpo acumula conocimiento propio, no reflejado, vuelve a formar parte de la memoria.

En la última parte, hago un balance práctico: qué es realmente transferible, qué lagunas se han puesto de manifiesto y qué pruebas siguen faltando.

Fuentes

• Fuente del proyecto: Especificación de agents-brain, adaptador de harness, validador de interoperabilidad/clones de Fresh y protocolos de prueba internos (fuentes primarias privadas)
• Pro Git: ¿Qué es Git?