Flujos dinámicos de Copilot para automatizar tareas repetibles

Cuando un prompt ya no basta

Hay tareas que repetimos demasiadas veces como para resolverlas con un prompt improvisado. Revisar una incidencia, preparar una entrega o investigar un fallo en un servidor suelen seguir una secuencia conocida, aunque cada caso tenga sus matices. El problema aparece cuando esa secuencia queda solo en la cabeza de quien la ejecuta.

Los flujos dinámicos de GitHub Copilot sirven para convertir ese proceso en código. El flujo puede combinar comandos, herramientas, llamadas a servicios y agentes que se encargan de las partes que requieren análisis. No se trata solo de lanzar varios agentes, sino de decidir de antemano qué pasos existen, en qué orden se ejecutan y qué resultado pasa de uno a otro.

Un caso razonable en un proyecto Laravel

En un proyecto Laravel, por ejemplo, puedo plantear un flujo para investigar un fallo reportado tras un despliegue. Primero recopilaría información determinista: estado de Git, versión de PHP, salida de las pruebas relevantes y extractos de los logs de Laravel. Después podría repartir el análisis entre subagentes, uno centrado en la excepción, otro en los cambios recientes y otro en la cobertura de tests.

La ventaja no es que Copilot encuentre siempre la causa del problema. La ventaja es que la recopilación inicial, la separación de responsabilidades y el formato de los resultados dejan de depender de acordarse del prompt correcto. Si el flujo exige resultados estructurados, los pasos posteriores pueden trabajar con ellos en lugar de interpretar una conversación larga y poco consistente.

También encaja para revisiones antes de publicar una versión. Un flujo puede ejecutar comprobaciones, pedir a un agente que clasifique los fallos y detenerse antes de continuar para que una persona revise el diagnóstico. Esa pausa es importante cuando el siguiente paso podría modificar código, abrir una incidencia o convertir una sospecha en una decisión técnica.

Del repositorio al homelab

En un homelab el mismo patrón puede servir para investigar un servicio caído. El flujo puede recoger el estado de los contenedores, consultar registros, comprobar espacio libre y repartir el análisis entre servicios independientes. Después puede reunir los hallazgos en un informe único con una línea temporal y posibles causas.

Aquí conviene separar muy bien la observación de la acción. Recopilar información sobre Docker, un host Proxmox o una aplicación autoalojada es una tarea razonable para automatizar. Reiniciar servicios, borrar volúmenes o cambiar configuraciones debería quedar detrás de una revisión humana, especialmente cuando el flujo se ha diseñado para ejecutarse con frecuencia.

Límites para que la automatización no se descontrole

GitHub permite limitar cuántos subagentes del flujo pueden estar activos al mismo tiempo, cuántos pueden lanzarse durante toda la ejecución, el tiempo máximo activo y el consumo aproximado de créditos de IA. El límite de concurrencia no cancela trabajo: hace esperar a los subagentes adicionales hasta que haya capacidad. Los demás límites pueden detener la ejecución y conservar su estado para reanudarla más adelante.

En Copilot CLI se pueden establecer límites personales por defecto con /settings. La documentación oficial define estas claves: workflows.defaultLimits.maxConcurrentSubagents, workflows.defaultLimits.maxTotalSubagents, workflows.defaultLimits.timeoutSeconds y workflows.defaultLimits.maxAiCredits. El tiempo se expresa en segundos.

/settings workflows.defaultLimits.maxConcurrentSubagents 3
/settings workflows.defaultLimits.maxTotalSubagents 8
/settings workflows.defaultLimits.timeoutSeconds 3600
/settings workflows.defaultLimits.maxAiCredits 100

Un límite de créditos no es una barrera exacta. GitHub indica que el consumo se registra después de que ocurre, por lo que trabajo que ya está en marcha puede hacer que el total supere la cifra indicada. Para una investigación grande, empezaría siempre con un alcance pequeño, revisaría el consumo real y ajustaría los límites antes de lanzar el flujo sobre todo el repositorio o todos los nodos.

Ejecutarlo desde la terminal o desde CI

Los flujos existentes se pueden ejecutar directamente desde Copilot CLI con copilot workflow run WORKFLOW-NAME. El comando espera hasta que la ejecución termina o se detiene, así que encaja en scripts y en una canalización de CI/CD cuando interesa guardar el resultado o repetir el proceso con entradas concretas. También se pueden iniciar desde una conversación con Copilot, y la aplicación de Copilot muestra las ejecuciones actuales y anteriores.

copilot workflow run laravel-release-check

La ejecución no sustituye el diseño de una pipeline tradicional. Para tareas puramente deterministas, como instalar dependencias, ejecutar PHPUnit o generar artefactos, sigue siendo más simple y más auditable usar los pasos normales de CI. El flujo aporta más valor cuando hay que combinar esas comprobaciones con clasificación, análisis o decisiones que requieren contexto.

La letra pequeña

Un flujo dinámico no convierte a Copilot en un operador seguro por defecto. Los subagentes usan el sistema de permisos de Copilot CLI y heredan los permisos concedidos por la sesión que los inició. Además, una extensión puede ejecutar su propio código fuera de los avisos de permisos de los subagentes, así que revisar la extensión y limitar su alcance no es opcional.

Hay otra diferencia importante al usar copilot workflow run desde scripts o CI/CD: el comando no muestra solicitudes interactivas de permisos. Los permisos necesarios deben estar concedidos antes de iniciar la ejecución. Si un flujo necesita acceso a sistemas internos, secretos o comandos con efectos reales, conviene tratarlo como cualquier otra automatización privilegiada: con credenciales mínimas, entornos aislados y una revisión clara de lo que puede hacer.

Tampoco usaría un flujo dinámico para una pregunta rápida o un cambio pequeño. GitHub recomienda el chat normal para esas situaciones, y tiene sentido: definir, probar y mantener un proceso cuesta más que pedir una respuesta puntual. Esta funcionalidad está en vista previa pública, por lo que sus capacidades y detalles operativos pueden cambiar.

Un proceso que se puede revisar

Lo interesante no es añadir agentes a cualquier tarea, sino capturar procesos que ya existen y que merece la pena repetir de forma consistente. Para Laravel, empezaría con una revisión de release que solo lea información y produzca un informe. Para el homelab, con una investigación de incidencias que recopile estado y logs sin ejecutar acciones correctivas.

Cuando el flujo dé resultados útiles en pequeño, entonces añadiría paralelismo, límites y puntos de revisión. Esa secuencia reduce el riesgo de construir una automatización cara, opaca y difícil de parar. El objetivo es tener un procedimiento reproducible que ayude a decidir mejor, no delegar el control de la infraestructura.

Fuente: GitHub Changelog

Documentación oficial: Dynamic workflows en GitHub Docs