Agentes vs chatbots: una checklist de producción

Un patrón conocido: una empresa despliega un chatbot, el deflection sube unas semanas, luego llegan las conversaciones difíciles y el bot falla con total seguridad. Casi nunca el problema era el modelo. Un chatbot y un agente son sistemas distintos, y producción los juzga con estándares distintos. Esta es la checklist que usamos antes de llamar agente a algo.

Deflection vs resolución

Un chatbot se mide por deflection: cuántas conversaciones evitaron a una persona. Un agente se mide por resolución: cuántas tareas completó de verdad.

Las dos métricas divergen. Un bot puede desviar la mayoría de conversaciones y no resolver casi nada, porque los usuarios se rinden y llaman por teléfono. Resolver significa que el sistema hace el trabajo: consulta el pedido, cambia la reserva, emite la factura.

Herramientas y memoria

Un agente lee y escribe en tus sistemas: CRM, calendario, gestión de pedidos, pagos. Sin herramientas es un asistente.

De ahí salen dos requisitos:

• Integraciones reales. Acceso de escritura con permisos claros, no un índice de FAQ de solo lectura.
• Memoria con política. El agente recuerda lo que importa dentro de una tarea, y entre conversaciones cuando toca, y es explícito sobre lo que guarda.

Límites

Un agente que puede actuar también puede actuar mal. Cada acción que puede ejecutar pertenece a una de tres listas:

• Hace solo. Trabajo de bajo riesgo y reversible: responder, hacer seguimiento, conciliar.
• Te consulta. Todo lo que supera un umbral: pagos grandes, descuentos, excepciones.
• Nunca hace. Acciones que ningún agente debe ejecutar: firmar contratos, cambiar cuentas bancarias.

El agente que reprograma una cita no debería poder devolver un año de facturas sin una persona. Las listas empiezan siendo conservadoras y se amplían cuando la evidencia lo justifica.

Evaluación

A un modelo de lenguaje no se le pueden hacer unit tests como a una función. La misma entrada puede dar salidas válidas distintas, y un pequeño cambio de prompt puede romper un flujo que ayer funcionaba.

Los agentes necesitan un harness de evaluación: escenarios reales con resultados esperados, ejecutados en cada cambio. Como mínimo:

• Evals de tarea. ¿Completó el agente la reserva, con los datos correctos, en el sistema correcto?
• Evals de regresión. Los fallos pasados, repetidos en cada release.
• Evals adversariales. Prompt injection, peticiones fuera de alcance, instrucciones contradictorias.

Observabilidad

Para cualquier acción del agente tienes que poder responder: qué vio, qué decidió, a qué llamó y cuánto costó. Eso significa trazar cada ejecución de principio a fin, registrar cada llamada a herramienta con entradas y salidas, y medir el coste por tarea completada.

La checklist

1. ¿Completa tareas de principio a fin en sistemas reales, o solo habla de ellas?
2. ¿Está cada acción en una de las tres listas, con umbrales que piden aprobación humana?
3. ¿Hay un harness de evaluación que corre en cada cambio, con fallos reales dentro?
4. ¿Puedes trazar cualquier ejecución y explicar por qué el agente hizo lo que hizo?
5. ¿Conoces el coste por tarea resuelta?
6. ¿Conoces tu tasa de resolución, y no solo la de deflection?
7. Cuando el agente se equivoca, ¿escala o falla en silencio?

Siete síes: tienes un agente. Menos: tienes un chatbot, y no pasa nada mientras lo dimensiones y lo midas como tal.

Si quieres saber dónde está tu sistema, habla con nosotros o mira cómo construimos agentes de IA a medida.