GitHub Actions vs. agente: quién debe mover los tickets
Delegar las transiciones de estado de Jira o Linear a integraciones de GitHub reduce tokens consumidos y elimina lógica del contexto del agente. Cuándo hacerlo y cuándo no.
El problema: el agente como gestor de proyectos
En muchos flujos de trabajo con agentes, se le da al propio agente la responsabilidad de mover los tickets entre estados: de "In Progress" a "In Review", de "In Review" a "Done". Parece natural porque el agente ya tiene acceso a Linear o Jira para leer los tickets. Pero esta decisión tiene un coste silencioso.
Cada transición de estado que gestiona el agente consume tokens, ocupa espacio en el contexto y añade lógica que en realidad no necesita razonamiento: simplemente reacciona a un evento de git predecible. El agente se convierte en un intermediario innecesario entre GitHub y el gestor de proyectos.
El síntoma más frecuente: el agente falla en mover un ticket porque su llamada a la API del gestor de proyectos ocurre fuera de contexto, con el token expirado o después de que otro proceso ya cambió el estado. La lógica dispersa genera estados inconsistentes.
La alternativa: GitHub Actions o webhooks
GitHub Actions puede reaccionar a eventos de git y llamar directamente a la API de Linear o Jira sin involucrar al agente. El workflow se ejecuta en la infraestructura de GitHub, es determinista y no consume tokens del modelo. A continuación, un ejemplo conceptual de cómo mover un ticket a "Done" automáticamente al mergear una PR:
# .github/workflows/linear-transition.yml
name: Linear — mover ticket al hacer merge
on:
pull_request:
types: [closed]
branches: [main]
jobs:
transition:
if: github.event.pull_request.merged == true
runs-on: ubuntu-latest
steps:
- name: Extraer ID de ticket del título de la PR
id: extract
run: |
TICKET=$(echo "${{ github.event.pull_request.title }}" | grep -oP 'MAR-\d+')
echo "ticket=$TICKET" >> $GITHUB_OUTPUT
- name: Mover ticket a Done en Linear
if: steps.extract.outputs.ticket != ''
run: |
curl -X POST https://api.linear.app/graphql \
-H "Authorization: ${{ secrets.LINEAR_API_KEY }}" \
-H "Content-Type: application/json" \
-d '{"query":"mutation { issueUpdate(id: \"${{ steps.extract.outputs.ticket }}\" input: { stateId: \"done-state-id\" }) { success } }"}'El ID del ticket se extrae del título de la PR — lo que refuerza la convención de naming de ramas y PR que ya es una buena práctica en cualquier equipo.
Cuándo tiene sentido que lo gestione el agente
No todas las transiciones son simples. Hay casos en los que la decisión de avanzar un ticket requiere razonamiento real — y ahí el agente sí aporta valor:
Cuándo delegarlo a GitHub Actions
Si la condición para mover el ticket es un evento de git — determinista, sin ambigüedad — no hay ninguna razón para involucrar al agente:
Recomendación
La regla es simple: si la condición es un evento de git, resuélvelo en GitHub Actions; si requiere razonamiento sobre el contenido del cambio, dale esa responsabilidad al agente.
Aplicar esta separación tiene tres beneficios inmediatos: reduce el consumo de tokens del agente, hace que el flujo de estados sea más predecible y auditado en el historial de GitHub Actions, y elimina una fuente común de errores que son difíciles de debugear porque mezclan responsabilidades.
Patrón recomendado: mantener en el agente únicamente las transiciones que requieren leer y evaluar código. Todas las transiciones basadas en eventos de git (push, merge, deploy) van a GitHub Actions o webhooks equivalentes. El agente se reserva para lo que realmente necesita inteligencia.
¿Quieres aplicar esto en tu equipo?
En Kuuli Technologies llevamos estas metodologías a equipos reales. Escríbenos si quieres una sesión de trabajo o una consultoría sobre agentes IA y SDD.