flowchart TD
A[Usuario formula tarea] --> B[Modelo]
B --> C{¿Necesita una tool?}
C -- No --> H[Genera respuesta]
C -- Sí --> D[Selecciona tool y argumentos]
D --> E[Aplicación valida y ejecuta]
E --> F[Resultado / observación]
F --> B
Tool calling
Cómo pasa una aplicación desde reconocer que necesita una capacidad hasta seleccionar una tool, preparar argumentos, ejecutarla, recibir el resultado y continuar el trabajo.
Ya tenemos herramientas.
Supongamos que la aplicación dispone de estas capacidades:
buscar_documentos
obtener_documento
calcular_exposicion
crear_borrador_revision
enviar_alertaY recibe una instrucción sencilla:
“Comprueba cuál es el anexo de seguridad vigente del proveedor ACME.”
Todavía falta explicar el mecanismo central.
¿Cómo pasa el sistema desde lenguaje natural a una operación concreta?
¿Cómo sabe qué herramienta utilizar?
¿Quién completa sus parámetros?
¿Quién ejecuta realmente la función?
¿Y cómo vuelve el resultado al modelo?
Ese ciclo se denomina habitualmente tool calling o, en muchas implementaciones, function calling.
Idea central
En términos simplificados, tool calling es el proceso mediante el cual el modelo puede proponer una llamada estructurada a una herramienta y la aplicación puede ejecutarla, devolver el resultado y continuar la interacción.
El ciclo básico es:
detectar necesidad → elegir herramienta → preparar argumentos → ejecutar → recibir resultado → continuar.
Antes de llamar una tool, la aplicación debe describirla
El modelo no puede seleccionar adecuadamente una capacidad que no conoce.
Por eso una aplicación suele proporcionar una descripción de las herramientas disponibles.
Por ejemplo:
Nombre:
buscar_documentos
Descripción:
Busca contratos y anexos asociados a un proveedor dentro de repositorios autorizados.
Parámetros:
- proveedor: texto
- tipo_documento: texto
Salida:
Lista de documentos encontrados.Esta descripción funciona como un pequeño contrato operacional.
Huyen señala que las herramientas suelen declararse mediante un nombre, parámetros y documentación sobre qué hace la función y qué necesita. Google subraya además que los schemas de entrada y salida ayudan tanto a describir la capacidad como a validar la llamada durante la ejecución.
Describir finalidad, no sólo implementación
Comparemos dos descripciones.
Mala descripción
Llama GET /v3/contracts con payload JSON.Mejor descripción
Busca contratos y anexos asociados al proveedor dentro de los repositorios autorizados.La primera puede ser correcta desde el punto de vista técnico, pero explica poco sobre cuándo utilizar la herramienta.
La segunda comunica finalidad.
Para un modelo que debe seleccionar entre varias capacidades, esa diferencia importa.
1. Detectar la necesidad
La primera etapa consiste en reconocer que la tarea no puede completarse únicamente con el contexto disponible.
El sistema recibe:
“Comprueba cuál es el anexo de seguridad vigente.”
Pero sólo tiene el contrato principal.
Una respuesta posible sería:
No dispongo del anexo.Si la aplicación tiene tools, puede ocurrir algo más.
El modelo puede generar una salida equivalente a:
Necesito buscar documentos asociados al proveedor.Esta etapa es importante porque un error puede ocurrir incluso antes de seleccionar una tool.
El modelo podría no detectar que falta información y simplemente inferir una respuesta.
2. Elegir la herramienta
Supongamos que el inventario disponible es:
buscar_documentos
calcular_exposicion
crear_borrador_revision
enviar_alertaPara resolver la necesidad actual, la opción razonable es:
buscar_documentosA esta colección de capacidades disponibles Huyen la denomina tool inventory.
Cuantas más herramientas ofrecemos, más capacidades tiene el sistema.
Pero también puede aumentar la dificultad de seleccionar correctamente.
Esto conduce a un principio de diseño útil:
más tools no significa automáticamente mejor sistema.
Una herramienta redundante, ambigua o excesivamente parecida a otra puede aumentar errores de selección.
3. Preparar argumentos
Elegir la función correcta no basta.
También debemos completarla.
La tool espera:
buscar_documentos(proveedor, tipo_documento)El sistema puede generar:
buscar_documentos(
proveedor = "ACME",
tipo_documento = "anexo_seguridad"
)Los valores concretos se denominan argumentos.
Aquí aparece otro punto de fallo.
La tool puede existir.
El nombre puede ser correcto.
El formato puede ser válido.
Y aun así el argumento puede ser incorrecto.
Por ejemplo:
proveedor = "ACNE"La estructura no detecta necesariamente que se trata del proveedor equivocado.
Forma válida no equivale a contenido correcto
Esta diferencia conecta directamente con lo aprendido en salidas estructuradas.
Una llamada como:
{
"name": "buscar_documentos",
"arguments": {
"proveedor": "ACNE",
"tipo_documento": "anexo_seguridad"
}
}puede cumplir perfectamente el schema.
Eso sólo demuestra que:
el nombre existe
+
los campos requeridos están presentes
+
los tipos son válidosNo demuestra:
que el proveedor sea correcto
que la operación sea necesaria
que el usuario tenga permiso
que el resultado vaya a ser interpretado bien
Tool call válida ≠ tool call correcta
La validación estructural puede comprobar la forma de la llamada.
La corrección de la tarea exige además evaluar la semántica, el contexto y la autorización.
4. Ejecutar
Este paso es arquitectónicamente decisivo.
El modelo puede producir una estructura que indica:
usa buscar_documentos con estos argumentosPero eso no significa que el modelo haya entrado por sí mismo al DMS.
En una implementación típica, otra parte de la aplicación recibe la solicitud.
Puede entonces:
1. comprobar que la tool está habilitada
2. validar argumentos
3. comprobar autenticación
4. comprobar autorización
5. ejecutar la función real
6. manejar errores
7. registrar la operaciónBerryman y Ziegler muestran este patrón de manera explícita: la aplicación envía al modelo las definiciones de tools, recibe una posible tool call, localiza la función correspondiente, ejecuta sus argumentos y añade la respuesta de la función de vuelta a la conversación.
La frase precisa es entonces:
el modelo genera una solicitud de tool calling; la aplicación controla la ejecución.
La aplicación puede rechazar la llamada
Esto es muy importante.
La existencia de una tool call no obliga al sistema a ejecutarla.
Supongamos:
eliminar_documento(id = "DOC-021")La aplicación puede responder:
OPERACIÓN NO AUTORIZADAO puede solicitar confirmación humana.
Esta separación entre propuesta y ejecución crea un punto de control.
5. Recibir el resultado
Supongamos que la búsqueda se ejecuta correctamente.
La función devuelve:
DOC-011 | Anexo_Seguridad_ACME_2024.pdf | reemplazado
DOC-019 | Anexo_Seguridad_ACME_2026_draft.pdf | borrador
DOC-021 | Anexo_Seguridad_ACME_2026.pdf | firmadoEse resultado vuelve a la aplicación.
Después puede incorporarse al contexto del modelo.
En arquitecturas de agentes suele utilizarse la palabra observación para referirse a información obtenida después de ejecutar una acción.
No necesitamos adoptar obligatoriamente esa terminología aquí.
La idea importante es:
la salida de la tool se convierte en una nueva entrada para la siguiente etapa.
6. Continuar el trabajo
El resultado anterior no resuelve todavía toda la tarea.
Ahora el sistema sabe que existe un documento firmado:
DOC-021Puede necesitar recuperarlo.
Entonces genera otra llamada:
obtener_documento(id = "DOC-021")La aplicación vuelve a ejecutar.
El contenido regresa.
El modelo puede finalmente comparar el anexo con el contrato principal.
Tool calling puede, por tanto, formar un ciclo.
Un ciclo no es todavía un agente
Esta frontera merece cuidado.
Un sistema puede ejecutar una tool call y volver al modelo sin que debamos llamarlo agente en el sentido pedagógico de este curso.
Por ejemplo:
siempre que el usuario pregunte por un documento
→ ejecutar buscador
→ devolver resultadoLa ruta puede estar predeterminada.
O el usuario puede presionar un botón que dispare la tool.
Más adelante estudiaremos agentes como sistemas capaces de seleccionar dinámicamente próximos pasos dentro de ciertos límites.
Por ahora:
TOOL CALLING
≠
AUTONOMÍAErrores en cada etapa
Una de las ventajas de descomponer el ciclo es que podemos reconocer fallos diferentes.
Error de necesidad
El sistema no detecta que falta el anexo.
Error de selección
Utiliza buscar_correos en vez de buscar_documentos.
Error de argumentos
Busca ACNE en vez de ACME.
Error de ejecución
El DMS no responde.
Error de interpretación
La tool devuelve tres archivos y el sistema elige el borrador.
Error de autorización
La llamada técnicamente válida intenta acceder a un matter no autorizado.
Cada fallo necesita un tratamiento diferente.
Los errores también pueden ser información
Google destaca un punto interesante: los mensajes de error pueden diseñarse para ayudar al sistema a corregir el siguiente paso.
Comparemos:
ERROR 404con:
No se encontró un documento con ese ID.
Comprueba si utilizaste el identificador correcto o busca el documento por proveedor y tipo.El segundo mensaje no sólo informa que algo falló.
También proporciona contexto útil para continuar.
Esto convierte el manejo de errores en parte del diseño de la herramienta.
Tool calling y schemas
Las definiciones de tools suelen utilizar schemas estructurados para describir entradas.
Por ejemplo:
{
"name": "buscar_documentos",
"parameters": {
"type": "object",
"properties": {
"proveedor": {"type": "string"},
"tipo_documento": {"type": "string"}
},
"required": ["proveedor", "tipo_documento"]
}
}No necesitamos aprender a programar este objeto.
Sólo debemos reconocer qué expresa:
la función se llama buscar_documentos
espera dos campos
ambos deben ser texto
ambos son obligatoriosEso permite al sistema validar parte de la llamada.
Tool calling y APIs
Todavía queda una pregunta.
La aplicación sabe que debe ejecutar:
buscar_documentos(...)Pero ¿cómo se comunica esa tool con el DMS?
Una forma muy habitual es mediante una API.
La tool puede envolver una operación técnica de otro sistema y presentar al modelo una interfaz más pequeña y comprensible.
Por eso el siguiente paso natural no es estudiar más sobre selección de herramientas, sino comprender cómo se comunican sistemas de software.
Un caso completo
Encargo:
“Verifica si el contrato ACME tiene un anexo de seguridad vigente y dime si está firmado.”
1. Detectar necesidad
El modelo observa que el anexo no está en contexto.
2. Seleccionar tool
buscar_documentos3. Preparar argumentos
proveedor = ACME
tipo_documento = anexo_seguridad4. Ejecutar
La aplicación valida la solicitud y ejecuta la función.
5. Resultado
DOC-021 | firmado6. Continuar
El modelo responde:
Existe un anexo de seguridad identificado como DOC-021 y el sistema documental lo registra como firmado.Observe la diferencia entre esta frase y:
El contrato tiene un anexo de seguridad firmado.La primera hace visible la procedencia del dato.
Eso puede ser valioso en trabajo profesional.
¿Quién decide si la tool es opcional u obligatoria?
Las implementaciones de function calling suelen permitir distintas políticas de uso.
Huyen resume tres patrones frecuentes:
NONE
no utilizar tools
REQUIRED
debe utilizar al menos una
AUTO
el modelo puede decidir si necesita unaLa nomenclatura concreta depende del proveedor, pero la distinción conceptual es útil.
El sistema puede controlar cuánto espacio de decisión entrega al modelo.
Por ejemplo, si una tarea siempre debe verificar el estado del proveedor en una base oficial, la arquitectura puede exigir esa consulta en vez de dejarla como opción.
Si la consulta sólo es necesaria en algunos casos, puede permitirse selección contextual.
Y si una tarea debe ejecutarse sin acceso externo, las tools pueden deshabilitarse.
Esto muestra nuevamente que tool calling no equivale a autonomía plena. La aplicación puede definir un marco muy estrecho dentro del cual ocurre la selección.
Tool calling puede detenerse antes de ejecutar
También podemos insertar una etapa de confirmación.
El modelo produce:
Tool propuesta:
enviar_correo
Destinatario:
proveedor@acme.example
Asunto:
Desviaciones contractualesLa aplicación puede mostrar:
[Autorizar] [Cancelar]Sólo después de la confirmación ejecuta la función.
La arquitectura separa entonces:
SELECCIÓN
el modelo propone
AUTORIZACIÓN
la persona confirma
EJECUCIÓN
el software actúaNo necesitamos desarrollar todavía toda la política de permisos. La enseñanza aquí es que la tool call puede ser un objeto revisable antes de convertirse en acción.
Resultado de tool y texto del modelo son canales diferentes
Otra distinción útil es separar:
TOOL OUTPUT
dato devuelto por la operación
MODEL OUTPUT
interpretación o respuesta generadaSupongamos que la tool devuelve:
status = signedy el modelo afirma:
El anexo está plenamente vigente y no requiere revisión.La segunda frase contiene una inferencia que no estaba necesariamente en el resultado de la tool.
Para trabajos verificables conviene conservar la procedencia:
Dato obtenido:
status = signed
Interpretación:
el documento aparece registrado como firmado
Evaluación:
su vigencia jurídica requiere revisar fecha, partes y posibles sustitucionesEsto evita que una respuesta generada transforme silenciosamente una observación limitada en una conclusión más amplia.
Qué debes recordar
Tool calling no es magia ni acceso directo del modelo al mundo.
Es un ciclo compuesto por etapas:
DETECTAR NECESIDAD
↓
ELEGIR TOOL
↓
PREPARAR ARGUMENTOS
↓
VALIDAR Y EJECUTAR
↓
RECIBIR RESULTADO
↓
CONTINUARCada etapa puede fallar.
Y la aplicación puede introducir controles entre la solicitud y la ejecución.
El problema que todavía queda abierto
Ya sabemos cómo una aplicación puede pasar desde una necesidad expresada en lenguaje a una operación estructurada.
Pero la tool todavía necesita comunicarse con otros sistemas.
¿Cómo pide información a un DMS?
¿Cómo envía datos a un calendario?
¿Cómo consulta un CRM?
Para responder necesitamos una abstracción más antigua que los LLM y mucho más general que la IA: la API.