Flujos frente a agentes: dónde se acaba de verdad el código rígido

«Agente» se ha convertido en la palabra que se usa para cualquier sistema con un modelo dentro. Es una lástima, porque debajo hay una distinción real, tiene consecuencias sobre qué puedes depurar a las tres de la mañana, y ya está escrita con claridad.

1. Dos modelos de control

Building Effective Agents, de Anthropic, traza la línea con una sola pregunta: quién decide el camino. Los flujos son «systems where LLMs and tools are orchestrated through predefined code paths». Los agentes son «systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks».

Esa prueba reclasifica muchas cosas que se venden como agentes. Y reclasifica también nuestro propio sistema, y conviene decirlo sin rodeos: con esta definición, el orquestador conversacional de Bentho es un flujo. El modelo extrae con temperatura 0; el código decide.

2. El marco, y lo que de verdad recomienda

El artículo nombra seis patrones: encadenado de prompts, enrutado, paralelización, orquestador-trabajadores, evaluador-optimizador y el agente autónomo. Cinco de los seis son flujos. Esa proporción es la recomendación, enunciada como taxonomía.

Start with simple prompts, optimize them with comprehensive evaluation, and add multi-step agentic systems only when simpler solutions fall short.

Anthropic — Building Effective Agents

Viniendo de una empresa que vende los modelos, es un consejo contra su propio interés a corto plazo, que es más o menos el único que merece la pena citar.

3. Dónde se acaba de verdad un lienzo

Lo habitual aquí es afirmar que los constructores visuales se rompen a partir de cierto número de nodos. No existe tal número — ni un umbral documentado en n8n, Make o Zapier, ni un resultado de investigación. Así que va el mecanismo, que además lo puedes contrastar contra tu propia pantalla.

Un lienzo sostiene el camino feliz estupendamente. Lo que sostiene mal es todo lo que no es un camino: una invariante («esta cifra siempre tiene que venir de la cotización»), un contrato («este campo es una cadena de como mucho 4000 caracteres»), una política («nunca respondas un precio que no puedas respaldar»). Nada de eso es un paso, así que nada de eso tiene dónde vivir en un diagrama.

Entonces se codifican como más ramas, y el diagrama crece justo en la dirección en la que peor se lee. La señal de verdad no es el número de nodos: es el momento en que el equipo empieza a añadir sub-flujos y nodos de código. Ahí el lienzo está admitiendo que dejó de ser la representación.

4. Autonomía acotada: contratos, no confianza

Si le das margen a un modelo para decidir, la pregunta útil no es cuánta libertad tiene sino qué no puede hacer pase lo que pase. Tres fronteras hacen casi todo el trabajo, y las tres son ingeniería corriente:

1. Valida la entrada antes de que nada decida. Comandos tipados extraídos del turno, comprobados en la frontera. Lo que llega al código de decisión ya tiene forma conocida.
2. Dale un contrato a cada capacidad. Qué recibe, qué devuelve y para qué cliente, comprobado antes de ejecutarse. Una capacidad que verifica quién pregunta no se deja convencer de responder por otro.
3. Verifica la salida antes de que salga. Toda cifra del mensaje final tiene que venir de una autoridad. La que no, se descarta y responde una plantilla determinista.

Con esas tres puestas, la autonomía deja de ser un riesgo que aceptas y pasa a ser una región que dibujaste. Bentho además aísla el trabajo realmente abierto en sub-agentes —con interrupción determinista para aprobación humana en transferencias y disputas—, que es la forma híbrida en la práctica: un flujo que delega, no un agente supervisado.

5. Una matriz de decisión que se puede aplicar

6. Patrones híbridos

Los dos no se excluyen, y la forma útil no suele ser ninguna de las dos puras. Una columna vertebral determinista lleva el turno, el dinero y los contratos; un agente acotado se encarga de la única subtarea cuya longitud nadie puede predecir —una investigación, una conciliación, un documento sucio— y devuelve un resultado tipado que la columna verifica como cualquier otra entrada.

La disciplina es que la columna nunca delega la decisión de la que responde. Delegar trabajo es una optimización; delegar criterio es un cambio de arquitectura.

El marco, y dónde leerlo entero

El marco no es nuestro. Es de Anthropic, citado palabra por palabra más arriba, y merece leerse entero: es corto, y contradice buena parte de lo que se vende como agéntico.

• building-effective-agents — Define flujos como «systems where LLMs and tools are orchestrated through predefined code paths» y agentes como «systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks». La diferencia es QUIÉN decide el camino, no cuánta IA hay dentro.
• building-effective-agents — «Workflows offer predictability and consistency for well-defined tasks, whereas agents are the better option when flexibility and model-driven decision-making are needed at scale». Los agentes encajan en «open-ended problems where it's difficult or impossible to predict the required number of steps».
• building-effective-agents — «Start with simple prompts, optimize them with comprehensive evaluation, and add multi-step agentic systems only when simpler solutions fall short». El consejo va en contra de la propia venta: construir el sistema CORRECTO, no el más complejo.
• building-effective-agents — Los patrones que nombra: encadenado de prompts, enrutado, paralelización (seccionado y votación), orquestador-trabajadores, evaluador-optimizador, y el agente autónomo. Cinco de los seis son FLUJOS.

Consultado en el artículo de Anthropic el 2026-09-25. Puede haber cambiado desde entonces: si vas a tomar una decisión con alguno de estos datos, míralo en el tuyo.