Nombrar el resultado antes que la tecnología
Un equipo quiere transformar las solicitudes recibidas en respuestas útiles. Antes de elegir un agente, debería definir qué significa útil: una respuesta completa, una fuente identificable, información ausente señalada y un siguiente paso claro. Es un ejemplo hipotético, no el resultado de un proyecto. Si la tarea no puede describirse y evaluarse, llamarla agente no la hará más clara. Quizá solo oculte la falta de entendimiento detrás de una interfaz convincente.
Cuando el recorrido es conocido
Anthropic distingue los flujos predefinidos de los agentes que eligen dinámicamente sus pasos y herramientas. En nuestro ejemplo, clasificar la solicitud, consultar una fuente designada y redactar una propuesta pueden formar un flujo fácil de seguir. Una persona puede revisar la propuesta antes de enviarla. La pregunta práctica es si alguna situación importante queda fuera de esa secuencia, no si el flujo parece suficientemente avanzado.
Cuando hay que descubrir el siguiente paso
Supongamos que las solicitudes son muy diferentes y la información necesaria solo se vuelve evidente después de una primera comprobación. Un agente podría elegir qué fuente consultar después o qué pregunta devolver al usuario. Su valor propuesto es adaptar el recorrido. Para evaluarlo, el equipo debería observar cuándo las decisiones dinámicas producen una respuesta mejor que la ruta fija y cuándo añaden rodeos innecesarios.
Hacer que los límites formen parte del producto
Microsoft recomienda el nivel de complejidad que satisface los requisitos, teniendo en cuenta el coste y el tiempo. En un experimento, esto se convierte en preguntas concretas: cuántas comprobaciones son aceptables, qué puede consultar el sistema y cuándo debe pedir ayuda. Preparar una respuesta y tener permiso para enviarla son cosas distintas. Registrar el motivo de la parada y la información ausente hace comprensible el comportamiento para quien utiliza el producto, además del equipo técnico.
Comparar las opciones con la misma tarea
Una evaluación útil podría presentar los mismos ejemplos a una llamada simple al modelo, un flujo y un agente. Criterios propuestos: respuesta correcta y completa, información inventada, intervenciones humanas, coste y tiempo hasta el resultado. Conviene incluir solicitudes ambiguas o imposibles de resolver con los datos disponibles. Sin esta comparación, añadir pasos puede parecer progreso simplemente porque son visibles. Merece la pena ampliar la arquitectura cuando una mejora observada justifica el esfuerzo de operación y mantenimiento. Repetir la comparación después de los cambios también muestra si una nueva versión conserva la ventaja que el equipo observó inicialmente.