La diferencia entre un asistente y un agente está en las acciones. El agente puede consultar, escribir, reservar o derivar. Eso lo hace útil y también más difícil de controlar.
Qué es una herramienta
Una herramienta es una función que el modelo puede llamar. Puede consultar el estado de un pedido, buscar un hueco en el calendario, crear una reserva, enviar un correo o abrir una incidencia. El modelo no ejecuta el código: decide qué función llamar y con qué argumentos, y tu sistema la ejecuta.
Una herramienta con un nombre confuso, demasiados parámetros o errores poco claros hace que el modelo falle. Una herramienta pequeña, con un contrato claro y un resultado verificable, hace que el agente sea más fiable.
El bucle del agente
Un agente trabaja en un bucle. Recibe una petición, decide si necesita una herramienta, llama, lee el resultado y decide el siguiente paso. Puede hacer varios turnos antes de responder. Ese bucle es lo que le permite resolver tareas que no caben en una sola llamada.
El bucle también es el riesgo. Si no tiene un límite de pasos, puede dar vueltas. Si no tiene un presupuesto, puede gastar. Si no tiene un criterio de parada, puede seguir actuando cuando ya debería haber derivado. El agente necesita un techo.
Permisos y confirmaciones
No todas las herramientas tienen el mismo riesgo. Leer un pedido no es lo mismo que cancelarlo. Consultar un calendario no es lo mismo que reservar. El sistema debe distinguir entre acciones de lectura, acciones de escritura y acciones irreversibles.
Para las acciones de escritura, conviene una confirmación. Para las irreversibles, una persona. Para las que manejan dinero, un límite y una revisión. El modelo puede proponer, pero no debería tener permiso para hacer cualquier cosa que se le ocurra.
Idempotencia
Un agente puede reintentar una llamada si no recibe respuesta. Si la herramienta no es idempotente, el reintento puede crear dos reservas, dos pedidos o dos correos. Diseña las herramientas para que repetir la misma operación no duplique el efecto, o para que el sistema pueda comprobar si ya se hizo.
Esto es especialmente importante en voz, donde la latencia y los cortes son frecuentes. Una llamada que se corta a mitad puede dejar una acción a medias. El agente tiene que saber en qué estado quedó antes de volver a intentarlo.
Cuándo no usar un agente
Si el proceso es siempre el mismo, un workflow con pasos fijos es más barato y más fácil de probar. Si la tarea es una sola llamada al modelo, no necesitas un agente. Si el riesgo es alto y no hay forma de verificar el resultado, tampoco.
Un agente aporta cuando el camino no está claro y puede comprobar el estado real con herramientas. Cuando el camino está claro, añadir autonomía solo añade variables.
Cómo evaluarlo
No basta con mirar la respuesta final. Evalúa si eligió la herramienta correcta, si pasó los argumentos correctos, si respetó los límites y si el estado final es el esperado. Un agente puede dar una respuesta perfecta y no haber hecho nada en el sistema.
La traza es tu unidad de análisis. Revisa los turnos, las llamadas, los errores y las decisiones. Con suficientes trazas empiezas a ver patrones: herramientas que se confunden, argumentos que se extraen mal, pasos que se repiten. Eso es lo que hay que arreglar.
Un caso concreto: reservar una visita
Un agente de reservas necesita tres herramientas: buscar disponibilidad, crear la cita y enviar la confirmación. La primera es de lectura. Las otras dos escriben en el mundo. El agente puede buscar solo, pero antes de crear la cita tiene que confirmar la fecha con la persona. Si la persona no confirma, no se escribe nada.
La herramienta de creación tiene que ser idempotente. Si la llamada se corta y el agente reintenta, no puede crear dos citas. La confirmación tiene que ser explícita y el resultado tiene que poder comprobarse. Si el agente no sabe si la cita se creó, no debe decir que sí. Debe comprobarlo o derivar.
Sigue leyendo