Un agente utiliza una herramienta cuando necesita consultar o modificar un sistema que no forma parte de la generación de texto. La herramienta puede ser una búsqueda, una base de datos, una API o una función de la propia aplicación. El modelo propone un paso; el backend decide si ese paso existe, si está autorizado y si se ejecuta.
Esta separación evita una confusión habitual: un modelo no obtiene acceso mágico a un servidor por recibir instrucciones. Todo acceso real pasa por una interfaz programada con permisos, validaciones y límites concretos.
Modelo, controlador y herramientas
El modelo interpreta el objetivo y puede seleccionar una herramienta disponible. El controlador coordina la conversación, conserva el estado necesario y transforma la propuesta en una llamada que la aplicación pueda revisar. La herramienta es el componente que realiza la operación fuera del modelo.
Una herramienta de consulta puede devolver el estado de un pedido; otra puede crear un ticket; otra puede calcular una fecha. Declarar su finalidad y sus argumentos reduce ambigüedad. Una función que acepta un identificador y una acción libre tiene una superficie de riesgo mayor que otra que solo permite leer un estado.
Cómo aparece una necesidad de acción
La aplicación recibe una petición del usuario y la envía al modelo con el contexto y las herramientas permitidas. Si el modelo determina que necesita información externa, devuelve una propuesta estructurada. Esa propuesta no es todavía el resultado de la operación: es una solicitud que el controlador debe procesar.
Por ejemplo, ante “¿en qué estado está mi pedido?”, el agente puede proponer una consulta. El backend debe comprobar la identidad y limitar el identificador a los pedidos que ese usuario puede ver antes de llamar al sistema de comercio.
Argumentos y validación
Los argumentos generados por un modelo deben validarse en el servidor como cualquier entrada externa. Un esquema puede comprobar tipos, campos obligatorios y formatos, pero no demuestra que el valor sea correcto para ese usuario o ese momento. La aplicación debe validar también relaciones y reglas de negocio.
Si una herramienta espera una fecha, no basta con que la cadena tenga el formato adecuado. Hay que comprobar que la fecha está dentro del periodo permitido y que la operación solicitada es coherente con el estado actual. La validación no debe delegarse en el prompt.
Autorización antes de ejecutar
La identidad del usuario, el rol de la aplicación y el alcance de la herramienta deben evaluarse antes de cada operación relevante. Un agente puede tener acceso de lectura a un catálogo y carecer de permiso para cambiar precios. La lista de herramientas disponible debería variar según el contexto y no incluir capacidades que la tarea no necesita.
Las acciones destructivas o externas requieren más control que una lectura. Borrar un registro, enviar un mensaje o modificar una cuenta puede exigir confirmación, una segunda comprobación o una cola de revisión. El modelo puede preparar la acción sin tener permiso para ejecutarla.
Ejecución y resultado
Una vez validados los argumentos y la autorización, el backend llama al servicio correspondiente. La herramienta devuelve un resultado controlado, que puede contener datos, un estado de error o una indicación de que hace falta intervención. El controlador incorpora ese resultado al estado y puede pedir al modelo que lo explique.
El resultado debe limitarse a la información necesaria. No conviene devolver credenciales, trazas internas o campos privados solo porque el modelo pueda leerlos. El filtrado de salida protege tanto la conversación como los registros posteriores.
Estado, reintentos y operaciones repetibles
Un agente puede necesitar varios pasos: buscar un cliente, consultar una incidencia y redactar una respuesta. El estado debe distinguir lo que el usuario pidió, lo que ya se ejecutó y lo que solo fue propuesto. Sin esa diferencia, un reintento puede duplicar una operación.
Para acciones que cambian datos, una clave de idempotencia o una comprobación del estado previo puede evitar duplicados. Los reintentos tienen sentido ante un fallo temporal, no ante un rechazo de autorización o unos argumentos inválidos. Cada herramienta debe documentar qué errores son recuperables.
Contenido no confiable y límites de seguridad
Un documento recuperado, un correo o una respuesta de una API puede contener texto que intenta influir en el modelo. Ese contenido debe tratarse como datos, no como instrucciones con más autoridad que las reglas de la aplicación. La autorización se decide fuera del modelo.
El principio de mínimo privilegio también se aplica al agente: herramientas separadas, permisos pequeños, límites de tiempo y acceso solo a los datos necesarios. Los registros deben indicar quién inició la petición, qué propuso el modelo, qué validó el backend y qué resultado devolvió la herramienta.
Qué debe controlar la aplicación antes de ejecutar una herramienta
El agente aporta coordinación, no una exención de los controles normales. Antes de publicar una herramienta, define su propósito, entradas, permisos, errores, límites, trazabilidad y forma de deshacer la operación. Para lecturas de bajo riesgo puede bastar una validación automática; para cambios sensibles, la aplicación debe interrumpir el flujo o solicitar aprobación. Esa frontera determina hasta dónde puede llegar el agente con seguridad.
Diseñar herramientas pequeñas
Una herramienta debe exponer una operación acotada y un resultado comprensible. Separar consultar un pedido, añadir una nota y cerrar una incidencia permite asignar permisos y revisar cada efecto por separado. También simplifica las pruebas: se puede verificar qué entradas acepta y qué respuesta devuelve sin tener que evaluar todo el comportamiento del agente a la vez.
Cuando una acción no puede deshacerse, el controlador debe mostrar una vista previa o derivarla a un proceso de aprobación. El agente puede preparar un cambio, pero una política de negocio debe decidir si ese cambio está permitido.