Cómo usan herramientas los AI agents (function calling explicado)

Un AI agent usa una herramienta mediante function calling: el modelo lee la tarea que tiene delante, la contrasta con las herramientas que se le han dado y produce una solicitud estructurada que indica la herramienta y los valores exactos que debe recibir. Su aplicación, o el propio proveedor de AI en el caso de las herramientas alojadas, ejecuta esa solicitud contra un sistema real y devuelve el resultado, que el modelo lee antes de decidir qué hacer a continuación. El function calling es el mecanismo que convierte a un modelo de lenguaje, que solo escribe texto, en algo capaz de revisar un calendario, actualizar un registro del CRM o emitir un reembolso.

Esto ya no es una función de nicho. Gartner predice que el 40% de las aplicaciones empresariales incluirá AI agents específicos para tareas a fines de 2026, frente a menos del 5% en 2025, y casi todos esos agents dependen del function calling para hacer algo más que generar una respuesta. Si usted construye o compra un agent, entender cómo funcionan realmente las llamadas a herramientas, y dónde fallan, marca la diferencia entre un agent genuinamente útil y uno que luce impresionante en una demo y se desmorona en producción.

De hablar de una tarea a hacerla

Un modelo sin herramientas puede describir lo que debería ocurrir: "Recomiendo reprogramar esto para el jueves y enviar una confirmación". Un modelo con herramientas puede hacer que ocurra. Llama a una herramienta de calendario para consultar la disponibilidad del jueves, llama a una herramienta de mensajería para enviar la confirmación e informa que está hecho. Esa es toda la diferencia entre un chatbot y un agent, que se explica con más profundidad en cómo funcionan los AI agents: la percepción alimenta el razonamiento, el razonamiento elige una herramienta y la herramienta es lo que realmente cambia algo fuera del modelo.

El concepto tiene nombre en la literatura de AI: tool use, a veces llamado function calling según el proveedor. Para la definición en lenguaje sencillo y el enfoque de negocio, qué es el tool use cubre ese terreno. Este artículo va un nivel más a fondo y se centra en lo que importa cuando ya está operando un agent: cómo se construye una llamada a una herramienta, cómo decide el modelo hacer una, qué ocurre cuando algo sale mal y cómo se gestiona un conjunto creciente de herramientas sin que se vuelva un caos.

La anatomía de una llamada a una herramienta

Toda herramienta que un agent puede usar se define básicamente de la misma manera, sin importar el proveedor de AI. Tres piezas componen la definición, y el modelo nunca ve más que lo que usted incluya en esas tres, una estructura documentada de forma consistente en la plataforma de tool use de Anthropic y en todos los demás proveedores principales:

Cuando el modelo decide usar una herramienta, no ejecuta ningún código por sí mismo. Produce un objeto estructurado que nombra la herramienta y completa los parámetros, algo como "llamar a check_order_status con order_id: 48213". Su sistema, o la infraestructura alojada del proveedor en el caso de herramientas como la búsqueda web que se ejecutan del lado del proveedor, ejecuta esa llamada contra el sistema de pedidos real y envía el resultado de vuelta en la misma conversación. El modelo lee el resultado como información nueva y continúa, exactamente como lo describe el ciclo de percibir, razonar, actuar y observar.

La calidad de la descripción y del esquema decide la mayor parte del resultado. Una herramienta llamada update_record sin ninguna descripción del tipo de registro ni de los campos que acepta le da al modelo casi nada con qué trabajar. Una herramienta que el modelo puede usar mal porque un parámetro está tipado de forma laxa, por ejemplo un campo date de texto libre en lugar de un formato estricto, es una herramienta que tarde o temprano se llamará con un valor que nadie esperaba.

Cómo decide el modelo si llamar a una herramienta

En cada turno, el modelo toma una pequeña decisión: ¿esta solicitud necesita una herramienta, o puede responder con lo que ya sabe? Una pregunta sobre su política de reembolsos podría responderse directamente si el texto de la política ya está en el contexto. Una pregunta sobre el pedido de un cliente específico necesita una herramienta, porque el modelo no conoce esos datos y nunca los conocerá a menos que los consulte.

Dos cosas moldean esta decisión. Primero, qué tan bien la descripción de la herramienta se corresponde con la solicitud; una descripción vaga se omite o se aplica mal. Segundo, cómo el system prompt o la configuración del agent orientan el comportamiento. Se puede indicar a un agent que siempre consulte una knowledge base antes de responder, que solo use herramientas cuando sea necesario, o que exija una llamada a una herramienta antes de responder en un escenario determinado. Es un ajuste configurable en la mayoría de los frameworks de agents, no un comportamiento fijo, y por eso dos agents construidos sobre el mismo modelo pueden actuar de manera muy distinta según cuán directamente se les indique que recurran a las herramientas.

Este punto de decisión es exactamente la parte de "razonar" del ciclo del agent. Cómo funcionan los AI agents cubre ese ciclo completo con más profundidad; el momento de selección de la herramienta descrito aquí es donde el razonamiento se convierte en acción. Para ver más de cerca lo que ocurre del lado del razonamiento antes de que se llame a una herramienta, consulte cómo razonan los AI agents.

Llamadas únicas, secuenciales, paralelas y condicionales

No todas las tareas necesitan una sola llamada a una herramienta. El trabajo real de un agent suele tomar una de cuatro formas:

El plan del AI Meeting Scheduler Agent es un ejemplo secuencial claro: consulta de disponibilidad, luego reserva y luego confirmación, cada paso dependiente del anterior. El plan del AI Research Agent combina llamadas paralelas y secuenciales, consultando varias fuentes a la vez y leyendo cada resultado para decidir la siguiente búsqueda. El plan del AI Support Triage Agent es el caso condicional: la clasificación determina si la siguiente llamada es una consulta a la knowledge base, una acción de enrutamiento o una escalada.

Cómo se ven las herramientas en los planes de producción

Las descripciones abstractas llegan hasta cierto punto. Así se ven en realidad los conjuntos de herramientas en trabajos reales.

El AI SDR Agent llama a una herramienta de investigación para obtener datos firmográficos de una cuenta objetivo, a una herramienta de CRM para revisar relaciones existentes y registrar el contacto, y a una herramienta de email para enviar la secuencia. Tres herramientas, tres sistemas distintos, un trabajo coherente.

El AI Invoice AP Agent llama a una herramienta de extracción de documentos para obtener las líneas de una factura, a una herramienta de búsqueda de proveedores para cotejarla con una orden de compra y a una herramienta de ERP para registrar el pago aprobado. Cada llamada aquí tiene consecuencias financieras reales, y por eso hay un paso de aprobación entre la extracción y el registro en lugar de dejar que el agent encadene todo de corrido.

Observe el patrón: las herramientas a las que un agent tiene acceso definen el techo de lo que puede hacer, y nada más. Un agent con una herramienta de CRM de solo lectura puede consultar registros pero no cambiarlos. Un agent con una herramienta con permiso de escritura sí puede. Ese límite es una decisión de diseño, no un accidente, y suele ser lo primero que conviene revisar cuando un agent hace algo que no esperaba.

Cuando las llamadas fallan: errores, reintentos y límites

Las llamadas a herramientas fallan más a menudo de lo que sugieren las demos. Los modos de falla más comunes:

• Parámetros incorrectos o faltantes. El modelo adivina un valor que no se le dio, sobre todo ante solicitudes ambiguas. Un agent bien construido hace una pregunta aclaratoria en lugar de adivinar en cualquier asunto de consecuencias.
• Errores de permisos. La herramienta existe, pero las credenciales del agent no permiten esa acción específica, una salvaguarda que debe mantenerse en lugar de "arreglarse" ampliando el acceso.
• La herramienta no existe o el modelo la recordó mal. Es más común con conjuntos de herramientas grandes y mal organizados que con uno pequeño y bien acotado.
• Tiempos de espera y caídas. El sistema de destino está lento o caído, y el agent necesita una alternativa definida en lugar de quedarse colgado o adivinar un resultado.

La escala cambia este problema. La guía de function calling de OpenAI recomienda mantener pequeño el número de herramientas disponibles en un solo turno, por lo general menos de 20, porque la precisión cae a medida que el modelo debe distinguir entre más y más opciones de aspecto similar. Para los agents que de verdad necesitan una biblioteca grande de herramientas, la solución no es meter todas en cada prompt. Es cargar solo el subconjunto relevante para la tarea en curso, de modo que el modelo elija de una lista corta y pertinente en lugar de una abrumadora.

El paso de observar es lo que detecta la mayor parte de esto. Un agent bien diseñado verifica si una llamada a una herramienta realmente tuvo éxito antes de darla por hecha, reintenta ante una falla transitoria y realiza una transferencia a una persona en lugar de adivinar cuando una falla se repite. Un agent que dispara una llamada a una herramienta y asume que funcionó es la causa raíz más común de "la AI dijo que envió el email, pero no lo envió".

El function calling y el problema de la estandarización

Durante un tiempo, cada integración de herramientas fue un trabajo a medida: un conector propio para su CRM, otro para su calendario, otro para su mesa de soporte, y cada uno fallaba de una manera distinta cuando cambiaba la API de base o cuando se cambiaba de proveedor de AI. Model Context Protocol aborda esto estandarizando cómo un modelo descubre y llama a las herramientas, de modo que una herramienta construida una vez pueda funcionar con distintos proveedores de AI en lugar de reconstruirse para cada uno.

El estándar ha crecido rápido. Anthropic, que originalmente desarrolló MCP, informó de más de 10.000 servidores MCP públicos activos a diciembre de 2025, frente a unos pocos cientos en el lanzamiento un año antes, y el protocolo ahora se sitúa bajo la mayoría de las principales plataformas agentic en lugar de a su lado. Si está conectando un agent a un conjunto creciente de herramientas de negocio sin reconstruir la capa de integración cada vez que cambia de modelo, qué es Model Context Protocol es la referencia más profunda, incluidas las consideraciones de seguridad que conlleva conectar un conjunto más amplio de servidores.

Guardrails: lo que una herramienta nunca debería poder hacer libremente

No toda llamada a una herramienta merece la misma confianza. Una consulta de solo lectura y una acción que emite reembolsos tienen un riesgo muy distinto si el agent se equivoca, y tratarlas igual es como un pequeño error de razonamiento se convierte en un daño financiero o a clientes real.

El patrón que funciona: acote cada herramienta al permiso más estrecho que aún cumpla su función, exija un paso de aprobación humana para las herramientas financieras, irreversibles o de cara al cliente a gran escala, y registre cada llamada para que una acción equivocada sea rastreable después en lugar de un misterio. Es la misma disciplina que se cubre en guardrails para AI agents, y es lo que separa a un agent que se puede dejar funcionando con seguridad de uno que técnicamente funciona hasta el día en que deja de hacerlo. El patrón Autonomous Agent profundiza en por qué los ciclos de llamadas a herramientas son la parte de mayor riesgo en cualquier diseño de agent, ya que cada llamada es una oportunidad de cambiar un estado real.

Datos clave

• El function calling funciona con tres partes: un nombre de herramienta, una descripción en lenguaje sencillo y un esquema de parámetros. El modelo nunca ejecuta código por sí mismo; produce una solicitud estructurada que su sistema ejecuta.
• El modelo decide si llamar a una herramienta contrastando la solicitud con las descripciones de las herramientas y siguiendo las instrucciones que recibió sobre cuándo recurrir a una herramienta y cuándo responder directamente.
• Las llamadas a herramientas adoptan cuatro formas: única, secuencial, paralela y condicional, a menudo combinadas dentro de una misma ejecución de un agent.
• La precisión cae a medida que crece el número de herramientas disponibles. OpenAI recomienda mantener la lista de herramientas activas por debajo de aproximadamente 20 y cargar herramientas adicionales bajo demanda en el caso de bibliotecas más grandes.
• Model Context Protocol estandariza la integración de herramientas entre proveedores de AI, y el ecosistema ha superado los 10.000 servidores públicos activos.

A dónde ir a continuación

El tool use es lo que le da manos a un agent. Combínelo con el lado de razonamiento del ciclo en cómo razonan los AI agents para ver cómo decide un modelo a qué herramienta recurrir y cuándo detenerse, y consulte cómo funcionan los AI agents para ver el ciclo completo en el que encajan estas llamadas a herramientas. Si está comparando plataformas para construir, el resumen de herramientas de automatización y la guía de las mejores herramientas de automatización no-code muestran dónde aparece la capacidad de llamar a herramientas en los productos que se pueden comprar hoy.