Tool Calling
Tool Calling es un patrón de interacción en el que un modelo o sistema agente solicita utilizar una capacidad externa mediante una invocación identificable y argumentos estructurados, recibe un resultado y decide cómo continuar. La definición de trabajo del Atlas separa la solicitud de su ejecución efectiva: producir una llamada no significa que una herramienta haya actuado, que la operación esté autorizada ni que el objetivo se haya cumplido.
La interacción puede aparecer dentro de un loop agente, un workflow predefinido o una única solicitud a un modelo. No requiere autonomía sostenida ni varios agentes. El runtime puede ejecutar, rechazar, transformar o pedir aclaraciones sobre una solicitud según sus contratos y políticas. Esas responsabilidades no desaparecen porque el modelo produzca una estructura sintácticamente válida.
Solicitud, ejecución y continuación
Una interacción típica identifica una capacidad disponible, construye argumentos, somete la solicitud a los controles pertinentes y entrega una observación al sistema que continúa. Los pasos pueden distribuirse entre componentes o estar integrados. El patrón no prescribe un transporte, un SDK ni una representación universal de mensajes.
La herramienta puede consultar información, computar o modificar un recurso. Su resultado puede ser dato, confirmación, error o estado parcial. El agente necesita interpretar qué ocurrió realmente. Que una API acepte una solicitud puede significar que programó trabajo, no que terminó; que un cliente agote su tiempo de espera no demuestra que la operación remota no se ejecutó.
Agent Harness media disponibilidad, despacho y resultados; Agent Execution Environment determina los recursos efectivos. El modelo puede participar seleccionando el próximo paso, pero no adquiere acceso a esos recursos solo por nombrarlos. La ejecución depende de una capacidad implementada y de una identidad con condiciones concretas.
Tool Calling y Tool Use
Tool Use es el patrón de aplicación más amplio de incorporar capacidades externas al comportamiento de un sistema AI. Tool Calling describe una forma de solicitar una invocación estructurada y recibir su resultado. Un runtime puede incorporar herramientas mediante código predefinido, workflows u otros mecanismos sin delegar la selección de cada operación al modelo.
Por ejemplo, una aplicación puede recuperar datos antes de llamar al modelo siguiendo reglas convencionales. Esa capacidad externa participa en el comportamiento de la aplicación, pero no implica que el modelo haya emitido una llamada. Un agente puede, en cambio, elegir una consulta a partir de una observación y continuar con el dato obtenido. La diferencia está en la interacción y el control concreto, no en que ambos usen una API.
Tool Calling tampoco transforma automáticamente un workflow en agente. Una etapa puede permitir una llamada entre pasos programados. Workflows vs Agents conserva la discusión sobre quién controla la continuación; este documento conserva el mecanismo de invocación sin absorber el tratamiento general de Tool Use.
Terminología de Function Calling
Function calling puede ser el nombre que una API o producto da a invocaciones estructuradas de funciones o herramientas. Su alcance, tipos de argumentos, restricciones y manejo de resultados dependen de la implementación. El Atlas utiliza Tool Calling como término canónico para esta interacción y no crea otro concepto durable por una diferencia de nombre comercial.
No toda función interna es una herramienta para el modelo. Una función puede existir en el código y no estar expuesta en el catálogo, no estar disponible bajo la identidad actual o requerir otra frontera de ejecución. Del mismo modo, una herramienta puede envolver varias funciones, un servicio remoto o trabajo más complejo que una llamada local.
La investigación Toolformer, de 2023, estudia aprender qué APIs utilizar, cuándo hacerlo y con qué argumentos. Es un ejemplo académico de integración de herramientas, no un contrato universal de mensajes ni evidencia de que todos los agentes aprendan o ejecuten herramientas mediante ese método.
Tool Registry y catálogo
Un registry o catálogo hace identificables definiciones de herramientas y capacidades. Puede incluir nombre, descripción, schema de entrada, expectativas de salida y una identidad de capacidad. El detalle depende del sistema. El catálogo permite expresar qué operaciones se ofrecen, pero no determina por sí mismo cuáles conviene utilizar para la tarea.
La calidad de las descripciones afecta selección e interpretación. Dos nombres parecidos pueden ocultar diferencias de alcance, efectos o consistencia. Una descripción que omite que una operación escribe datos facilita decisiones equivocadas. Aun así, una descripción informativa no es una frontera de seguridad: los límites efectivos necesitan aplicarse en la ejecución pertinente.
También importa distinguir identidad y presentación. Un nombre visible puede cambiar o colisionar con otra herramienta de otro proveedor. El runtime necesita mantener suficiente correspondencia entre definición seleccionada, implementación y resultado. El patrón no impone un esquema de IDs único, pero sí hace visible el problema de atribuir una respuesta a la capacidad correcta.
Discovery
Discovery responde qué herramientas o capacidades están disponibles bajo las condiciones actuales. Puede partir de una lista estática, configuración, consulta de runtime o negociación mediante un protocolo. No es sinónimo de registry: el catálogo representa definiciones; discovery permite conocer las que se ofrecen en un momento o alcance determinado.
Una capacidad descubierta puede no estar autorizada para la siguiente acción. Puede requerir otra identidad, un recurso permitido o aprobación adicional. También puede dejar de estar disponible entre descubrimiento e invocación. El agente debe manejar esas condiciones sin asumir que conocer el nombre equivale a disponer de autoridad permanente para utilizarlo.
Una búsqueda vacía tampoco prueba que la capacidad no exista en todo el sistema. Quizá está fuera del alcance consultado o no se expone a esa sesión. La respuesta razonable depende del encargo: una alternativa permitida, una comprobación focalizada o informar la limitación. No corresponde inventar el nombre de una herramienta ni ampliar acceso automáticamente.
Schemas y significado
Un schema describe forma y restricciones estructurales de entradas o salidas. Puede ayudar a detectar campos ausentes, tipos incompatibles o valores fuera de un conjunto admitido. No establece por sí solo que una acción sea apropiada, segura o semánticamente correcta. Un identificador bien formado puede señalar el recurso equivocado.
Si el agente solicita publicar un documento, el schema puede exigir título y contenido sin resolver si corresponde hacerlo, si el destino es el correcto o si el texto está aprobado. La validez estructural facilita interpretar la solicitud; la autorización y el juicio sobre el resultado pertenecen a otras responsabilidades. Generar una estructura correcta no demuestra cumplimiento del objetivo.
La misma cautela aplica a salidas. Un objeto que cumple un schema puede contener datos incompletos, obsoletos o una respuesta de otro recurso. El consumidor necesita interpretar el contrato de la herramienta, incluyendo estados parciales y errores. Structured Generation tiene un alcance general propio; mencionarlo no introduce otro canonical ni convierte su formato en garantía de verdad.
Disponibilidad y autorización
Agent Permissions and Approval Boundaries distingue capacidad técnica de autoridad. Una herramienta visible puede admitir operaciones que el agente no debe realizar en el encargo actual. Un argumento válido no constituye aprobación. Tampoco una instrucción recuperada desde una salida de herramienta puede ampliar por sí sola los permisos vigentes.
La mediación puede aplicar límites por identidad, recurso, operación o entorno. Algunas acciones ya estarán autorizadas; otras necesitarán detenerse en una frontera explícita. El patrón no obliga a pedir confirmación para cada lectura ni permite asumir que una autorización local cubre cualquier efecto externo. La interpretación debe seguir el alcance real concedido.
Agent Sandboxing restringe recursos y consecuencias técnicas. Complementa la autorización sin sustituirla. Un sandbox puede bloquear una llamada que el modelo intentó emitir; ese bloqueo es evidencia sobre la ejecución, no sobre la corrección de la intención. El sistema necesita comunicar el resultado sin transformar un rechazo en una operación completada.
Relación con MCP
Model Context Protocol aporta interoperabilidad para descubrir y utilizar herramientas y otras capacidades entre aplicaciones y servidores. Tool Calling conserva la interacción general de solicitar una operación. Puede implementarse sin MCP, y una integración MCP puede incluir capacidades distintas de herramientas o acciones seleccionadas mediante control predefinido.
El protocolo puede transportar una solicitud y describir capacidades; no decide por definición qué objetivo debe perseguir el agente ni si conviene repetir una operación. Un servidor tampoco se vuelve una skill por exponer una herramienta. Agent Skills describe procedimientos reutilizables que pueden utilizarla y Agent Extension Packages puede distribuir configuración o recursos relacionados.
Esas relaciones permiten composición sin una pila obligatoria. Adoptar MCP no implica adoptar autonomía, memoria persistente o coordinación multiagente. El concepto de Tool Calling conserva su utilidad aunque cambien transportes, schemas o productos que lo implementan.
Resultados y evidencia
El resultado debe relacionarse con la solicitud que lo produjo y con la revisión o estado pertinente. Una lectura correcta de otro archivo puede llevar a una decisión coherente sobre evidencia equivocada. Un resultado truncado necesita conservar esa condición; presentarlo como completo impide que el agente reconozca lo que todavía no sabe.
Una herramienta puede terminar con error y aportar información útil, como falta de permisos o una entrada inválida. Puede terminar con éxito y no responder la pregunta del encargo. Generated Code Verification utiliza evidencia apropiada para juzgar cambios; un exit code favorable de una herramienta no reemplaza ese juicio.
Agent Tracing puede conservar solicitud, argumentos pertinentes, resultado y relación con la continuación. Esa evidencia no necesita incluir secretos ni razonamiento privado. Permite investigar si el sistema recibió un dato y cómo siguió, sin convertir automáticamente el recorrido registrado en una evaluación favorable.
Una solicitud con varias invocaciones requiere conservar la correspondencia de cada resultado. Algunas pueden terminar y otras quedar pendientes o fallar. La respuesta agregada no debería ocultar esas diferencias ni permitir que el dato de una operación se interprete como confirmación de otra. Ejecutar esas herramientas concurrentemente sigue sin implicar que existan varios agentes tomando decisiones.
La cancelación también tiene alcance concreto. Dejar de esperar una respuesta puede detener trabajo local sin impedir que una operación remota continúe. El sistema necesita distinguir solicitud cancelada, efecto confirmado y estado desconocido. Esa precisión permite elegir una recuperación segura en lugar de presentar la ausencia de respuesta como ausencia de efectos o como autorización para repetirlos.
Fallos, repetición y efectos
Un error de red, una respuesta ambigua o un timeout requieren distinguir qué se sabe sobre la operación. Retry puede ser pertinente ante ciertas fallas transitorias. Idempotency ayuda a razonar sobre repetir efectos. El agente no debería volver a escribir simplemente porque no recibió confirmación de la primera escritura.
También puede haber selección incorrecta, argumentos basados en un supuesto inválido o un loop de llamadas que no agrega evidencia. Coding-Agent Failure Modes and Recovery examina esas situaciones en desarrollo. Cambiar de herramienta, reducir una consulta o detenerse puede ser mejor recuperación que insistir con la misma operación.
El límite de continuación importa tanto como invocar. Después de recibir información suficiente, más llamadas pueden agregar ruido o efectos innecesarios. Detenerse demasiado pronto puede dejar una expectativa sin comprobar. No hay un número universal de herramientas que caracterice un agente competente.
Ejemplo: localizar y actualizar una referencia
El agente necesita corregir un enlace en una documentación. Descubre una capacidad de búsqueda y una de edición. La búsqueda devuelve dos documentos con títulos similares; antes de editar necesita identificar el destino correcto y la revisión que corresponde al encargo. Que la herramienta de escritura esté en el catálogo no resuelve esa ambigüedad.
Con el destino comprobado y la modificación autorizada, puede solicitar la edición y contrastar el resultado real. Si la escritura devuelve una confirmación parcial, todavía no puede afirmar que el sitio publicado cambió. Puede existir otra etapa de publicación y otra autoridad. La interacción de herramientas debe conservar esas fronteras en vez de comprimir todo el trabajo en “la llamada pasó”.
Límites del patrón
Tool Calling organiza una frontera entre solicitud estructurada y capacidad ejecutada. No prescribe que el modelo elija todas las acciones, no garantiza seguridad por schema y no obliga a utilizar un protocolo específico. Puede envolver trabajo sofisticado, incluso otro agente, pero la interfaz de herramienta y la relación de delegación conservan significados distintos.
El criterio de diseño es exponer y mediar las capacidades necesarias para la tarea con resultados interpretables. Agregar catálogos extensos, protocolos o herramientas por anticipado introduce selección y mantenimiento adicionales. La forma más simple suficiente puede ser una sola capacidad claramente delimitada dentro de un workflow convencional.
Fuentes
- Toolformer: Language Models Can Teach Themselves to Use Tools, 2023: ejemplo académico citado. Las definiciones y fronteras del Atlas no adoptan su método como requisito de implementación.