La versión honesta de esta comparación empieza con una confesión: para muchos casos de uso el chatbot sigue siendo la respuesta correcta, y la industria lleva dos años fingiendo lo contrario.
Así que va la diferencia, y después la parte donde te decimos cuándo no construir el agente.
La diferencia real
Un chatbot sigue un camino que escribió una persona. Alguien dibujó el árbol: si el cliente toca "Rastrear mi pedido", pedir el número, llamar al endpoint de tracking, mostrar el resultado. Cada rama existe porque una persona la puso ahí.
Un agente decide. Recibe un objetivo, un conjunto de tools y permiso para elegir. Nadie escribió el camino, porque el camino es distinto cada vez.
Esa es toda la distinción. No es inteligencia, ni el modelo, ni si "entiende lenguaje natural" (los chatbots manejan lenguaje natural desde hace años). La pregunta es: quién eligió qué pasa después, una persona en tiempo de diseño o el modelo en tiempo de ejecución.
El mismo pedido, de las dos formas
Un cliente escribe: "hola compré algo la semana pasada para el cumpleaños de mi mamá y todavía no llega, el cumpleaños es el sábado, ¿pueden revisar?"
El chatbot:
No entendí eso. Elige una opción:
1. Rastrear un pedido
2. Devoluciones
3. Hablar con un agenteNo falló. Hizo exactamente lo que fue construido para hacer. El mensaje no coincidió con ninguna rama, así que cayó al default.
El agente:
turno 1 no hay número de pedido en el mensaje
llama: find_orders(customerPhone) -> un pedido, del 4 de agosto
turno 2 llama: lookup_order("4471") -> in_transit, eta 14 de agosto
turno 3 responde"Encontré tu pedido del 4 de agosto. Va en camino y la transportadora estima el 14, que es después del sábado. Puedo pedir que lo agilicen o iniciar un reembolso. ¿Qué prefieres?"
Pasaron dos cosas que ninguna rama podría haber cubierto: dedujo que el número de pedido faltante se podía encontrar desde el teléfono, y notó que la fecha de entrega cae después del cumpleaños que el cliente mencionó al pasar. Nadie scriptó "comparar la ETA con una fecha que el cliente mencionó de paso".
Ese es el argumento a favor de los agentes, dicho con toda la fuerza que merece.
Ahora el argumento en contra
Los chatbots son predecibles, y la predictibilidad vale. Puedes enumerar todo lo que un chatbot va a decir alguna vez. Con un agente no puedes. En contextos regulados eso no es una preferencia, es un requisito.
Los chatbots son más baratos. Tocar un botón no cuesta nada. Un turno de agente es una llamada al modelo cargando toda la conversación, y los pedidos complejos toman varios.
Los chatbots son más rápidos. Sin modelo en el camino, la respuesta es instantánea. Un agente que llama dos tools tarda unos segundos, lo que en WhatsApp está bien y en una llamada telefónica no.
Los chatbots fallan de forma visible. Cuando un chatbot se rompe, ves un menú roto. Cuando un agente se rompe, produce una respuesta fluida, segura y equivocada, y te enteras por un cliente.
La decisión
| Tu situación | Construye |
|---|---|
| Cinco opciones, y el 90 por ciento de la gente quiere una de ellas | Chatbot |
| Las respuestas deben estar aprobadas palabra por palabra (legal, médico, financiero) | Chatbot |
| Los pedidos son abiertos y llegan con las palabras del cliente | Agente |
| Responder requiere consultar dos o tres cosas y combinarlas | Agente |
| Tu knowledge base cambia cada semana y nadie quiere redibujar un árbol | Agente |
| Estás en una llamada con un presupuesto de latencia de un segundo | Agente, con tools muy rápidas |
| La acción es irreversible y cara si sale mal | Cualquiera de los dos, con un humano aprobando |
| No tienes tools que darle | Ninguno. Quieres búsqueda sobre tus documentos |
La última fila atrapa a más equipos de los que uno esperaría. Un agente sin tools es un FAQ bien hablado, y montar infraestructura de agentes para llegar a eso es mucho trabajo para algo que resuelve una caja de búsqueda.
Lo que realmente se lanza: los dos
El patrón que sobrevive a producción no es uno u otro. Es un flow con script en el camino que ya conoces, y un agente en todo lo demás.
El opt-out es el ejemplo más claro. Cuando alguien escribe BAJA, no quieres un modelo decidiendo. Quieres una rama determinista que lo desuscriba, siempre, en menos de un segundo. Lo mismo con "quiero hablar con una persona": sin interpretación, solo el handoff.
Todo lo que no está en la lista de caminos conocidos va al agente.
En Zavu esto mapea directo. Los flows manejan los caminos deterministas con triggers por keyword. El agente maneja el resto, con tools para lo que necesita hacer y una tool transfer_to_human para lo que no debería.
Ese reparto lo describes, no lo programas. Instalas las skills y el CLI una vez (npx skills add zavudev/zavu-skills y npx zavudev@latest login), y después le pasas la política a tu coding agent:
> Deja los flows de keyword de BAJA y "hablar con una persona" exactamente como están. Agrega un agente para todo lo demás. Dale una tool transfer_to_human que haga POST a nuestro webhook de guardia, y haz que use esa tool para reembolsos sobre USD 200 en vez de decidir por su cuenta.
Lo que vuelve:
TypeScriptimport { defineAgent, defineTool } from "@zavudev/functions" defineAgent({ senderId: process.env.SENDER_ID!, name: "Soporte", provider: "zavu", model: "openai/gpt-4o-mini", prompt:Eres soporte de una tienda online. Nunca prometas una fecha de entrega que la transportadora no te haya dado. Para reembolsos sobre USD 200, usa transfer_to_human en vez de decidir., }) defineTool({ name: "transfer_to_human", description: "Hand the conversation to a person. Use for refunds over $200, complaints about damage, or any time the customer asks for a human.", parameters: { type: "object", properties: { reason: { type: "string" } }, required: ["reason"], }, handler: async ({ reason }, ctx) => { await notifyOnCall({ conversation: ctx.sessionId, reason }) return { transferred: true } }, })
Revisa una cosa en ese diff antes de mandarlo: la regla de escalamiento vive en dos lugares a propósito. En el prompt, para que el modelo conozca la política, y en la descripción de la tool, para que reconozca el momento. Los prompts declaran la política. Las descripciones de tools disparan el comportamiento. Ponerlo en solo uno de los dos es la razón más común de que un agente que "sabe" que debe escalar nunca lo haga, y es lo que un coding agent deja a medias más seguido.
Cómo saber cuál ya tienes
Si un proveedor te vende un "agente de IA", tres preguntas lo resuelven:
Migrar de uno al otro
No necesitas tirar el chatbot. El camino que funciona:
Empezar por el fallback significa que el agente solo maneja conversaciones que ya estaban fallando, así que el downside está acotado desde el día uno.
Para seguir leyendo
- Qué es un agente de IA: la definición y las cuatro partes.
- Cómo crear un agente de IA: el loop desde cero y después deployado en un canal.
- Cómo crear un chatbot de WhatsApp: si la tabla de decisión te trajo hasta acá.
- Frameworks de agentes de IA comparados: una vez que decidiste por el agente.