6. Cuándo usar un agente y cuándo no

Descripción

Al terminar esta lección vas a poder tomar un caso de automatización real y decidir, con un criterio concreto (no con intuición), si necesita un agente que razona y elige herramientas o si un workflow determinista con IF/Switch resuelve lo mismo con menos costo, menos latencia y menos riesgo. También vas a saber reconocer las señales de que un equipo metió un agente donde sobraba.

Esto importa porque es el error que más dinero cuesta en proyectos de automatización con IA: montar un agente para un caso de tres rutas fijas (algo que un Switch resuelve en segundos y sin factura de LLM), o al revés, forzar un IF interminable para un caso donde la entrada es tan variable que ningún árbol de decisión la cubre. Un cliente que pide "automatiza mis respuestas de soporte" no está pidiendo un agente — está pidiendo que el problema se resuelva. A veces la respuesta correcta es la más aburrida.

Conexión con el módulo: en la lección anterior viste las cuatro piezas que se conectan al agente (modelo, prompt, tools, memoria). Esta lección es el filtro que va antes de esas piezas: decide si vale la pena conectarlas.

El costo de la autonomía

Imagina que administras una tienda y necesitas cubrir la caja un día. Tienes dos opciones para la persona que la cubre:

Le entregas un manual con pasos fijos: "si el cliente paga en efectivo, haz X; si paga con tarjeta, haz Y; si pide factura, haz Z". La persona no piensa, ejecuta. Es rápida, predecible, y si algo sale mal sabes exactamente en qué paso falló.

O le das la tarjeta de la empresa y el criterio para usarla: "resuelve el problema del cliente, tienes presupuesto de hasta $500 y puedes pedir ayuda si dudas". Esa persona puede resolver casos que el manual nunca previó — un cliente con un problema raro, una situación que combina dos reglas — pero también puede tomar una decisión que tú no habrías tomado, y cada decisión le toma más tiempo pensarla.

Un workflow determinista en n8n (nodos IF, Switch, Code encadenados) es el manual: rutas fijas, conocidas de antemano, sin sorpresas. Un agente es la tarjeta de la empresa: el modelo decide qué tool usar, en qué orden, y cuándo detenerse. Esa decisión no es gratis — la vuelves a pagar en cada paso del bucle agéntico. Anthropic lo resume así en su guía de ingeniería de agentes: "la naturaleza autónoma de los agentes implica costos más altos, y el riesgo de errores que se acumulan" (traducción propia; ver Recursos). Cada vuelta del ciclo razonar → actuar → observar que viste en la lección 3 es otra llamada al modelo — y otra oportunidad de que interprete mal la entrada.

Esto te da una pregunta rápida antes de tocar el nodo AI Agent:

Pregunta	Si respondes SÍ	Si respondes NO
¿Puedes enumerar de antemano todas las rutas posibles (2, 5, incluso 15 casos)?	Workflow determinista	Sigue evaluando
¿La misma entrada debe producir siempre la misma salida (auditoría, compliance, facturación)?	Workflow determinista	Sigue evaluando
¿El volumen es tan alto que una llamada extra al LLM por caso pesa en el costo mensual?	Workflow determinista (o IA procedural de un solo paso, G6)	Sigue evaluando
¿La tarea combina varias fuentes o herramientas en un orden que depende de lo que dice el cliente, no de una regla fija?	Agente	Workflow determinista

Si respondiste "workflow determinista" en dos o más filas, ese es tu camino — aunque el proyecto suene más interesante como agente.

Ejemplo trabajado: la misma bandeja de WhatsApp, dos consultas distintas

Un equipo de soporte recibe mensajes de WhatsApp. Llegan dos consultas el mismo día:

Consulta A: "¿Cuál es su horario de atención?"

Esto tiene una ruta única y conocida: clasificar la intención (una sola llamada a un LLM, IA procedural — lo que ya viste en G6) y responder con un texto fijo desde un Set node. No hay tools que elegir, no hay orden que decidir. Si montas un agente aquí, el modelo va a "razonar" para terminar haciendo lo mismo que un IF habría hecho en cero llamadas extra.

• Input: el mensaje de WhatsApp.
• Proceso: un nodo de clasificación (LLM Chain, 1 llamada) detecta la intención horario → Switch enruta a la rama fija.
• Output: "Atendemos de lunes a viernes, 9:00 a 18:00 hora local." Siempre igual, siempre barato, cero sorpresas.

Consulta B: "Necesito cambiar la dirección de entrega del pedido #4521, y de paso quiero saber si me aplica el descuento de esta semana antes de confirmar."

Aquí no hay una ruta fija: el modelo tiene que decidir en qué orden resolver dos cosas relacionadas, y el orden importa (si el descuento ya no aplica, quizás el cliente no quiera cambiar nada). Esto es candidato real a agente:

• Input: el mismo mensaje de WhatsApp, pero con dos peticiones encadenadas.
• Proceso (bucle agéntico, 3 vueltas):
  1. El agente identifica que necesita el pedido → llama a la tool lookup_order(order_id=4521) → observa el resultado (dirección actual, estado del pedido).
  2. El agente identifica que necesita la regla de descuento → llama a la tool check_discount(customer_id, week=current) → observa el resultado (aplica o no).
  3. El agente compone la respuesta combinando ambos resultados y decide si pedir confirmación antes de ejecutar el cambio.
• Output: "El descuento de esta semana ya no aplica a pedidos modificados después de las 48 horas — tu pedido se hizo hace 3 días. ¿Aun así quieres que cambie la dirección a la nueva que me diste?"

Interpretación: la Consulta A resolvió en 1 llamada al LLM y cero tools. La Consulta B necesitó 3 llamadas (una por vuelta del bucle) más dos ejecuciones de tools reales. Si tu volumen diario es 500 consultas tipo A, montar un agente para todas te cobra 3x el costo y la latencia de lo que necesitas — el determinismo del Switch te sale gratis en comparación. Si tu volumen es 50 consultas tipo B al día, el agente es la única forma razonable de cubrir la combinatoria sin escribir un IF por cada combinación posible de pedido + descuento + método de pago.

Las señales de sobre-ingeniería

Estas son las señales de que un equipo montó un agente donde un workflow simple bastaba — revísalas contra cualquier agente que heredes o construyas:

• El agente solo usa una tool, siempre en el mismo orden. Si documentas las ejecuciones de las últimas dos semanas y ves que siempre llama a la misma tool primero, nunca se salta un paso ni cambia el orden, no es un agente — es un workflow determinista disfrazado, pagando el costo de que el modelo "decida" algo que ya estaba decidido.
• El system prompt es en realidad un algoritmo. Si tu prompt dice "primero haz X, luego si pasa Y haz Z, si no haz W", estás tratando de forzar determinismo dentro de un componente diseñado para tomar juicio. Ese algoritmo debería vivir en nodos IF/Switch, no en texto que el modelo puede malinterpretar.
• Nadie puede explicar por qué el agente tomó cierta ruta en producción. Si un caso salió mal y el equipo se encoge de hombros ("el modelo decidió así"), eso es aceptable para una recomendación de contenido, pero es una señal de alarma si el caso involucraba dinero, datos sensibles o una acción irreversible.
• El costo mensual del LLM sube y la calidad de respuesta no mejora. Si estás pagando más llamadas (más vueltas del bucle, más tokens de contexto por memoria) sin que el usuario final note una diferencia, estás pagando autonomía que nadie usa.

Errores comunes

1. Creer que "agente" significa "mejor". Es el malentendido conceptual más frecuente: tratar la autonomía como una funcionalidad que se agrega gratis, como si un agente fuera "un chatbot con más poder". No lo es — es un componente distinto, con un costo por decisión y un modo de fallo distinto (rutas impredecibles) al de un workflow (rutas fijas que puedes probar una por una). Cómo detectarlo: si al listar los casos que atiende tu "agente" cuentas 2 o 3 rutas y siempre son las mismas, ya sabes la respuesta. Cómo corregirlo: reemplaza el nodo AI Agent por un nodo de clasificación (IA procedural, una sola llamada) + Switch con las rutas fijas.

2. Confundir "la entrada es lenguaje natural" con "necesito un agente". Que el mensaje llegue en texto libre no significa que la resolución tenga que ser autónoma — puedes clasificar la intención con un solo prompt y luego ejecutar una rama fija, que es exactamente el patrón de IA procedural de G6. Cómo detectarlo: revisa si tu agente, en la práctica, nunca combina más de una tool ni cambia el orden entre ejecuciones. Cómo corregirlo: separa "entender qué quiere el usuario" (clasificación, 1 llamada) de "ejecutar la acción" (nodos deterministas); reserva el agente para cuando el orden de las acciones también depende del contexto.

3. Dar tools irreversibles a un agente en producción sin un paso de aprobación. Qué pasa: el agente decide cuándo usar una tool, no solo cómo — si le das acceso a "cancelar pedido" o "enviar reembolso" sin supervisión, una mala interpretación de la entrada se traduce directo en una acción real, no en un texto que puedes corregir después. Por qué ocurre: es fácil pensar en tools como "funciones que el agente puede llamar" y olvidar que cada tool con efecto en el mundo real necesita su propio análisis de riesgo. Cómo detectarlo: clasifica tus tools en reversibles (buscar, leer, listar) e irreversibles (cancelar, enviar, borrar, cobrar). Cómo corregirlo: para las irreversibles, agrega un paso de aprobación humana antes de ejecutar — n8n tiene soporte nativo para esto (ver Recursos). Este tema se retoma a fondo en el módulo de seguridad y confiabilidad del agente, más adelante en la guía.

Ejercicios

Ejercicio 1. Un negocio de e-commerce quiere automatizar: "cuando llega un email a soporte@, si el asunto contiene la palabra 'devolución', crear un ticket en el sistema de tickets con prioridad alta". ¿Agente o workflow determinista? Justifica con al menos dos filas de la tabla de decisión.

Ver solución

Workflow determinista. La ruta está completamente enumerada de antemano ("si contiene la palabra X, hacer Y") y no depende de que el modelo elija entre varias tools ni decida un orden — es un IF (o incluso un filtro de texto) seguido de la creación del ticket. Además, la misma entrada (asunto con "devolución") debe producir siempre la misma salida (ticket de prioridad alta): eso es la segunda fila de la tabla, y por sí sola ya descarta el agente. Meter un nodo AI Agent aquí solo agrega una llamada al LLM (costo y latencia) para tomar una decisión que un IF toma en cero llamadas.

Por qué funciona esta respuesta: aplica el criterio de enumerabilidad de rutas antes de mirar cualquier otra cosa — si las rutas se pueden contar y son fijas, el agente no aporta nada que el determinismo no dé más barato.

Ejercicio 2. Un equipo de ventas quiere que un bot de WhatsApp: reciba la pregunta de un lead, busque en el catálogo de productos si existe algo que coincida, consulte el inventario disponible, y si hay stock, ofrezca agendar una llamada — pero si el lead pregunta por un producto descontinuado, debe sugerir una alternativa antes de ofrecer la llamada. ¿Agente o workflow determinista?

Ver solución

Agente. La cuarta fila de la tabla aplica: la tarea combina varias fuentes (catálogo, inventario) en un orden que depende de lo que responde cada una, no de una regla fija — si el producto está descontinuado, el siguiente paso cambia (sugerir alternativa antes de ofrecer la llamada). Enumerar todas las combinaciones posibles con IF/Switch (producto existe × hay stock × está descontinuado × hay alternativa) crece rápido y cualquier producto nuevo en el catálogo rompe el árbol de decisión. Un agente con tools de search_catalog y check_inventory puede componer la secuencia correcta caso por caso sin que reescribas la lógica cada vez que cambia el catálogo.

Por qué funciona esta respuesta: el criterio decisivo no es "hay lenguaje natural" (ambos ejercicios lo tienen), sino si el orden de las acciones varía según lo que devuelve cada fuente — ahí es donde el determinismo deja de escalar.

Ejercicio 3. Tienes un agente en producción con una sola tool, send_email, y revisas los logs de las últimas 200 ejecuciones: en el 100% de los casos la tool se llama exactamente una vez, después de la misma pregunta de clasificación. ¿Qué señal de sobre-ingeniería aplica y qué harías?

Ver solución

Aplica la primera señal: "el agente solo usa una tool, siempre en el mismo orden" — eso es un workflow determinista disfrazado de agente, pagando en cada ejecución el costo de una decisión que ya está decidida (siempre es la misma tool, siempre después del mismo paso). La corrección es reemplazar el nodo AI Agent por: un nodo de clasificación (1 llamada, si de verdad necesitas que un LLM redacte el email) seguido de un nodo Send Email fijo — o incluso quitar el LLM del todo si el contenido del email también es fijo.

Por qué funciona esta respuesta: la evidencia (200 ejecuciones idénticas en estructura) es exactamente el tipo de dato que debes revisar antes de confiar en la intuición de "esto necesita ser un agente".

Resumen y siguiente paso

Ya tienes el filtro que decide si vale la pena conectar las cuatro piezas que viste en la lección anterior: enumerabilidad de rutas, necesidad de determinismo, volumen y costo, y si el orden de las acciones depende del contexto. Este criterio es el que vas a aplicar cada vez que alguien te pida "automatiza esto con IA" — antes de abrir el nodo AI Agent, antes de pensar en tools o memoria.

Antes de avanzar deberías poder: tomar un caso de automatización descrito en una frase y clasificarlo como agente o workflow determinista, justificando con al menos una fila de la tabla de decisión — y nombrar al menos dos señales de que un agente existente está sobre-diseñado.

Con esa decisión resuelta, lo que falta es dónde vas a correr el agente una vez que decidas construirlo — ese es el terreno de la próxima lección.

Recursos

• Building Effective Agents — la guía de Anthropic que origina el marco "workflow vs. agente" y la frase sobre el costo de la autonomía citada en esta lección; explica cuándo la complejidad de un agente se justifica y cuándo no.
• Agents vs chains — documentación oficial de n8n que compara el nodo AI Agent contra una chain simple con un workflow de ejemplo.
• What agents do — cómo n8n describe el ciclo de decisión del agente (setup, tool calls, evaluación, respuesta).
• How tools work — qué tools trae n8n de fábrica y cómo se conectan al agente; útil para dimensionar cuántas llamadas añade cada tool.
• Human-in-the-loop for tools — cómo insertar un paso de aprobación humana antes de que el agente ejecute una tool irreversible, el tema del tercer error común de esta lección.