Cómo un agente usa herramientas (Bases)

Trabaja solo con texto.
En esta página
  1. Entonces, ¿cómo interactúa un agente con el mundo real?
  2. Qué es realmente una herramienta
  3. Cómo sabe el modelo qué herramientas existen
  4. Cómo el agente elige una herramienta
  5. Qué pasa después de llamar una herramienta
  6. En código se ve así
  7. Analogía de la vida real
  8. En resumen
  9. FAQ
  10. Qué sigue

Cuando decimos que un agente puede "usar una herramienta", suena como si pulsara un botón o ejecutara un programa.

Pero por dentro funciona distinto. El agente no puede abrir un archivo, enviar un correo ni llamar una API por sí solo.

Trabaja solo con texto.

Entonces, ¿cómo interactúa un agente con el mundo real?

¿Cómo puede un modelo de texto:

  • Obtener datos de una base de datos
  • Enviar una solicitud a un servidor
  • Escribir un resultado en un archivo

La respuesta es tool calling.

El modelo no ejecuta acciones por sí mismo. Le pide al sistema que las ejecute.

Decide cuándo se necesita una herramienta.
Y el sistema alrededor la ejecuta.

Qué es realmente una herramienta

Agente de IA: pide ejecutar una acción

Una herramienta es una acción cuya ejecución el agente puede solicitar.

Puede ser:

  • Obtener datos desde una API
  • Buscar información en una base de datos
  • Leer un archivo
  • Enviar un mensaje
  • Escribir un resultado

Para el modelo, esto se ve como otra opción de respuesta.

En lugar de escribir texto, puede decir:

"Para avanzar, necesito que se ejecute esta acción."

Y especificar:

  • Qué herramienta usar
  • Con qué parámetros

Por ejemplo:

JSON
{
  "tool": "get_user_data",
  "parameters": {
    "user_id": 123
  }
}

En este punto, el modelo no ejecuta la acción por sí mismo. Solo propone ejecutarla.

Diagram

Si el sistema permite la acción, ejecuta la herramienta y devuelve el resultado (Datos, Estado o Error) al modelo.

Después de eso, el agente decide qué hacer a continuación.

Cómo sabe el modelo qué herramientas existen

El modelo no busca herramientas por su cuenta.

Se le informa de antemano qué acciones están disponibles.

Antes de empezar, el sistema le entrega al modelo una lista de herramientas que puede usar.

Cada herramienta tiene:

  • Nombre - cómo se llama
  • Descripción - qué hace
  • Parámetros - qué datos necesita

Por ejemplo:

JSON
{
  "name": "get_user_data",
  "description": "Obtiene información del usuario por ID",
  "parameters": {
    "user_id": "number"
  }
}

Para el modelo, esto se ve como un conjunto de acciones posibles que puede elegir en el momento adecuado.

No inventa herramientas nuevas.
Elige entre las que tiene permitidas.

Por eso un agente no puede llamar cualquier API.
Solo las que se le dieron.

Cómo el agente elige una herramienta

En cualquier momento, el agente puede tener varias opciones de acción.

Puede:

  • Escribir una respuesta
  • Usar una herramienta
  • O terminar la tarea

Para elegir, mira:

  • El objetivo actual
  • Los datos disponibles
  • El resultado de pasos anteriores

Y se hace una pregunta simple:

"¿Qué me ayuda a avanzar hacia el resultado ahora mismo?"


Si la respuesta no alcanza, quizá conviene llamar una herramienta y obtener datos nuevos.

Si los datos ya son suficientes, puede continuar sin ella.

Si la tarea está resuelta, puede terminar.


Esto no es un guion rígido.
Es una elección que el agente hace en cada ciclo.

Por eso puede usar distintas herramientas según la situación, no en un orden fijo predefinido.

Qué pasa después de llamar una herramienta

Cuando el agente elige una herramienta y pide ejecutarla, el sistema alrededor toma el control.

Este sistema:

  • Revisa si esa herramienta está permitida
  • Ejecuta la acción
  • Obtiene el resultado

Puede ser:

  • Datos de una API
  • Contenido de un archivo
  • Estado de ejecución
  • O un error

Después, el resultado vuelve al modelo en forma de texto.

Para el agente, eso es información nueva que puede usar.

El agente analiza el resultado:

  • ¿Obtuvo los datos necesarios?
  • ¿Quedó más cerca del objetivo?
  • ¿Necesita dar otro paso?

Y con base en eso decide:

  • Usar otra herramienta
  • Continuar sin herramienta
  • O terminar la tarea

Así cada llamada de herramienta se vuelve parte del ciclo de acciones.

En código se ve así

Imagina que el agente quiere obtener datos de usuario. No puede llamar una función por sí solo. Solo puede pedirle al sistema que lo haga, en forma de una solicitud de texto:

PYTHON
# El modelo decide:
# "Para avanzar, necesito datos del usuario"

model_output = {
    "tool": "get_user_data",
    "parameters": {
        "user_id": 123
    }
}

El modelo no ejecuta nada. Solo dice: "Por favor, ejecuta esta herramienta."

Ahora esta solicitud la recibe el sistema alrededor del agente:

PYTHON
def get_user_data(user_id: int):
    return {"id": user_id, "name": "Anna"}


TOOLS = {
    "get_user_data": get_user_data
}

El sistema verifica:

  • si existe esa herramienta
  • si está permitido usarla

Y solo después ejecuta:

PYTHON
tool_name = model_output["tool"]
params = model_output["parameters"]

result = TOOLS[tool_name](**params)

Después de eso, el resultado vuelve al modelo como texto:

PYTHON
tool_result = f"User data: {result}"

Y ahora el agente puede decidir:

  • usar esos datos
  • llamar otra herramienta
  • o terminar la tarea

En este ejemplo, creamos model_output manualmente. En un agente real, lo genera el propio modelo de lenguaje. Analiza la tarea, decide que hace falta una herramienta y forma la misma solicitud automáticamente.

Ejemplo completo de implementación con LLM conectada

PYPython
TSTypeScript · pronto

Analogía de la vida real

Imagina que estás preparando la cena.

Tienes:

  • una nevera
  • una cocina
  • un cuchillo
  • un microondas

Esas son todas las herramientas que puedes usar.

No puedes:

  • usar un horno si no existe
  • ni tomar una licuadora si no está en la cocina

Ahora quieres preparar sopa.

Piensas:

¿Qué me ayuda justo ahora?

Puedes:

  • abrir la nevera
  • encender la cocina
  • o tomar un cuchillo

Eliges una herramienta, la usas y ves qué cambió.

Luego eliges la siguiente.

Y así, hasta que el plato esté listo.


Lo mismo pasa con el agente.

Recibe una lista de herramientas disponibles.
No puede inventar nuevas, solo elegir entre las existentes.

En cada paso decide:

qué herramienta ayuda a avanzar hacia el resultado

La usa y sigue adelante.

En resumen

Tool calling es la forma en que un agente interactúa con el mundo real.

El modelo no ejecuta acciones por sí solo. Le pide al sistema que las ejecute en su nombre.

El sistema le pasa la lista de herramientas disponibles. El modelo elige la adecuada en el momento correcto. El sistema revisa permisos, ejecuta la acción y devuelve el resultado.

Y con base en eso, el agente decide qué hacer después.

FAQ

Q: ¿El agente ejecuta acciones por su cuenta?
A: No. El modelo no ejecuta acciones por sí mismo; solo le pide al sistema que ejecute una herramienta en su nombre.

Q: ¿Qué es tool calling?
A: Es una forma en que el modelo puede pedir una acción, por ejemplo obtener datos o escribir un resultado, para avanzar hacia el objetivo.

Q: ¿Cómo sabe el agente qué herramientas puede usar?
A: Antes de empezar, el sistema le entrega al modelo una lista de herramientas disponibles entre las que puede elegir en cada paso.

Qué sigue

Ahora entiendes las bases de tool calling.

Pero en el trabajo real aparecen preguntas más difíciles:

¿Cómo controlar qué herramientas puede usar el agente?
¿Qué hacer si una herramienta es cara y otra es riesgosa?
¿Cómo darle acceso a datos al agente pero prohibirle borrar?

Esto ya no son bases.
Esta es la realidad de producción.

⏱️ 7 min de lecturaActualizado Mar, 2026Dificultad: ★☆☆
Continuación práctica

Ejemplos de implementación del patrón

Continúa con la implementación usando proyectos de ejemplo.

Integrado: control en producciónOnceOnly
Guardrails para agentes con tool-calling
Lleva este patrón a producción con gobernanza:
  • Presupuestos (pasos / topes de gasto)
  • Permisos de herramientas (allowlist / blocklist)
  • Kill switch y parada por incidente
  • Idempotencia y dedupe
  • Audit logs y trazabilidad
Mención integrada: OnceOnly es una capa de control para sistemas de agentes en producción.
Autor

Esta documentación está curada y mantenida por ingenieros que despliegan agentes de IA en producción.

El contenido es asistido por IA, con responsabilidad editorial humana sobre la exactitud, la claridad y la relevancia en producción.

Los patrones y las recomendaciones se basan en post-mortems, modos de fallo e incidentes operativos en sistemas desplegados, incluido durante el desarrollo y la operación de infraestructura de gobernanza para agentes en OnceOnly.