No todos los problemas se resuelven igual con un agente. La forma en que trabajas con él —cuánto controlas, cuánto delegas— cambia completamente el resultado. Hay dos modelos. Y saber cuándo usar cada uno es parte del oficio.
El workflow lineal: tú en el bucle
El modo más intuitivo. El agente genera, tú revisas, corriges y das la siguiente instrucción. Un ciclo síncrono en el que nada avanza sin tu aprobación.
Es lento por diseño. Y eso no es un defecto: es la garantía. Cada paso está supervisado. Cada decisión pasa por ti. El agente actúa como un ejecutor muy capaz, pero el criterio es siempre tuyo.
Este modelo tiene sentido cuando el contexto es crítico, cuando el riesgo de una decisión incorrecta es alto o cuando estás en territorio desconocido y necesitas entender lo que se está construyendo antes de seguir adelante. También cuando el equipo que va a mantener ese código necesita haber estado presente en las decisiones.
La trampa del workflow lineal es convertirse en un cuello de botella. Si el agente espera tu validación en cada micro-decisión, no estás amplificando tu capacidad: estás gestionando un ejecutor muy rápido a velocidad humana.
Los agentic loops: el agente en el bucle
El segundo modelo es cualitativamente distinto. El agente —o un orquestador que coordina subagentes especializados— entra en un ciclo autónomo: genera, ejecuta, verifica contra los criterios definidos, corrige y vuelve a intentarlo. Sin esperar. Sin preguntar. Hasta que la tarea se da por completada.
Tú defines el punto de partida y los criterios de éxito. El proceso que ocurre en medio no depende de ti.
Esto cambia la escala de lo que es posible. Un orquestador puede lanzar en paralelo un agente que implementa el backend, otro que genera los tests y otro que revisa la consistencia con el contrato OpenAPI. Cada uno trabaja en su dominio, reporta al orquestador y el ciclo continúa hasta que todos los criterios se cumplen.
El agente no para cuando termina. Para cuando verifica que ha terminado bien. Esa diferencia es lo que hace el loop.
El requisito que no es opcional
Los agentic loops tienen una dependencia crítica: los criterios de salida.
Sin ellos, el loop no sabe cuándo ha terminado. O se detiene demasiado pronto, entregando algo incompleto. O no se detiene nunca, dando vueltas sobre un problema que no tiene solución con la información disponible. O peor: se detiene cuando el agente decide que lo que ha generado es suficientemente bueno, sin que nadie haya definido qué significa suficientemente bueno.
Aquí vuelve a aparecer la misma conclusión de siempre: sin especificaciones sólidas, sin criterios concretos, sin una fuente de verdad que el agente pueda consultar, la autonomía no multiplica la calidad. Multiplica la velocidad a la que se acumula el trabajo mal hecho.
Los loops funcionan cuando el punto de partida está bien definido. Cuando no lo está, el workflow lineal no es una opción más conservadora: es la opción correcta.
Cuándo usar cada uno
El workflow lineal es para cuando necesitas control, cuando el riesgo es alto o cuando el contexto es demasiado específico para que el agente lo navegue solo. También cuando estás aprendiendo: revisar cada paso es la forma más rápida de entender lo que el agente está haciendo y por qué.
Los agentic loops son para cuando las especificaciones son sólidas, los criterios de verificación están bien definidos y la tarea es lo suficientemente grande como para que la autonomía compense. Un módulo completo con tests. Una suite de endpoints contra un contrato OpenAPI. Una fase entera de un pipeline de generación.
No son modelos excluyentes. En un proyecto real, conviven. Las decisiones de arquitectura se toman en modo lineal. La implementación de cada feature, una vez que las decisiones están claras, puede correr en loop.
El workflow lineal te da control. El agentic loop te da escala. Saber cuándo necesitas cada uno es lo que convierte el uso de agentes en algo productivo.
