Un agente de IA es más que un modelo de lenguaje al que se le da más autonomía. Es un sistema donde el modelo actúa como cerebro que coordina tres capacidades que individualmente son simples pero juntas producen comportamiento complejo: el acceso a herramientas externas, la capacidad de mantener contexto a través de múltiples pasos, y el razonamiento encadenado para descomponer problemas.
Herramientas: los brazos del agente
Un modelo de lenguaje por sí solo solo puede procesar texto y producir texto. Las herramientas son lo que le dan capacidad de actuar en el mundo.
Técnicamente, una herramienta es una función que el modelo puede invocar. El modelo decide cuándo usarla, con qué argumentos, y recibe el resultado para incorporarlo a su razonamiento. La implementación varía entre frameworks, pero el patrón es siempre el mismo: el modelo produce texto estructurado indicando qué herramienta usar y con qué parámetros, el sistema ejecuta esa herramienta, y devuelve el resultado al modelo.
Categorías de herramientas:
Herramientas de información:
- Búsqueda web (Google, Bing, búsquedas especializadas)
- Consulta a bases de datos
- Lectura de archivos y documentos
- Acceso a APIs de datos (clima, finanzas, noticias)
Herramientas de cómputo:
- Ejecución de código Python/JavaScript
- Calculadoras y procesamiento matemático
- Procesamiento de imágenes
- Análisis estadístico
Herramientas de acción:
- Envío de emails o mensajes
- Creación o modificación de archivos
- Interacción con interfaces web (browser automation)
- Llamadas a APIs de terceros (CRM, calendarios, Slack)
El diseño del conjunto de herramientas es una de las decisiones de arquitectura más importantes al construir un agente. Más herramientas no es necesariamente mejor: cada herramienta adicional aumenta la complejidad del razonamiento del agente y el riesgo de que elija la herramienta equivocada.
Cómo el modelo usa herramientas
El mecanismo de “tool calling” o “function calling” es la interfaz estándar entre el modelo y las herramientas. El proceso es el siguiente:
- El desarrollador define las herramientas disponibles con un esquema que describe qué hace cada una y qué parámetros acepta.
- Esa descripción se incluye en el prompt del sistema.
- Cuando el modelo decide que necesita una herramienta, genera una respuesta estructurada (generalmente JSON) indicando qué herramienta invocar y con qué argumentos.
- El sistema intercepta esa respuesta, ejecuta la herramienta, y devuelve el resultado al modelo como si fuera parte de la conversación.
- El modelo continúa con el resultado disponible.
Ejemplo simplificado de un ciclo con herramientas:
Modelo: "Necesito buscar el precio actual de Apple."
→ tool_call: {"name": "web_search", "query": "AAPL stock price today"}
Sistema: Ejecuta la búsqueda → resultado: "AAPL: $189.45 (15:30 EST)"
Modelo: "El precio actual de Apple es $189.45.
Ahora comparo con el precio de hace un mes..."
→ tool_call: {"name": "web_search", "query": "AAPL stock price May 2026"}
La clave es que el modelo elige cuándo y cómo usar cada herramienta basándose en el objetivo y el contexto. No es un script predefinido: es razonamiento en cada paso.
Memoria: los tres tipos
Los agentes necesitan memoria para funcionar bien en tareas que se extienden más allá de un único intercambio. Hay tres tipos que funcionan de formas muy distintas:
Memoria de trabajo (in-context). Es simplemente la ventana de contexto del modelo: todo lo que ha pasado en la sesión actual —el objetivo, las acciones tomadas, los resultados obtenidos, las reflexiones del modelo. Es la más inmediata y potente, pero está limitada por el tamaño de la ventana.
Memoria episódica (scratchpad). Para tareas largas que pueden superar la ventana de contexto, el agente puede escribir en un “bloc de notas” —un archivo o variable externa— resúmenes de lo que ha hecho y aprendido, y consultarlo cuando necesita contexto anterior.
Memoria a largo plazo. Información que persiste entre sesiones distintas. Se implementa con bases de datos vectoriales (RAG) o bases de datos tradicionales. El agente puede recordar que el usuario prefiere cierto formato de informes, o que una API específica tiene un límite de llamadas por minuto.
La orquestación de estos tres tipos de memoria es uno de los problemas técnicos más complejos en el diseño de agentes. Demasiada información en el contexto lo llena y degrada el rendimiento. Demasiado poco y el agente pierde el hilo.
Razonamiento encadenado
El razonamiento encadenado (chain-of-thought) que vimos como técnica de prompting toma una dimensión diferente en el contexto de los agentes: el modelo escribe sus pasos de razonamiento explícitamente como parte de su proceso de trabajo.
Frameworks como ReAct (Reasoning and Acting) estructuran este proceso:
Pensamiento: ¿Qué necesito hacer? El usuario quiere saber si
su empresa debería invertir en publicidad en TikTok.
Primero debería entender a qué audiencia se dirigen.
Acción: buscar_web("demografía usuarios TikTok España 2025")
Observación: [resultados de la búsqueda]
Pensamiento: El 60% de usuarios tienen entre 18-34 años.
¿Cuál es el público objetivo del usuario?
Necesito más información.
Acción: preguntar_usuario("¿Cuál es el grupo de edad de vuestros clientes objetivo?")
Observación: "25-45 años, profesionales de nivel medio-alto"
Pensamiento: La audiencia del cliente tiene cierto solapamiento
con TikTok pero no es el core. Voy a buscar
datos de coste y conversión para ese segmento.
...
Este razonamiento explícito tiene dos ventajas: produce mejores decisiones (el modelo no salta directamente a conclusiones) y hace el proceso auditable (se puede revisar por qué el agente tomó cada decisión).
El problema de la confiabilidad
Los agentes son más potentes que los chatbots, pero también más frágiles. Los problemas de confiabilidad son el mayor obstáculo para su adopción a escala.
Errores que se propagan. Si el agente comete un error en el paso 3 de un proceso de 10 pasos, los pasos 4 a 10 se construyen sobre esa base incorrecta. El error se amplifica.
Bucles infinitos. Un agente puede quedarse atascado en un ciclo de razonamiento donde cada acción lleva a una situación que requiere una acción similar, sin progreso real.
Elección incorrecta de herramienta. El agente puede usar una herramienta apropiada para el problema incorrecto, o usar la herramienta correcta con los parámetros equivocados.
Interpretación ambigua del objetivo. Un objetivo mal definido puede llevara el agente a completar algo diferente de lo que el usuario quería, de forma que el resultado final parece correcto superficialmente.
Las soluciones a estos problemas incluyen: objetivos bien definidos, herramientas bien documentadas, puntos de control humano en pasos críticos, límites de pasos para evitar bucles, y supervisión del proceso en tiempo real. En el próximo capítulo, veremos cómo aplicar esto en casos reales.