Tool Use

Incorporar capacidades externas

Tool Use es el patrón de incorporar capacidades externas a un sistema AI para observar, recuperar información, calcular, actuar o integrarse con otros sistemas. Una herramienta amplía lo que la aplicación puede hacer más allá de generar una respuesta a partir de la entrada actual. El patrón abarca selección, condiciones de ejecución, interpretación del resultado y continuidad del proceso.

Una aplicación puede consultar una fuente, ejecutar un cálculo y utilizar el resultado en una respuesta. También puede modificar un recurso si dispone de autoridad y mecanismos adecuados. Esas posibilidades tienen consecuencias diferentes: acceder a una capacidad no significa que cualquier uso sea pertinente o esté autorizado.

Las herramientas pueden exponer filesystem, shell, navegador, computer use, bases de datos, APIs, búsqueda, inteligencia de código, calculadoras o servicios especializados. Son clases de capacidades, no nuevos tipos de agente. Una operación pequeña puede ser suficiente; un catálogo extenso agrega dificultades de selección y mantenimiento sin garantizar mejores resultados.

Tool Use y Tool Calling

Tool Calling describe el mecanismo estructurado mediante el cual un modelo o runtime solicita una invocación y recibe su resultado. Tool Use describe el patrón más amplio de incorporar capacidades a la aplicación. La solicitud estructurada es una forma de implementarlo, no su definición completa.

Un workflow puede ejecutar una consulta en una etapa predefinida y suministrar el resultado al modelo, sin permitirle elegir una herramienta. Otra implementación puede dejar que seleccione nombre y argumentos. Ambas pueden utilizar capacidades externas, aunque el control y la interfaz de invocación sean diferentes.

El trabajo Toolformer, de 2023, estudia una forma de aprender cuándo invocar APIs y cómo incorporar sus resultados. Es un ejemplo académico del espacio de soluciones, no un requisito del patrón. No se necesita entrenar un modelo para cada herramienta ni adoptar ese método para implementar Tool Use.

Structured Generation puede ayudar a producir argumentos interpretables. La conformidad estructural no demuestra selección correcta, existencia del recurso o autorización. Generar una solicitud válida y ejecutar una acción adecuada siguen siendo responsabilidades diferentes.

Herramientas sin autonomía obligatoria

Tool Use no implica que exista un Agent autónomo. Un programa puede consultar un dato una sola vez, efectuar una inferencia y terminar. Un workflow fijo puede decidir qué operación corresponde a cada fase. Ninguno necesita delegar al modelo el control de toda la secuencia.

Un agente puede utilizar herramientas dentro de un ciclo de observación y decisión. En ese caso también importa cuándo detenerse, qué resultados justifican continuar y qué límites conserva la ejecución. La diferencia entre Workflows and Agents no se decide contando llamadas ni observando si existe un cliente de API.

La capacidad expuesta puede envolver un procedimiento complejo o incluso otro agente. Desde quien la invoca sigue siendo una interfaz de capacidad; la relación interna de delegación necesita su análisis propio. Convertir cualquier función accesible en una nueva identidad de agente confunde interfaz, control y responsabilidad.

Tools, Skills y protocolos

Una tool ofrece una capacidad operativa: consultar, calcular, escribir o ejecutar. Agent Skills ofrece conocimiento procedural reutilizable, instrucciones y recursos para realizar un trabajo. Una skill puede explicar qué herramientas utilizar y bajo qué condiciones, pero no se vuelve la herramienta por describir su uso.

La distinción importa al integrar sistemas. Cargar instrucciones sobre un servicio no crea acceso a él; descubrir una operación no aporta automáticamente el procedimiento correcto para utilizarla. La aplicación puede necesitar ambas cosas y debe conservar cuál provee conducta orientativa y cuál produce observaciones o efectos.

Model Context Protocol es un protocolo de interoperabilidad que puede exponer herramientas y otras capacidades, como recursos y prompts. La herramienta es la capacidad; MCP organiza una forma de descubrirla e interactuar. Tool Use no requiere MCP, y adoptar MCP no implica autonomía ni una política de autorización suficiente.

Una API propia, un adaptador local o una función controlada por el workflow pueden servir a la misma responsabilidad conceptual. La elección del transporte no define el objetivo de la tarea ni convierte el resultado en evidencia confiable por sí sola. El patrón debe sobrevivir al reemplazo de una integración concreta.

Tool Capabilities

Una capacidad describe qué puede hacer la herramienta: leer, escribir, buscar, ejecutar, consultar, navegar, enviar o modificar. Su descripción necesita ser suficientemente precisa para distinguir operaciones parecidas y entender sus consecuencias. Una interfaz que agrupa lectura y modificación bajo un nombre ambiguo dificulta una selección informada.

También importan alcance y condiciones: recurso sobre el que opera, entradas admitidas, límites de resultado y estado relevante. Una búsqueda puede limitarse a un repositorio; una consulta puede devolver solo registros visibles para cierta identidad. Esos límites influyen en qué conclusiones se pueden obtener de la respuesta.

Describir mejor una capacidad no reemplaza su implementación ni su mediación. Un texto que dice «solo lectura» no impide una escritura si el ejecutor la permite. El sistema necesita contrastar las expectativas con el comportamiento efectivo de la herramienta y conservar las restricciones pertinentes en el punto de ejecución.

Capacidad y autorización

Una herramienta disponible no es una herramienta autorizada para cualquier encargo. Una operación descubierta puede quedar fuera del permiso actual; una llamada con argumentos válidos puede requerir una aprobación que todavía no existe. La autorización depende de identidad, recurso, acción y alcance concedido.

Agent Permissions and Approval Boundaries mantiene ese contrato. Tool Use debe respetarlo, sin convertir cada lectura rutinaria en una aprobación nueva ni deducir permiso universal de la presencia de una herramienta. Lo relevante es la autoridad vigente para la acción concreta.

Agent Sandboxing puede restringir recursos y consecuencias técnicas. No decide por sí solo si una modificación es correcta para el objetivo. Tampoco una autorización conceptual garantiza que el entorno permita ejecutarla. La aplicación necesita distinguir acción permitida, acción técnicamente posible y acción efectivamente realizada.

Un resultado recuperado no puede ampliar por su cuenta la autoridad del sistema. Si una fuente incluye instrucciones para realizar otra operación, sigue siendo información que debe interpretarse bajo el contrato vigente. El análisis detallado de amenazas queda fuera de este patrón; la frontera básica entre evidencia y autorización permanece necesaria.

Execution Feedback

La ejecución produce feedback: resultados, errores, exit status, respuestas parciales, timeouts, confirmaciones de estado o evidencia de una modificación. El sistema debe interpretarlo, no tratar el envío de una solicitud como finalización del trabajo. Invocación, aceptación, ejecución y confirmación pueden ser momentos distintos.

Un error puede aportar evidencia útil, como falta de permisos o un argumento inválido. Un exit code favorable puede describir una operación que no resolvió la pregunta del usuario. La continuidad debería depender del significado del resultado y de la tarea, no únicamente de una señal genérica de éxito.

Un resultado parcial necesita conservar esa condición. Si una consulta devuelve una página de resultados, no es correcto concluir que contiene todo el conjunto sin conocer paginación y límites. Si una herramienta no observó un recurso por falta de acceso, una respuesta vacía no demuestra inexistencia.

También debe conservarse la correspondencia entre solicitud y respuesta. Al ejecutar varias operaciones, mezclar el resultado de una con los argumentos de otra puede producir una conclusión aparentemente coherente sobre evidencia equivocada. La concurrencia no elimina esa obligación y tampoco convierte múltiples herramientas en múltiples agentes.

Tool output como evidencia

Una salida puede ser obsoleta, parcial, incorrecta, mal interpretada, limitada por permisos o dependiente del entorno. Que provenga de una herramienta no la convierte en verdad automática. Importa qué observó, con qué alcance y si responde a la pregunta actual.

La procedencia ayuda a evaluar esas condiciones. Una cifra calculada correctamente sobre una entrada equivocada conserva el error de origen. Una búsqueda puede identificar candidatos sin demostrar que uno sea la fuente autoritativa. El sistema debe distinguir resultado recibido, interpretación y conclusión sostenida por evidencia.

Context Management decide qué feedback incorporar, cómo actualizar supuestos y qué información ya quedó obsoleta. Agregar cada salida al historial sin revisar contradicciones puede producir una acumulación de estados incompatibles. La herramienta aporta material; la administración del contexto determina cómo participa en la siguiente inferencia.

Generated Code Verification desarrolla el uso de evidencia en cambios de software. Tool Use conserva el patrón general y no lo reduce a «ejecutar tests»: otras aplicaciones requieren otras verificaciones. Un resultado favorable necesita relacionarse con requisitos concretos y con lo que realmente se comprobó.

Lecturas, cálculos y efectos

Conviene distinguir capacidades de lectura, cálculos puros y operaciones que cambian estado. Las primeras pueden observar información; las últimas pueden alterar archivos, datos, publicaciones, mensajes o servicios. Incluso una lectura puede consumir recursos o dejar registros operativos, por lo que la distinción no debe interpretarse como ausencia absoluta de consecuencias.

Las operaciones con efectos exigen especial cuidado ante resultados ambiguos. Un timeout puede significar que no se recibió la confirmación, mientras la operación remota continúa o ya terminó. Dejar de esperar no demuestra cancelación remota. Repetir puede duplicar una acción cuya primera ejecución fue exitosa.

Retry y Idempotency conservan los conceptos generales para razonar sobre repetición. Tool Use no crea una excepción a ellos porque la solicitud provenga de un modelo. Reintentar una consulta y volver a enviar un mensaje tienen perfiles distintos; la recuperación necesita reconocer esa diferencia.

Una devolución «aceptado» puede indicar que comenzó un proceso, sin demostrar que su efecto final ocurrió. El sistema debe seguir el contrato de confirmación pertinente. Si ese estado no puede comprobarse, la respuesta debería comunicar la incertidumbre en lugar de declarar éxito o fracaso definitivo sin evidencia.

Fallos y recuperación

Selección incorrecta, argumentos inadecuados, estado obsoleto, resultados truncados y repeticiones sin progreso requieren respuestas distintas. Cambiar de herramienta puede ayudar si la capacidad no corresponde; corregir argumentos requiere conocer el contrato; repetir indefinidamente no resuelve permisos ausentes ni un objetivo ambiguo.

Un límite de llamadas o tiempo puede impedir un ciclo interminable, pero no decide qué respuesta entregar al agotarlo. Puede ser necesario devolver un resultado parcial, pedir información o detener una acción. Coding-Agent Failure Modes and Recovery desarrolla casos de desarrollo sin ser reemplazado por este tratamiento general.

La recuperación también debe considerar efectos ya producidos. Corregir una solicitud futura no revierte una escritura previa. Si el estado quedó parcialmente modificado, la continuación necesita observarlo y razonar sobre él. Un mensaje del modelo que afirma haber corregido la operación no constituye evidencia de reparación.

Recuperación de información y composición

Tool Use invoca capacidades; RAG recupera evidencia para apoyar generación. Una recuperación puede exponerse como herramienta y una herramienta puede consultar información estática o actual. La frontera no es «datos estáticos frente a datos vivos», sino la responsabilidad que cumple cada mecanismo. RAG se materializará en XIII.

Una aplicación puede combinar herramientas con Human in the Loop para resolver excepciones o autorizar acciones. También puede utilizar Model Routing sin que cada modelo tenga acceso al mismo conjunto de capacidades. La composición debe preservar los contratos de cada frontera; no existe una pila obligatoria de todos los patrones.

Ejemplo y trade-offs

Una aplicación ayuda a preparar un cambio de dirección de entrega. Consulta el pedido y presenta la dirección propuesta en una estructura interpretable. Antes de modificar necesita conocer el recurso correcto, el estado actual y la autorización aplicable. La consulta exitosa no concede permiso para cambiar ni garantiza que el pedido siga modificable.

Si la escritura devuelve estado desconocido, la aplicación debe evitar repetir a ciegas. Puede consultar el estado si el contrato lo permite y conservar la relación con la operación anterior. Si necesita intervención humana, debe transferir la incertidumbre y las evidencias, no presentar una operación ambigua como «lista para aprobar de nuevo».

Exponer pocas capacidades claras reduce ambigüedad y mantenimiento. Exponer demasiadas puede aumentar selección errónea, entradas innecesarias y dificultad para interpretar resultados. Limitar excesivamente también puede obligar a decisiones sin evidencia. El diseño más simple suficiente depende de qué observaciones y acciones necesita realmente la aplicación.

Fuentes y alcance

Referencia primaria consultada el 2026-10-30: Schick et al., Toolformer, 2023. Se utiliza como ejemplo de investigación sobre incorporación de herramientas, no como arquitectura obligatoria. Las fronteras entre capacidad, invocación, evidencia y autoridad son síntesis del Atlas apoyada en sus canónicos existentes. No se fijan protocolos de proveedor, implementaciones de seguridad ni una taxonomía nueva de agentes.