GitLab lanza la orquestación de agentes: el comando /goal lleva la tarea hasta que el CI esté en verde

GitLab intenta eliminar las esperas entre las etapas del desarrollo. En la conferencia Transcend, la compañía anunció tres nuevas capacidades de orquestación de agentes en Duo Agent Platform: flujos orientados a objetivos (goal-driven flows), la integración GitLab for Slack y Custom Flows. Los flujos orientados a objetivos requieren GitLab 19.3 y Duo CLI 9.17.0 o posterior. El argumento de GitLab es sencillo: la IA ha acelerado la escritura de código, pero no su entrega. Un agente produce una corrección en minutos, y después esta espera semanas la firma de un revisor, el análisis de las alertas del pipeline, el triaje de los resultados de los escaneos y otro prompt manual.

Objetivo en lugar de pasos: cómo funciona /goal

Los flujos orientados a objetivos dan al agente una meta final, no la siguiente acción. El desarrollador describe la tarea y el criterio de finalización, y el flujo trabaja hasta alcanzar el resultado. La revisión, las pruebas, las comprobaciones de seguridad y las aprobaciones forman una única cadena conectada, sin paradas entre pasos.

El lanzamiento tiene este aspecto: `/goal Fix the checkout timeout. Continue until tests pass and CI is green.` El comando funciona en Duo CLI, en modo headless mediante `duo run --goal` y en Agentic Chat. La segunda forma es importante para la automatización: se puede invocar desde scripts y pipelines sin una sesión interactiva.

Otro detalle afecta al control de calidad. En cada paso, un modelo independiente compara el trabajo con el objetivo, es decir, el agente no se evalúa a sí mismo. La ejecución puede detenerse o redirigirse en cualquier momento.

Slack y Custom Flows: empezar donde se pide

GitLab for Slack resuelve el problema del punto de entrada. La mayoría de las tareas nacen en una conversación, no en el gestor de incidencias. Basta con mencionar a @GitLab en un canal o hilo y escribir, por ejemplo, «fix the failing pipeline»: se lanza un flujo y Duo muestra el progreso en streaming directamente en el hilo. El mismo bot responde preguntas sobre la base de código y convierte una conversación en una issue. El flujo se ejecuta con la misma identidad y las mismas políticas que cualquier otro en GitLab, de modo que el control de acceso sigue en manos de la plataforma y no del chat.

Custom Flows cubren el tercer escenario: el equipo describe por su cuenta una secuencia de agentes de varios pasos y la vincula a eventos de GitLab, como una mención, una asignación o un pipeline. Los flujos se ejecutan en CI/CD. Un ejemplo de GitLab: un pipeline que se autorrepara analiza una prueba fallida, genera la corrección, la envía en un commit y avisa al equipo. En los pasos sensibles se pueden fijar puntos de control con intervención humana.

Todo esto funciona bajo un único modelo de gobernanza: la identidad, las políticas y la cadena de evidencias (evidence chain) son comunes a todos los flujos. Para las empresas sujetas a auditoría, este es probablemente el principal argumento a favor de un enfoque de plataforma frente a una dispersión de agentes externos. El conjunto puede ampliarse a través del AI Catalog, conectando agentes y herramientas externos mediante el cliente MCP y el servidor MCP. Los agentes y flujos básicos ya cubren las etapas desde la planificación hasta el análisis en la interfaz de GitLab, en el IDE y en Duo CLI.

Disponibilidad y primeros pasos

Según las condiciones del lanzamiento:

• flujos orientados a objetivos: GitLab.com, Self-Managed y Dedicated, planes Premium y Ultimate;
• versiones mínimas: GitLab 19.3 y Duo CLI 9.17.0;
• Custom Flows: ya en disponibilidad general (GA);
• servidor MCP y GitLab for Slack: se espera GA más adelante este mes;
• pago: GitLab Credits, que se incluyen en la suscripción Premium o Ultimate.

Lo razonable es empezar por algo pequeño. Primero, compruebe las versiones de GitLab y Duo CLI, active Duo Agent Platform y ejecute `/goal` sobre una tarea acotada con un criterio de finalización inequívoco, por ejemplo, una prueba fallida con un error reproducible. La formulación del objetivo lo decide casi todo: un «CI en verde» lo comprueba una máquina; «mejorar el código», no. Después, traslade un proceso manual repetitivo a un Custom Flow, manteniendo puntos de control humanos en el merge y en el manejo de secretos. Conviene planificar la conexión con Slack para después de la GA, cuando la integración salga del acceso anticipado.

La gran pregunta sigue abierta: hasta qué punto el modelo verificador distingue de forma fiable un objetivo realmente cumplido de un pipeline en verde solo en apariencia. Conviene medirlo en los repositorios propios antes de que los flujos puedan mover código más allá de la revisión.