flowchart TD
subgraph flujo["Flujo de trabajo"]
direction LR
a1["Paso 1"] --> a2["Paso 2"] --> a3["Paso 3"]
end
subgraph agente["Agente"]
direction LR
b1["Modelo"] --> b2["Herramienta"]
b2 --> b1
b1 --> b3["¿Termino?"]
b3 -->|no| b1
end
classDef control fill:#d7eddc,stroke:#4a9463,stroke-width:1.5px,color:#1c4a2e
classDef modelo fill:#e6ddf5,stroke:#7457bd,stroke-width:1.5px,color:#332757
classDef herramienta fill:#fae3c8,stroke:#bf7f28,stroke-width:1.5px,color:#573809
class a1,a2,a3 control
class b1,b3 modelo
class b2 herramienta
10 Qué es un agente
Pocos términos se han desgastado tan rápido. En 2026 se llama agente a un chatbot con un botón, a un flujo con tres llamadas encadenadas y a un sistema autónomo que abre incidencias en producción. Conviene una definición que sirva para decidir cosas.
La más operativa que conozco es la de Anthropic, y se apoya en quién manda (Anthropic 2024):
- Un flujo de trabajo (workflow) es un sistema donde los pasos y las llamadas al modelo están escritos por nosotros en el código. El modelo rellena huecos; el camino lo decidimos nosotros.
- Un agente es un sistema donde el modelo decide qué hacer a continuación y cuándo parar, usando herramientas en un bucle.
La diferencia no es de sofisticación, es de quién tiene el control del flujo. Y de ahí se derivan casi todas las consecuencias prácticas: lo que cuesta, lo que tarda, lo que se puede probar y lo que puede salir mal.
ImportanteLa recomendación menos comercial del sector
La misma gente que fabrica y vende modelos para construir agentes insiste en lo mismo: usad la solución más simple que funcione, y muchas veces eso es una sola llamada al modelo.
Un agente introduce no determinismo, coste variable, latencia variable y una superficie de fallo mucho mayor. Solo compensa cuando el problema exige decidir sobre la marcha: cuando el número de pasos depende de lo que se vaya encontrando y no se puede escribir de antemano.
Si podéis dibujar el diagrama de flujo completo, escribid el diagrama de flujo. Será más barato, más rápido, más fácil de probar y podréis explicar por qué hizo lo que hizo.
10.1 El bucle
Todo agente, por debajo de cualquier framework, es este bucle:
- Se le da un objetivo y una lista de herramientas disponibles.
- El modelo decide: o responde, o pide ejecutar una herramienta con unos argumentos.
- Nuestro código ejecuta la herramienta y devuelve el resultado al contexto.
- Vuelta al punto 2 hasta que el modelo responda o se acabe el presupuesto.
El patrón se formalizó como ReAct, razonar y actuar alternadamente (Yao et al. 2023), y hoy está incorporado de serie en los modelos, que se entrenan específicamente para producir llamadas a herramientas.
Merece la pena subrayar el punto 3, porque desmonta un malentendido habitual: el modelo no ejecuta nada. Emite una petición estructurada de que se ejecute algo. Quien ejecuta es nuestro código, en nuestra infraestructura, con nuestros permisos. Eso es una excelente noticia para la seguridad, porque significa que el punto de control existe y está de nuestro lado: la lista de herramientas y sus permisos son un límite duro, no una sugerencia. Todo lo que no esté en esa lista, el agente no lo puede hacer.
10.2 Anatomía
Con el bucle claro, un agente tiene cinco piezas y ninguna es opcional:
| Pieza | Qué es | Dónde se trata |
|---|---|---|
| Modelo | El que decide | Panorama |
| Instrucciones | Objetivo, criterio y límites | Prompting |
| Herramientas | Lo que puede hacer | Herramientas |
| Memoria | Qué recuerda entre pasos y entre sesiones | Memoria |
| Límites | Cuándo para, cuánto gasta, qué necesita aprobación | Este capítulo |
TipSi preferís verlo dibujado
Este manual explica con prosa y con diagramas sueltos. Quien aprenda mejor con ilustraciones tiene la Visual Guide to LLM Agents de Maarten Grootendorst (Grootendorst 2025), que recorre lo mismo en viñetas y organiza el asunto en tres pilares en lugar de cinco piezas: memoria, herramientas y planificación.
La equivalencia con esta parte del manual es casi directa, y viene bien como mapa:
| Su pilar | Nuestro capítulo |
|---|---|
| Memoria, a corto y a largo plazo | Memoria |
| Herramientas y MCP | Herramientas |
| Planificación, ReAct y reflexión | El bucle, aquí arriba |
| Sistemas multiagente | Orquestación |
Un aviso sobre su reparto de la memoria en semántica, episódica y de procedimiento, tomado de la psicología: es una taxonomía cómoda para pensar y no una arquitectura que haya que implementar tal cual. Casi todos los sistemas que funcionan tienen bastante menos de eso.
10.3 Los límites no son un detalle
Un bucle cuya condición de parada la decide un modelo probabilístico es, dicho suavemente, un bucle sin condición de parada garantizada. Hay que ponerla desde fuera, y desde el primer día:
- Máximo de iteraciones. Un tope duro. Cuando salta, se para y se avisa.
- Presupuesto de tokens y de tiempo. Por tarea, no por llamada.
- Detección de repetición. El fallo más común de un agente atascado no es explotar, es llamar tres veces a la misma herramienta con los mismos argumentos y seguir tan tranquilo.
- Aprobación humana para lo irreversible. Enviar un correo, borrar un registro, mover dinero. La distinción relevante no es leer o escribir, es reversible o no.
AdvertenciaEl coste no es lineal, es cuadrático
En cada vuelta del bucle, el contexto entero, incluidos todos los resultados de herramientas anteriores, se vuelve a enviar. Un agente que da diez vueltas no cuesta diez veces una llamada: cuesta bastante más, porque cada vuelta arrastra todo lo anterior.
Es la razón práctica por la que los agentes que “casi funcionan” salen tan caros. Y también la razón por la que la compresión del contexto deja de ser un refinamiento y pasa a ser un requisito.
10.4 Cuándo sí
Después de tanta advertencia, conviene decir dónde está funcionando de verdad. El patrón común de los casos que salen bien es que el resultado se puede verificar:
- Programación asistida. El código compila, los tests pasan o no pasan. El agente tiene una señal objetiva para corregirse. No es casualidad que sea el caso de uso más maduro con diferencia.
- Investigación y síntesis. Buscar en muchas fuentes, cruzar y redactar con citas. El número de búsquedas no se puede saber de antemano, así que aquí el bucle es genuinamente necesario.
- Triage y enrutado. Leer una incidencia, consultar sistemas, clasificar y proponer. Con la actuación final supervisada.
- Operaciones sobre datos. Explorar un esquema, escribir consultas, comprobar los resultados y afinar.
Y donde sale mal, con la misma regularidad: tareas largas sin señal de verificación intermedia, con muchos pasos irreversibles, o donde un error silencioso cuesta caro. Ahí el bucle amplifica el error en lugar de corregirlo, porque cada paso construye sobre el anterior sin nada que le diga que va mal.
NotaEl 95% que no llega a producción
Los estudios de adopción de 2025 y 2026 coinciden con machaconería en que la enorme mayoría de los pilotos de IA generativa en empresa no produce impacto medible. Vale la pena entender por qué, porque las razones casi nunca son las que uno esperaría.
No suele ser el modelo. Suele ser que nadie definió qué significaba que funcionase, que no había forma de medirlo, que el proceso al que se acoplaba no se rediseñó, o que el sistema funcionaba el 80% de las veces y ese 20% restante era precisamente el que justificaba el proyecto.
De ahí que la mitad de este manual hable de evaluación, observabilidad y gobierno. No por prudencia, sino porque es ahí donde se decide.
10.5 El cuaderno
Escribe el bucle de arriba entero, sin ninguna librería de agentes, en cuarenta líneas. La razón de hacerlo a mano no es el ascetismo: es que cuando aparezcan los frameworks conviene saber exactamente qué están haciendo por vosotros, porque lo que abstraen es justo eso.
Sobre esas cuarenta líneas comprueba tres cosas que este capítulo afirma. Que el modelo no ejecuta nada, contando las filas de la tabla antes y después. Que el coste crece con el cuadrado de las vueltas, sumando los tokens de entrada de cada una. Y que los límites no son un refinamiento, viendo qué pasa cuando se quitan.
Termina con un experimento que conviene hacer antes de poner un agente delante de nadie: suavizar una frase del prompt de sistema, de una forma que parece inocua y hasta más completa, y ver cómo el agente deja de usar las herramientas y empieza a contestar de memoria.
Empecemos por lo que le da capacidad de actuar: las herramientas.