Agentes de IA: planificación, herramientas y memoria

Cuando pides a un chatbot que «compare el precio de este producto en las tres tiendas online más grandes», o te da información antigua que recuerda de sus datos de entrenamiento, o te dice que no puede hacerlo. Da la misma petición a un agente de IA y dividirá el trabajo en pasos: buscará las tiendas, abrirá cada página de producto, extraerá el precio, probará otra vía donde no lo encuentre y, al final, construirá una tabla. Detrás de ambos sistemas puede haber el mismo tipo de modelo de lenguaje; la diferencia viene del bucle, las herramientas y la memoria que se construyen alrededor del modelo.

En este artículo explicamos qué es un agente de IA y en qué se diferencia de un chatbot, el bucle percibir-planificar-actuar-evaluar que un agente repite en cada paso y cómo funcionan la planificación, el uso de herramientas (function calling) y la memoria. Después vemos cómo llegan los agentes a la web, por qué se equivocan y cómo decidir si un trabajo necesita un agente o un flujo de trabajo predefinido.

¿Qué es un agente de IA y en qué se diferencia de un chatbot?#

Un chatbot produce una respuesta por mensaje. Puede recordar el historial de la conversación, pero no inicia una acción por su cuenta ni comprueba el resultado de un trabajo para dar un nuevo paso. Tú preguntas y él responde.

Un agente de IA trabaja hacia un objetivo y decide por sí mismo qué pasos dar para alcanzarlo. El artículo Building effective agents de Anthropic traza la línea así: los sistemas que conectan un modelo de lenguaje y herramientas mediante rutas de código definidas de antemano son flujos de trabajo (workflows); los sistemas en los que el modelo dirige dinámicamente su propio proceso y el uso de herramientas son agentes.

¿Cómo funciona el bucle del agente?#

El modelo más fiel del funcionamiento de un agente es la repetición de un único bucle. El bucle continúa hasta alcanzar el objetivo o cumplir una condición de parada.

1. Percibir. El agente reúne la situación actual: el objetivo del usuario, el historial de la conversación, los resultados de los pasos anteriores y la información recuperada de la memoria. Todo ello entra en la ventana de contexto del modelo.
2. Planificar. Mirando ese contexto, el modelo elige la siguiente acción. A veces es un solo paso como «primero debería buscar» y a veces un plan de varios pasos.
3. Actuar. El modelo produce una llamada a herramienta: escribe en un formato estructurado qué herramienta quiere ejecutar y con qué parámetros. La aplicación ejecuta realmente la llamada.
4. Evaluar. El resultado de la herramienta vuelve al modelo. El modelo comprueba si el resultado le acerca al objetivo: ¿llegaron los datos esperados, se produjo un error, conviene cambiar el plan?
5. Repetir o terminar. Si se alcanzó el objetivo, el modelo produce la respuesta final. Si no, el bucle vuelve al paso uno. Condiciones de parada como un número máximo de pasos, un límite de presupuesto o la aprobación del usuario evitan que el bucle funcione indefinidamente.

Una de las expresiones más citadas de este bucle es el artículo ReAct, publicado en 2022. El artículo muestra que hacer que el modelo alterne entre «reasoning» (texto de razonamiento) y «acting» (llamadas a herramientas) da mejores resultados que los enfoques que se basan solo en razonar o solo en actuar. La mayoría de los frameworks de agentes actuales usan alguna variante de esta idea.

El esqueleto siguiente muestra el bucle con independencia del proveedor. La función call_model se sustituye por la API del modelo que uses:

MAX_STEPS = 10

def run_agent(goal, tools, call_model):
    messages = [{"role": "user", "content": goal}]
    for step in range(MAX_STEPS):
        reply = call_model(messages, tools)          # planificar
        messages.append(reply.as_message())
        if not reply.tool_calls:                      # no pidió herramientas: trabajo terminado
            return reply.text
        for call in reply.tool_calls:                 # actuar
            try:
                result = tools[call.name](**call.arguments)
            except Exception as exc:                  # devolver el error al modelo
                result = f"Error de herramienta: {exc}"
            messages.append({"role": "tool", "tool_call_id": call.id, "content": str(result)})
        # la evaluación ocurre en la siguiente llamada a call_model
    return "Se alcanzó el límite de pasos, no se pudo completar el trabajo."

En el código se ven dos detalles críticos del bucle: los errores de las herramientas no hacen caer el programa, sino que se devuelven al modelo para que pruebe otra vía, y siempre hay una condición de parada como MAX_STEPS.

¿Cómo se hace la planificación?#

Planificar es que el agente divida un objetivo grande en pasos ejecutables. Enfoques habituales:

• Paso a paso (estilo ReAct): el modelo elige solo la siguiente acción en cada vuelta del bucle. Es flexible, porque el resultado de cada paso influye en el siguiente. En trabajos largos corre el riesgo de perderse.
• Planificar primero y ejecutar después: el modelo produce un plan completo al principio y luego ejecuta los pasos en orden. Es eficiente cuando el trabajo es previsible; cuando aparece un resultado inesperado, hay que rehacer el plan.
• Descomposición en tareas: un agente principal divide el trabajo en subtareas y entrega cada una a un subagente o a una llamada al modelo aparte. Se usa en trabajos de investigación en paralelo.
• Autoevaluación (reflection): el modelo critica en un paso aparte el resultado que ha producido y lo corrige si hace falta. La calidad sube, pero cada evaluación supone costo y latencia adicionales.

Qué enfoque elegir depende de la estructura del trabajo. Para un trabajo cuyos pasos se conocen en gran parte de antemano encaja mejor planificar al principio; para una investigación en la que el resultado de cada paso determina el siguiente, el enfoque paso a paso.

¿Cómo funciona el uso de herramientas (function calling)?#

Un modelo de lenguaje no puede por sí solo abrir una página web, consultar una base de datos ni escribir un archivo. Para que pueda hacerlo, la aplicación le da definiciones de herramientas. Cuando el modelo quiere usar una herramienta, en lugar de texto plano produce una llamada estructurada que sigue el esquema de esa herramienta. La documentación de function calling de OpenAI y la documentación equivalente de otros proveedores describen este flujo con la misma lógica.

Una definición de herramienta tiene tres partes: un nombre, una descripción que permite al modelo entender para qué sirve la herramienta y una definición de los parámetros en JSON Schema. Por ejemplo, una herramienta que obtiene el precio de una página de producto podría definirse así:

{
  "name": "get_product_price",
  "description": "Abre la URL de la página de producto indicada y devuelve el precio y la moneda que muestra la página. Úsala solo con URL de dominios permitidos.",
  "input_schema": {
    "type": "object",
    "properties": {
      "url": {
        "type": "string",
        "description": "La dirección completa de la página de producto, empezando por https://"
      },
      "country": {
        "type": "string",
        "enum": ["TR", "DE", "US"],
        "description": "Desde qué país debe verse el precio"
      }
    },
    "required": ["url"]
  }
}

El nombre del campo del esquema de parámetros varía según el proveedor; algunas API usan input_schema y otras parameters. La lógica es la misma.

El flujo de una llamada a herramienta:

1. La aplicación envía al modelo la petición del usuario y las definiciones de herramientas.
2. Si el modelo decide que necesita la herramienta, devuelve una llamada con el nombre get_product_price y argumentos como {"url": "https://...", "country": "TR"}.
3. La aplicación recibe la llamada, valida los argumentos y ejecuta la herramienta en su propio código.
4. El resultado de la herramienta ({"price": "...", "currency": "TRY"} o un mensaje de error) se devuelve al modelo.
5. El modelo usa el resultado para llamar a otra herramienta o para responder al usuario.

Lo más importante aquí es el paso tres: quien ejecuta la herramienta es siempre la aplicación. El modelo solo pide que se ejecute. Por eso la autorización, la validación y los controles de seguridad son responsabilidad del código que ejecuta la herramienta, no del modelo. Y por eso las descripciones de las herramientas deben ser claras: el modelo usa bien una herramienta solo en la medida en que la entiende por su descripción.

Explicamos MCP, el protocolo para compartir herramientas entre distintas aplicaciones de forma estándar, en Qué es MCP (Model Context Protocol).

Memoria: a corto y a largo plazo#

Los modelos de lenguaje no recuerdan nada por sí mismos de una llamada a la siguiente. La «memoria» de un agente es simplemente lo que la aplicación le da al modelo en cada llamada.

La memoria a corto plazo es la ventana de contexto: el objetivo del usuario, el historial de la conversación, las llamadas a herramientas y sus resultados. A medida que el bucle se alarga, esta ventana se llena. Cuando se acerca el límite de la ventana de contexto, la aplicación suele elegir una de estas vías:

• Resumir los pasos antiguos y descartar los detalles.
• Acortar las salidas grandes de las herramientas (como una página HTML entera) o conservar solo la parte necesaria.
• Conservar solo el resultado de las subtareas completadas.

La memoria a largo plazo se guarda fuera de la ventana de contexto, en una base de datos, un archivo o un almacén vectorial. El agente recupera información de ese almacén con una herramienta cuando la necesita. Así se guardan las preferencias del usuario, lo aprendido en tareas anteriores y las colecciones grandes de documentos.

¿Cómo llega un agente a la web?#

La mayoría de los agentes que necesitan información actual llegan a la web de una de estas tres formas:

• API de búsqueda. El agente envía una consulta y recibe una lista de títulos, direcciones y fragmentos breves. Es rápida y barata, pero solo ve fragmentos.
• Cliente HTTP. El agente obtiene una dirección concreta y recibe el HTML o el texto de la página. Funciona bien en páginas estáticas y vuelve vacío en páginas cuyo contenido carga con JavaScript.
• Navegador. El agente controla un navegador real: abre páginas, hace clic, rellena formularios, toma capturas de pantalla. Es la vía más capaz, pero también la más lenta y cara.

Detrás de estas herramientas hay, en la parte de red, peticiones HTTP normales, y aquí también se aplican todas las reglas del web scraping: límites de velocidad, robots.txt, condiciones del sitio, gestión de sesiones. Como un agente puede abrir decenas de páginas en segundos, estas reglas importan todavía más en los agentes.

En este esquema, un proxy se sitúa en la capa de red y se usa para tres cosas:

• Ubicación: que el agente vea por separado el precio de un producto en Türkiye y en Alemania.
• Control de salida: limitar y registrar desde un solo punto qué dominios alcanza el agente y a qué velocidad.
• Aislamiento: mantener el tráfico del agente separado de las direcciones IP principales de la empresa.

Cómo diseñar esta capa, junto con medidas contra la inyección de prompts, se explica en Acceso web seguro para LLM: límites y permisos. Cómo tratan los sitios el tráfico de agentes y por qué se bloquean los agentes se trata en ¿Por qué los sitios bloquean a los agentes de compra con IA?. Para un ejemplo de cómo puede usarse un modelo de lenguaje para extraer datos estructurados de páginas web, consulta Web scraping con GPT-6 Astra.

¿Por qué se equivocan los agentes?#

Los fallos de los sistemas de agentes son distintos de los errores de una sola llamada al modelo, porque los errores se acumulan a lo largo de los pasos.

• Acumulación de errores. Aunque cada paso tenga una probabilidad de error pequeña, esas probabilidades se multiplican en un trabajo de diez pasos. Abrir la página equivocada al principio hace que todos los pasos siguientes se basen en datos erróneos.
• Argumentos de herramienta incorrectos. El modelo puede producir un parámetro que no existe, una dirección mal formada o un identificador inventado. Sin validación en el lado de la herramienta, el error sigue adelante en silencio.
• Quedarse atascado en bucles. Llamar una y otra vez a la misma herramienta que falla con los mismos argumentos. Sin límite de pasos ni detección de repeticiones, el costo crece sin control.
• Un contexto lleno. Las salidas grandes de las herramientas llenan la ventana de contexto y el modelo empieza a pasar por alto las instrucciones del principio de la tarea.
• Un objetivo ambiguo. Un objetivo con criterios sin definir, como «encuentra el producto más adecuado», deja al agente sin saber cuándo parar.
• Contenido no fiable. Las páginas web, los documentos y los correos pueden contener texto que parece una instrucción para el modelo. Si el agente confunde ese texto con la petición del usuario, puede realizar acciones inesperadas. Este riesgo se llama inyección indirecta de prompts.
• Mensajes de error perdidos. Si el error de una herramienta no se devuelve con claridad al modelo, el modelo puede suponer que el trabajo terminó bien.

La mayoría de estos fallos vienen del diseño del sistema, no del modelo, y se reducen con diseño: validar los argumentos de las herramientas, fijar límites de pasos y de presupuesto, acortar las salidas de las herramientas, pedir aprobación humana antes de las acciones críticas y tratar el contenido web como datos y no como instrucciones.

¿Flujo de trabajo o agente?#

Los agentes son impresionantes, pero no son la herramienta adecuada para todos los trabajos. La recomendación del artículo de Anthropic es empezar por la estructura más sencilla que resuelva el trabajo y añadir complejidad solo cuando aporte un beneficio medible. En la práctica, eso significa:

• Para un trabajo cuyos pasos se conocen de antemano y se hacen siempre en el mismo orden (obtener cada día los precios de las mismas 50 páginas y escribirlos en una tabla), un flujo de trabajo definido en código es más barato, más rápido y más previsible. Dentro de ese flujo puede usarse un modelo de lenguaje solo en un paso concreto, por ejemplo para extraer datos de un texto irregular.
• Para un trabajo cuyos pasos cambian según la situación y en el que no se sabe de antemano qué fuentes mirar (reunir información sobre un mercado nuevo a partir de fuentes dispersas), tiene sentido un agente.

La diferencia de costo y fiabilidad entre un pipeline de scraping clásico y un enfoque basado en agentes también debe valorarse dentro de este marco. La extracción con selectores da el mismo resultado en cada página; un agente puede adaptarse cuando cambia la estructura de la página, pero supone el costo de una llamada al modelo por cada página.

Casos de uso#

• Investigación de mercado y de la competencia: el agente reúne información de productos, precios y campañas de distintas fuentes y señala las incoherencias. La configuración de investigación está en nuestra página de solución de investigación de mercado.
• Gestión de excepciones en un pipeline de recogida de datos: un pipeline de scraping clásico se ocupa de la mayoría de las páginas; las páginas en las que fallan los selectores se entregan a un agente. La configuración general de recogida de datos está en nuestra página de solución de extracción de datos.
• Asistente de conocimiento interno: el agente busca en los documentos internos, recupera las secciones relevantes y responde citando las fuentes.
• Desarrollo de software: el agente busca en el código, lee archivos, propone cambios y ejecuta pruebas.
• Clasificación en atención al cliente: el agente clasifica la solicitud, consulta el estado del pedido y solo pasa a una persona cuando hace falta.

Errores comunes#

• Construir un agente para un trabajo que resolvería un flujo de trabajo sencillo. El costo, la latencia y la imprevisibilidad suben sin motivo.
• No fijar una condición de parada. Un agente sin límite de pasos, límite de presupuesto ni timeout puede generar un costo sin control.
• Escribir descripciones de herramientas cortas y vagas. El modelo llama a la herramienta en la situación equivocada o con argumentos incorrectos.
• No validar los argumentos de las herramientas. Todo valor que produce el modelo debe tratarse como entrada no fiable.
• Tratar el contenido web como instrucciones. El texto de una página no debe tener la misma autoridad que la petición del usuario.
• Dejar las acciones críticas sin aprobación. Las acciones irreversibles como pagos, envío de correos o borrado de datos deben requerir aprobación humana.
• Suspender las reglas del sitio para el agente. Cada página que abre un agente está sujeta a los mismos límites de velocidad y condiciones que una página que abre un scraper. Para el marco legal, consulta ¿Es legal el web scraping?.

Guía de decisión#

Preguntas frecuentes#

¿Cuál es la diferencia clave entre un agente de IA y un chatbot?#

Un chatbot produce una respuesta por mensaje y no inicia acciones por su cuenta. Un agente de IA planifica varios pasos para alcanzar un objetivo, llama a herramientas, evalúa los resultados y mantiene el bucle en marcha hasta alcanzar el objetivo.

¿El agente ejecuta las herramientas por sí mismo?#

No. El modelo solo escribe, en un formato estructurado, qué herramienta quiere ejecutar y con qué argumentos. Quien ejecuta la herramienta, devuelve el resultado al modelo y realiza los controles de seguridad es siempre la aplicación que hace funcionar el agente.

¿Dónde se guarda la memoria de un agente?#

La información de la tarea actual se guarda en la ventana de contexto del modelo, es decir, en el historial de mensajes que se envía al modelo en cada llamada. La información que debe persistir entre tareas se guarda en una base de datos o un archivo gestionado por la aplicación y se recupera con una herramienta cuando hace falta.

¿Qué reglas debe seguir un agente al recoger datos de sitios web?#

Las mismas que un scraper: robots.txt, condiciones del sitio, límites de velocidad y leyes de datos personales. Ser un sistema de IA no cambia esas reglas; como puede trabajar rápido, es aún más importante aplicar los límites a nivel de sistema.

¿Por qué los agentes pueden dar resultados distintos para el mismo trabajo?#

Los modelos de lenguaje pueden no producir exactamente la misma salida en cada llamada, y la vía que elige el agente en cada paso influye en la siguiente. Además, como las fuentes externas como la web cambian, la misma consulta puede llegar a datos distintos. Para trabajos en los que importa la repetibilidad, encaja mejor el enfoque de flujo de trabajo.

¿Cómo sé si un trabajo es adecuado para un agente?#

Si puedes dibujar de antemano los pasos del trabajo como un diagrama de flujo, probablemente basta con un flujo de trabajo. Si los pasos solo pueden decidirse a medida que llegan los resultados intermedios, y el beneficio de esa flexibilidad compensa el costo adicional, tiene sentido un agente.

En resumen#

Un agente de IA es un sistema en el que un modelo de lenguaje recorre un bucle percibir-planificar-actuar-evaluar hasta alcanzar un objetivo. La planificación divide el trabajo en pasos, el uso de herramientas permite al modelo actuar en el mundo exterior y la memoria se gestiona con la ventana de contexto y almacenes externos. Quien ejecuta las herramientas es siempre la aplicación, así que los permisos, la validación, los límites de velocidad y la aprobación humana forman parte del diseño del sistema. Elige un flujo de trabajo para trabajos cuyos pasos se conocen de antemano y un agente para trabajos abiertos. Para gestionar el acceso web de tus agentes con control de ubicación y de salida, echa un vistazo a nuestros servicios de proxy.