Agentes de IA y chatbots no son lo mismo, y la diferencia se puede verificar

Si alguna vez escribiste «QUIERO HABLAR CON UN HUMANO» en el chat de una empresa, sabes cómo se siente un chatbot que llegó a su límite. Lo que casi nadie explica es dónde está ese límite y por qué un agente de IA lo mueve.

La respuesta corta: no compres la etiqueta. Comprueba el recorrido que puede ejecutar, con qué permisos y quién responde por el resultado.

Si necesitas una referencia antes de comparar, el glosario de chatbots y agentes de IA define LLM, RAG, MCP, memoria, handoff y aprobación humana sin convertirlos en promesas de producto.

Un chatbot puede resolver la conversación; el proceso se debe demostrar

Un chatbot, incluso uno con un modelo de lenguaje detrás, suele empezar por responder con la información que le cargaste: manuales, políticas, sitio web o base de conocimiento. Algunos también se conectan a sistemas o activan automatizaciones. Lo decisivo no es llamarlo chatbot o agente: es saber qué dato vivo consulta, qué acción puede ejecutar y qué sucede si esa acción falla.

Cuando quien pregunta es un empleado y la respuesta debe cruzar conocimiento interno, CRM y sistemas con acceso por rol, la intención es distinta de atender clientes en varios canales. Meteor concentra ese recorrido en su Company Brain operativo; la página de chatbot omnicanal conserva el recorrido comercial y de servicio al cliente.

Eso funciona perfecto mientras la respuesta esté escrita en alguna parte y no cambie:

• «¿A qué hora abren?»
• «¿Cuál es la política de devoluciones?»
• «¿Hacen envíos a Pasto?»

Las preguntas que dependen de un dato vivo exigen evidencia adicional:

• «¿Tienen la referencia 4021 en talla M?»
• «¿Cuánto me sale enviar 3 kilos a Bucaramanga?»
• «¿Me pueden agendar el jueves en la tarde?»

Ninguna de esas tres se responde de forma fiable leyendo un documento. Se necesita consultar un sistema o transferir el caso. Un chatbot configurado con esa conexión puede participar; pide que te muestren el conector, la credencial, la acción y el camino de error antes de asumir el alcance.

Un agente de IA llama a herramientas

Un agente tiene, además del modelo, una lista de herramientas. Cada herramienta es una función concreta contra un sistema real, con un nombre, unos parámetros y unos permisos.

No es una metáfora. En nuestro caso las herramientas se publican con nombre propio en cada ficha del catálogo, y esa lista sale del código, no de un documento de mercadeo. Por ejemplo, el CRM nativo expone crm_create_contact, crm_update_contact, crm_search_contacts y otras veintiuna. La agenda expone agenda_get_event_types, agenda_get_slots y agenda_create_booking.

Con esa lista, «agéndame el jueves en la tarde» deja de ser una promesa y pasa a ser un procedimiento de tres llamados:

1. agenda_get_event_types devuelve qué servicios se pueden agendar y cuánto dura cada uno.
2. agenda_get_slots devuelve los huecos que de verdad están libres entre dos fechas.
3. agenda_create_booking reserva el hueco exacto que la persona eligió.

El Met no inventa el horario: lo lee. Y no lo reescribe a mano, que es donde se cuelan los errores de zona horaria. Si quieres ver el procedimiento completo, incluido el recordatorio de la víspera, está publicado en la automatización de agendamiento por WhatsApp.

Esa capacidad de conectar un modelo con herramientas reales se apoya hoy en un estándar abierto, el Model Context Protocol. Que sea un estándar y no un invento de cada fabricante importa por una razón práctica: la lista de herramientas de un agente es inspeccionable, y por lo tanto verificable.

La tabla que sirve, y la que no

Casi todas las comparaciones que vas a encontrar tienen una tabla con adjetivos: «rígido» contra «fluido», «literal» contra «contextual». Son ciertas y son inútiles, porque no se pueden comprobar antes de firmar.

Esta es la versión que sí se puede comprobar:

Pregunta que haces al proveedor	Chatbot o automatización conversacional	Met de Meteor
¿Qué herramientas puede llamar?	Pide la lista verificable, si ofrece integraciones.	Meteor publica herramientas y límites por conector.
¿Qué credencial necesita?	Pide el permiso y quién lo administra.	Una por cada sistema conectado, con el alcance que requiere el flujo.
¿Qué hace si el sistema externo falla?	Pide el caso de error y el escalamiento.	El Met debe transferir o detener el paso según el flujo y el límite configurado.
¿Puede escribir, o solo leer?	Depende de la configuración y del proveedor.	Depende del conector y del permiso; SIESA es solo lectura.
¿Dónde queda registrado lo que hizo?	Confirma el registro que ofrece la solución.	CRM conserva conversación, contexto y siguiente paso cuando ese flujo está habilitado.

Si a la primera pregunta te responden con una categoría («se integra con tu CRM») en vez de con nombres y límites, todavía no tienes base para decidir qué automatización puede ejecutar.

Cuando ventas, operación y marketing tienen que avanzar

La diferencia que Meteor debe demostrar no es una respuesta más atractiva. Es que una conversación avance el trabajo de tres equipos, sin perder el control humano:

• Ventas + CRM: el Met reconoce o crea el contacto, captura el contexto, califica y entrega el siguiente paso. La negociación y las excepciones se transfieren al responsable.
• Operación: consulta datos publicados de los sistemas conectados. En SIESA puede consultar stock, precio, cartera, cupo o pedido, pero no crea pedidos, pagos ni documentos contables.
• Marketing: el Met de Redes crea piezas, publica en Facebook e Instagram y prepara pauta en Meta y Google. El equipo aprueba antes de publicar y antes de gastar; el lead entra al mismo flujo de CRM.

Pide esos tres recorridos en una demo. Si la plataforma solo demuestra mensajes, todavía no ha demostrado cómo trabaja el área que debe actuar después del mensaje.

Ejecutar también significa poder equivocarse

Aquí viene la parte que la mayoría de los artículos sobre este tema no escribe, y es la que más te conviene leer.

Un chatbot falla de forma ruidosa: dice que no entiende, la persona se molesta, tú te enteras. Un agente falla de forma silenciosa: crea el pedido con la cantidad equivocada, y te enteras cuando llega el reclamo.

Por eso la pregunta «¿qué herramientas tiene?» es en realidad una pregunta de seguridad, no de capacidad. Un agente que solo puede leer no puede romper nada. Uno que puede escribir necesita límites explícitos, y esos límites tienen que estar escritos antes de encenderlo.

Es la razón por la que varias de nuestras integraciones son deliberadamente de solo lectura, y por la que cada ficha del catálogo tiene un bloque que dice qué no hace. Consultar el ERP no es lo mismo que modificarlo. Crear una factura no es lo mismo que timbrarla ante la DIAN.

Cómo decidir cuál necesitas

No es una decisión de tecnología, es una decisión de qué preguntas te llegan.

Toma cien conversaciones reales de la semana pasada y clasifícalas en dos montones: las que se responden con información que ya está escrita, y las que necesitan consultar o modificar algo. Si el primer montón es la mayoría, un chatbot bien cargado te resuelve el problema y cuesta menos.

Si el segundo montón es la mayoría, evalúa una solución que pueda demostrar el acceso, la acción y la transferencia que necesita tu proceso. En Meteor, esa prueba se hace con Mets y las herramientas de tus sistemas conectadas.

La mayoría de los negocios que miramos tienen el segundo montón más grande de lo que creían, y esa sorpresa suele venir del mismo lugar: las preguntas de stock, precio y disponibilidad se sienten simples de responder, pero ninguna se responde leyendo un documento.