Introducción a los agentes de IA

01Objetivos de aprendizaje

Al finalizar esta clase, el estudiantado será capaz de:

1. Definir qué es un agente de IA y distinguir los agentes de los sistemas de software convencionales.
2. Trazar la evolución histórica desde los sistemas expertos hasta los agentes modernos basados en LLM.
3. Clasificar agentes según la taxonomía de Russell y Norvig (reflejo simple, basado en modelo, basado en objetivos, basado en utilidad, con aprendizaje).
4. Identificar los cuatro componentes fundamentales de un agente basado en LLM: planificación, memoria, uso de herramientas y acción.
5. Describir al menos tres sistemas de agentes desplegados en el mundo real y explicar sus arquitecturas a alto nivel.
6. Implementar un bucle de agente mínimo en Python qué interactúe con un LLM.

021. Qué es un agente de IA?

1.1 La definición fundamental

Un agente de IA es un sistema que percibe su entorno a través de sensores, razona sobre lo que percibe y ejecuta acciones a través de actuadores para alcanzar objetivos. Esta definición, adaptada de Russell y Norvig (2021), es engañosamente simple pero conlleva implicaciones profundas.

Para comprender por qué esta definición es importante, consideremos lo que excluye. Una calculadora de bolsillo no es un agente: no percibe un entorno ni decide que hacer a continuación. Un filtro de spam es apenas un agente: percibe (correos entrantes) y actúa (clasificándolos), pero sigue reglas rígidas sin noción de objetivos ni autonomía. Un asistente de programación con IA capaz de leer tu código fuente, decidir que archivos necesitan cambios, realizar ediciones, ejecutar pruebas e iterar hasta que las pruebas pasen es claramente un agente: percibe, razona, planifica, actúa y se adapta.

La distinción clave entre un agente y un programa convencional es la autonomía: un agente opera con un grado de independencia, tomando decisiones sin intervención humana directa en cada paso. Un servidor web responde a peticiones con lógica predeterminada. Un agente decide qué hacer a continuación.

De manera más formal, un agente puede describirse como una función:

f: Percept* -> Action

La función del agente asocia una secuencia de percepciones (el historial completo de todo lo que el agente ha percibido) con una acción. El programa del agente es la implementación concreta de esta función ejecutándose sobre una arquitectura física o virtual.

Idea clave: La notación Percept* (con el asterisco) es crucial. Significa que la decisión del agente puede depender de su historial completo de observaciones, no solo de la actual. Esto es lo que distingue a un agente basado en modelo de un agente de reflejo simple, y constituye la base de la memoria en los sistemas de agentes.

1.2 El bucle de percepción-acción

Todo agente, independientemente de su simplicidad o complejidad, sigue un ciclo fundamental:

Este bucle se repite continuamente. El entorno cambia (en parte debido a las acciones del agente, en parte debido a factores externos), el agente percibe el nuevo estado, razona y actúa de nuevo. A esto se le denomina a veces el ciclo percibir-razonar-actuar o el bucle de percepción-acción.

Pensemós en ello como un médico tratando a un paciente. El médico observa síntomas (percibir), considera posibles diagnósticos y tratamientos (razonar) y prescribe medicación u ordena pruebas (actuar). Después, el médico espera, observa la respuesta del paciente al tratamiento (percibir de nuevo), ajusta el diagnóstico si es necesario (razonar) y modifica el plan de tratamiento (actuar de nuevo). Este ciclo continúa hasta que el paciente se recupera.

El bucle de percepción-acción puede parecer obvio, pero es sorprendentemente poderoso como patrón de diseño. Cada agente que encontraremos en este curso, desde chatbots simples hasta sistemas multiagente sofisticados, está fundamentalmente organizado en torno a este bucle. Lo que cambia es la sofisticación de cada paso.

1.3 Por qué ahora? La confluencia de factores

Antes de profundizar, merece la pena preguntarse: por qué los agentes de IA están de repente en todas partes en 2025-2026, cuando el concepto existe desde los años 50?

Varios factores convergieron:

1. Los modelos de lenguaje de gran escala alcanzaron un umbral de capacidad. Modelos como GPT-4, Claude y Gemini pueden seguir instrucciones complejas, generar código, usar herramientas y razonar a través de problemas de múltiples pasos. Antes de 2022, ningún modelo individual podía hacer todo esto a la vez.

2. El coste de la inferencia cayó drásticamente. En 2023, una sola llamada a la API de GPT-4 costaba aproximadamente 0,03 $ por cada 1K tokens. En 2025, una capacidad equivalente cuesta una fracción de eso con modelos más pequeños y rápidos. Un agente que realiza 20 llamadas a la API por tarea pasó de ser prohibitivamente caro a costar céntimos.

3. La infraestructura de uso de herramientas maduro. Protocolos como MCP (Model Context Protocol), APIs de function calling y entornos de ejecución aislados dieron a los agentes una forma estandarizada de interactuar con el mundo.

4. Surgieron herramientas de desarrollo. Frameworks como LangGraph, CrewAI y el OpenAI Agents SDK hicieron práctico construir agentes sin partir de cero.

5. Los problemas reales lo demandan. La ingeniería de software, la investigación, la atención al cliente y el análisis de datos implican trabajo de múltiples pasos y dependiente del contexto que se resuelve mal con interacciones de IA de un solo turno.

1.4 Entornos

La naturaleza del entorno afecta profundamente al diseño del agente. Russell y Norvig (2021) clasifican los entornos a lo largo de varias dimensiones:

Para concretar estas dimensiones, consideremos un agente de programación como Claude Code operando en un repositorio de software:

• Parcialmente observable: El agente no puede ver todo el código fuente a la vez. Debe elegir qué archivos leer, y parte de la información (como el comportamiento en tiempo de ejecución) solo es accesible ejecutando código.
• Estocástico: Incluso el código determinista puede tener comportamientos sorprendentes. Las propias llamadas al LLM del agente son probabilísticas, lo qué significa qué la misma entrada puede producir salidas diferentes.
• Secuencial: Cada edición de archivo cambia el estado del código fuente. Un cambio en un archivo puede romper otro, y el agente debe tener en cuenta estas dependencias.
• Dinámico: Si trabajas en equipo, otros desarrolladores pueden subir cambios mientras el agente está trabajando. El entorno cambia independientemente del agente.
• Multiagente: En un flujo de desarrollo moderno, puede haber múltiples asistentes de IA, bots de CI/CD y desarrolladores humanos actuando todos sobre el mismo código fuente.

Los agentes modernos basados en LLM suelen operar en entornos parcialmente observables, estocásticos, secuenciales, dinámicos y multiagente. Esto hace que su diseño sea particularmente desafiante, razón por la cual necesitamos los enfoques estructurados que se cubren en este curso.

Pruébalo tú: Elige tres aplicaciones de software que uses a diario (por ejemplo, un buscador, una app de navegación, un cliente de correo). Para cada una, clasifica el entorno según las seis dimensiones anteriores. Cuáles podrían beneficiarse de una arquitectura agéntica? Por que?

1.5 Agentes vs. software tradicional

Consideremos las diferencias:

Un matiz importante: no todo sistema que usa un LLM es un agente. Este es un error común que merece la pena abordar directamente.

Un chatbot qué responde preguntas en un solo turno no es un agente; es una herramienta. Un sistema qué llama a un LLM una vez para clasificar un correo electrónico no es un agente; es un clasificador con un backend de LLM. Un agente toma decisiones sobre qué hacer a continuación, mantiene estado a través de pasos y ejecuta acciones qué cambian su entorno.

Error común: "Si usa GPT-4, es un agente." Esto es incorrecto. La agencia tiene que ver con la arquitectura (bucle de percepción-acción, autonomía, orientación a objetivos), no con el modelo subyacente. Se puede construir un sistema no agéntico sobre GPT-4 (un clasificador simple) y un sistema agéntico sobre un modelo mucho más pequeño (un controlador de robot con un modelo de 7B parámetros).

El límite entre "herramienta" y "agente" es difuso, y eso está bien. Una pregunta más útil que "Es esto un agente?" es "Cuánto grado de agencia tiene este sistema?" Podemos pensar en la agencia como un espectro:

1.6 Un modelo mental para el diseño de agentes

A lo largo de este curso, será útil pensar en un agente de IA como un nuevo empleado en una empresa:

• El prompt del sistema es como la descripción del puesto y el manual de la empresa. Le dice al agente quién es, qué puede hacer y qué reglas debe seguir.
• Las herramientas son como el software y el equipamiento al qué tiene acceso el empleado (correo electrónico, bases de datos, editores de código).
• La memoria es como las notas del empleado, su experiencia pasada y la wiki de la empresa.
• El bucle del agente es como el ciclo de trabajo diario: revisa tus tareas, determina qué hacer a continuación, hazlo, observa los resultados, repite.
• El LLM es como el cerebro del empleado: su conocimiento general, capacidad de razonamiento y habilidades de comunicación.

Esta analogía es imperfecta (los agentes no se cansan, no tienen emociones ni comprenden en el sentido humano), pero proporciona intuiciones útiles sobre el diseño de agentes. Del mismo modo que darías a un nuevo empleado instrucciones claras, las herramientas adecuadas y tareas manejables, necesitas dar a tu agente un prompt claro, herramientas bien diseñadas y un alcance apropiado.

032. Contexto histórico: de los sistemas expertos a los agentes basados en LLM

Comprender la historia de los agentes de IA no es simple nostalgia académica; revela desafíos recurrentes y patrones de diseño que siguen siendo relevantes hoy. Muchas ideas "nuevas" en IA agéntica son reinvenciones de conceptos antiguos con mejor tecnología.

2.1 Sistemas expertos (décadas de 1970-1990)

Los primeros agentes de IA fueron los sistemas expertos: programas basados en reglas que codificaban el conocimiento humano como reglas sí-entonces. MYCIN (Shortliffe, 1976) diagnosticaba infecciones bacterianas. XCON (McDermott, 1982) configuraba pedidos de ordenadores para DEC. DENDRAL (Feigenbaum et al., 1971) ayudaba a químicos a identificar estructuras moleculares.

IF paciente tiene fiebre AND paciente tiene rigidez de cuello
THEN sospechar meningitis (confianza: 0.7)

Fortalezas: Explicables, deterministas, con experiencia específica de dominio. Se le podía preguntar a MYCIN por qué había hecho un diagnóstico concreto, y mostraba la cadena de reglas.

Debilidades: Frágiles, no podían manejar situaciones novedosas, requerían una laboriosa ingeniería manual del conocimiento, sin capacidad de aprendizaje. Construir un sistema experto para un nuevo dominio significaba entrevistar a expertos humanos durante meses y codificar manualmente cientos o miles de reglas.

El cuello de botella del conocimiento fue el defecto fatal. El mundo es demasiado complejo para codificarlo como reglas explícitas. Esta limitación impulsó a la comunidad de IA hacia enfoques basados en aprendizaje.

Idea clave: El cuello de botella del conocimiento de los sistemas expertos es exactamente lo que resuelven los LLM. En lugar de codificar manualmente el conocimiento como reglas, los LLM absorben conocimiento de vastos corpus de texto durante el preentrenamiento. El desafío pasa de "cómo introducimos el conocimiento?" a "cómo obtenemos un comportamiento fiable?"

2.2 Agentes basados en comportamiento y robótica (décadas de 1980-1990)

Rodney Brooks (1986) cuestionó el enfoque clásico de la IA con su arquitectura de subsunción, argumentando que el comportamiento inteligente podía emerger de capas reactivas simples sin modelos explícitos del mundo. Sus robots en el MIT, como Herbert, que recogía latas de refresco de los escritorios, demostraron que los bucles de percepción-acción sin razonamiento complejo podían producir comportamientos sorprendentemente capaces.

La idea clave de Brooks fue que el propio mundo puede servir como su propio modelo. En lugar de construir una representación interna elaborada del mundo y luego razonar sobre ella, un agente puede usar sus sensores para interactuar directamente con el mundo en tiempo real.

La arquitectura de subsunción organizaba los comportamientos en capas:

Capa 3: [Explorar] ------------ explorar nuevas areas
Capa 2: [Deambular] ----------- moverse aleatoriamente
Capa 1: [Evitar obstaculos] --- evitar colisiones
Capa 0: [Quedarse quieto] ----- comportamiento base

Las capas superiores pueden subsumir (anular) las capas inferiores

Esta época introdujo la idea de que los agentes no necesitan un modelo completo del mundo para actuar eficazmente, un principio que resurge en los agentes modernos basados en LLM que usan herramientas. Cuando Claude Code lee un archivo, no intenta construir primero un modelo completo de todo el código fuente; lee lo que necesita, actúa, observa el resultado e itera.

2.3 Agentes BDI y sistemas multiagente (décadas de 1990-2000)

El marco Belief-Desire-Intention (BDI) (creencias, deseos, intenciones) de Rao y Georgeff (1995) formalizó el razonamiento de agentes de una manera que conecta sorprendentemente bien con los agentes modernos basados en LLM:

• Creencias (Beliefs): Lo que el agente cree que es verdad sobre el mundo. En un agente moderno, esta es la información en la ventana de contexto más cualquier memoria recuperada.
• Deseos (Desires): Los objetivos que el agente quiere alcanzar. En un agente moderno, esto proviene de la petición del usuario y del prompt del sistema.
• Intenciones (Intentions): Los planes que el agente se ha comprometido a ejecutar. En un agente moderno, este es el plan actual (explícito o implícito) que guía la siguiente acción.

Plataformas cómo JADE (Java Agent DEvelopment Framework) y la investigación en sistemas multiagente exploraron cómo múltiples agentes podían coordinarse, negociar y cooperar. Este trabajo sentó las bases conceptuales para los sistemas modernos de IA multiagente cómo CrewAI y AutoGen.

El marco BDI también introdujo la distinción importante entre agentes reactivos y deliberativos:

• Los agentes reactivos responden inmediatamente a estímulos (como los robots de Brooks).
• Los agentes deliberativos mantienen un modelo interno y planifican antes de actuar (como los sistemas expertos).
• La mayoría de los agentes prácticos son híbridos: tienen una capa reactiva para respuestas inmediatas y una capa deliberativa para planificación compleja.

Los agentes modernos basados en LLM son inherentemente híbridos: la generación token a token del LLM es reactiva (condicionada al contexto inmediato), pero las estrategias de prompting como Chain-of-Thought añaden una capa deliberativa encima.

2.4 Agentes de aprendizaje por refuerzo (década de 2010)

La combinación de aprendizaje profundo y aprendizaje por refuerzo produjo agentes capaces de aprender comportamientos complejos a partir de la interacción. Hitos clave:

• DQN (Mnih et al., 2015): Jugar a juegos de Atari a nivel sobrehumano a partir de píxeles sin procesar. Esto demostró que los agentes podían aprender políticas de control complejas a partir de entrada sensorial de alta dimensionalidad.
• AlphaGo (Silver et al., 2016): Derrotar al campeón del mundo en Go, un juego con más posiciones posibles que átomos en el universo. AlphaGo combinaba búsqueda en árbol con funciones de valor aprendidas.
• AlphaFold (Jumper et al., 2021): Predecir estructuras de proteínas con una precisión notable, resolviendo un problema biológico de 50 años de antigüedad.

Estos agentes eran potentes pero estrechos: cada uno estaba entrenado para una sola tarea y no podía generalizar. AlphaGo no podía jugar al ajedrez, y mucho menos escribir código o mantener una conversación. Entrenar cada agente requería millones de episodios de interacción, funciones de recompensa especializadas y enormes recursos computacionales.

Idea clave: Los agentes de RL aprenden de la experiencia; los agentes basados en LLM aprenden de texto sobre la experiencia. Un agente de RL que juega al ajedrez aprende jugando millones de partidas. Un LLM "aprende" sobre ajedrez leyendo libros, artículos y transcripciones de partidas escritos por humanos. Esta diferencia fundamental explica tanto la generalidad de los agentes basados en LLM (pueden hablar de cualquier cosa) como sus limitaciones (pueden describir con confianza estrategias de ajedrez que en realidad no pueden ejecutar).

2.5 La revolución de los LLM (2022-presente)

El lanzamiento de ChatGPT en noviembre de 2022 marcó un punto de inflexión. Por primera vez, un único modelo podía:

• Comprender y generar lenguaje natural en múltiples dominios
• Seguir instrucciones complejas de múltiples pasos
• Escribir y razonar sobre código
• Adoptar diferentes personalidades y seguir instrucciones del sistema

Los investigadores rápidamente se dieron cuenta de que los LLM podían servir como el núcleo de razonamiento de agentes de propósito general. Los artículos clave que catalizaron este cambio incluyen:

• ReAct (Yao et al., 2023): Demostró que intercalar trazas de razonamiento con acciones en un único prompt de LLM mejoraba dramáticamente el rendimiento del agente. Este artículo es tan importante que dedicamos una gran parte de la Semana 5 a él.
• Toolformer (Schick et al., 2023): Demostró que los LLM podían aprender a usar herramientas externas (calculadoras, motores de búsqueda, APIs) mediante aprendizaje autosupervisado. Esto abrió la puerta a agentes aumentados con herramientas.
• Generative Agents (Park et al., 2023): Creó un pueblo simulado con 25 agentes de IA con comportamientos sociales creíbles, usando LLM con arquitecturas de memoria. Esto capturó la imaginación pública y demostró que los agentes basados en LLM podían producir comportamiento colectivo emergente.

El ritmo de desarrollo desde entonces ha sido extraordinario. En aproximadamente dos años, pasamos de "puede un LLM usar una calculadora?" a agentes de programación en producción, agentes de navegación web y sistemas de orquestación multiagente.

2.6 Resumen cronológico

Pruébalo tú: Elige un sistema histórico de agentes de IA (MYCIN, Herbert, AlphaGo u otro que te interese). Investiga cómo percibía su entorno, tomaba decisiones y ejecutaba acciones. Identifica el bucle de percepción-acción. Cuáles eran sus mayores limitaciones y cómo las abordan los agentes modernos basados en LLM?

043. Taxonomía de agentes (Russell y Norvig)

Russell y Norvig (2021) definen cinco tipos de agentes, cada uno más capaz qué el anterior. Comprender esta taxonomía nos ayuda a apreciar qué son y qué no son los agentes modernos basados en LLM. Piensa en ello como una escala de sofisticación creciente.

3.1 Agentes de reflejo simple

El tipo de agente más sencillo. Selecciona acciones basándose únicamente en la percepción actual, ignorando todo el historial. Sin memoria, sin modelo del mundo, sin planificación. Sólo reglas condición-acción.

def simple_reflex_agent(percept):
    """A thermostat-like agent."""
    if percept["temperature"] > 25:
        return "turn_on_cooling"
    elif percept["temperature"] < 18:
        return "turn_on_heating"
    else:
        return "do_nothing"

Este es el termostato de tu casa. Si la temperatura es demasiado alta, enciende la refrigeración. Si es demasiado baja, enciende la calefacción. El termostato no recuerda lo que hizo hace cinco minutos, no planifica para la previsión meteorológica de mañana y no razona sobre por qué está subiendo la temperatura. Sólo reacciona.

Las reglas condición-acción (reglas si-entonces) dirigen el comportamiento. Pueden ser sorprendentemente eficaces para tareas bien definidas en entornos totalmente observables y deterministas.

Limitaciones: No puede manejar entornos parcialmente observables. Si el sensor se avería, el agente no tiene forma de compensar. No puede razonar sobre las consecuencias de las acciones. No puede manejar situaciones no cubiertas por sus reglas.

Ejemplos reales: Termostatos, filtros de spam simples (basados en palabras clave), sensores de puertas automáticas, respuestas automáticas básicas de correo electrónico.

3.2 Agentes de reflejo basados en modelo

Estos agentes mantienen un estado interno, un modelo del mundo, que actualizan con cada percepción. Esto les permite manejar observabilidad parcial recordando cosas que no pueden ver actualmente.

class ModelBasedAgent:
    def __init__(self):
        self.state = {"room_occupied": False, "lights_on": False}

    def update_state(self, percept):
        if percept.get("motion_detected"):
            self.state["room_occupied"] = True
            self.state["last_motion_time"] = percept["timestamp"]
        elif self._time_since_last_motion() > 600:  # 10 minutes
            self.state["room_occupied"] = False

    def act(self, percept):
        self.update_state(percept)
        if self.state["room_occupied"] and not self.state["lights_on"]:
            self.state["lights_on"] = True
            return "turn_on_lights"
        elif not self.state["room_occupied"] and self.state["lights_on"]:
            self.state["lights_on"] = False
            return "turn_off_lights"
        return "do_nothing"

La diferencia crítica respecto a un agente de reflejo simple: este sistema de iluminación inteligente recuerda que alguien estuvo en la habitación hace diez minutos, aunque el sensor de movimiento no haya detectado nada recientemente. Usa esta memoria para decidir que la habitación probablemente sigue ocupada (quizá la persona está sentada y quieta, leyendo).

Idea clave: El estado interno permite al agente razonar sobre cosas que no puede observar actualmente. Este es el mismo principio detrás de la "ventana de contexto" en los agentes basados en LLM: el historial de conversación sirve como modelo interno del agente sobre la tarea en curso.

Ejemplos reales: Sistemas de hogar inteligente, control de crucero adaptativo, sistemas antibloqueo de frenos, sistemas de gestión de inventario.

3.3 Agentes basados en objetivos

Los agentes basados en objetivos van más allá de reaccionar al estado actual. Consideran el futuro: concretamente, que acciones conducirían a alcanzar sus objetivos. Este es un salto cualitativo respecto a los agentes basados en modelo. Los agentes basados en modelo preguntan "Cómo es el mundo?" Los agentes basados en objetivos preguntan "Cómo quiero que sea el mundo y cómo llegó allí?"

Esto requiere tres cosas:

1. Un modelo de cómo evoluciona el mundo (si ejecutó la acción A en el estado S, qué estado resultará?).
2. Una representación del estado objetivo (cómo es el "éxito"?).
3. Un algoritmo de búsqueda o planificación para encontrar una secuencia de acciones desde el estado actual hasta el objetivo.

class GoalBasedAgent:
    def __init__(self, goal):
        self.goal = goal  # e.g., {"location": "airport"}
        self.state = {"location": "home"}
        self.plan = []

    def act(self, percept):
        self.update_state(percept)

        if self.goal_achieved():
            return "done"

        if not self.plan:
            self.plan = self.search_for_plan()

        if self.plan:
            return self.plan.pop(0)

        return "replan"  # No plan found, try again

Consideremos una aplicación de navegación. Conoce tu ubicación actual (estado), tu destino deseado (objetivo) y cómo se conectan las carreteras (modelo del mundo). Busca la mejor ruta (plan) y te guía paso a paso. Si una carretera está bloqueada, replanifica.

Los agentes basados en objetivos pueden ser flexibles: si la ruta al aeropuerto está bloqueada, pueden encontrar una ruta alternativa. Los agentes de reflejo simple no pueden hacer esto porque no tienen concepto de objetivo ni de plan.

La transición de basado en modelo a basado en objetivos es un salto cualitativo. Los agentes basados en modelo reaccionan al mundo tal como es. Los agentes basados en objetivos actúan para transformar el mundo en lo que quieren que sea.

Ejemplos reales: Sistemas de navegación (Google Maps, Waze), IA para juegos, sistemas de planificación automática, planificación de trayectorias de robots.

3.4 Agentes basados en utilidad

A veces hay múltiples formas de alcanzar un objetivo, y algunas son mejores que otras. Una función de utilidad asigna a los estados un número real que representa lo "satisfecho" que está el agente en ese estado.

class UtilityBasedAgent:
    def __init__(self):
        self.state = {}

    def utility(self, state):
        """Multi-objective utility combining several factors."""
        return (
            0.4 * state.get("comfort", 0) +
            0.3 * state.get("energy_saved", 0) +
            0.2 * state.get("safety", 0) +
            0.1 * state.get("cost_saved", 0)
        )

    def act(self, percept):
        self.update_state(percept)
        possible_actions = self.get_possible_actions()

        # Choose the action that maximizes expected utility
        best_action = max(
            possible_actions,
            key=lambda a: self.expected_utility(a)
        )
        return best_action

Consideremos la elección de un vuelo. Un agente basado en objetivos pregunta: "Este vuelo me lleva a Londres?" Si la respuesta es sí, el objetivo se cumple. Pero un agente basado en utilidad pregunta: "Cómo de buena es está opción?" Sopesa precio, hora de salida, número de escalas, reputación de la aerolínea y comodidad del asiento. Podría elegir un vuelo algo más caro que sale a una hora razonable frente a un vuelo nocturno barato.

Los agentes basados en utilidad manejan compromisos e incertidumbre de forma natural. Pueden razonar sobre el riesgo (debería tomar la ruta más rápida pero más arriesgada?) y tomar decisiones con múltiples objetivos en competencia.

Idea clave: Cuando un agente basado en LLM elige entre diferentes enfoques para resolver una tarea, está realizando implícitamente un razonamiento basado en utilidad. La "función de utilidad" está incorporada en el entrenamiento del modelo y en el prompt del sistema, no está programada explícitamente. Comprender esto ayuda a explicar por qué la ingeniería de prompts es tan importante: estás moldeando la función de utilidad implícita del agente.

Ejemplos reales: Sistemas de recomendación (Netflix, Spotify), vehículos autónomos (equilibrando velocidad, seguridad, comodidad), optimización de carteras, sistemas de precios dinámicos.

3.5 Agentes con aprendizaje

Un agente con aprendizáje tiene cuatro componentes conceptuales:

1. Elemento de aprendizaje: Mejora al agente basándose en la experiencia.
2. Elemento de rendimiento: Selecciona acciones (este es el agente tal como se ha descrito anteriormente).
3. Crítico: Proporciona retroalimentación sobre cómo lo está haciendo el agente.
4. Generador de problemas: Sugiere acciones exploratorias para descubrir nuevo conocimiento.

El marco de agente con aprendizaje es elegante porque explica cómo un agente puede mejorar con el tiempo. El generador de problemas es particularmente interesante: sugiere acciones que podrían no ser óptimas ahora pero que ayudan al agente a aprender algo útil para el futuro. Este es el dilema exploración vs. explotación que aparece en toda la IA.

Los agentes modernos basados en LLM son los más cercanos a los agentes con aprendizaje, pero con una advertencia importante. La mayoría de los agentes actuales basados en LLM no actualizan los pesos de su modelo durante el despliegue. En su lugar, "aprenden" a través de:

• Aprendizaje en contexto (in-context learning): Adaptándose dentro de una conversación basándose en ejemplos y retroalimentación proporcionados en el prompt.
• Memoria externa: Almacenando y recuperando experiencias pasadas usando bases de datos vectoriales u otros almacenamientos.
• Refinamiento del prompt: Mejorando sus propias instrucciones basándose en retroalimentación (esto es lo que hace Reflexión, cómo veremos en la Semana 5).

Esta es una forma de aprendizaje no paramétrico: los parámetros del modelo permanecen fijos, pero el comportamiento efectivo del agente cambia a través de su contexto y memoria. Es como si un empleado mejorará no adquiriendo nuevas habilidades, sino tomando mejores notas y consultándolas de forma más efectiva.

Pruébalo tú: Piensa en una tarea reciente de múltiples pasos que completaste frente a un ordenador (depurar código, escribir un informe, planificar un viaje). Identifica los momentos en que: (a) reaccionaste reflexivamente, (b) consultaste tu "modelo interno" de la situación, (c) planificaste con antelación, (d) sopesaste compromisos, (e) aprendiste de un error. Cuántos de estos comportamientos querrías que tuviera un agente de IA?

054. El agente de IA moderno: el LLM como "cerebro"

4.1 Por qué los LLM lo cambiaron todo

Antes de los LLM, construir un agente requería:

• Especificar manualmente reglas o funciones de recompensa
• Entrenar modelos especializados para cada capacidad
• Diseñar pipelines complejos para conectar componentes
• Contratar expertos del dominio para codificar conocimiento

Los LLM proporcionan un motor de razonamiento de propósito general capaz de:

• Comprender instrucciones en lenguaje natural (sin necesidad de especificación formal)
• Generar planes en lenguaje natural
• Escribir y ejecutar código
• Usar herramientas descritas en lenguaje natural
• Mantener contexto conversacional
• Adaptarse a nuevas tareas solo mediante prompting

Esto colapsa lo que antes requería un equipo de ingeniería completo en una sola llamada al modelo, complementada con infraestructura relativamente simple.

Para apreciar la magnitud de este cambio, consideremos lo que implicaba construir un agente de preguntas y respuestas en 2015 frente a 2025:

Enfoque de 2015: Necesitarías un reconocedor de entidades nombradas, un analizador de dependencias, un clasificador de preguntas, una base de conocimiento, un generador de consultas, un recuperador de pasajes, un modelo de comprensión lectora y un generador de respuestas. Cada componente sería un modelo separado, entrenado con datos separados, con código de integración personalizado entre ellos. El sistema podría funcionar bien para preguntas factuales sobre un dominio y fallar completamente en todo lo demás.

Enfoque de 2025: Escribes un prompt del sistema, defines algunas herramientas (búsqueda web, calculadora) e implementas un bucle básico de agente. El LLM se encarga de la comprensión, el razonamiento, la planificación y la generación de respuestas. Añadir un nuevo dominio es un cambio de prompt, no un esfuerzo de reingeniería.

4.2 El paradigma del agente basado en LLM

En el paradigma moderno, un agente basado en LLM consta de:

El LLM es el coordinador central. Recibe información de la percepción (entrada del usuario, salidas de herramientas, observaciones del entorno), razona sobre qué hacer a continuación y despacha acciones a través de herramientas.

Imaginemos al LLM como el cerebro de un trabajador del conocimiento sentado ante un escritorio. El escritorio tiene varias herramientas (teléfono, ordenador, calculadora, archivador). El cerebro decide que herramienta coger y cómo usarla. Las herramientas amplían las capacidades del cerebro: la calculadora maneja aritmética precisa, el archivador almacena información para recuperarla más tarde y el teléfono conecta con el mundo exterior. De manera similar, el LLM decide cuándo llamar a una herramienta de búsqueda, cuándo ejecutar código y cuándo recuperar información de la memoria.

065. Componentes de un agente basado en LLM

La influyente revisión de Wang et al. (2024), "A Survey on Large Language Model Based Autonomous Agents", identifica cuatro componentes clave de los agentes basados en LLM. Examinamos cada uno en detalle.

5.1 Planificación

La planificación es la capacidad de descomponer una tarea compleja en subtareas manejables y determinar el orden de ejecución. Es quizá la capacidad más genuinamente "agéntica": un sistema que planifica está tomando decisiones sobre acciones futuras, no solo reaccionando al presente.

Por qué importa la planificación: Sin planificación, un agente al qué se le pida "escribe un informe de investigación sobre el cambio climático" podría empezar inmediatamente a escribir la conclusión. Con planificación, primero identifica las secciones, determina qué información necesita para cada una, busca esa información y luego escribe en un orden lógico.

Piensa en cómo abordarías una tarea compleja en el trabajo. Si tu jefe te pide que "prepares un análisis de mercado", no empiezas a escribir inmediatamente. Primero piensas: Que mercados? Que datos necesito? Donde puedo encontrarlos? Que formato espera el jefe? Cual es la fecha límite? Este paso de descomposición es planificación, y es esencial para cualquier tarea que no pueda completarse en una sola acción.

Los agentes basados en LLM necesitan la misma capacidad, pero son sorprendentemente inconsistentes en ella. A veces producen planes excelentes; otras veces omiten pasos críticos o crean planes con dependencias circulares. Esta variabilidad es la razón por la que las arquitecturas de agentes (Semana 5) a menudo incluyen mecanismos explícitos de planificación en lugar de depender de la capacidad implícita de planificación del LLM.

Estrategias de descomposición de tareas:

1. Chain of Thought (CoT): El agente razona paso a paso a través del problema (Wei et al., 2022). Esta es la forma más simple de planificación: pensar antes de actuar.
2. Planificar-y-luego-ejecutar: Generar un plan completo primero, luego ejecutar cada paso. Esto proporciona una hoja de ruta pero puede necesitar ajustes a medida que el agente aprende más.
3. Refinamiento iterativo: Comenzar con un plan aproximado, refinarlo a medida que hay más información disponible. Este es el enfoque más flexible y refleja cómo los humanos abordan tareas complejas.

Ejemplo: planificación para una tarea de investigación:

Objetivo: "Escribir una revision bibliografica sobre deteccion de sesgo mediatico"

Plan:
1. Definir el alcance: Que tipos de sesgo mediatico? Que periodo temporal?
2. Buscar en bases de datos academicas articulos relevantes
3. Leer y categorizar los articulos por metodologia
4. Identificar temas y tendencias clave
5. Redactar las secciones de la revision bibliografica
6. Anadir citas y dar formato adecuado
7. Revisar y corregir

Replanificación: Los buenos agentes reconocen cuando su plan inicial está fallando y se adaptan. Si el paso 2 no devuelve resultados para una consulta de búsqueda específica, el agente debería probar consultas alternativas en lugar de seguir adelante sin datos. Esta replanificación adaptativa es lo que distingue a un agente sofisticado de un script rígido.

La jerarquía de planificación: En la práctica, la planificación ocurre a múltiples niveles:

• Planificación estratégica: "Necesito escribir una revisión bibliográfica" (objetivo general)
• Planificación táctica: "Primero buscaré artículos, luego los categorizaré, luego escribiré cada sección" (descomposición en subtareas)
• Planificación operativa: "Para la búsqueda, usaré Google Scholar con estas palabras clave" (detalles específicos de la acción)

Las buenas arquitecturas de agentes manejan los tres niveles. Veremos esto en Plan-and-Execute (Semana 5), donde el planificador maneja los niveles estratégico y táctico, y el ejecutor maneja los detalles operativos.

Idea clave: La planificación es donde los agentes basados en LLM fallan con mayor frecuencia. Estudios han demostrado que los LLM a menudo generan planes que parecen plausibles pero tienen errores sutiles de dependencia (el paso 4 requiere información que solo está disponible después del paso 6) u omiten pasos críticos. Por eso las arquitecturas como Plan-and-Execute (Semana 5) incluyen mecanismos explícitos de replanificación.

5.2 Memoria

Los agentes basados en LLM necesitan sistemas de memoria porque los LLM por sí solos tienen una ventana de contexto fija. Una vez que la conversación supera la ventana de contexto, la información anterior se pierde. La memoria viene en varias formas, cada una sirviendo a un propósito diferente:

Memoria a corto plazo (memoria de trabajo):

• La conversación actual o ventana de contexto
• Típicamente de 8K a 200K tokens dependiendo del modelo
• Incluye la tarea actual, observaciones recientes y resultados intermedios
• Análoga a la memoria de trabajo humana: la información en la que estás pensando activamente

Memoria a largo plazo:

• Almacenamiento persistente más allá de la ventana de contexto
• Implementada mediante bases de datos vectoriales (por ejemplo, Pinecone, Chroma, pgvector)
• Generación Aumentada por Recuperación (RAG): recuperar información pasada relevante cuando se necesita
• Análoga a la biblioteca de referencia de un ser humano: información almacenada externamente que consultas cuando la necesitas

Memoria episódica:

• Registros de experiencias pasadas y sus resultados
• "La última vez que intenté el enfoque X, falló porque Y"
• Permite aprender de errores pasados
• Análoga a la memoria autobiográfica humana: recordar lo que sucedió en situaciones pasadas específicas

Memoria semántica:

• Conocimiento factual sobre el mundo
• A menudo almacenada como embeddings o grafos de conocimiento
• Permite al agente recordar información específica del dominio
• Análoga al conocimiento general humano: hechos que sabes pero cuyo origen no puedes rastrear a una experiencia específica

class AgentMemory:
    """A simplified agent memory system."""

    def __init__(self):
        self.short_term = []       # Recent conversation turns
        self.long_term = []        # Stored experiences
        self.episodic = []         # Past task outcomes

    def add_to_short_term(self, observation: str):
        self.short_term.append(observation)
        # Keep only the last N observations to fit context
        if len(self.short_term) > 50:
            self.compress_and_archive()

    def recall_relevant(self, query: str, k: int = 5) -> list[str]:
        """Retrieve k most relevant memories for the current context."""
        # In practice, this would use embedding similarity search
        return self._semantic_search(query, self.long_term, k)

    def store_experience(self, task: str, outcome: str, success: bool):
        """Store a task outcome for future reference."""
        self.episodic.append({
            "task": task,
            "outcome": outcome,
            "success": success,
            "timestamp": datetime.now()
        })

Analicemos este código para entender el diseño:

• add_to_short_term: Cada observación (resultado de herramienta, mensaje del usuario, etc.) va a la memoria a corto plazo. Pero la memoria a corto plazo tiene un límite (50 elementos aquí, representando la restricción de la ventana de contexto). Cuando se desborda, compress_and_archive resumiría las entradas más antiguas y las movería al almacenamiento a largo plazo.
• recall_relevant: Cuando el agente necesita información del pasado, no busca a través de todo; usa similitud semántica para encontrar las memorias más relevantes. Es como cuando no relees todos los libros que has leído; recuerdas el que parece más relevante para tu pregunta actual.
• store_experience: Después de completar una tarea, el agente registra lo que sucedió. Esto crea una base de datos creciente de experiencias que puede informar decisiones futuras.

Pruébalo tú: Piensa en cómo gestionas tú propia "memoria" al trabajar en un proyecto complejo. Qué mantienes en tú cabeza (memoria de trabajo)? Qué escribes en notas (memoria a largo plazo)? Qué experiencias pasadas influyen en tú enfoque actual (memoria episódica)? Cómo diseñarás un sistema artificial que imite tú enfoque?

5.3 Uso de herramientas

Las herramientas extienden al agente más allá de la generación pura de texto. Tienden un puente entre lo que el LLM puede razonar y lo que realmente puede hacer en el mundo.

Categorías comunes de herramientas:

Una herramienta se describe típicamente al agente como una firma de función con una descripción en lenguaje natural:

tools = [
    {
        "name": "web_search",
        "description": "Search the web for current information. Use this when you need up-to-date facts.",
        "parameters": {
            "query": {
                "type": "string",
                "description": "The search query"
            }
        }
    },
    {
        "name": "calculator",
        "description": "Perform mathematical calculations. Use this for any arithmetic.",
        "parameters": {
            "expression": {
                "type": "string",
                "description": "A mathematical expression, e.g., '2 + 2 * 3'"
            }
        }
    }
]

El LLM decide cuándo llamar a una herramienta, cuál herramienta llamar y qué argumentos pasar. Esta es una capacidad notable qué emerge del entrenamiento con grandes corpus qué incluyen código, documentación y ejemplos de uso de herramientas.

Piensa en cómo decides usar una calculadora. No sacas la calculadora para "2 + 3"; lo calculas mentalmente. Pero para "Cuánto es el 7,3% de 148.293,57 $?", recurres a la calculadora porque sabes que la aritmética mental no es fiable para ese nivel de precisión. Los agentes basados en LLM exhiben un comportamiento similar: usan herramientas selectivamente, basándose en la dificultad y los requisitos de precisión de la tarea.

Idea clave: La descripción de la herramienta es posiblemente más importante que la implementación de la herramienta. El LLM decide si usar y cómo usar una herramienta basándose enteramente en su descripción en lenguaje natural. Una herramienta bien implementada con una mala descripción será mal utilizada; una herramienta bien descrita será usada correctamente incluso si la implementación es simple.

5.4 Acción

El componente de acción es la interfaz entre las decisiones del agente y el mundo externo. Las acciones pueden ser:

• Acciones digitales: Llamadas API, ejecución de código, modificaciones de archivos, envío de mensajes.
• Acciones físicas: En robótica, controlar motores, pinzas u otros actuadores.
• Acciones comunicativas: Generar respuestas a usuarios, hacer preguntas de clarificación, delegar a otros agentes.

Una decisión de diseño crítica es el espacio de acciones: qué acciones están disponibles para el agente? Un espacio de acciones estrecho (pocas acciones bien definidas) es más seguro pero menos capaz. Un espacio de acciones amplio (muchas acciones posibles, incluyendo ejecución de código) es más poderoso pero más arriesgado.

Consideremos la diferencia:

• Estrecho: El agente puede clasificar correos como "urgente" o "no urgente". Seguro, predecible, pero muy limitado.
• Medio: El agente puede leer correos, buscar en una base de conocimiento y redactar respuestas para revisión humana. Útil y razonablemente seguro.
• Amplio: El agente puede leer correos, buscar en la web, escribir código, ejecutar código, enviar correos y modificar archivos. Muy poderoso, pero un error podría tener consecuencias graves.

Este equilibrio entre capacidad y seguridad es una de las tensiones centrales en él diseño de agentes, y volveremos a él a lo largo de este curso.

5.5 Cómo trabajan juntos los cuatro componentes

En la práctica, los cuatro componentes están profundamente interconectados. Consideremos un agente de programación corrigiendo un error:

1. Planificación: "Necesito entender el error, encontrar la causa, corregirlo y verificar la corrección."
2. Memoria: "Este código fuente usa un framework de pruebas específico (de una conversación anterior). El error se reportó en el módulo de autenticación."
3. Uso de herramientas: Leer el archivo de pruebas qué falla, buscar funciones relacionadas en el código, editar el archivo con el error, ejecutar las pruebas.
4. Acción: Ejecutar cada llamada a herramienta, observar los resultados y decidir qué hacer a continuación.

El agente alterna entre estos componentes de forma fluida. Planifica (descompone la tarea), usa herramientas (lee archivos), almacena información en memoria (cómo era el código?), planifica de nuevo (ahora qué veo el error, cómo debería corregirlo?), usa herramientas (edita el archivo, ejecuta pruebas) y evalúa el resultado (pasaron las pruebas?).

Idea clave: Los cuatro componentes (planificación, memoria, uso de herramientas, acción) no son módulos separados qué se ejecutan en secuencia. Están entrelazados y son interdependientes. La planificación requiere memoria (qué se ya?). El uso de herramientas requiere planificación (qué herramienta debería usar?). La memoria se actualiza mediante acciones (qué acabo de aprender?). Diseñar agentes significa diseñar cómo interactúan estos componentes.

076. Sistemas de agentes reales (2025-2026)

6.1 Agentes de programación

Los agentes de programación son la categoría más madura y ampliamente desplegada de agentes basados en LLM en 2025-2026. Demuestran el paradigma completo del agente: percepción (lectura de código), razonamiento (comprensión de errores), planificación (decisión de qué cambiar), uso de herramientas (ejecución de pruebas, búsqueda en código) y acción (edición de archivos).

Por qué los agentes de programación maduraron primero? Varias razones: (1) El código tiene criterios de éxito claros (compila? pasan las pruebas?), lo que facilita evaluar el rendimiento del agente. (2) El entorno es digital, evitando los desafíos de la interacción física. (3) Hay una cantidad masiva de código en los datos de entrenamiento, por lo que los LLM tienen fuertes priors de programación. (4) Los desarrolladores, al ser los primeros usuarios de herramientas de IA, proporcionaron bucles rápidos de retroalimentación para la mejora.

Claude Code (Anthropic, 2025)

• Un asistente de programación agéntico que opera directamente en la terminal
• Puede leer archivos, escribir código, ejecutar comandos, buscar en el código fuente y ejecutar pruebas
• Usa un bucle de percepción-acción: observar el estado del código, razonar sobre que cambiar, hacer ediciones, verificar con pruebas
• Notable por su arquitectura de uso de herramientas con sistemas explícitos de permisos: pide aprobación antes de ejecutar comandos potencialmente destructivos
• Demuestra el patrón "humano en el bucle" en su mejor expresión: autónomo para operaciones seguras, supervisado para las arriesgadas

Cursor (Cursor Inc., 2024-2025)

• Un IDE construido en torno a la programación asistida por IA
• La función "Composer" actúa como agente: puede editar múltiples archivos, ejecutar comandos de terminal e iterar sobre retroalimentación
• Demuestra cómo los agentes pueden integrarse en flujos de trabajo existentes de desarrollo en lugar de reemplazarlos
• Lección importante: los agentes no siempre necesitan ser sistemas independientes; pueden aumentar herramientas existentes

Devin (Cognition Labs, 2024)

• Comercializado como un "ingeniero de software de IA"
• Puede planificar tareas, escribir código, depurar y desplegar aplicaciones
• Opera en un entorno aislado con acceso a navegador, terminal y editor
• Ilustró tanto el potencial como las limitaciones de los agentes de programación autónomos: demos impresionantes, pero el rendimiento en el mundo real mostró que la autonomía total sigue siendo un desafío

SWE-agent (Yang et al., 2024)

• Un proyecto de investigación académica que creó un agente para resolver issues de GitHub
• Demostró que el diseño de la interfaz agente-ordenador importa tanto como el modelo subyacente: al diseñar una interfaz personalizada (una terminal simplificada con comandos útiles), los investigadores mejoraron significativamente la capacidad del agente para navegar y editar código
• Esta es una lección importante: el entorno y las herramientas que proporcionas a un agente son tan importantes como su capacidad de razonamiento

6.2 Agentes de investigación y conocimiento

Elicit (Ought)

• Un asistente de investigación con IA que puede buscar artículos, extraer afirmaciones y sintetizar hallazgos
• Usa LLM aumentados con herramientas para interactuar con bases de datos académicas
• Demuestra diseño de agentes específicos de dominio para revisión bibliográfica
• Muestra cómo los agentes pueden aportar valor en el trabajo del conocimiento manejando tareas tediosas (buscar artículos, extraer datos) mientras dejan el análisis a los humanos

Research Agent de Semantic Scholar

• Funciones impulsadas por IA para buscar, filtrar y comprender literatura científica
• Ilustra cómo los agentes pueden operar sobre bases de conocimiento estructuradas
• Usa el concepto de "RAG agentico": el agente decide qué buscar, evalúa los resultados e itera

6.3 Agentes web y de uso de ordenador

Anthropic Computer Use (2024-2025)

• Un agente que puede ver e interactuar con la pantalla de un ordenador
• Usa percepción de capturas de pantalla + acciones de raton/teclado
• Demuestra cómo la percepción visual puede complementar a los agentes tradicionales basados en texto
• El bucle de percepción-acción aquí es literal: mirar la pantalla, decidir dónde hacer clic, hacer clic, mirar el resultado

OpenAI Operator (2025)

• Un agente de navegación web que puede completar tareas en un navegador
• Navega sitios web, rellena formularios, pulsa botones
• Plantea preguntas significativas sobre autenticación, seguridad y confianza
• Cuando encuentra una página de pago, se detiene y pide aprobación al humano: un ejemplo práctico de restricción del espacio de acciones por seguridad

6.4 Sistemas multiagente

ChatDev (Qian et al., 2024)

• Simula una empresa de software con múltiples agentes LLM (CEO, CTO, Programador, Tester)
• Los agentes colaboran a través de protocolos de comunicación estructurados
• Demuestra comportamiento de coordinación emergente: el CEO establece requisitos, el CTO diseña la arquitectura, el Programador implementa y el Tester encuentra errores
• Muestra que la especialización de roles puede mejorar la calidad incluso cuando todos los agentes usan el mismo modelo subyacente

AutoGen (Microsoft, 2023)

• Un framework para construir sistemas multiagente conversacionales
• Los agentes pueden tener diferentes roles, capacidades e incluso diferentes modelos subyacentes
• Soporta flujos de trabajo tanto autónomos como con humano en el bucle
• Fue pionero en el concepto de "orquestación conversacional de agentes" donde los agentes hablan entre sí para resolver problemas

6.5 El panorama de agentes en 2025-2026

El ecosistema de agentes ha madurado significativamente:

Frameworks:

• LangChain / LangGraph: El framework de agentes más utilizado, con soporte para flujos de trabajo complejos como grafos dirigidos
• CrewAI: Se centra en la colaboración multiagente basada en roles
• AutoGen: El framework de Microsoft para sistemas multiagente conversacionales
• Pydantic AI: Framework de agentes con seguridad de tipos y validación robusta
• OpenAI Agents SDK: Framework ligero con soporte nativo para handoffs entre agentes

Infraestructura:

• Model Context Protocol (MCP): El estándar de Anthropic para conectar agentes a herramientas y fuentes de datos, análogo al USB para la IA. Lo cubriremos en profundidad en la Semana 4.
• Bases de datos vectoriales: Pinecone, Chroma, Weaviate, pgvector para memoria de agentes
• Sandboxing: E2B, Modal y Docker para ejecución segura de código

Patrones de despliegue:

• Agente único, con humano en el bucle: El patrón más común (por ejemplo, Claude Code, Cursor). El agente trabaja autónomamente pero se detiene para aprobación en puntos críticos.
• Orquestación multiagente: Agentes especializados coordinados por un orquestador. Emergiendo en producción para flujos de trabajo complejos.
• Totalmente autónomo: Aún raro en producción debido a preocupaciones de fiabilidad y seguridad. Usado principalmente en entornos controlados con criterios de éxito claros.

087. Construyendo un agente simple: implementación en Python

Construyamos un bucle de agente mínimo pero funcional. Este ejemplo demuestra el patrón central que subyace a todos los agentes basados en LLM. Lo analizaremos cuidadosamente, explicando cada decisión de diseño.

7.1 El bucle del agente

"""
A minimal LLM-based agent demonstrating the perception-action loop.

This agent can answer questions by optionally searching the web
or performing calculations. It decides which tool to use (if any)
based on the user's query.
"""

import json
from openai import OpenAI  # Or any LLM client library

# --- Configuration ---
client = OpenAI()  # Uses OPENAI_API_KEY environment variable
MODEL = "gpt-4o"   # Or "claude-sonnet-4-20250514" with Anthropic client

# --- Tool Definitions ---
TOOLS = [
    {
        "type": "function",
        "function": {
            "name": "calculator",
            "description": "Evaluate a mathematical expression. Use for any arithmetic.",
            "parameters": {
                "type": "object",
                "properties": {
                    "expression": {
                        "type": "string",
                        "description": "A Python mathematical expression, e.g., '2**10 + 3*4'"
                    }
                },
                "required": ["expression"]
            }
        }
    },
    {
        "type": "function",
        "function": {
            "name": "get_current_date",
            "description": "Get the current date and time.",
            "parameters": {
                "type": "object",
                "properties": {}
            }
        }
    }
]


# --- Tool Implementations ---
def calculator(expression: str) -> str:
    """Safely evaluate a mathematical expression."""
    try:
        # WARNING: In production, use a proper sandbox, not eval()
        allowed_names = {"__builtins__": {}}
        import math
        allowed_names.update({k: v for k, v in math.__dict__.items()
                              if not k.startswith('_')})
        result = eval(expression, allowed_names)
        return json.dumps({"result": result})
    except Exception as e:
        return json.dumps({"error": str(e)})


def get_current_date() -> str:
    """Return the current date and time."""
    from datetime import datetime
    return json.dumps({"date": datetime.now().isoformat()})


TOOL_REGISTRY = {
    "calculator": calculator,
    "get_current_date": get_current_date,
}


# --- The Agent Loop ---
def run_agent(user_query: str, max_iterations: int = 10) -> str:
    """
    Run the agent loop.

    The agent will:
    1. Receive the user's query
    2. Decide whether to use a tool or respond directly
    3. If using a tool, execute it and feed the result back
    4. Repeat until the agent produces a final response
    """
    messages = [
        {
            "role": "system",
            "content": (
                "You are a helpful assistant. You have access to tools. "
                "Use them when needed to provide accurate answers. "
                "Think step by step before answering."
            )
        },
        {"role": "user", "content": user_query}
    ]

    for iteration in range(max_iterations):
        print(f"\n--- Iteration {iteration + 1} ---")

        # Step 1: Call the LLM
        response = client.chat.completions.create(
            model=MODEL,
            messages=messages,
            tools=TOOLS,
            tool_choice="auto"  # Let the model decide
        )

        assistant_message = response.choices[0].message
        messages.append(assistant_message)

        # Step 2: Check if the agent wants to use tools
        if assistant_message.tool_calls:
            for tool_call in assistant_message.tool_calls:
                function_name = tool_call.function.name
                function_args = json.loads(tool_call.function.arguments)

                print(f"  Tool call: {function_name}({function_args})")

                # Step 3: Execute the tool
                if function_name in TOOL_REGISTRY:
                    result = TOOL_REGISTRY[function_name](**function_args)
                else:
                    result = json.dumps({"error": f"Unknown tool: {function_name}"})

                print(f"  Tool result: {result}")

                # Step 4: Feed the result back to the LLM
                messages.append({
                    "role": "tool",
                    "tool_call_id": tool_call.id,
                    "content": result
                })
        else:
            # No tool calls — the agent is done
            final_response = assistant_message.content
            print(f"\n  Final response: {final_response}")
            return final_response

    return "Agent reached maximum iterations without producing a final answer."


# --- Run the Agent ---
if __name__ == "__main__":
    # Example queries
    queries = [
        "What is 2^32 minus 1?",
        "What day is it today?",
        "If I invest $10,000 at 7% annual compound interest, how much will I have after 20 years?",
    ]

    for query in queries:
        print(f"\n{'='*60}")
        print(f"User: {query}")
        result = run_agent(query)
        print(f"\nAgent: {result}")

7.2 Análisis del bucle del agente línea por línea

Tracemos lo que sucede cuando un usuario pregunta: "Si invierto 10.000 $ al 7% de interés compuesto anual, cuánto tendré después de 20 años?"

Configuración (líneas en run_agent):

• La lista messages se inicializa con un prompt del sistema y la consulta del usuario. Esta es la "memoria de trabajo" del agente para esta tarea.
• El parámetro max_iterations es una válvula de seguridad: impide que el agente entre en un bucle infinito.

Iteración 1:

• El LLM recibe los mensajes y las definiciones de herramientas. Ve la herramienta calculadora y decide: "Necesito calcular interés compuesto. Debería usar la calculadora."
• Genera un tool_call con function_name="calculator" y arguments={"expression": "10000 * (1.07 ** 20)"}.
• Ejecutamos la calculadora: eval("10000 * (1.07 ** 20)") devuelve 38696.84.
• El resultado se añade a messages como respuesta de herramienta.

Iteracion 2:

• El LLM ahora ve la pregunta original Y el resultado de la calculadora.
• Decide que tiene suficiente información y genera una respuesta final en texto: "Después de 20 años al 7% de interés compuesto, su inversión de 10.000 $crecería hasta aproximadamente 38.696,84$."
• Como no hay llamadas a herramientas, el bucle termina.

El código demuestra varios principios fundamentales:

1. El bucle: El agente itera, llamando al LLM y ejecutando herramientas, hasta que produce una respuesta final sin llamadas a herramientas.

2. Selección de herramientas: El LLM decide qué herramienta usar (o no). Esta decisión se basa en el prompt del sistema, las descripciones de herramientas y la consulta del usuario. El parámetro tool_choice="auto" indica al modelo qué puede elegir usar herramientas o responder directamente.

3. Historial de mensajes: Cada llamada al LLM incluye el historial completo de la conversación, incluyendo los resultados de las llamadas a herramientas. Esto da al LLM contexto para razonar sobre lo que ya ha hecho.

4. Terminación: El bucle termina cuando el LLM produce una respuesta sin solicitar ninguna llamada a herramienta, o cuando se alcanza el conteó máximo de iteraciones (una medida de seguridad).

5. Manejo de errores: La consulta al TOOL_REGISTRY maneja el caso en que el modelo solicita una herramienta desconocida. En producción, se anadria un manejo de errores mucho más robusto.

7.3 Traza de un escenario con múltiples herramientas

Para construir una intuición más profunda, tracemos una consulta más compleja: "Qué día es hoy, y cuánto es 2 elevado al número del día de hoy?"

Iteración 1:

• El LLM ve la pregunta y las dos herramientas disponibles. Razona (implícitamente): "Primero necesito la fecha de hoy, luego puedo calcular."
• Genera una llamada a herramienta: get_current_date().
• Ejecutamos la herramienta: devuelve {"date": "2026-03-19T14:30:00"}.
• El resultado se añade a los mensajes.

Iteración 2:

• El LLM ahora ve la pregunta Y el resultado de la fecha. Extrae el número del día (19) y decide calcular.
• Genera una llamada a herramienta: calculator(expression="2**19").
• Ejecutamos la herramienta: devuelve {"result": 524288}.
• El resultado se añade a los mensajes.

Iteración 3:

• El LLM ahora ve la pregunta, la fecha y el resultado del cálculo. Tiene todo lo que necesita.
• Genera una respuesta final en texto: "Hoy es 19 de marzo de 2026. 2 elevado a la potencia de 19 (el número del día) es igual a 524.288."
• Sin llamadas a herramientas, así que el bucle termina.

Esta traza demuestra el uso secuencial de herramientas: la segunda llamada a herramienta dependía del resultado de la primera. El LLM gestionó esta dependencia implícitamente, sin ningún mecanismo de planificación explícita. Para dependencias simples como esta, el bucle básico funciona bien. Para cadenas de dependencia más complejas, necesitamos las arquitecturas cubiertas en la Semana 5.

7.4 Qué no puede hacer este agente (aún)

A este agente mínimo le faltan varias capacidades que los agentes de producción requieren:

• Memoria más allá de la conversación: No tiene memoria a largo plazo. Si le haces una pregunta en una ejecución, no recordará la respuesta en la siguiente. Cada invocación de run_agent() comienza desde cero.
• Planificación de múltiples pasos: Reacciona turno a turno en lugar de planificar con antelación. No piensa "Primero calcularé esto, luego buscaré aquello, luego combinaré los resultados." Solo toma la siguiente mejor acción en cada paso.
• Autorreflexion: No evalúa si sus respuestas son correctas. Si la calculadora devolviera un resultado erróneo (por una expresión incorrecta), el agente no lo detectaría. Confía completamente en sus herramientas.
• Recuperación de errores: Si una herramienta falla, puede no recuperarse de forma elegante. Un agente de producción debería reintentar con diferentes parámetros o probar un enfoque alternativo.
• Ejecución paralela de herramientas: Procesa las herramientas secuencialmente. Si necesita tres datos independientes, los obtiene uno a la vez, aunque podrían obtenerse simultáneamente.
• Conciencia de costés: El agente no registra cuántos tokens ha usado ni cuánto está costando la tarea. Un agente de producción necesita controles de presupuesto.

Abordaremos cada una de estas limitaciones en semanas posteriores de este curso: estrategias de prompting para mejor razonamiento (Semana 3), uso de herramientas y MCP (Semana 4), arquitecturas de agentes para planificación y reflexión (Semana 5), y sistemas de memoria (Semana 7).

7.5 De mínimo a producción: la brecha

La brecha entre nuestro agente mínimo y un agente de producción es significativa. Para dárte una idea de lo que manejan los agentes de producción, aquí tienes una lista no exhaustiva de preocupaciones:

Construir agentes de producción es una disciplina de ingeniería, no solo un ejercicio de prompting. Este curso te equipará con los conceptos y patrones necesarios para cerrar esta brecha.

Pruébalo tú: Ejecuta el código del agente (o adaptalo para la API de Anthropic). Prueba estas consultas y observa el comportamiento del agente: (1) "Cuál es la raíz cuadrada de 144?" (Usa la calculadora para algo que podría calcular directamente?) (2) "Cuál es el sentido de la vida?" (Intenta usar una herramienta cuando ninguna es apropiada?) (3) "Calcula 2+2, luego dime que día es hoy" (Llama a ambas herramientas?)

098. Consideraciones éticas y preguntas abiertas

La ética en el diseño de agentes de IA no es un añadido o una casilla qué marcar; está entretejida en cada decisión de diseño. Cuando eliges cuánta autonomía dar a un agente, estás tomando una decisión ética. Cuando decides a qué datos puede acceder el agente, estás tomando una decisión de privacidad. Cuando despliegas un agente qué toma decisiones con consecuencias, estás tomando una decisión de equidad. Esta sección introduce las dimensiones éticas clave qué recurrirán a lo largo del curso.

8.1 Autonomía y control

A medida que los agentes se vuelven más capaces, surge una tensión fundamental: autonomía vs. control. Agentes más autónomos pueden lograr más, pero también son más difíciles de supervisar y pueden tomar acciones inesperadas.

Consideremos este escenario concreto: pides a un agente de programación que "limpie el repositorio". Un agente cauteloso podría renombrar algunos archivos y actualizar imports. Un agente más agresivo podría eliminar archivos que considera innecesarios, refactorizar grandes secciones de código y reescribir el README. Ambas interpretaciones son válidas, pero una podría destruir trabajo que querías conservar.

Preguntas clave:

• Cuánta autonomía deberíamos otorgar a un agente de IA?
• Que acciones deberían requerir siempre aprobación humana? (Eliminar archivos? Enviar correos? Hacer compras?)
• Cómo diseñamos sistemas efectivos de "humano en el bucle" que no se conviertan en cuellos de botella?
• Cuál debería ser la opción por defecto: opt-in (el agente no hace nada sin permiso) u opt-out (el agente hace todo a menos que se le diga que pare)?

Claude Code proporciona un ejemplo práctico: puede leer archivos y editar código libremente, pero pide permiso antes de ejecutar comandos de shell. Este es un compromiso pragmático entre autonomía y seguridad: las operaciones de lectura son seguras; las operaciones de escritura necesitan verificación; las operaciones destructivas necesitan aprobación explícita.

8.2 Responsabilidad

Cuando un agente comete un error, digamos que un agente de programación introduce una vulnerabilidad de seguridad, o un agente de investigación cita un artículo inexistente, quién es responsable? El desarrollador que construyó el agente? El usuario que le dio instrucciones? La empresa detrás del LLM?

Esta no es una pregunta hipotética. A medida que los agentes asumen tareas de mayor importancia (revisión de documentos legales, recomendaciones médicas, gestión de carteras financieras), la cuestión de la responsabilidad se vuelve urgente. Los marcos legales actuales no fueron diseñados para agentes de IA autónomos, y la industria sigue debatiendo cómo asignar la responsabilidad.

8.3 Transparencia

Los usuarios qué interactúan con agentes deben comprender:

• Qué están interactuando con un sistema de IA (no con un humano)
• Qué capacidades tiene el agente (y qué no puede hacer)
• Qué limitaciones existen (fechas de corte del conocimiento, potencial de errores)
• A qué datos puede acceder el agente (implicaciones de privacidad)

La transparencia también es importante para la depuración y la confianza. Cuando un agente toma una acción inesperada, el desarrollador (e idealmente el usuario) debería poder rastrear por qué. Esta es una de las razones por las que la arquitectura ReAct (Semana 5) es tan popular: las trazas explícitas de razonamiento hacen que las decisiones del agente sean inspeccionables.

8.4 Sesgo y equidad

Los agentes basados en LLM heredan los sesgos de sus datos de entrenamiento y las decisiones de diseño de sus creadores. Un agente que filtra solicitudes de empleo, modera contenido o hace recomendaciones lleva estos sesgos a decisiones con consecuencias.

Por ejemplo, un agente de investigación encargado de "encontrar artículos influyentes" podría favorecer sistemáticamente artículos de instituciones prestigiosas o de revistas en inglés, no porque fuera programado explícitamente para hacerlo, sino porque sus datos de entrenamiento reflejan los sesgos existentes en la publicación académica.

Idea clave: Los agentes amplifican sesgos a través de su capacidad de acción. Un modelo de lenguaje sesgado genera texto sesgado; un agente sesgado ejecuta acciones sesgadas. Las implicaciones son fundamentalmente diferentes. Por eso el diseño responsable de agentes requiere no solo buenos modelos, sino arquitectura reflexiva, diseño cuidadoso de herramientas y evaluación robusta.

109. Preguntas de discusión

1. Agente vs. herramienta: Considera un corrector ortográfico y un asistente de escritura con IA. En que punto una herramienta se convierte en agente? Que características exigirías antes de llamar a un sistema "agente"?

   Punto de partida para la reflexión: Considera el espectro desde una herramienta tipo Grammarly (corrige errores mientras escribes) hasta un sistema que reescribe párrafos enteros, sugiere cambios estructurales y mantiene su propia comprensión de los objetivos de tu documento. En que punto de este espectro comienza la "agencia"?

2. Espectro de autonomía: Claude Code pide permiso antes de ejecutar comandos destructivos. OpenAI Operator se detiene cuándo encuentra una página de pago. Qué principios deberían guiar las decisiones sobre cuándo los agentes deben actuar autónomamente y cuándo pedir permiso?

   Punto de partida: Piensa en la "reversibilidad" de las acciones. Se puede deshacer la acción? Si es así, más autonomía podría ser aceptable. Si no (enviar un correo, eliminar datos), la supervisión humana se vuelve más importante.

3. Correspondencia con Russell y Norvig: Dónde encajan los agentes modernos basados en LLM como Claude Code en la taxonomía de Russell y Norvig? Son agentes basados en objetivos? Basados en utilidad? Agentes con aprendizaje? Podrían ser todos estos a la vez?

   Punto de partida: Considera que Claude Code mantiene un modelo interno (del código fuente), persigue objetivos (corregir errores, implementar funcionalidades) y adapta su enfoque basándose en retroalimentación (resultados de pruebas, mensajes de error). Encaja limpiamente en una sola categoría?

4. Consecuencias imprevistas: La historia del chatbot Tay de Microsoft (2016) demostró cómo un agente interactuando con un entorno hostil puede ir rápidamente por mal camino. Qué salvaguardas diseñaras para un agente que opera en internet abierto?

   Punto de partida: Considera la validación de entradas, el filtrado de salidas, las restricciones de acciones, la limitación de tasa y la monitorización. Cuál de estas habría prevenido el incidente de Tay?

5. Perspectiva histórica: Los sistemas expertos requerían ingeniería explícita del conocimiento. Los agentes basados en LLM aprenden de datos. Cuáles son las ventajas y desventajas de cada enfoque? Hay casos donde los sistemas expertos aún podrían ser preferibles?

   Punto de partida: Piensa en dominios donde los errores son extremadamente costosos (diagnóstico médico, control de centrales nucleares). Confiarías en un agente basado en LLM o en un sistema experto con reglas rigurosamente probadas? Por qué?

1110. Resumen y conclusiones clave

1. Un agente de IA percibe su entorno, razona sobre él y ejecuta acciones para alcanzar objetivos. El bucle de percepción-acción es él patrón fundamental.

2. La trayectoria histórica desde los sistemas expertos hasta los agentes basados en LLM representa un cambio de la ingeniería manual del conocimiento al razonamiento aprendido de propósito general. Cada generación abordó las limitaciones de la anterior.

3. La taxonomía de Russell y Norvig (reflejo simple, basado en modelo, basado en objetivos, basado en utilidad, con aprendizaje) proporciona un marco útil para comprender las capacidades de los agentes, aunque los agentes modernos basados en LLM a menudo difuminan los límites entre categorías.

4. Los agentes basados en LLM usan un modelo de lenguaje de gran escala como núcleo de razonamiento, complementado con cuatro componentes clave: planificación (descomposición de tareas), memoria (almacenamiento y recuperación de información), uso de herramientas (interacción con sistemas externos) y acción (ejecución de decisiones).

5. El bucle del agente (percibir, razonar, actuar, observar, repetir) es simple en estructura pero rico en detalles de implementación. Incluso un agente mínimo requiere un manejo cuidadoso de la selección de herramientas, la recuperación de errores y la terminación.

6. Los agentes reales en 2025-2026 incluyen agentes de programación (Claude Code, Cursor, Devin), agentes de investigación (Elicit), agentes web (Computer Use, Operator) y sistemas multiagente (ChatDev, AutoGen).

7. Las consideraciones éticas sobre autonomía, responsabilidad, transparencia y sesgo no son preocupaciones secundarias; son centrales para el diseño responsable de agentes y solo cobrarán más importancia a medida que los agentes asuman tareas de mayor trascendencia.

1211. Ejercicio práctico

Construye tu primer agente: Usando la plantilla de código proporcionada en la Sección 7, extiende el agente mínimo con lo siguiente:

1. Añade una tercera herramienta: read_file(filepath) que lea el contenido de un archivo de texto. Incluye manejo de errores adecuado (archivo no encontrado, permiso denegado) y una comprobación de seguridad (restringir a un directorio específico para impedir que el agente lea archivos arbitrarios).

2. Modifica el prompt del sistema para dar al agente una persóna específica (por ejemplo, "Eres un asistente de enseñanza para un curso de Informática"). Observa como la persóna afecta a las respuestas del agente y a los patrones de uso de herramientas.

3. Prueba el agente con tres consultas diferentes que ejerciten distintas herramientas. Documenta lo que el agente hace en cada paso.

4. Prueba escenarios con múltiples herramientas: Dale al agente una consulta que requiera múltiples llamadas a herramientas en secuencia (por ejemplo, "Lee el archivo data.txt y calcula la media de los números que contiene"). Documenta:

   • Cuántas iteraciones del bucle del agente se necesitan
   • Qué llamadas a herramientas hace el agente y en qué orden
   • Si el razonamiento del agente (cuándo es visible) es correcto
   • Cualquier fallo o comportamiento inesperado

5. Reflexiona sobre las limitaciones: Después de las pruebas, escribe un párrafo sobre lo que el agente hace bien y con qué tiene dificultades. Que cambiarías para hacerlo más fiable?

Entregable: Un script de Python y un informe breve (1-2 páginas) describiendo el comportamiento del agente y cualquier limitación observada.

13Referencias

• Brooks, R. A. (1986). A robust layered control system for a mobile robot. IEEE Journal on Robotics and Automation, 2(1), 14-23.
• Jumper, J., Evans, R., Pritzel, A., Green, T., Figurnov, M., Ronneberger, O., ... & Hassabis, D. (2021). Highly accurate protein structure prediction with AlphaFold. Nature, 596(7873), 583-589.
• Mnih, V., Kavukcuoglu, K., Silver, D., Rusu, A. A., Veness, J., Bellemare, M. G., ... & Hassabis, D. (2015). Human-level control through deep reinforcement learning. Nature, 518(7540), 529-533.
• Park, J. S., O'Brien, J. C., Caí, C. J., Morris, M. R., Liang, P., & Bernstein, M. S. (2023). Generative agents: Interactive simulacra of human behavior. In Proceedings of the 36th Annual ACM Symposium on User Interface Software and Technology (UIST).
• Qian, C., Liu, W., Liu, H., Chen, N., Dang, Y., Li, J., ... & Sun, M. (2024). ChatDev: Communicative agents for software development. In Proceedings of the 62nd Annual Meeting of the ACL.
• Rao, A. S., & Georgeff, M. P. (1995). BDI agents: From theory to practice. In Proceedings of the First International Conference on Multiagent Systems (ICMAS).
• Russell, S., & Norvig, P. (2021). Artificial Intelligence: A Modern Approach (4th ed.). Pearson.
• Schick, T., Dwivedi-Yu, J., Dessi, R., Raileanu, R., Lomeli, M., Hambro, E., ... & Scialom, T. (2023). Toolformer: Language models can teach themselves to use tools. In Advances in Neural Information Processing Systems (NeurIPS).
• Silver, D., Huang, A., Maddison, C. J., Guez, A., Sifre, L., van den Driessche, G., ... & Hassabis, D. (2016). Mastering the game of Go with deep neural networks and tree search. Nature, 529(7587), 484-489.
• Wang, L., Ma, C., Feng, X., Zhang, Z., Yang, H., Zhang, J., ... & Wang, J. (2024). A survey on large language model based autonomous agents. Frontiers of Computer Science, 18(6), 186345.
• Wei, J., Wang, X., Schuurmans, D., Bosma, M., Ichter, B., Xia, F., ... & Zhou, D. (2022). Chain-of-thought prompting elicits reasoning in large language models. In Advances in Neural Information Processing Systems (NeurIPS).
• Wu, Q., Bansal, G., Zhang, J., Wu, Y., Li, B., Zhu, E., ... & Wang, C. (2023). AutoGen: Enabling next-gen LLM applications vía multi-agent conversation. arXiv preprint arXiv:2308.08155.
• Yang, J., Jiménez, C. E., Wettig, A., Liber, K., Narasimhan, K., & Press, O. (2024). SWE-agent: Agent-computer interfaces enable automated software engineering. In Advances in Neural Information Processing Systems (NeurIPS).
• Yao, S., Zhao, J., Yu, D., Du, N., Shafran, I., Narasimhan, K., & Cao, Y. (2023). ReAct: Synergizing reasoning and acting in language models. In Proceedings of the International Conference on Learning Representations (ICLR).

Parte de "IA Agentica: Fundamentos, Arquitecturas y Aplicaciones" (CC BY-SA 4.0).