Un chatbot responde; un agente de IA hace. Esa es la diferencia entre chatbot y agente en una línea: el chatbot recibe una pregunta y devuelve un texto, mientras que el agente recibe un objetivo, consulta y modifica tus sistemas (el calendario, el inventario, el CRM) y termina con una tarea completada, no con una explicación de cómo completarla. He construido los dos: chatbots para clientes que responden desde los documentos de una empresa o redactan cartas listas para enviar, un agente autónomo que publica noticias cada tres horas y un agente de voz, hecho como prueba de concepto para un cliente, que termina la llamada con una cita creada en el calendario. La forma más rápida de saber cuál necesitas es mirar qué pasa cuando termina la conversación: si alguien de tu equipo copia datos a otro sistema, ese trabajo es el que haría un agente.
TL;DR
- Un chatbot entrega información: responde preguntas desde tus documentos. Un agente entrega resultados: usa herramientas conectadas a tus sistemas para agendar, registrar o actualizar algo.
- El chatbot es más barato, más rápido de construir y su peor error es una respuesta equivocada. El agente ahorra trabajo real, pero su peor error es una acción equivocada, y eso exige confirmaciones, permisos acotados y registro de todo lo que hace.
- Si la conversación termina con una persona de tu equipo copiando datos a otro sistema, lo que necesitas es un agente. Si termina cuando el cliente tiene su respuesta, un chatbot alcanza.
Qué es un chatbot y qué es un agente de IA
Un chatbot con IA es un programa que conversa: recibe un mensaje, un modelo de lenguaje genera una respuesta y la devuelve. Los buenos no responden de memoria. Buscan primero en los documentos de tu empresa (manuales, políticas, catálogo, preguntas frecuentes) y responden a partir de lo que encontraron; esa técnica se llama RAG, generación aumentada por recuperación. Lo que sale de un chatbot, siempre, es texto: una respuesta, un resumen, un borrador. Es lo que muchas empresas llaman asistente virtual, y puede vivir en tu web o en WhatsApp.
Un agente de IA también conversa, pero además tiene herramientas. Una herramienta es una función que el modelo puede pedir que se ejecute: consultar los horarios libres, crear una reserva, buscar un pedido por número, registrar un contacto en el CRM. El agente decide qué herramienta usar, lee el resultado y decide el siguiente paso, en un ciclo que se repite hasta que la tarea está hecha o hasta que necesita que alguien le confirme algo. Ese ciclo es lo que en la parte técnica se llama agent loop.
La diferencia práctica está en lo que queda cuando termina la conversación. Con un chatbot, el cliente sabe algo que antes no sabía. Con un agente, algo cambió en tus sistemas: hay una cita en el calendario, un ticket abierto, un pedido actualizado.
Diferencia entre chatbot y agente de IA, en una tabla
| Chatbot con IA | Agente de IA | |
|---|---|---|
| Qué entrega | Una respuesta o un texto | Una tarea completada |
| Con qué trabaja | Tus documentos y el historial de la conversación | Tus documentos más herramientas conectadas a tus sistemas |
| Quién hace el paso final | Una persona, con la información que le dio el chatbot | El propio agente, dentro de los límites que le pusiste |
| Peor error posible | Una respuesta equivocada | Una acción equivocada: una reserva duplicada, un dato mal registrado |
| Integraciones | Pocas o ninguna | Una por cada sistema que toca |
| Llamadas al modelo por conversación | Normalmente una por mensaje | Varias por mensaje, una por cada paso del ciclo |
| Cómo se mide si funciona | Porcentaje de respuestas correctas y de preguntas que no supo responder | Porcentaje de tareas completadas sin intervención humana y errores en acciones |
La fila del peor error es la que más pesa al decidir. Un chatbot que se equivoca da una mala respuesta, que se corrige con otra. Un agente que se equivoca deja un efecto en tus sistemas que alguien tiene que detectar y deshacer.
Sigue leyendo
Hasta aquí la primera mitad. El recorrido completo — con el resto de la implementación, las decisiones de diseño y lo que solo aparece en producción — está en mi blog:
Lee el artículo completo en ramonchancay.me →
Publicado originalmente en www.ramonchancay.me/es/blog/chatbot-vs-agente-de-ia.
Top comments (3)
La fila del peor error es la que yo pondría primero en la tabla, y creo que también cambia la fila de cómo se mide.
Si la métrica principal del agente es el porcentaje de tareas completadas sin intervención humana, el incentivo empuja a quitar confirmaciones, que es justo el control que pides en el TL;DR. Yo la pondría al lado de otra: cuántas acciones hubo que deshacer o corregir cada 100 tareas. La primera mide trabajo ahorrado; la segunda, cuánto de ese trabajo volvió a tu equipo como limpieza.
La reserva duplicada que mencionas suele venir de un reintento. En un agente de voz, si la llamada al calendario tarda y el ciclo vuelve a pedir la herramienta de crear cita, puedes terminar con dos citas. Una clave de idempotencia por intento de reserva (por ejemplo, el id de la llamada más el horario) hace que el segundo pedido devuelva la cita que ya existe en lugar de crear otra.
En tu prueba de concepto de voz, ¿qué pasaba si el calendario no respondía a tiempo: el agente reintentaba o le avisaba al cliente?
Tienes razón con la métrica, y la adopto: tareas completadas sin intervención dice cuánto trabajo ahorró el agente, y acciones deshechas o corregidas por cada 100 tareas dice cuánto de ese trabajo volvió al equipo. Medir solo la primera premia quitar confirmaciones, que es justo lo contrario de lo que pido.
Sobre la reserva duplicada: en la PoC de voz la clave de idempotencia es el id de la conversación, que ElevenLabs ya provee, así que la segunda petición devuelve la cita existente en vez de crear otra. Tu variante con el horario añadido es más fina, porque permite que la misma llamada agende dos citas distintas sin chocar; en mi caso una llamada agenda una sola.
Si el calendario no responde a tiempo, el agente no reintenta solo. A los 3 segundos suelta una frase fija para que no haya silencio, y si la llamada falla el backend devuelve un 200 con booked: false y una frase hablada que explica qué pasó y ofrece volver a intentarlo en un momento. El reintento lo decide la persona, no el ciclo.
El caso que yo revisaría es el timeout, porque ahí booked: false puede ser falso. Si el calendario recibió la petición y solo tardó en contestar, la cita pudo quedar creada sin que tu backend lo sepa. La persona escucha que falló, cuelga, vuelve a llamar más tarde con otro id de conversación, y la clave de idempotencia ya no la cubre: dos citas.
Yo usaría tres estados en vez de dos: reservada, no reservada y sin confirmar. En el tercero, antes de ofrecer el reintento, el backend busca en el calendario un evento marcado con el id de la conversación. En Google Calendar, por ejemplo, puedes guardarlo en extendedProperties.private y filtrar events.list con privateExtendedProperty. Si aparece, confirmas esa cita; si no aparece, ofreces volver a intentarlo.
¿La PoC usa un calendario que permita guardar ese id en el evento, o solo puedes buscar por horario?