Ejecuciones de Agentes Gestionadas

Managed agent runs in the Agent Hub

Las Ejecuciones de Agentes Gestionadas te permiten despachar agentes de IA autónomos directamente desde Archyl. Asígnales una tarea, elige el perfil que define cómo se comportan, conéctalos a servicios externos mediante conectores MCP, define una programación recurrente y déjalos trabajar en tu código base con contexto arquitectónico completo.

Ve a Hub de Agentes → Ejecuciones en la barra lateral para gestionar tus ejecuciones, a Hub de Agentes → Perfiles para definir cómo se comportan los agentes, o a Hub de Agentes → Programaciones para la automatización recurrente.

Descripción general

Una ejecución gestionada es una sola ejecución del agente. El agente:

  1. Clona el repositorio de tu proyecto en un espacio de trabajo nuevo en el worker de agentes
  2. Recibe tu contexto arquitectónico (modelo C4, ADRs, reglas de conformidad, contratos de API, stack tecnológico) junto con el briefing de su sesión de trabajo: los elementos que toca la tarea, lo que las sesiones anteriores aprendieron sobre ellos y el veredicto del preflight
  3. Ejecuta la tarea que definiste, invocando herramientas y tomando decisiones dentro de los límites de su perfil
  4. Publica sus cambios de código como pull request y reporta con una traza completa de cada acción

Las ejecuciones pueden dispararse manualmente (una sola vez) o automáticamente mediante programaciones.

Iniciar una ejecución

  1. Ve a Hub de Agentes → Ejecuciones
  2. Selecciona tu proyecto en el menú desplegable
  3. Haz clic en Nueva ejecución
  4. Elige un perfil
  5. Escribe una descripción de la tarea (por ejemplo, "Verificar dependencias obsoletas y crear un resumen")
  6. Opcionalmente, adjunta conectores (ver más abajo)
  7. Haz clic en Iniciar ejecución

El agente comienza a trabajar de inmediato. Puedes seguir el progreso en tiempo real en la página de detalle de la ejecución.

Perfiles de agentes

Un perfil es una definición reutilizable de cómo se comporta un agente. Cada ejecución y cada programación usa uno. Archyl crea un perfil backend-fixer para tu organización en la primera visita; puedes crear más en Hub de Agentes → Perfiles.

Al eliminar un perfil se conserva el historial de las ejecuciones que realizó. Las programaciones que lo usaban se pausan y se marcan como Perfil eliminado; elige otro perfil en la programación para reanudarla.

Ajuste Qué hace
Prompt de sistema Instrucciones que se añaden a cada ejecución del perfil
Skills Playbooks integrados que sigue el agente (ver más abajo)
Herramientas permitidas Patrones glob que limitan qué herramientas puede invocar el agente — p. ej. read_file, list_*, github__*. Déjalo vacío para permitir todas las herramientas que adjunta la ejecución. Las herramientas de la plataforma (report_outcome, propose_plan, update_plan, ask_human, open_repository) siguen disponibles diga lo que diga la lista
Coste máximo La ejecución se detiene en cuanto su gasto estimado en modelo supera este límite
Duración máxima Límite de tiempo real de la ejecución
Tokens de salida máx. Límite de salida de cada llamada al modelo
Tokens de entrada máx. Reduce el presupuesto de prompt de las ejecuciones con modelos de Anthropic (el modelo de Archyl, Anthropic o Bedrock): los turnos más antiguos se compactan para no superarlo, y para quedar por debajo de 90.000 tokens sea cual sea el ajuste. Las ejecuciones con OpenAI y con endpoints compatibles con OpenAI lo ignoran y dejan que el proveedor trunque el contexto

Skills

Las skills son playbooks que mantiene Archyl, siempre alineados con las herramientas de las que disponen realmente los agentes. Actívalas por perfil en lugar de copiar instrucciones en el prompt.

Skill El agente…
Architecture memory Recupera lo que las sesiones anteriores aprendieron sobre un elemento antes de trabajar en él, y memoriza los escollos y convenciones que el código por sí solo no muestra
Conformance first Comprueba cada archivo que modificó contra tus reglas de conformidad antes de terminar
Decision records Registra un ADR para las decisiones que lo merecen — y solo para esas
Impact analysis Revisa los consumidores de una interfaz antes de cambiarla, e indica el equipo responsable cuando hace falta un cambio coordinado
Model sync Actualiza el modelo C4 cuando su cambio añade, elimina o renombra un contenedor, un componente o una relación

Un perfil con una skill desconocida o un patrón de herramientas permitidas no válido se rechaza al guardarlo.

El perfil predeterminado backend-fixer activa Architecture memory, Conformance first y Decision records.

Página de detalle de la ejecución

Cada ejecución tiene una página de detalle que muestra:

Campo Descripción
Estado pending, awaiting_approval, running, waiting_for_input, succeeded, failed o cancelled
Tiempo transcurrido Cuánto tiempo lleva trabajando el agente
Heartbeat Cuándo se reportó por última vez el worker de agentes, y la fecha límite de la ejecución
Run ID Identificador único para trazabilidad
Plan El plan del agente, como una checklist que se completa en directo
Actividad Cada acción que realiza el agente, en orden cronológico
Cambios Los archivos que escribió el agente, con sus diffs y la pull request

El feed de eventos muestra tarjetas expandibles para cada acción:

  • Llamadas a herramientas — Muestra el nombre de la herramienta, los parámetros de entrada y la salida. Cada tarjeta muestra una etiqueta de origen que indica de qué conector proviene la herramienta (por ejemplo, github, archyl, linear).
  • Mensajes — El razonamiento y las decisiones del agente.
  • Resultado — El desenlace, el consumo de tokens, la pull request y los archivos que modificó el agente.
  • Errores — Resaltados para identificarlos rápidamente.

Dirigir un agente en ejecución

Mientras una ejecución está en curso, escribe un mensaje en el cuadro de dirección para reorientar al agente sin cancelarlo ("sáltate la migración, céntrate en el handler"). El mensaje se pone en cola de inmediato y se inyecta en la conversación del agente en su siguiente paso; el feed muestra Mensaje de dirección entregado al agente en cuanto el agente lo recibe.

Cuando una ejecución se detiene antes de tiempo

Si una ejecución falla, alcanza su límite de coste o de tiempo, o agota sus iteraciones, el trabajo que ya hizo no se pierde: Archyl lo publica como una pull request en borrador que explica por qué se detuvo. Consulta Pull request más abajo. Una ejecución que cancelas no publica nada.

Garantías de fiabilidad

  • Se detectan los workers caídos. El worker de agentes se reporta cada 10 segundos. Una ejecución cuyo worker lleva 3 minutos en silencio, o que sigue en marcha 10 minutos después de su límite de tiempo, se marca automáticamente como failed y libera su plaza.
  • Las ejecuciones atascadas no retienen plazas. Una ejecución que ningún worker de agentes ha recogido en 10 minutos falla, y también una ejecución que ha esperado la respuesta de una persona durante más de 1 hora y 10 minutos.
  • Las credenciales no sobreviven a las ejecuciones. Cada ejecución recibe su propia clave de API de Archyl de corta duración, que se revoca en cuanto termina.
  • La cancelación llega al agente. Una ejecución cancelada se detiene en su siguiente reporte aunque la petición directa de parada nunca haya llegado al worker.

Sesiones de trabajo y coordinación

Cada ejecución va envuelta en una sesión de trabajo de Archyl, el protocolo que el harness de Archyl ofrece a los agentes de código locales. La plataforma abre y cierra la sesión; el agente nunca la gestiona.

La sesión de trabajo de una ejecución

Cuando arranca una ejecución, Archyl abre una sesión sobre los elementos de arquitectura que toca la tarea. Toma reservas sobre esos elementos, calcula el veredicto del gate de preflight (allow, warn o deny) y añade al briefing del agente las decisiones, guardarraíles y memorias relevantes. El veredicto aparece en el feed de eventos como un evento Control.

Respetar el trabajo de otros agentes

Respetar el trabajo de otros agentes es un ajuste del perfil, en Coordinación, desactivado por defecto. Cuando está activado, la sesión se abre en exclusiva:

  • Otro agente ya tiene los elementos. Si otro agente tiene una reserva sobre los mismos elementos, ya sea un agente de código como Claude Code u otra ejecución gestionada, la ejecución se rechaza. El motivo indica quién está trabajando ahí.
  • El gate solo avisa, por ejemplo porque se aplica un guardarraíl de nivel error. La ejecución queda Pendiente de aprobación sin ocupar ninguna plaza de concurrencia. La página de la ejecución muestra los motivos, junto con Aprobar e iniciar y Cancelar ejecución.

Al aprobar se vuelve a comprobar el gate: un conflicto que haya surgido mientras tanto sigue rechazando la ejecución. Una ejecución que nadie aprueba en 24 horas se cancela.

Con el ajuste desactivado, la ejecución arranca sea cual sea el veredicto del gate; el agente lee los motivos en su briefing.

Guard en las escrituras de archivos

Siempre que el agente trabaja en un repositorio, vinculado al proyecto o abierto con el conector de GitHub, cada llamada a write_file y edit_file se comprueba contra las reglas de conformidad del proyecto antes de que el cambio se aplique:

Violación Efecto
critical La escritura se rechaza. El agente ve qué regla ha incumplido y corrige el cambio
high La escritura se aplica, con un aviso para el agente

Si la propia comprobación falla, la escritura se aplica: el Guard nunca bloquea a un agente por sus propios errores. Se comporta igual que el hook Guard de los agentes de código locales, descrito en la guía del harness.

Resultado de la sesión de trabajo

Antes de terminar, el agente informa de su resultado: un resumen, sus decisiones, los seguimientos y las memorias en las que se ha apoyado. Cuando la ejecución termina, Archyl:

  1. Atribuye los archivos modificados a la sesión, lo que muestra en qué elementos reservados cayó el trabajo real
  2. Cierra la sesión y guarda el resumen como memoria en esos elementos
  3. Registra las decisiones como memoria del proyecto y abre un borrador de solicitud de cambio de arquitectura para su revisión. Solo una ejecución que termina con éxito registra decisiones

La página de la ejecución muestra una tarjeta Resultado de la sesión de trabajo con el resumen, las decisiones, los seguimientos, los elementos tocados y un enlace a la solicitud de cambio. Los elementos que tiene otra sesión aparecen marcados como Retenido por otra sesión de trabajo.

Seguir una ejecución en directo

Una página de ejecución tiene dos vistas: Actividad, el feed de eventos, y Cambios, los archivos que escribió el agente. Cuando el agente te necesita, un aviso encima de ellas indica qué está esperando (Esperando tu revisión del plan o El agente tiene una pregunta) y te lleva hasta ahí.

El plan

Antes de cambiar nada, el agente comparte un plan: un resumen de una frase y un puñado de pasos concretos, 12 como máximo. El panel Plan, en la parte superior de la página de la ejecución, lo convierte en una checklist. El agente marca cada paso como En curso, Hecho u Omitido, a veces con una nota breve, y el panel muestra el paso en el que está y el progreso (3/7).

Revisar el plan primero es un ajuste del perfil, en Coordinación, desactivado por defecto. Cuando está activado, el agente espera una revisión antes de cambiar nada:

  1. El panel pasa a Revisa el plan. Puedes renombrar pasos, añadir detalles, y añadir, quitar o reordenar pasos.
  2. Aprobar plan (Aprobar plan editado si lo has editado) deja que el agente continúe. Tu versión editada es el plan que sigue el agente y el que refleja la checklist.
  3. Solicitar cambios envía tus comentarios. El agente rehace el plan y te propone una nueva versión para revisar. Las versiones anteriores siguen en el feed.

Mientras no haya un plan aprobado, el agente puede leer pero no cambiar nada: se rechazan la escritura de archivos y cualquier herramienta que cree, actualice, elimine, vincule, importe, haga push o fusione (en Archyl y en cualquier conector, p. ej. linear__create_issue), y también remember. Se le indica al agente que espere la revisión.

Preguntas

Cuando una decisión necesita a una persona, como un requisito ambiguo, una disyuntiva sin una opción claramente mejor o algo destructivo, el agente pregunta. La pregunta aparece encima del feed, con Respuestas sugeridas cuando el agente ofrece algunas, y un cuadro de respuesta libre (Cmd/Ctrl + Enter la envía). Cualquiera que pueda editar el proyecto puede responder, y el feed registra quién lo hizo.

El agente hace como máximo 5 preguntas por ejecución, y tiene instrucciones de no preguntar nunca algo que pueda consultar por sí mismo.

Cuando el agente te espera

Mientras el agente espera una revisión del plan o una respuesta, la ejecución muestra Esperándote y aparece en Te necesitan en la lista de ejecuciones, junto con las ejecuciones retenidas en Pendiente de aprobación.

  • La espera no cuenta para el límite de tiempo de la ejecución: su fecha límite se retrasa lo que dure la espera. La ejecución conserva su plaza de ejecución simultánea.
  • Una pregunta que nadie responde en una hora: el agente continúa según su propio criterio e indica en su resultado la suposición que hizo.
  • Un plan que nadie revisa en una hora: la ejecución falla, sin haber cambiado nada.

Dónde trabaja el agente

El agente lee y cambia código en su espacio de trabajo, un clon del repositorio:

  • Repositorio vinculado al proyecto: Archyl lo clona cuando empieza la ejecución.
  • Sin repositorio vinculado, con un conector de GitHub adjunto: el propio agente clona el repositorio del que trata la tarea, con las credenciales del conector, antes de tocar ningún archivo. Solo se admite el servidor MCP alojado de GitHub (api.githubcopilot.com). El conector debe autenticarse con un encabezado Authorization: Bearer, y su token necesita acceso al repositorio.

Una vez abierto un espacio de trabajo, el agente solo cambia archivos ahí: se rechaza subir archivos o abrir pull requests con las herramientas de un conector. Así cada cambio pasa por el Guard, aparece en la vista Cambios y acaba en una única pull request.

Cambios

Cambios lista cada archivo que escribe el agente, en el momento en que lo escribe: Añadido, Modificado o Bloqueado, con las líneas añadidas y eliminadas por archivo y para toda la ejecución. Selecciona un archivo para ver qué cambió cada escritura.

  • Si el Guard rechaza una escritura, el archivo queda Bloqueado: el diff muestra lo que el agente intentó escribir, con la regla que incumplió. Una escritura que el Guard solo marcó sigue adelante, con un aviso en el archivo.
  • Los diffs largos se cortan a partir de 600 líneas, y los archivos de más de 128 KB aparecen sin diff.

Comentar una línea

Revisa el diff mientras el agente trabaja. En Cambios, haz clic en un número de línea para comentar esa línea y luego en Enviar al agente (Cmd/Ctrl + Enter). El agente recibe el archivo, la línea y su contenido, atiende el comentario y después sigue con su plan.

  • El comentario aparece bajo su línea, En cola hasta que el agente lo lee y después Entregado. También aparece en Actividad, y cada archivo muestra cuántos comentarios tiene.
  • Puedes comentar líneas añadidas, sin cambios y eliminadas. Las escrituras bloqueadas por el Guard no admiten comentarios.
  • Los comentarios se aceptan mientras el agente trabaja o te espera. Un comentario que sigue En cola cuando termina la ejecución aparece como No entregado.

En una ejecución terminada, un comentario se convierte en una nota para la siguiente: Guardar para continuar lo conserva en tu navegador, y la barra sobre los archivos (3 comentarios para una continuación) continúa la ejecución con ellos (Continuar con ellos).

Pull request

Cuando termina la ejecución, Archyl hace commit de los cambios del espacio de trabajo en una rama llamada archyl/agent- seguido de los 8 primeros caracteres del ID de la ejecución, y abre una pull request contra la rama de la que partió el clon. Su enlace aparece en la parte superior de Cambios (Abrir pull request) y en el resultado.

Cómo termina la ejecución Qué publica Archyl
Con éxito Una pull request
Con un fallo, o detenida por su límite de tiempo o de coste Una pull request en borrador que explica por qué se detuvo
Cancelada Nada

En GitLab, el borrador es una merge request Draft:. En Bitbucket, la rama se sube sin pull request. Una ejecución que no cambió ningún archivo no publica nada.

Las pull requests se abren en github.com, gitlab.com y bitbucket.org. Archyl solo envía tus credenciales de Git a esos hosts: un repositorio en un servidor Git autoalojado (GitHub Enterprise, un GitLab privado, Azure DevOps, Gitea) se clona sin credenciales, así que uno privado no se puede clonar, y no se abre ninguna pull request.

Continuar una ejecución

Una ejecución terminada, sea cual sea su resultado, ofrece dos botones:

  • Continuar inicia una nueva ejecución que retoma el trabajo de esta. Escribe qué debe hacer el agente a continuación: tus comentarios para continuar rellenan las instrucciones, uno por línea (ruta:línea — comentario). El perfil es por defecto el de la ejecución, y puedes elegir conectores.
  • Volver a ejecutar abre el diálogo de inicio con la misma tarea y el mismo perfil, para empezar de cero.

Una continuación sabe qué se le pidió a la ejecución anterior y qué hizo. Parte de la rama que publicó esa ejecución, hace commit en ella y añade sus cambios a la misma pull request en lugar de abrir otra. Si la ejecución anterior subió su rama sin abrir una pull request, la continuación abre una, contra la rama a la que apuntaría una nueva ejecución. Si la ejecución anterior abrió un repositorio con el conector de GitHub, la continuación lo vuelve a abrir en esa rama.

  • Si la rama ya no existe (por ejemplo, fusionada y eliminada), la continuación parte de la rama de la que partiría una nueva ejecución, la rama vinculada del proyecto o la rama por defecto del repositorio, y abre una nueva pull request. El feed lo indica.
  • Una pull request en borrador sigue en borrador: márcala como lista para revisión cuando el trabajo esté terminado.
  • Archyl solo continúa en ramas creadas por sus agentes, nunca en las tuyas.

La página de la nueva ejecución enlaza con la ejecución que continúa (Continúa la ejecución), y la ejecución anterior enlaza con sus continuaciones (Continuada en). Una ejecución todavía en curso no se puede continuar: comenta sus líneas en su lugar.

Conectores MCP

Los conectores te permiten adjuntar servicios externos a tus ejecuciones de agentes. Cualquier servicio que exponga un servidor MCP (Model Context Protocol) puede conectarse.

Servicios compatibles

Servicio Capacidades
GitHub Leer PRs, verificar estado de CI, listar issues, revisar código
GitLab Las mismas capacidades para proyectos alojados en GitLab
Linear Leer/actualizar issues, verificar progreso del sprint
Slack Publicar mensajes, leer canales, notificar equipos
Custom Cualquier servidor compatible con MCP

Crear un conector

  1. Ve a Hub de Agentes → Conectores
  2. Haz clic en Nuevo conector
  3. Ingresa un nombre (por ejemplo, "github")
  4. Pega la URL del servidor MCP
  5. Agrega encabezados de autenticación si es necesario
  6. Haz clic en Crear conector — Archyl sondea el servidor y muestra las herramientas disponibles

Espacios de nombres de herramientas

Cuando un conector se adjunta a una ejecución, sus herramientas se prefijan con el nombre del conector:

Conector Ejemplo de herramienta
github github__list_pull_requests
linear linear__get_issue
slack slack__post_message

Las herramientas del servidor MCP integrado de Archyl no tienen prefijo (por ejemplo, get_agent_context, list_conformance_rules).

Este sistema de espacios de nombres evita colisiones entre nombres de herramientas, facilita la lectura del feed de eventos y permite que las herramientas permitidas de un perfil cubran un conector entero con un único patrón como github__*.

Programaciones

Las programaciones te permiten definir ejecuciones recurrentes de agentes con expresiones cron estándar.

Crear una programación

  1. Ve a Hub de Agentes → Programaciones
  2. Haz clic en Nueva programación
  3. Elige un perfil y escribe la descripción de la tarea
  4. Selecciona una expresión cron (hay preajustes disponibles o puedes ingresar una personalizada)
  5. Adjunta conectores si es necesario
  6. Haz clic en Crear programación

Gestión de programaciones

Cada programación muestra:

  • Expresión cron — Cuándo se ejecuta el agente
  • Próxima ejecución — Cuándo está programada la siguiente ejecución
  • Última ejecución — Cuándo se ejecutó el agente por última vez
  • Estado — Activa o pausada, o Perfil eliminado cuando se eliminó su perfil

Puedes:

  • Pausar una programación sin eliminarla
  • Reanudar una programación pausada
  • Ejecutar ahora — Lanzarla de inmediato fuera de su cadencia normal
  • Editar el texto de la tarea, la expresión cron o los conectores adjuntos
  • Eliminar la programación

Una programación cuyo perfil se eliminó sigue pausada: se rechaza reanudarla o usar Ejecutar ahora hasta que edites la programación y elijas otro perfil.

Ejemplos de programaciones

Caso de uso Expresión cron Descripción
Revisión semanal de arquitectura 0 9 * * 1 Cada lunes a las 9am
Auditoría diaria de dependencias 0 7 * * * Todos los días a las 7am
Sincronización semanal de documentación 0 14 * * 5 Cada viernes a las 2pm

Contexto arquitectónico

Cada ejecución gestionada recibe automáticamente acceso al servidor MCP de tu proyecto en Archyl. El agente puede:

  • Consultar el modelo C4 para comprender los límites del sistema
  • Leer los ADRs para entender las decisiones arquitectónicas pasadas
  • Verificar las reglas de conformidad para saber qué patrones seguir
  • Explorar los contratos de API para comprender las interfaces de los servicios
  • Consultar las asignaciones de tecnología para elegir las herramientas adecuadas
  • Recuperar y memorizar hechos sobre los elementos mediante la memoria de arquitectura

Este contexto se inyecta antes de que el agente comience a trabajar; no necesita descubrir tu arquitectura desde cero. Además, cada ejecución se envuelve en una sesión de trabajo del harness, de modo que su resultado se convierte en memoria de los elementos que tocó.

Proveedor de IA

Las ejecuciones usan el modelo gestionado por Archyl, salvo que tu organización tenga activado Trae tu propio proveedor de IA. Con BYO activado, las ejecuciones corren en tu proveedor con tus credenciales: Anthropic, AWS Bedrock, OpenAI o un endpoint compatible con OpenAI que implemente la Responses API. Google Gemini todavía no puede ejecutar agentes gestionados: las ejecuciones se rechazan con un mensaje explícito en lugar de pasar en silencio al modelo de Archyl.

Cuotas y concurrencia

Las Ejecuciones de Agentes Gestionadas están disponibles en los planes Scale y Custom. El uso se registra por organización con cuotas mensuales, que se muestran en la parte superior de las páginas Ejecuciones y Programaciones. Continuar una ejecución y aprobar una ejecución retenida también cuentan como ejecuciones. Las organizaciones con BYO AI activado no consumen cuota, tanto en ejecuciones manuales como programadas.

Cada ejecución activa (pending, running o waiting_for_input) ocupa una de las plazas de ejecución simultánea de tu organización. La plaza se libera en el momento en que la ejecución termina, sea cual sea el motivo.

Buenas prácticas

  • Sé específico en las descripciones de las tareas — "Verificar paquetes Go con CVEs conocidos y listarlos con su severidad" funciona mejor que "verificar dependencias"
  • Dale a cada tarea su propio perfil — Un revisor de solo lectura con allowedTools limitado a list_*, get_* y read_file no puede modificar nada por accidente.
  • Adjunta solo los conectores necesarios — Cada conector agrega herramientas al contexto del agente. Menos herramientas significa una ejecución más enfocada.
  • Comienza con ejecuciones manuales — Prueba tu descripción de tarea con una ejecución única antes de crear una programación.
  • Usa las reglas de conformidad en conjunto — Define primero las restricciones y luego activa la skill Conformance first para que las ejecuciones las validen automáticamente.