Los agentes gestionados ahora responden ante el Harness
A las cuatro de la tarde, la sesión de Claude Code de un desarrollador abre una sesión de trabajo sobre la Billing API para añadir prorrateo a los cambios de plan. Veinte minutos después, mientras esa sesión sigue trabajando, una ejecución programada de Archyl con el perfil backend-fixer coge un ticket sobre el redondeo de facturas, que también vive en la Billing API.
Hasta esta semana, esto es lo que hacía la ejecución programada. Abría su propia sesión de trabajo, como ya hacían las ejecuciones gestionadas. El gate de preflight devolvía warn, con el motivo 1 target element(s) are being worked on by other active sessions — coordinate before changing them. Ese veredicto aparecía en el feed de eventos de la ejecución. Y después la ejecución arrancaba igualmente, porque nada actuaba sobre el veredicto y nadie estaba pendiente de una ejecución programada con quien poder coordinarse.
Prefiero decirlo claramente: en las ejecuciones alojadas, el envoltorio era casi cosmético. El gate se mostraba y se ignoraba. Los archivos que cambiaba el agente nunca se vinculaban a su sesión, así que la memoria acababa en los elementos que el texto de la tarea mencionaba por casualidad. Y la sesión se cerraba con un resumen de una línea, que dejaba muy poco que aprender al siguiente agente.
Eso cambió esta semana. El harness ahora dirige las ejecuciones gestionadas, y las ejecuciones alojadas y los agentes de código locales se coordinan sobre el mismo modelo.
Ejecutar un agente se está convirtiendo en la parte fácil
Tres de los nombres más grandes del sector ofrecen ya un lugar alojado donde ejecutar agentes. La documentación de Anthropic describe Claude Managed Agents como "un harness de agentes preconstruido y configurable que se ejecuta en infraestructura gestionada", con sandboxes en la nube o autoalojados, sesiones persistentes y ejecuciones programadas con cron. La Agents API de OpenAI, anunciada en beta pública el 10 de septiembre, ejecuta el bucle del agente en la infraestructura de OpenAI y se encarga de "la orquestación, las sesiones de larga duración y la gestión del contexto". Cursor Projects, anunciado el mismo día, pone un agente coordinador en su propia máquina en la nube, que delega en subagentes y puede ejecutarse según una programación o seguir tus pull requests.
Son buenos productos, y apuntan en la misma dirección: sandbox, bucle de tools, sesiones y programaciones se están convirtiendo en algo que eliges de una lista.
Lo que un runtime no puede saber por sí solo es tu sistema. A qué container pertenece el código de facturación. Quién es su responsable. El contrato del que dependen sus consumidores. La decisión que hizo deliberada una frontera. Y lo que importa cuando nadie está mirando: qué otro agente, incluidos los que este runtime no lanzó, está trabajando ahora mismo en qué parte.
Ese conocimiento no puede vivir en un runtime, porque tus agentes no se ejecutan todos en el mismo. Algunos corren en un portátil, otros en CI, otros en un worker alojado. Así que lo vemos así: tu runtime, nuestra arquitectura. Sea lo que sea lo que ejecuta al agente, el modelo ante el que responde es el mismo.
Las ejecuciones de agentes gestionadas de Archyl, lanzadas en abril, son un runtime más entre ellos. Esta semana empezaron a comportarse como tal. También puedes seguir y dirigir una ejecución en directo.
Ahora una ejecución puede rechazarse, con su motivo
La coordinación es opcional. Cada perfil de agente tiene un ajuste nuevo en Coordinación, Respetar el trabajo de otros agentes, desactivado por defecto. Con él activado, la ejecución abre su sesión de trabajo en exclusiva, y el veredicto del gate decide lo que pasa después.
Si otro agente tiene una reserva sobre los mismos elementos, la ejecución se rechaza, tanto si ese agente es Claude Code en el portátil de alguien como si es otra ejecución gestionada. La ejecución termina antes de clonar nada, el evento del gate dice Ejecución rechazada, y el motivo indica quién está trabajando ahí y en qué. Para la tarde de antes:
session denied by preflight gate: "Billing API" is being worked on by
claude-code/vincent (add proration to plan changes)
El formato es el real; la tarea es un ejemplo. Quien lea la ejecución por la mañana sabe exactamente con quién hablar.
Si el gate solo avisa, por ejemplo porque a la tarea se le aplica un guardarraíl de nivel error, la ejecución ni arranca ni falla. Espera en Pendiente de aprobación sin ocupar ninguna de las plazas de concurrencia de tu organización. La página de la ejecución lista los motivos, con Aprobar e iniciar y Cancelar ejecución.
Aprobar no da por bueno el veredicto antiguo sin más. Vuelve a evaluar el gate, así que si un agente local tomó una reserva sobre esos elementos mientras la ejecución esperaba, la ejecución aprobada se rechaza igualmente. Una ejecución que nadie aprueba en 24 horas se cancela.
Por qué una ejecución en espera no retiene nada
Mientras una ejecución espera, su sesión se descarta. La sesión que lanzó el aviso se cancela, sus reservas se van con ella, y la aprobación abre una nueva. Mantener las reservas sonaría más prudente y sería peor: una ejecución que nadie llega a aprobar mantendría a todos los demás agentes lejos de esos elementos durante un día, diciéndole a cada uno que algo estaba trabajando ahí cuando no había nada.
Esto sigue una línea que trazamos en agosto. Las reservas son consultivas, no bloqueos. La exclusividad es algo que pide un perfil, no algo que impone la plataforma, y una ejecución que espera a una persona no reclama nada.
El Guard se ha mudado al worker
La sesión cubre la intención. El Guard cubre lo que se escribe. Los agentes locales lo tienen como hook de Claude Code desde agosto, y las ejecuciones gestionadas tienen ahora la misma comprobación dentro del worker.
Cuando el proyecto tiene un repositorio vinculado, cada write_file y edit_file que hace el agente se comprueba contra las reglas de conformidad del proyecto antes de que el cambio se aplique. Una violación crítica rechaza la escritura, y el agente lee qué regla ha incumplido y por qué:
blocked by Archyl Guard: 1 critical architecture violation(s) in
backend/internal/adapter/http/handlers/invoice.go. Change the content so it
conforms, then write again:
- [critical] No direct database access from HTTP handlers — move the query behind a service
El agente mueve la consulta y vuelve a escribir. Una violación de severidad alta deja pasar la escritura con un aviso. Si la propia comprobación falla o agota el tiempo, la escritura se aplica: el Guard nunca bloquea a un agente por sus propios errores, porque una comprobación de gobernanza que rompe el trabajo que gobierna acaba desactivada.
Cada comprobación lleva además el ID de sesión, que atribuye el archivo a la sesión de la ejecución mientras el agente trabaja. Eso importa dos secciones más abajo.
El agente conoce su sesión, pero no es suya
El prompt de la ejecución ahora nombra su sesión y le dice al agente que la plataforma la abrió y la cerrará, "así que no hay tools de sesión que llamar". El agente no puede abrir una segunda sesión ni terminar esta antes de tiempo. El ciclo de vida pertenece a la plataforma, la única parte que sabe cuándo ha terminado una ejecución.
Lo que sí es del agente es su relato del trabajo. Justo antes de terminar, llama una vez a report_outcome, con un resumen honesto, las decisiones que merecen un ADR, los seguimientos para el trabajo que queda pendiente y las memorias del briefing en las que se ha apoyado. La descripción de la tool le pide que deje fuera de las decisiones los hallazgos circunstanciales, porque las decisiones se reproducen en sesiones futuras y una nota de depuración no debería atar a nadie.
El resultado cae donde cayó el trabajo
Cuando la ejecución termina, Archyl primero vincula a la sesión los archivos que cambió la ejecución. Esto arregla el más silencioso de los tres huecos. Los elementos que reserva una sesión se deducen del texto de la tarea, y el texto de la tarea es una suposición. Los archivos modificados son lo que pasó. La memoria va ahora a los elementos que tocó el trabajo real, no a todo lo que mencionaba el ticket.
Después cierra la sesión, guarda el resumen como memoria en esos elementos y da crédito a las memorias que el agente dice haber usado, que es la señal de la que aprende la ordenación de la memoria.
Las decisiones solo se registran si la ejecución terminó con éxito. Se convierten en memoria del proyecto y abren un Architecture Change Request en borrador, para que una persona revise cómo debe ponerse al día el modelo. Una ejecución fallida conserva su resumen y sus seguimientos, que es lo que necesita el siguiente intento, pero no registra decisiones. Un trabajo que no se completó no tiene nada que respaldar.
La página de la ejecución muestra todo esto en una tarjeta Resultado de la sesión de trabajo: resumen, decisiones, seguimientos, los elementos tocados, las memorias citadas y un enlace al Change Request. Un elemento que tiene otra sesión aparece marcado como Retenido por otra sesión de trabajo, para que una ejecución que editó código dentro de la reserva de otro no pase desapercibida.
Dos tipos de agente, un modelo
Esta es la pieza que buscaba muchos agentes, una arquitectura: coordinación entre agentes que nunca comparten un proceso, en ambas direcciones.
Una ejecución gestionada abre su sesión como managed-agent/<profile name>. Invierte la escena del principio de este post: la ejecución programada está en la Billing API cuando un desarrollador arranca Claude Code sobre ella. Su briefing ahora incluye la ejecución como conflicto:
- **Conflicts** (someone else is already working here):
- Billing API — held by managed-agent/backend-fixer: fix rounding on prorated invoices
Al agente local se le indica que se coordine antes de cambiar ese elemento, la consola Fleet muestra las dos sesiones, y la que termine deja memoria que la otra leerá la próxima vez.
También salió esta semana
Brevemente, porque el resto se apoya en ello. Los perfiles incluyen ahora skills integradas y listas de tools permitidas, así que un revisor de solo lectura puede limitarse a read_file, list_* y get_*. Los heartbeats del worker detectan ejecuciones muertas y las retiran, la API key de cada ejecución se revoca cuando la ejecución termina, y una ejecución fallida sigue publicando su trabajo como pull request en borrador. Las ejecuciones siempre corren en el propio worker de Archyl, con el proveedor de IA de tu organización cuando BYO está activado.
Lo que no hace
La coordinación solo ve a los agentes que usan el harness. Una reserva existe porque un agente abrió una sesión. Un agente que edita el repositorio sin sesión es invisible para el gate, y una ejecución que respeta el trabajo de otros agentes arrancará justo a su lado.
El worker no ejecuta tus tests. Tiene tools de archivos del espacio de trabajo (leer, escribir, editar, listar, grep) y ningún shell. No puede compilar el proyecto ni ejecutar la suite, así que una tarjeta de resultado limpia significa que las escrituras pasaron el Guard, no que el código compile. De eso se sigue encargando la CI.
Las decisiones de un agente no están revisadas. Una decisión en la tarjeta de resultado es una afirmación del agente hasta que alguien revise el Change Request. Esa revisión es lo importante, no un trámite.
El Guard necesita algo contra lo que comprobar. Sin repositorio vinculado no hay comprobación de escrituras, y un conjunto vacío de reglas de conformidad deja pasar todas las escrituras.
Por dónde empezar
Elige un perfil, el que se ejecuta según una programación sobre código que la gente también cambia a mano, y activa Respetar el trabajo de otros agentes en Coordinación. Deja los demás como están.
Si rechaza una ejecución, el motivo nombra al agente y la tarea que se solapaba con ella. Hasta ahora, ese solapamiento habría pasado sin que nadie se enterara.
Las ejecuciones de agentes gestionadas, las sesiones de trabajo, el Guard y la memoria forman parte de archyl. Todos los ajustes mencionados están en la documentación de las ejecuciones de agentes gestionadas, y la parte local está en la guía del Harness. Lecturas relacionadas: muchos agentes, una arquitectura, sesiones de trabajo para agentes de código, memoria para agentes de código y el lanzamiento de las ejecuciones de agentes gestionadas.