Un modelo que actúa

Un servicio de atención al cliente recibe una pregunta: «¿ha salido ya mi pedido 4417?». Tres implementaciones la responden. La primera envía la pregunta y la ficha del pedido en una única llamada al modelo y devuelve su respuesta: 900 tokens, 400 ms, un resultado idéntico en cada ejecución. La segunda ejecuta una secuencia escrita de antemano —extraer el número, llamar a la API de seguimiento, redactar la respuesta—: tres llamadas, un único camino, una prueba por etapa. La tercera da al modelo cuatro herramientas y le deja decidir: entre 2 y 30 llamadas, una trayectoria distinta en cada ejecución y una factura que nadie en el equipo sabe prever de antemano.

Las tres responden correctamente al caso sencillo. La diferencia solo aparece en los bordes: el pedido no existe, la API de seguimiento devuelve un 503, el cliente menciona dos pedidos en la misma frase. Ahí, la llamada única inventa, la cadena fija se rompe en la etapa prevista y se detiene, y el agente prueba otra cosa. Esa capacidad de probar otra cosa es lo único que se compra al pasar a un agente, y sale cara: en tokens, en latencia, en superficie de ataque y en horas de depuración. Toda esta lección sirve para decidir si la necesita, porque la respuesta honesta es que no con más frecuencia de la que se suele admitir.