¿Por qué seguimos necesitando flujos de trabajo en la era de los agentes de IA?

Para que un agente analice pedidos y envíe un informe cada mañana a las nueve, una tarea programada puede iniciarlo. Los eventos o Webhooks también permiten empezar cuando cambian los datos.

Si el informe cumple tus expectativas y el proceso es sencillo, puede ser suficiente.

Con el tiempo, los requisitos pueden concretarse: la tasa de reembolsos debe usar una definición común, solo deben analizarse ciertos datos y los mensajes a clientes necesitan aprobación antes de enviarse. Tras cambiar el cálculo, también hay que saber qué informes usaron la versión anterior.

Entonces surgen otras preguntas. ¿Qué decisiones debe tomar el agente durante la ejecución y qué pasos deben seguir reglas acordadas? ¿Dónde se guarda el estado mientras espera aprobación? ¿Podrá otra persona entender el proceso y mantenerlo?

Un flujo de trabajo permite organizar estos requisitos. Guarda de forma explícita los pasos, las relaciones entre datos y las condiciones de aprobación, mientras el sistema de ejecución gestiona el estado. El agente puede ayudar a construirlo y encargarse de las tareas que requieren interpretación y criterio.

Aplicar las reglas acordadas de forma consistente

En un informe diario de pedidos, sumar importes, agrupar estados y filtrar fechas siguen reglas concretas. ¿El denominador de la tasa de reembolsos incluye todos los pedidos o solo los pagados? ¿Se usa la fecha del pedido o la del reembolso? Una vez acordadas, estas definiciones deben incorporarse al código.

Un agente también puede llamar a ese código. El flujo guarda además su relación con los otros pasos: de dónde llegan los datos, qué nodo recibe el resultado y bajo qué condiciones se envía el informe. Esas relaciones pueden revisarse por separado.

La IA puede interpretar los comentarios de los clientes, sugerir posibles causas de las anomalías y elegir qué destacar en el resumen. Por ejemplo, el código selecciona primero los pedidos inusuales, pasa esos registros al modelo y envía su resumen al paso de notificación.

Lo que queda definido son las reglas de cálculo y la estructura de ejecución. Las conclusiones del modelo pueden variar, pero sus entradas, su tarea y el destino de su salida tienen un lugar explícito.

Conservar el progreso mientras se espera una aprobación

Pensemos en una respuesta a un cliente. El agente ha leído el correo, revisado el pedido y redactado un borrador. Ahora espera la aprobación de la persona responsable.

Esa persona puede revisarlo horas después. El sistema debe conservar las entradas, la respuesta, los pasos completados y lo que debe suceder tras aprobar o rechazar. Al continuar, debe utilizar el estado de la misma ejecución y evitar repetir los pasos ya terminados.

Un sistema de agentes puede implementar estos mecanismos. Al elegir una plataforma de flujos, conviene comprobar qué gestión de estado ofrece y si cubre las esperas, las decisiones humanas y la continuación que necesita la tarea.

Un disparador inicia el trabajo; una notificación o una llamada posterior a una API entrega el resultado. Los horarios, eventos, Webhooks y consultas periódicas pueden iniciar tanto agentes como flujos. El diagrama muestra cómo se conectan las reglas, la IA, la aprobación y la notificación después del inicio.

Un ejemplo que puedes construir. Elige el disparador según la tarea; la aprobación es opcional. La ejecución requiere fuentes de datos, servicios de modelos y cuentas de notificación configurados.

Los nodos Approval y Wait de Open Flow guardan de forma persistente el estado de espera. Tras una decisión, la misma ejecución puede continuar sin repetir los pasos completados. Es una capacidad concreta que evaluar en tareas con intervención humana. Leer sobre aprobación y ejecución (en inglés).

¿Puede otra persona mantener esta tarea?

Al principio, puedes pedir al agente que pruebe varias veces y concretar las fuentes de datos, los criterios de cálculo y el formato del informe. Cuando otras personas participan en el mantenimiento, esas decisiones deben quedar registradas.

Quien mantiene la tarea necesita saber qué paso lee los pedidos, dónde se calcula la tasa de reembolsos, qué datos recibe el modelo y cuándo se envían mensajes. El diagrama, los mapeos de entrada y el código de los nodos ayudan a responder. La documentación y la configuración del proyecto también necesitan mantenimiento.

Después de un cambio, hay que saber qué versión de la lógica usó cada ejecución. Si el cálculo cambia el lunes, revisar el informe de la semana anterior requiere el código y las entradas de entonces. Vincular los registros a versiones concretas permite comprobar el resultado.

Si tu sistema de agentes ya ofrece estas capacidades, puedes seguir usándolo. Una plataforma de flujos reúne mecanismos habituales y reduce lo que el equipo tiene que construir y mantener por su cuenta.

Guardar y ejecutar estos procesos con Open Flow

Open Flow es la plataforma de flujos de trabajo de código abierto de OOMOL. Usa la versión alojada en OOMOL Flow, o visita el repositorio de GitHub para ver el código y las instrucciones de alojamiento propio. Un agente puede crear un Flow y tú puedes revisar y editar el mismo proceso en el espacio visual Workbench.

Con oo flow, el agente crea nodos, comprueba borradores, prueba ejecuciones y consulta resultados. En Workbench puedes revisar las fuentes de datos, el código de cada paso y las condiciones de las ramas. Los clientes compatibles también pueden crear y ejecutar Flows mediante las herramientas MCP del Server.

Para el informe diario, una Code Task puede calcular y transformar datos con JavaScript, mientras una LLM Task genera el resumen. Si hacen falta varias llamadas a herramientas, puedes usar una Agent Task. Las entradas y salidas tienen nombres y tipos explícitos, y la lógica repetida puede organizarse en subflujos.

También necesitarás modificar el proceso una vez publicado. Open Flow crea una instantánea con versión para la automatización Live. Puedes seguir editando y probando el borrador y publicar una nueva versión cuando esté lista. El historial vincula cada ejecución a su revisión, lo que permite identificar el código y el proceso que produjeron un informe.

Leer datos de aplicaciones externas y enviar notificaciones requiere las cuentas y permisos adecuados. Open Flow ejecuta esas acciones a través de un entorno Connector como OpenConnector. El Connector guarda las credenciales y el Flow referencia los identificadores de las conexiones. Consultar las capacidades y opciones de despliegue (en inglés).

OOMOL se encarga de operar la versión alojada. Con alojamiento propio, tu equipo gestiona el almacenamiento, las copias de seguridad, las actualizaciones y las conexiones a servicios. El proyecto usa Apache-2.0 y está en Beta. Consulta la guía de inicio de Flow para conectar cuentas y configurar el agente.

Prueba con una tarea real

Elige una tarea recurrente que necesite reglas fijas o aprobación humana. Abre OOMOL Flow, conecta la fuente de datos y la cuenta de notificación necesarias y pide a tu agente:

Crea un Flow de informe diario de pedidos: lee los pedidos del día anterior, calcula los importes y la tasa de reembolsos según las definiciones que yo confirme, pide a la IA que resuma las anomalías y envía el informe al canal del equipo que indique. Primero crea y prueba un borrador; publica solo después de que revise los resultados.

Revisa los datos, el código y las salidas en Workbench. Si un agente programado es suficiente, puedes seguir usándolo. Cuando necesites reglas explícitas, aprobaciones e historial de versiones, decide si quieres poner este Flow en funcionamiento.

• Abrir OOMOL Flow y crear tu primer flujo de trabajo
• ¿Quieres alojarlo por tu cuenta o contribuir? Consulta el código fuente y las instrucciones de despliegue de Open Flow.