GitHub Agentic Workflows: la automatización con criterio (no solo scripts)

Este artículo dialoga con dos piezas previas del blog que conviene leer antes o después:

• Orquestando Agentes de IA en tu Pipeline de CI/CD — cómo montar un pipeline multi-agente clásico con GitHub Actions + Python.
• Documentación Automatizada: CI/CD con Dokka y MkDocs — el caso particular de docs generadas como ejemplo de automatización determinista.

Lo que vamos a ver aquí va un paso más allá: el agente razona sobre el repo en lenguaje natural, pero solo propone sus acciones a través de un canal validado.

---

🪝 El sábado a las 23:00 que me hizo escribir este artículo

Sábado noche. Recibo la notificación de rigor: CI failed on main. Abro el log, son 47 líneas, y al tercer scroll ya sé lo que pasó. Actualicé una dependencia “para estar al día” el martes y el test que arrastraba flaky desde hace tres meses ha decidido, por fin, dejar de fingir que pasa. No es un bug nuevo. No es un problema de mi código. Es deuda de mantenimiento disfrazada de feature.

En ese momento, mientras buscaba el último commit donde el test “todavía funcionaba”, pensé algo que se repite cada vez más a menudo en mi flujo de trabajo como indie:

“Tengo GitHub Actions bien montado, los builds y los deploys van solos. ¿Por qué sigo haciendo a mano todo lo que rodea al CI?”

Etiquetas en issues. PRs con descripciones de una línea. Release notes que nadie escribe. Comentarios de “esto ya estaba así” en PRs viejos. Documentación que se quedó obsoleta la semana pasada. Todo eso es trabajo automatizable con criterio, no con if/then rígido. Y eso es exactamente lo que GitHub Agentic Workflows (gh-aw) viene a llenar.

🎯 El hueco que CI/CD no cierra

CI/CD tradicional — GitHub Actions, Jenkins, GitLab CI, CircleCI — automatiza el camino feliz: compilar, testear, empaquetar, desplegar. Lo hace muy bien. Pero todo lo que requiere juicio sigue dependiendo de horas humanas:

• Clasificar un issue nuevo: ¿bug, pregunta, feature, docs?
• Decidir si un PR merece etiqueta de prioridad alta.
• Redactar un changelog coherente a partir de 47 commits.
• Diagnosticar por qué falla el test de las 3 AM (spoiler: la flaky test).
• Mantener la documentación al día con cada cambio de API.

Estos son los trabajos que absorben foco de un indie dev. No pagan dinero directamente, pero cuestan horas de concentración que no vuelven. Y no se pueden expresar en YAML declarativo porque cada caso es distinto.

La tesis del equipo de GitHub Next es directa: “CI/CD ya automatiza builds y deploys, pero todavía dedicamos horas a triage, fallos en CI y documentación desalineada. Queda un segundo anillo de tareas colaborativas y repetitivas que son automatizables con criterio, no con scripts rígidos.” Lo escribieron en el post oficial del technical preview de febrero de 2026, y es exactamente el problema que llevo años tropezándome.

🧠 Qué es GitHub Agentic Workflows (gh-aw)

GitHub Agentic Workflows es una capa experimental de GitHub Next, incubada en el repo github/gh-aw, que en junio de 2026 llevaba más de 4.600 estrellas, 384 releases y la versión 0.79.8 del 12 de junio. Su idea es simple de explicar y elegante de ejecutar:

Describes en Markdown + frontmatter YAML lo que quieres que ocurra en tu repositorio, y un compilador lo traduce a un workflow de GitHub Actions tradicional. El workflow ejecuta un coding agent (Copilot CLI, Claude Code, Codex o Gemini) que lee el repo, razona y propone — pero nunca tiene permisos de escritura directos.

Tres conceptos lo separan radicalmente de “tirar un agente de IA en un step de Actions”:

1. Workflows en Markdown, no en YAML puro

El archivo .github/workflows/daily-status.md es la fuente de verdad. Un compilador (gh aw compile) lo traduce a un .lock.yml ejecutable que también se commitea. Ambos son revisables, ambos son PR-legibles, ambos pasan por code review humanos.

---
on:
  schedule: daily

permissions:
  contents: read
  issues: read
  pull-requests: read

safe-outputs:
  create-issue:
    title-prefix: "[repo status] "
    labels: [report]

tools:
  github:
---

# Daily Repo Status Report

Create a daily status report for maintainers.

Include
- Recent repository activity (issues, PRs, discussions, releases, code changes)
- Progress tracking, goal reminders and highlights
- Project status and recommendations
- Actionable next steps for maintainers

Keep it concise and link to the relevant issues/PRs.

2. Safe Outputs: el agente nunca escribe, solo propone

Este es el giro de diseño clave. El job del agente corre con contents: read, issues: read. Sin permisos de escritura. Cuando el agente decide que quiere crear un issue, etiquetar un PR o comentar, no lo hace directamente — produce un artefacto agent_output.json describiendo qué querría hacer. Un job separado, con permisos scopeados al mínimo (create-issue, add-labels, noop, create-pull-request…), valida y ejecuta la propuesta.

Es el equivalente funcional de un commit-msg hook, pero a nivel de acciones. El daño potencial de un agente “loco” es, por construcción, cero.

3. Threat Detection: un segundo agente audita al primero

Antes de que cualquier safe-output se externe, corre un segundo job con un prompt de seguridad dedicado. Revisa agent_output.json + el parche propuesto + el prompt original buscando:

• Fugas de secretos (secrets.* referenciados se redactan automáticamente a abc*****).
• Parches maliciosos o intentos de modificar .github/workflows.
• URLs a infraestructura interna.
• Violaciones de scope.

Si la auditoría falla, el workflow aborta. Sin escrituras externas. Sin PR fantasma. Sin drama.

🛡️ Las tres capas de guardrails (defense-in-depth)

Lo que más me gusta de gh-aw es que el threat model está escrito y es público. No es “confía en el prompt”. Son tres capas explícitas:

1. Capa de sustrato — kernel, hypervisor, iptables. El agente corre en GitHub-hosted runners.
2. Capa de configuración declarativa — frontmatter con JSON Schema, action pinning por SHA, linters en tiempo de compilación (actionlint, zizmor, poutine).
3. Capa de plan — Safe Outputs + Threat Detection + Agent Workflow Firewall (AWF) + MCP Gateway.

Agent Workflow Firewall (AWF)

Un proxy Squid con allowlist explícita de dominios. Por defecto el agente solo habla con:

network:
  firewall: true
  allowed:
    - defaults     # infra básica (GitHub, etc.)
    - python       # ecosistema PyPI
    - node         # ecosistema npm
    - "api.example.com"  # dominios custom que declares

Si el agente intenta un curl https://evil.example.com, la URL se redacta como (redacted) y la petición se bloquea. Es la respuesta formal al problema de exfiltración de datos vía prompt injection.

MCP Gateway

Los servidores MCP (incluido el oficial de GitHub MCP) corren en contenedores aislados con filtrado de herramientas. Solo las herramientas que listes en allowed: son invocables. El agente no puede, por ejemplo, llamar a delete_repo si no lo declaraste.

Content sanitization pipeline

Antes de que el contenido del repo llegue al prompt del agente:

• @mentions se neutralizan (evita que el agente notifique a personas reales).
• Triggers de bots tipo fixes #123 se bloquean (evita cierres accidentales de issues).
• Tags HTML/XML se convierten a formato seguro (tag).
• URIs no-HTTPS se filtran.
• Unicode se normaliza.
• Payloads se limitan a 0.5 MB / 65k líneas.

Integrity filtering

Controla a qué contenido puede acceder el agente según autor y estado de merge, no solo push access:

min-integrity: approved  # owners, members, collaborators

Hay cuatro niveles (merged, approved, unapproved, none). Para repos públicos, approved es el default razonable. Esto significa que un PR abierto por un random de internet no puede envenenar el contexto del agente.

📦 Caso real: Auto-Triage de Issues en producción

El propio repo github/gh-aw ejecuta un workflow llamado auto-triage-issues.md cada 6 horas. Es el ejemplo más honesto de la herramienta: funciona, está en producción, y puedes leer el YAML.

---
emoji: "🔧"
name: Auto-Triage Issues
on:
  issues:
    types: [opened, edited]
  schedule: every 6h
  workflow_dispatch:
max-daily-ai-credits: 10000
user-rate-limit:
  max-runs-per-window: 5
  window: 60
permissions:
  contents: read
  issues: read
  copilot-requests: write
engine:
  id: copilot
  model: gpt-5-mini
strict: true
network:
  allowed:
    - defaults
    - github
imports:
  - shared/github-guard-policy.md
  - shared/reporting.md
tools:
  github:
    mode: gh-proxy
    toolsets: [issues]
    min-integrity: approved
  bash:
    - "jq *"
    - "cat *"
safe-outputs:
  add-labels:
    max: 10
  create-discussion:
    expires: 1d
    title-prefix: "[Auto-Triage] "
    category: "audits"
    close-older-discussions: true
    max: 1
  noop:
timeout-minutes: 15
---

# Auto-Triage Issues Agent 🏷️
...

Tres detalles que me parecen geniales:

• max-daily-ai-credits: 10000 — Coste predecible. Si se gasta el crédito, el workflow para. No te encuentras una factura sorpresa.
• imports: — Composicionalidad. Compartes github-guard-policy.md entre workflows como compartes GitHub Actions reutilizables.
• noop — Salida explícita para “no hice nada”. El agente aprende que no actuar también es válido. Esto reduce inventividad peligrosa.

📊 Los números: qué dice el Impact Report de mayo 2026

GitHub Next publicó el 14 de mayo de 2026 un Impact Report midiendo resultados en 15 repos open source que llevan meses ejecutando Repo Assist (el paquete de workflows agentic de gh-aw).

Los números duros:

• 651 issues netos cerrados en 13 repos analizados.
• Aumento mediano de 9× tanto en issue-closure velocity como en PR-merge velocity.
• Issue closure mediana: de 0.13 a 3.61 issues/semana.
• PR merge mediana: de 0.34 a 5.63 PRs/semana.
• Throughput mediano de PRs mergeados: 82% (684/877).
• En repos “dormidos” como GenPRES, FSharp.Data y AsyncSeq, el backlog pasó de estancado a 100% completado.

El caso más espectacular: FSharp.Formatting, una herramienta de documentación F#. Pasó de cerrar 0.00 issues/semana a 8.12. Y de mergear 0.09 PRs/semana a 11.15. Multiplicador ×90.

Pero — y aquí viene la parte que más me interesa como indie — el report es contundente sobre una cosa:

El cuello de botella siempre es humano.

El 30% de los runs son intervenciones humanas explícitas. El 52% involucran dirección humana de algún tipo. El 37.4% de los PRs agentic reciben commits humanos encima antes de merge. Los repos que NO mejoraron son los que tenían inaction bottleneck (nadie revisa PRs) o rejection bottleneck (se rechazan PRs sin explicación).

El agente no quita trabajo. Lo desplaza al punto donde el humano decide.

🆚 Diferencias con alternativas que ya conoces

Solución	Qué hace bien	Dónde se queda corta
GitHub Actions clásico (YAML)	Build/test/deploy deterministas. Perfecto para el camino feliz.	No interpreta lenguaje natural. Cada if hay que anticiparlo.
Copilot Coding Agent (#issue)	Un agente único asignado a un issue, abre un PR.	Monolítico, sin guardrails de scope, sin Safe Outputs, sin threat detection. Vive fuera del flujo de Actions.
Dependabot auto-triage	Cierra PRs de Dependabot sin sentido o actualiza分组.	Dominio muy estrecho (solo dependencies). Sin razonamiento.
Claude Code / Codex en un step suelto	Invocar un CLI de IA en un step normal.	El agente recibe más permisos de los necesarios. Sin Safe Outputs. Sin threat detection automático. Sin allowlist de red. El equipo de gh-aw lo señala como anti-patrón.
Atlassian Rovo / Jira Service Management	Agentes sobre la capa ITSM/ITIL.	Plataforma distinta (Jira), caso de uso distinto (service desk, no repo).
gh-aw / GitHub Agentic Workflows	Markdown + AI + 3 capas de guardrails. Safe Outputs, Threat Detection, AWF, MCP Gateway.	Es research preview, no GA. El README termina con “Use it with caution, and at your own risk.”

El aporte único de gh-aw que las demás opciones no tienen: el agente nunca escribe — solo propone a través de un buffer validado. Es la diferencia entre “un junior con permisos de merge” y “un junior que te deja las propuestas en una bandeja y tú decides”.

⚠️ Las honestidades que duelen

Porque esto no es marketing, es ingeniería real. Léete esto antes de adoptarlo en un repo de cliente:

1. No es GA. Technical preview desde febrero 2026. El repo dice literalmente “research prototype”. Si lo adoptas en producción, pinnea la versión y ten un plan B.
2. Hubo un bug de billing real. Las versiones 0.68.4 a 0.71.3 fueron retiradas por afectar la facturación de Copilot. Si pinneas versión, asegúrate de evitar ese rango.
3. Automation fatigue existe. Dos maintainers del report (FsAutoComplete, fantomas) bajaron el ritmo o pausaron workflows por “notification anxiety” y “too noisy”. El agentic puede aumentar la presión de mantenimiento si no lo configuras con cabeza.
4. El coste por run. ~2 premium requests de Copilot por ejecución. Un workflow con schedule: every 6h son ~240 runs/mes. Pon max-daily-ai-credits desde el día 1.
5. El README termina con un aviso que hay que leer: “Using agentic workflows in your repository requires careful attention to security considerations and careful human supervision, and even then things can still go wrong.”

Y un matiz que vale la pena repetir: el agente no acelera el código, acelera la decisión humana. Esto es liberador si lo entiendes como indie dev: gh-aw no te va a quitar el control del roadmap. Te va a quitar las 47 líneas de log que tenías que leer para diagnosticar un flaky test. Las decisiones siguen siendo tuyas.

🛠️ Setup para un indie: del git clone al primer workflow agentic

Asumiendo que ya tienes un repo con GitHub Actions funcionando (si no, revisa mi guía de GitHub Actions para Android):

# 1. Instalar la CLI gh-aw
curl -sL https://raw.githubusercontent.com/github/gh-aw/main/install-gh-aw.sh | bash

# 2. Verificar instalación
gh aw version

# 3. Crear workflow desde template
gh aw new auto-triage-issues

# 4. Compilar a .lock.yml
gh aw compile auto-triage-issues

# 5. Revisar diffs antes de commitear
git diff .github/workflows/

# 6. Commitear ambos (Markdown fuente + YAML compilado)
git add .github/workflows/auto-triage-issues.md .github/workflows/auto-triage-issues.lock.yml
git commit -m "ci(agentic): add auto-triage workflow"
git push

El CLI tiene más comandos útiles:

gh aw logs <workflow-name>   # ver runs pasados
gh aw audit <run-id>          # auditar un run específico (ver qué propuso el agente)
gh aw fix --write             # actualizar a la última versión compatible
gh aw compile --validate      # validar sin escribir el .lock.yml

🔁 Continuous AI: la “tercera pata” al lado de CI/CD

Don Syme, uno de los autores del blog oficial, lo nombra bien: “as CI/CD transformed software development by automating integration and deployment, Continuous AI covers the ways in which AI can be used to automate and enhance collaboration workflows.”

Si Hudson y Travis me quitaron el scp manual al servidor, gh-aw me quita el git log --oneline | head -20 manual para escribir el changelog. Es exactamente el mismo salto conceptual, aplicado a otra categoría de tareas.

Los Continuous AI Patterns oficiales son 16 y vale la pena conocerlos: ChatOps, DailyOps, DataOps, IssueOps, ProjectOps, MultiRepoOps, OrchestratorOps, SpecOps, LabelOps, MemoryOps, MonitorOps, BatchOps, WorkQueueOps, DeterministicOps, DispatchOps, CentralRepoOps, ResearchPlanAssignOps. Cada uno es un job shape reusable.

🎬 Cierre: el copiloto, no el piloto automático

Vuelvo al sábado a las 23:00. Con gh-aw, ese CI rojo de las 23:00 se vería así:

• A las 23:01, el workflow ci-doctor.md corre automáticamente.
• A las 23:03, el agente leyó el log, identificó que el test era flaky en commit abc123 (ya conocido por runs previos), propuso un PR que aumenta el timeout y desactiva el test en flaky=true.
• A las 23:04, Safe Outputs creó el PR.
• A las 23:05, Threat Detection lo marcó como ✅ no contiene secretos, no toca workflows, scope correcto.
• A las 23:06, me llega la notificación: “PR #247 listo para review. Acción propuesta: añadir a quarantine. Acción humana requerida: confirmar.”

Yo abro el PR, leo el diff (15 líneas), acepto, y a las 23:12 estoy de vuelta escribiendo la feature del domingo.

¿He perdido el control? No. Lo he recuperado. El agente no decide por mí; hace el trabajo tedioso que me impedía decidir bien. Eso es exactamente la diferencia entre un copiloto y un piloto automático.

Si tienes un repo en GitHub, aunque sea personal, pruébalo en una rama con un workflow de daily-report primero. Verás que el modelo mental cambia: ya no piensas en “tengo que hacer X esta semana”, sino en “¿qué quieres que haga el agente esta semana?”. Esa es la pregunta correcta.

---

📚 Bibliografía y Referencias

Documentación oficial

• GitHub Blog — Automate repository tasks with GitHub Agentic Workflows — Anuncio del technical preview, febrero 2026 (Don Syme & Peli de Halleux).
• Repo github/gh-aw — Código fuente, plantillas y workflow auto-triage-issues.md en producción.
• Documentación — How They Work — Modelo de ejecución, threat model.
• Documentación — Security Architecture — Capas de guardrails, AWF, MCP Gateway.
• GitHub Next — Agentic Workflows project page — Contexto de research.
• GitHub Next — Continuous AI project page — Marco conceptual de la “tercera pata”.
• Impact Report — Repo Assist, mayo 2026 — Métricas reales en 15 repos open source.
• Workflow de ejemplo auto-triage-issues.md — Producción real, no demo.
• Peli’s Agent Factory — blog intro — Más de 100 workflows agentic ejecutándose.

Artículos previos del blog relacionados

• Orquestando Agentes de IA en tu Pipeline de CI/CD — Enfoque multi-agente clásico con Python + Actions.
• Documentación Automatizada con Dokka y MkDocs — Caso particular de automatización determinista.
• GitHub Actions para Android: Guía Completa — Base de CI/CD sobre la que se apoya gh-aw.
• TDD con IA en Android — Contrapunto filosófico a “dejar que el agente haga el trabajo”.
• Agentes IA Autónomos en Android — Marco conceptual de agentes que actúan sin intervención humana.

Fuentes secundarias

• LinkedIn — GitHub LATAM, “Automatiza lo que se puede predecir” — Post que motivó este artículo (URL proporcionada por el lector).

Hilos de Reddit mencionados (no verificables al fetch)

• r/devops — CI/CD integration experiences — Bloqueado por verificación al momento de la consulta.
• r/devopsjobs — AI tools automating CI/CD monitoring — Bloqueado por verificación al momento de la consulta.

Nota metodológica: Los dos hilos de Reddit de las fuentes originales estaban bloqueados por la pantalla de verificación de Reddit al momento de la investigación. Su contenido no se cita ni parafrasea. Si quieres leerlos, ábrelos en un navegador autenticado.