¿Por Qué Agentes?

De chatbot a agente: ¿Cuál es la diferencia?

Un chatbot genera texto. Escribes una pregunta, el modelo produce una respuesta y la interacción termina. Eso es todo lo que hace un chatbot: mapea una cadena de entrada a una cadena de salida, por más impresionante que sea. Un agente , por el contrario, realiza acciones . No solo te dice la respuesta — va y hace cosas. Busca en la web, ejecuta código, lee archivos, llama a APIs y toma decisiones basadas en los resultados. El cambio de chatbot a agente es el cambio de un modelo que habla sobre el mundo a un modelo que actúa en él.

La distinción arquitectónica clave es que un agente tiene un bucle . La interacción con un chatbot es de una sola pasada: el usuario pregunta, el modelo responde, fin. La interacción con un agente es iterativa: el usuario hace una pregunta, el modelo piensa qué hacer, llama a una herramienta, lee el resultado, piensa de nuevo, quizás llama a otra herramienta, lee ese resultado y continúa hasta completar la tarea. Considera la diferencia entre preguntar "¿Cuál es el clima en Tokio?" a un chatbot (que solo puede adivinar basándose en sus datos de entrenamiento, y esos datos tienen meses de antigüedad) versus hacer la misma pregunta a un agente (que llama a una API del clima, lee la respuesta JSON y te da la temperatura actual real). El chatbot genera texto sobre el clima; el agente consulta el clima.

Este bucle es lo que hace a los agentes tanto poderosos como peligrosos. Como el agente puede encadenar secuencias arbitrarias de acciones — buscar, luego leer, luego calcular, luego escribir, luego verificar — puede realizar tareas que ninguna llamada única al modelo podría manejar. Pero también significa que el agente puede tomar acciones inesperadas, acumular errores entre pasos o entrar en bucles improductivos. Un chatbot puede alucinar una respuesta incorrecta; un agente puede alucinar una respuesta incorrecta y luego actuar en consecuencia . Abordaremos la seguridad y la evaluación en el artículo final de este track, pero vale la pena señalar lo que está en juego desde el principio: la agencia amplifica tanto la capacidad como el riesgo.

El bucle del agente

Todo agente, sin importar cuán sofisticado sea, ejecuta el mismo bucle fundamental. Ya sea un asistente de programación que edita archivos, un agente de investigación que busca en la web o un bot de servicio al cliente que consulta bases de datos y emite reembolsos, el patrón es idéntico:

• Observar: recibir entrada. Puede ser la consulta original del usuario, el resultado de una llamada a herramienta, un mensaje de error o cualquier información nueva del entorno.
• Razonar: decidir qué hacer a continuación. El LLM examina el estado actual — qué se ha preguntado, qué se ha intentado, qué se ha aprendido — y elige una acción. Puede ser llamar a una herramienta específica con argumentos específicos, o decidir que se ha reunido suficiente información y es momento de responder al usuario.
• Actuar: ejecutar la acción elegida. Llamar a una función, ejecutar un fragmento de código, enviar una solicitud API, hacer clic en un botón en un navegador o escribir en un archivo.
• Observar de nuevo: ver el resultado de la acción. ¿La API devolvió datos? ¿El código lanzó un error? ¿La escritura del archivo fue exitosa?
• Repetir: volver al paso de razonamiento con la nueva observación y continuar hasta que la tarea esté completa o se cumpla una condición de parada (como un número máximo de iteraciones, para evitar bucles infinitos).

Si esto te recuerda al bucle observar-decidir-actuar del aprendizaje por refuerzo y la robótica, no es coincidencia. La estructura es la misma — una entidad percibe su entorno, toma una decisión, ejecuta una acción y observa el resultado — excepto que aquí el "cerebro" es un LLM en lugar de una red de políticas, y el "entorno" es el mundo digital (APIs, archivos, bases de datos, sitios web) en lugar de uno físico. La fortaleza del LLM es que puede manejar el paso de razonamiento en lenguaje natural, haciéndolo lo suficientemente flexible para trabajar en tareas muy diferentes sin entrenamiento específico para cada tarea.

De manera crucial, el agente tiene acceso a un conjunto de herramientas — funciones que puede llamar. Cada herramienta tiene un nombre, una descripción y un esquema que define sus parámetros. El LLM decide qué herramienta llamar y con qué argumentos basándose en el estado actual de la conversación. Las herramientas son lo que conecta al modelo con el mundo exterior. Sin herramientas, el LLM es solo un generador de texto; con herramientas, se convierte en un agente. El pseudocódigo a continuación muestra el bucle principal:

def agent_loop(user_query, tools, llm, max_steps=10):
    """The fundamental agent loop."""
    messages = [{"role": "user", "content": user_query}]

    for step in range(max_steps):
        # REASON: LLM decides what to do next
        response = llm.generate(messages, tools=tools)

        # If the LLM wants to respond to the user (no tool call), we're done
        if response.type == "text":
            return response.content

        # ACT: execute the tool the LLM chose
        tool_name = response.tool_call.name
        tool_args = response.tool_call.arguments
        tool_result = tools[tool_name].execute(**tool_args)

        # OBSERVE: add the tool result to the conversation
        messages.append({"role": "assistant", "content": response})
        messages.append({"role": "tool", "content": tool_result})

        # Loop back to REASON with the new observation

    return "Max steps reached without a final answer."

Observa lo simple que es. Toda la inteligencia reside en la capacidad del LLM de examinar el historial de la conversación (que ahora incluye resultados de herramientas) y decidir qué hacer a continuación. El bucle en sí es una simple conexión. Sin embargo, esta simplicidad es engañosa: los problemas difíciles están en los detalles. ¿Cómo sabe el LLM qué herramienta llamar? ¿Cómo defines las herramientas para que el LLM pueda usarlas de manera confiable? ¿Qué pasa cuando falla una llamada a herramienta? ¿Cómo evitas que el agente se descarrile? Estas son las preguntas que el resto de este track responderá.

¿Qué pueden hacer los agentes que los chatbots no?

El bucle del agente desbloquea categorías enteras de capacidad que son simplemente imposibles para un modelo de generación de texto puro. Comprender estas categorías ayuda a clarificar por qué los agentes valen la complejidad añadida.

Acceder a información en tiempo real. El conocimiento de un chatbot está congelado en el momento del entrenamiento (como discutimos en el track de RAG ). Un agente puede buscar en la web, consultar una base de datos o llamar a una API para obtener información de hace segundos. "¿Cuál es el precio actual de las acciones de NVIDIA?" es una pregunta que un chatbot solo puede responder con datos desactualizados, pero un agente puede llamar a una API de bolsa y devolver el precio en vivo.

Tomar acciones en el mundo. Esta es la diferencia más trascendental. Un chatbot puede describir cómo enviar un correo electrónico; un agente puede enviar el correo electrónico. Un chatbot puede explicar cómo corregir un bug; un agente puede abrir el archivo, editar el código, ejecutar las pruebas y hacer commit de la corrección. La brecha entre "esto es lo que podrías hacer" y "está hecho" es enorme en la práctica, y los agentes la cierran.

Usar herramientas especializadas. Los LLMs son malos en aritmética, tienen dificultades con cálculos precisos de fechas y no pueden generar imágenes de forma nativa. Pero un agente con acceso a una herramienta de calculadora, una API de calendario y un modelo de generación de imágenes puede manejar todo esto correctamente. El LLM no necesita ser bueno en todo — solo necesita ser bueno en decidir qué herramienta usar y cómo usarla . Esta es una forma de división cognitiva del trabajo: el LLM maneja el razonamiento y el lenguaje, mientras que las herramientas especializadas manejan dominios donde la precisión importa.

Razonamiento de múltiples pasos con recuperación de errores. Las tareas reales rara vez se completan en un solo paso. "Resérvame un vuelo de NYC a Londres por menos de $500" requiere buscar vuelos, comparar precios, filtrar por presupuesto, seleccionar la mejor opción y completar la reserva — con posibles fallos en cada paso (no hay vuelos disponibles, el precio cambió, el pago fue rechazado). Un agente puede dividir esto en subtareas, manejar cada una y recuperarse de errores intentando enfoques alternativos. Un chatbot solo puede darte una única respuesta y esperar que cubra todo.

Mantener estado entre acciones. Como el bucle del agente acumula resultados de herramientas en el historial de la conversación, el agente recuerda lo que ha hecho, lo que ha aprendido y lo que falta. Puede evitar repetir trabajo, construir sobre resultados anteriores y rastrear el progreso hacia un objetivo. "Encuentra todos los bugs en este código base y corrígelos" requiere leer archivos, identificar problemas, editar código, ejecutar pruebas, verificar resultados e iterar — un proceso con estado que puede abarcar docenas de pasos.

Las tres eras de capacidad de los LLM

Para entender por qué los agentes están surgiendo ahora y no hace cinco años, es útil observar cómo las capacidades de los LLM han evolucionado en tres eras distintas. Cada era se construyó sobre la anterior, y la era de los agentes requirió específicamente capacidades que no existían antes de 2023.

Era 1: Generación de texto (GPT-3, 2020). Los primeros modelos de lenguaje grandes podían generar texto notablemente coherente, completar prompts e incluso realizar aprendizaje con pocos ejemplos. Pero no tenían ningún mecanismo para interactuar con el mundo exterior. Podían escribir un párrafo convincente sobre el clima, pero no podían consultar el clima. Podían producir código de apariencia plausible, pero no podían ejecutarlo. El mundo entero del modelo era el texto con el que había sido entrenado, y todo lo que podía hacer era producir más texto en la misma distribución.

Era 2: Seguimiento de instrucciones (ChatGPT, 2022). Con RLHF y ajuste de instrucciones, los modelos aprendieron a seguir instrucciones del usuario, mantener conversaciones coherentes de múltiples turnos, rechazar solicitudes dañinas y formatear salidas de maneras específicas. Esto fue una mejora masiva de usabilidad — convirtió generadores de texto en bruto en asistentes útiles — pero la limitación fundamental permaneció: el modelo solo podía producir texto. Podía explicar cómo hacer las cosas, pero no podía hacerlas.

Era 3: Uso de herramientas y agencia (2023–presente). Esta es la era en la que estamos ahora. Los modelos pueden llamar funciones, usar herramientas y tomar acciones de múltiples pasos en el mundo real. Un usuario dice "encuentra el vuelo más barato a Londres el próximo martes" y el modelo no solo describe lo que necesitarías hacer — llama a una API de búsqueda de vuelos, analiza los resultados, compara precios y te da la respuesta (o lo reserva, si se le da permiso). Esto no es una mejora menor; es un cambio cualitativo en para qué se pueden usar los LLMs.

¿Qué habilitó la Era 3? Varios desarrollos tuvieron que converger:

• Entrenamiento en llamadas a funciones: los modelos tuvieron que aprender a producir llamadas estructuradas a herramientas (no solo texto libre) durante el post-entrenamiento. Esto requirió nuevos formatos de datos de entrenamiento, nuevas funciones de pérdida y un cuidadoso fine-tuning para enseñar a los modelos cuándo y cómo invocar herramientas.
• Mejor razonamiento: los agentes necesitan planificar acciones de múltiples pasos, lo que requiere razonamiento en cadena de pensamiento y capacidades de pensamiento extendido. Los modelos tempranos no podían decidir de manera confiable qué herramienta llamar o qué argumentos pasar; los modelos más nuevos pueden razonar a través de secuencias complejas de acciones antes de ejecutarlas.
• Infraestructura: los agentes necesitan entornos de ejecución aislados, sistemas de permisos y protocolos estandarizados para conectarse a herramientas. El Model Context Protocol (MCP), que cubriremos en el artículo 4, es uno de esos protocolos que permite a cualquier modelo conectarse a cualquier herramienta a través de una interfaz estandarizada.
• Ventanas de contexto más largas: los agentes acumulan información a lo largo de una tarea — la consulta original, cada llamada a herramienta y su resultado, trazas de razonamiento, mensajes de error. Una interacción de agente de 10 pasos puede consumir decenas de miles de tokens. Los modelos tempranos con ventanas de contexto de 2K–4K no podían sostener bucles de agente de múltiples pasos; los modelos modernos con ventanas de 128K–1M tokens sí pueden.

Dos artículos fundacionales establecieron el caso de los LLMs que usan herramientas. ReAct (Yao et al., 2023) mostró que intercalar trazas de razonamiento ("Necesito buscar X porque...") con acciones ("Search[X]") mejoró drásticamente el rendimiento en tareas de múltiples pasos comparado con razonar o actuar solos. La idea clave fue que el razonamiento ayuda al modelo a planificar e interpretar resultados, mientras que las acciones fundamentan el razonamiento en información real. Toolformer (Schick et al., 2023) demostró que los modelos de lenguaje pueden aprender a usar herramientas (calculadoras, motores de búsqueda, traductores) de manera auto-supervisada: el modelo decide cuándo y dónde insertar llamadas a herramientas en su propio texto, entrenado con ejemplos donde el uso de herramientas mejoró la precisión de predicción. Juntos, estos artículos establecieron que los LLMs no son solo generadores de texto — pueden ser razonadores que usan herramientas.

El resto de este track

Este track cubre el panorama completo de los agentes LLM, desde el mecanismo de bajo nivel que hace posible el uso de herramientas hasta las arquitecturas de alto nivel que coordinan múltiples agentes en tareas complejas. Esto es lo que viene:

• Artículo 2: Llamadas a funciones. El mecanismo que permite a los LLMs usar herramientas. Cómo los modelos aprenden a producir llamadas estructuradas a herramientas, cómo defines esquemas de herramientas y cómo funciona la conexión de la API de principio a fin.
• Artículo 3: ReAct y bucles de razonamiento. Cómo los agentes deciden qué hacer. El framework ReAct, la planificación con cadena de pensamiento y los patrones que hacen que el razonamiento del agente sea confiable (o no confiable).
• Artículo 4: MCP (Model Context Protocol). El protocolo que conecta agentes a herramientas a escala. Cómo MCP estandariza la interfaz entre modelos y herramientas, habilitando un ecosistema plug-and-play.
• Artículo 5: Uso de computadora. Agentes que interactúan con interfaces gráficas de usuario — haciendo clic en botones, llenando formularios, navegando sitios web. Cómo los modelos de visión-lenguaje permiten a los agentes usar software de la misma manera que los humanos.
• Artículo 6: Agentes de código. Claude Code, Codex CLI, Devin y la generación de agentes que escriben, depuran y despliegan software. Cómo funcionan, qué pueden hacer y dónde fallan.
• Artículo 7: Sistemas multiagente. Cuando un solo agente no es suficiente. Arquitecturas para coordinar múltiples agentes especializados, incluyendo patrones de supervisor, debate y enfoques de enjambre.
• Artículo 8: Seguridad, evaluación y la frontera. Cómo evaluar agentes, evitar que se descarrilen y cómo luce la vanguardia.

Cada artículo se construye sobre los anteriores, pero también están diseñados para ser legibles de forma independiente si te interesa un tema específico. Si quieres entender cómo funcionan las llamadas a funciones internamente, puedes ir directamente al artículo 2. Si estás construyendo un sistema multiagente y quieres entender patrones de coordinación, el artículo 7 será el más relevante.

Quiz

Pon a prueba tu comprensión de lo que diferencia a los agentes de los chatbots.