Un agente en producción: herramientas, estado y límites

Un agente consulta un pedido y propone cambiar la dirección de entrega. La API deja de responder y el usuario vuelve a pulsar el botón. El equipo necesita saber si el cambio ocurrió, si puede intentarlo otra vez y qué mensaje debe mostrar mientras lo comprueba.

Ese ejemplo hipotético obliga a diseñar algo más que la llamada al modelo. Hace falta un programa que mantenga el estado del trabajo, autorice cada operación y distinga una propuesta de un resultado confirmado. Ese programa es el runtime del agente.

Decide qué parte necesita elegir el modelo

Dibuja primero el proceso que seguiría una persona. Si siempre hay que validar un formulario, consultar una API y mostrar el resultado, programa esa secuencia. El modelo puede resolver una parte concreta, como interpretar una petición escrita libremente.

El bucle de agente aporta valor cuando el siguiente paso depende de lo que se descubre. Ante una incidencia, quizá deba consultar documentación o pedir un dato antes de decidir qué herramienta usar. La distinción de Anthropic entre workflows y agentes separa las rutas fijadas en código de aquellas que el modelo elige durante la ejecución. Es una distinción de arquitectura; el artículo original es de 2024 y sus herramientas han evolucionado.

Empieza por un objetivo que pueda comprobarse. «Proponer una dirección válida y dejarla pendiente de aprobación» delimita un resultado. «Resolver el problema del cliente» deja demasiadas decisiones implícitas.

Diseña herramientas con consecuencias visibles

Cada herramienta debe explicar qué lee o modifica, qué argumentos acepta y cómo comunica el resultado. Separa las consultas de las operaciones que cambian datos. Devolver un texto ambiguo como «listo» dificulta saber qué sucedió después.

Un resultado de escritura debería identificar la operación y distinguir entre confirmación, rechazo y estado pendiente. El runtime necesita interpretar esas diferencias sin pedir al modelo que adivine si un error de red significa que la operación falló.

La identidad del usuario y su tenant deben proceder de la sesión validada por el servidor. Comprueba los permisos sobre el recurso concreto al ejecutar la herramienta. Un argumento generado por el modelo puede señalar un pedido; no acredita que el usuario sea su propietario.

Guarda el estado necesario para continuar

Para el ejemplo del cambio de dirección, una secuencia posible es:

El runtime recibe la petición y valida la identidad y el tenant. Guarda la propuesta y espera la aprobación de esa versión. Con aprobación y permisos vigentes, ejecuta la herramienta. La confirmación del servicio permite marcar la acción como confirmada. Si falta esa confirmación, conserva un resultado desconocido y reconcilia consultando el estado o pidiendo revisión humana. El esquema omite las salidas de rechazo y cancelación, que cada aplicación debe definir.

Son estados ilustrativos. El diseño debe añadir sus propias salidas de cancelación y rechazo. Lo relevante es que una caída del proceso no borre la diferencia entre una acción aún no enviada y otra cuyo resultado se desconoce.

Guarda la versión de la acción propuesta y la aprobación asociada. Si cambian la dirección o el pedido, hay una nueva propuesta que revisar. Después de una espera larga, vuelve a comprobar permisos y condiciones del negocio antes de ejecutar.

Los sistemas de persistencia, como el descrito en la documentación de LangGraph, permiten conservar estado de ejecución. La integración con el servicio externo necesita además resolver qué ocurre si el proceso cae después de enviar la petición y antes de guardar su respuesta.

Define reintentos y salidas de espera

Una consulta puede admitir reintentos limitados. Una escritura exige conocer antes las garantías de la API. Si existe una clave de idempotencia, conserva la misma para los reintentos de una única operación. Cuando el resultado es incierto, consulta el estado por su identificador o deriva la reconciliación a una persona. AWS explica esta distinción entre petición e intención en su guía de API idempotentes.

También necesitas presupuestos de tiempo y llamadas. Al agotarlos, devuelve una salida utilizable: trabajo pendiente, información que falta o revisión necesaria. El usuario debe poder distinguir «estoy esperando una confirmación» de «el cambio está hecho».

Las reglas de parada pueden basarse en señales observables, como repetir una herramienta con los mismos argumentos sin obtener información nueva. La confianza que el modelo se atribuye no sustituye esas comprobaciones.

Prueba los fallos que cambian el resultado

Comprueba la validación de argumentos y los permisos con tests convencionales. Añade pruebas de integración para una API lenta, una respuesta mal formada o un reinicio entre envío y confirmación. Simula también una segunda petición del usuario mientras la primera sigue pendiente.

La evaluación del modelo responde a otra pregunta: si elige la herramienta adecuada y pide la información necesaria. Usa casos habituales y casos que deban acabar sin acción. Un esquema válido limita la forma de la respuesta, pero sus valores aún pueden ser incorrectos, como recuerda la documentación de salidas estructuradas.

Registra los eventos que permiten reconstruir la ejecución: versión del modelo, herramienta solicitada, resultado y transición de estado. Conserva referencias o versiones con los datos sensibles ocultos cuando sea posible. No bases la observabilidad en capturar razonamiento interno del modelo ni vuelques datos completos del cliente en cada log.

Delimita la primera entrega

Una primera entrega puede cubrir una sola operación con sus permisos, estados de error y pruebas de recuperación. La integración de LLM debe incluir ese trabajo de aplicación. La auditoría técnica de IA sirve para revisar un runtime que ya existe.

Describe la herramienta que quieres habilitar y qué podría modificar. Con ese alcance se puede revisar dónde necesita autonomía el modelo y qué debe quedar bajo control del software o de una persona.