English

¿Agente o flujo de trabajo? Pregúntalo antes de construir

Todo el mundo corre a construir un agente de IA. La mitad debería estar construyendo algo más simple y más barato. Antes de conectar un LLM que decide su propio siguiente paso, hazte una pregunta: ¿esta tarea alguna vez cambia de verdad? Si la respuesta es no, no necesitas un agente — necesitas un flujo de trabajo con un paso de IA dentro.

La única pregunta que lo decide todo

La diferencia entre un flujo de trabajo y un agente se reduce a cómo se eligen los pasos. En un flujo de trabajo, los pasos están fijados de antemano: paso uno, paso dos, paso tres, siempre, en el mismo orden. La estructura de la salida está predeterminada. Un script — o una herramienta de automatización simple — puede ejecutarlo todo sin que ningún modelo decida qué ocurre a continuación.

Un agente es diferente. Es un LLM que decide dinámicamente qué herramientas o pasos usar, en qué orden, según lo que encuentra en el camino. Esa flexibilidad es exactamente lo que hace útiles a los agentes para problemas desordenados y abiertos — y exactamente lo que los convierte en la herramienta equivocada para cualquier cosa predecible.

Así que pregúntate: ¿este proceso es determinista o no determinista? Esa única pregunta te dice cuál construir.

Un ejemplo concreto

Toma una tarea común de operaciones de ventas: llega un nuevo prospecto, lo investigas, redactas un correo de contacto y lo envías. Los mismos cuatro pasos, cada vez, sin importar qué prospecto aparezca. Eso no es territorio de agentes — es un flujo de trabajo con un paso de IA dentro (la investigación y la redacción pueden usar perfectamente una llamada a un LLM; la orquestación a su alrededor no lo necesita).

Compáralo con una bandeja de soporte al cliente, donde cada mensaje entrante es distinto: algunos necesitan una búsqueda de reembolso, otros necesitan escalamiento, otros necesitan una cadena de herramientas completamente diferente según lo que el cliente realmente dijo. Ese es el tipo de problema impredecible y ramificado para el que se construye un agente.

Cómo decidir, paso a paso

1. Escribe los pasos que tu tarea realmente toma, desde el disparador hasta la salida. Si puedes escribirlos en orden y no cambian según la entrada, tienes un flujo de trabajo.
2. Revisa si el número de pasos es fijo. Un flujo de trabajo puede tener una o dos ramas condicionales (si X entonces Y), pero un agente puede agregar, omitir o reordenar pasos por completo según lo que encuentre a mitad de la tarea.
3. Si es predecible, arma un flujo de trabajo — una tubería lineal, con una llamada a un LLM para la parte que genuinamente requiere criterio (redactar texto, clasificar un elemento), y código determinista para todo lo demás.
4. Si es impredecible, construye un agente — dale un prompt de sistema, un conjunto de herramientas, y déjalo decidir por sí mismo cuáles llamar y cuándo.
5. Revísalo periódicamente. Una tarea que al principio parece impredecible (p. ej. "manejar tickets de soporte") a menudo se descompone en un puñado de subflujos predecibles detrás de un agente que solo toma la decisión inicial de enrutamiento.

Por qué la opción "más barata" suele ganar

Los flujos de trabajo superan a los agentes en cuatro frentes cuando la tarea es genuinamente fija: confiabilidad, costo, facilidad de depuración y escala.

• Confiabilidad — un flujo de trabajo hace lo mismo cada vez; no hay riesgo de que el modelo decida omitir un paso o llamar una herramienta en un orden extraño.
• Costo — cada decisión de un agente es una llamada a un LLM (a veces varias, para planificación y selección de herramientas). Un flujo de trabajo solo gasta tokens donde tú explícitamente pusiste un paso de IA.
• Depuración — cuando un flujo de trabajo falla, sabes exactamente qué paso falló, porque los pasos son fijos y se registran en orden. La falla de un agente puede estar en cualquier lugar de una cadena de decisiones abierta.
• Escala — el costo y la latencia de un flujo de trabajo son predecibles y lineales. Los de un agente no, porque el número de pasos (y de llamadas al LLM) que toma puede variar de una ejecución a otra.

Nada de esto significa que los agentes sean malos — significa que son la herramienta adecuada para un tipo específico de problema: trabajo desordenado, ramificado y con mucho criterio, como investigación abierta o clasificar tickets de soporte con puntos de decisión reales.

Errores comunes

• No construyas un agente porque se siente más impresionante. Un agente que reimplementa un proceso de cuatro pasos siempre en el mismo orden es estrictamente peor que un flujo de trabajo en costo, latencia y confiabilidad — y sin ninguna de las ventajas.
• Tampoco fuerces un problema genuinamente ramificado dentro de un flujo de trabajo rígido. Si te encuentras escribiendo un muro de condiciones if/else anidadas para cubrir cada caso, eso suele ser señal de que la tarea en realidad necesita un modelo que tome la decisión de ramificación — es decir, un agente.
• Revisa la clasificación a medida que la tarea evoluciona. Un flujo de trabajo que empieza simple puede acumular casos límite hasta convertirse silenciosamente en "trabajo de un agente" disfrazado.

Recursos

• Anthropic — Building Effective Agents (workflows vs. agents)
• LangChain — Agent concepts and when to use them