Qué es un AI agent: cinco tipos clásicos, dos definiciones rivales

El ejemplo más antiguo del campo es una aspiradora en un mundo de dos casillas, A y B, cada una limpia o sucia.¹ Sobrevive en todos los manuales porque es el mundo más pequeño en el que un agent puede acertar o equivocarse.

El percept es un par —dónde estoy y si aquí está sucio— y las acciones son SUCK, LEFT y RIGHT. Todo el programa es una línea.

type Percept = { dirty: boolean; where?: "A" | "B" };
type Action = "SUCK" | "LEFT" | "RIGHT";

const textbook = (p: Percept): Action =>
  p.dirty ? "SUCK" : p.where === "A" ? "RIGHT" : "LEFT";   

Ejecútalo contra todas las configuraciones iniciales del mundo de dos casillas:

A dirty, B dirty, start A    -> steps=3 clean=true
A clean, B dirty, start A    -> steps=2 clean=true
A dirty, B clean, start B    -> steps=2 clean=true

Eso es un agent reflejo simple: actúa solo sobre el percept actual, sin memoria de nada anterior. No es una categoría de juguete: un termostato lo es, y también una sola llamada a un modelo de lenguaje sin conversación adjunta.

Ahora rómpelo como lo hace la realidad. Un robot aspirador real tiene un sensor de suciedad y un parachoques, no una casilla etiquetada como A debajo de la alfombra. Saca la ubicación del percept y no cambies nada más:

const dirtOnly = (p: Percept): Action => (p.dirty ? "SUCK" : "RIGHT");

A dirty, B dirty, start A    -> steps=3   clean=true   still dirty=0
      t=0 at=A percept={dirty:true}  -> SUCK
      t=1 at=A percept={dirty:false} -> RIGHT
      t=2 at=B percept={dirty:true}  -> SUCK

A dirty, B clean, start B    -> steps=500 clean=false  still dirty=1
      t=0 at=B percept={dirty:false} -> RIGHT
      t=1 at=B percept={dirty:false} -> RIGHT
      t=2 at=B percept={dirty:false} -> RIGHT
      t=3 at=B percept={dirty:false} -> RIGHT

El mismo programa, dos casillas. Desde un estado inicial termina en tres pasos; desde otro se estrella contra la pared derecha quinientas veces y seguiría hasta que muriera la batería. No puede percibir la diferencia entre las dos situaciones, así que no puede actuar de forma distinta en ellas. Russell y Norvig enuncian el resultado general en una línea: los bucles infinitos suelen ser inevitables para los agents reflejos simples en entornos parcialmente observables.¹

Hay una solución que cuesta una línea y nada de memoria; merece la pena medirla antes de recurrir a nada más ingenioso.

let seed = 12345;
const rnd = () => ((seed = (seed * 1103515245 + 12345) & 0x7fffffff) / 0x7fffffff);

const coin = (p: Percept): Action => (p.dirty ? "SUCK" : rnd() < 0.5 ? "LEFT" : "RIGHT");  

Dos mil ejecuciones de un pasillo completamente sucio en tres tamaños, con un único generador sembrado durante todo el proceso:

La aleatorización elimina el bucle por completo. También cuesta: ocho habitaciones requieren quince movimientos si sabes lo que haces, y este agent promedia 68,7 y una vez tardó 306. Ese es todo el capítulo en miniatura. Cada capacidad que añadimos compra corrección en un caso que el agent anterior no podía manejar, y la cobra en una moneda que primero tienes que nombrar.

Un agent percibe su entorno mediante sensores y actúa mediante actuadores. El programa del agent es la función de percepts a acciones: cada listado anterior es uno. La secuencia de percepts es todo lo percibido hasta ahora, y un agent reflejo simple ignora todo salvo el último elemento.

Racionalidad es la palabra que la mayoría de artículos entiende mal, y entenderla bien hace utilizable el resto de este capítulo. Un agent no es racional o irracional por sí mismo. Russell y Norvig definen un agent racional como aquel que, para cada posible secuencia de percepts, selecciona la acción que se espera que maximice su medida de rendimiento, dada la evidencia de esa secuencia y cualquier conocimiento incorporado que tenga.¹ La medida de rendimiento no está dentro del agent: pertenece al diseñador, y la racionalidad solo se define en relación con ella.

La especificación se escribe convencionalmente como cuatro cosas, PEAS: medida de rendimiento, entorno, actuadores, sensores.

Observa qué fila es la rara. Casi todos los equipos que construyen agents en 2026 escriben E, A y S —los esquemas de herramientas, las integraciones, el formato de mensaje— porque el código no se ejecuta sin ellos. Casi nadie escribe P. Sin ella, «nuestro agent lo está haciendo bien» no tiene un significado que alguien pueda comprobar, y «racional» no puede aplicarse al sistema en absoluto, solo a una demostración. El Capítulo 29 trata de convertir P en un número, y por eso existe.

    ┌───────────────────────── the environment ─────────────────────────┐
    │                                                                   │
    │   ┌──────────────────────── the agent ─────────────────────┐      │
    │   │                                                        │      │
 ───┼──►│  sensors  ──►  the agent program  ──►  actuators  ─────┼──────┼──►
percept │                                                        │    action
    │   └────────────────────────────────────────────────────────┘      │
    └───────────────────────────────────────────────────────────────────┘
                                   ▲
              the performance measure lives out here, in the head of
              whoever built the thing, and the agent cannot change it

Los entornos de tarea se clasifican además en siete ejes, cinco de los cuales deciden aquí la mayor parte de la dificultad: total o parcialmente observables, deterministas o no, episódicos o secuenciales, estáticos o dinámicos, conocidos o desconocidos.¹ Un agent que habla con herramientas reales sobre una red real está en la esquina difícil de los cinco: no determinista incluso a temperatura cero (Capítulo 17) y, la parte infravalorada, desconocido, porque no tienes un modelo fiable de lo que tus propias herramientas hacen al mundo. Por eso el bucle del Capítulo 23 necesita más gestión de errores que planificación.

Los suelos reales no son unidimensionales, así que eleva el mundo a un plano. Las almohadillas son paredes, los asteriscos son suciedad y el robot empieza en la cámara central:

        col  0 1 2 3 4 5 6
      row 0  * . . # . . *
      row 1  . # . # . # .
      row 2  . # . S . # .        S = the robot starts here
      row 3  . # . # . # .
      row 4  * . . # . . *

La mejora obvia es la memoria. El agent conserva un mapa: cada casilla que ha pisado y cada casilla donde saltó el parachoques. Su regla es entrar en una casilla adyacente que no haya visitado —derecha, luego abajo, luego izquierda, luego arriba— y retroceder cuando todo a su alrededor es conocido. Es un agent reflejo basado en modelo: mantiene un estado interno a partir del historial de percepts, así que puede actuar sobre lo que no ve en ese momento.

Es una mejora real, y aun así no basta:

5,000 steps allowed -> steps=5,000  distinct squares visited=13/25  still dirty=2/4

Cinco mil movimientos, media planta sin ver. El mapa es correcto y las reglas son correctas. Lo que el agent no puede hacer es usar el mapa para ir a algún sitio: sus reglas solo responden «a cuál de mis cuatro vecinos debería entrar», así que cuando se queda sin casillas no visitadas junto a él, no tiene forma de expresar la idea hay una casilla no visitada a ocho movimientos y me gustaría estar de pie en ella. Sabe dónde está. No sabe dónde quiere estar.

Un agent basado en objetivos mantiene, además de su modelo del mundo, una descripción de la situación que quiere provocar, y elige acciones buscando entre secuencias de ellas hasta encontrar una que termine allí. Los objetivos convierten la selección de acciones de una consulta en una búsqueda.

El objetivo es «no queda ninguna casilla sucia». La búsqueda es un recorrido en anchura hasta la casilla sucia más cercana, y la ruta que devuelve es el plan.

goal-based (fewest moves)      -> moves=27  battery=52  still dirty=0
      from 2,3 -> 4,6 via 5 moves:  2,3 2,4 3,4 4,4 4,5 4,6
      from 4,6 -> 0,6 via 4 moves:  4,6 3,6 2,6 1,6 0,6
      from 0,6 -> 4,0 via 10 moves: 0,6 0,5 0,4 1,4 2,4 2,3 2,2 3,2 4,2 4,1 4,0
      from 4,0 -> 0,0 via 4 moves:  4,0 3,0 2,0 1,0 0,0

Veintisiete movimientos, suelo limpio. Pero mira la columna de batería y el último tramo del plan. La columna 0 tiene alfombra: cruzar una casilla con alfombra cuesta seis unidades de batería; una casilla de baldosa, una. El agent volvió a casa por la columna 0 porque son cuatro movimientos en vez de ocho, y esos cuatro movimientos sobre alfombra costaron 24, mientras que el rodeo de ocho movimientos habría costado 13.

No puede hacer otra cosa. Un objetivo es una prueba binaria: el suelo está limpio o no lo está. Todo plan que termine con el suelo limpio lo satisface por igual, así que cuando varios tienen éxito el agent no tiene nada con lo que elegir entre ellos. Preferir un éxito a otro exige un número sobre resultados, y ese número es una función de utilidad. Un agent que la maximiza es un agent basado en utilidad.

El cambio en el código es un término dentro de la búsqueda. La búsqueda en anchura cuenta movimientos; haz que cuente coste en su lugar y tendrás el algoritmo de Dijkstra y un agent distinto:

const nd = dist.get(k)! + (byCost ? cell.cost : 1);   // <- the entire difference

goal-based    (fewest moves)   -> moves=27  battery=52  still dirty=0
utility-based (cheapest route) -> moves=31  battery=41  still dirty=0
      from 4,0 -> 0,0 via 8 moves: 4,0 4,1 4,2 3,2 2,2 1,2 0,2 0,1 0,0

Cuatro movimientos extra, once unidades de batería menos: un veintiuno por ciento más barato. Mismo objetivo, mismo mapa, mismo código salvo por un término. Los dos agents solo difieren en aquello en lo que intentan ser buenos, y toman rutas distintas de vuelta a casa.

Este es también el primer punto en el que el agent necesita algo que no puede producir. Alguien tiene que decidir cuánto vale una unidad de batería en relación con un movimiento. La utilidad es la medida de rendimiento escrita en una forma con la que el agent puede calcular, y escribirla es trabajo del diseñador. Cuando la gente dice que un agent «optimizó lo equivocado», casi nunca quiere decir que hubiera un bug. Quiere decir que esta línea se escribió sin cuidado.

Ahora deja que vuelva la suciedad. Cuatro habitaciones se vuelven a ensuciar a cuatro ritmos distintos, y nunca se le dicen al agent. Visita una habitación por tick y solo ve esa habitación. La medida de rendimiento son ticks-habitación pasados en suciedad durante 4.000 ticks: cuanto más bajo, mejor.

Un agent de aprendizaje, en la descomposición del manual, es cualquiera de los anteriores más tres partes: un elemento de aprendizaje que cambia al agent, un crítico que le dice cómo lo está haciendo el agent frente a un estándar de rendimiento fijo y un generador de problemas que propone acciones que merece la pena probar por lo que enseñarían.¹ Tres políticas en el mismo entorno. La primera no aprende; la segunda y la tercera aprenden lo mismo y lo usan de forma distinta.

Las tasas ocultas eran 0,35 para la cocina, 0,05 para el pasillo, 0,02 para el estudio y 0,01 para el ático; y el aprendiz A las encontró. Identificó correctamente la cocina como la habitación más sucia de la casa, y luego fue a la cocina en cada tick durante el resto de la simulación mientras las otras tres permanecían sucias para siempre. Es cinco veces peor que no aprender nada, y no está roto.

La lección es la de la sección de utilidad. El aprendiz A maximizó «probabilidad de que la habitación que estoy a punto de visitar esté sucia». La medida de rendimiento era «ticks-habitación pasados en suciedad». Números distintos; el segundo es lo que puntuaba el crítico, y nadie se lo dijo al agent. El aprendiz B multiplica la misma tasa aprendida por el tiempo desde la última visita —la suciedad que espera encontrar, no la probabilidad de encontrar alguna— y supera a la patrulla de la que partió.

Un detalle de implementación decidió el resultado. En la primera versión del aprendiz B, una habitación donde no había aparecido suciedad en tres visitas recibía una tasa exactamente de cero; y cero por cualquier cosa es cero, así que nunca volvía a visitarse y la estimación nunca podía corregirse. Suavizar la fracción, éxitos más uno entre intentos más dos, convirtió 11.895 en 1.576. «Aún no observado» y «medido y salió cero» son afirmaciones distintas, y un sistema que las guarda en el mismo campo toma decisiones que no puede deshacer.

  1  simple reflex    percept ────────────────────────────────► rules ────► action
  2  model-based      percept ──► [state] ──────────────────► rules ────► action
  3  goal-based       percept ──► [state] ──► [goal] ──────► search ───► action
  4  utility-based    percept ──► [state] ──► [goal] ──► [U] ──► argmax ► action
  5  learning         all of the above, plus [critic] ──► changes the parts above

Cada uno de los cinco está en producción hoy bajo otro nombre.

Dos filas son más que una analogía, de una forma que cuesta dinero.

El chat es un agent reflejo basado en modelo cuyo modelo no es interno. En el manual, el estado es una variable dentro del programa del agent. En un chat es la transcripción: vive de tu lado, se reenvía completa en cada llamada y se reconstruye desde cero dentro del modelo cada vez. Esa es la factura cuadrática del Capítulo 16, y es el mismo objeto que el manual dibujaba como una caja etiquetada «estado». Aquí está la diferencia, medida en una pregunta de seguimiento con y sin los dos mensajes anteriores:

with the transcript      prompt=67  "The current temperature in Lisbon, Portugal is 15°C."
without the transcript   prompt=29  "Lisbon is the capital of Portugal, not a city in Portugal."

El mismo modelo, las mismas tres palabras de entrada del usuario, y la segunda es el robot del pasillo chocando contra la pared. No había herramientas en esa ejecución, así que el 15 es inventado; pero el estado es lo que hace que el seguimiento signifique algo. Lo reconstruyes cada vez y pagas 2,3× los tokens de entrada por ello en una conversación de dos turnos. El Capítulo 16 midió a cuánto llega ese multiplicador en el turno cuarenta.

Reflexion es un agent de aprendizaje que cambia su entrada en lugar de su programa. En la descomposición del manual, el elemento de aprendizaje modifica el elemento de rendimiento. Reflexion deja los pesos en paz y escribe texto reflexivo en un búfer episódico que lee el siguiente intento.³ El elemento de aprendizaje es un prompt, la memoria una fila de base de datos, el elemento de rendimiento un modelo congelado; y el diagrama es el del manual, sin cambios.

Y aquí está el límite honesto del mapeo. Los cinco tipos clasifican el programa del agent. En 2026 ese programa está partido por la mitad: una parte es tu código y otra está dentro de pesos que tú no entrenaste. Cuando un modelo decide por sí solo llamar a una herramienta, ¿la prueba de objetivo está en tu programa o en el modelo? La taxonomía no tiene respuesta, porque cuando se escribió no había otro sitio donde pudiera estar; y esa pregunta es exactamente donde las dos definiciones modernas se separan.

Las definiciones son argumentos sobre comportamiento, y son mucho más fáciles de juzgar con una traza delante.

El bucle siguiente envía la conversación a un modelo; si la respuesta contiene una llamada a herramienta, ejecuta la herramienta, añade el resultado y lo envía todo de nuevo. Corre contra un Qwen2.5-0.5B-Instruct local detrás de un endpoint con forma de OpenAI en esta máquina: la costura del Capítulo 14, así que al bucle ni le va ni le viene qué hay detrás del puerto.

const BASE = process.env.LLM_BASE_URL ?? "http://127.0.0.1:8799/v1";

async function loop(question: string, maxTurns = 6) {
  const messages: Msg[] = [
    { role: "system", content: SYSTEM },
    { role: "user", content: question },
  ];

  for (let turn = 1; turn <= maxTurns; turn++) {
    const reply = await call(messages, TOOLS);
    const calls = reply.choices[0].message.tool_calls ?? [];
    messages.push(reply.choices[0].message);

    if (!calls.length) return messages;                      

    for (const c of calls) {
      const out = runTool(c.function.name, JSON.parse(c.function.arguments));
      messages.push({ role: "tool", name: c.function.name, content: out });
    }
  }
  throw new Error("turn cap reached");                       
}

Dos líneas contienen toda la idea, y ambas están marcadas; el resto es contabilidad. Los tres comportamientos son visibles en una ejecución. Si se le pregunta algo que puede hacer por sí mismo, el modelo responde. Si se le pregunta algo que no puede, llama:

=== a question the model cannot answer, one tool available
  turn 1  prompt= 187  out= 21  finish=tool_calls  CALL get_temperature({"city": "Oslo"})
          tool  get_temperature -> {"city":"Oslo","celsius":4}
  turn 2  prompt= 238  out= 12  finish=stop        TEXT "The current temperature in Oslo is 4
                                                        degrees Celsius."
  => model calls=2  prompt tokens=425  output=33  wall=6,257 ms
  => stopped by: the model produced text instead of a call

Y para: el tercer comportamiento, y el más fácil de pasar por alto, porque parece que no pasa nada. El bucle termina porque el turno 2 volvió sin una llamada a herramienta. Nadie decidió eso; lo decidió el modelo, emitiendo prosa. La condición de terminación de este programa es el signo de una ausencia.

Merece la pena dedicar espacio a dos ejecuciones más. Al pedirle que compare dos ciudades, el modelo emite ambas llamadas a herramientas en un turno, recibe ambas lecturas y se equivoca en la comparación:

  turn 1  prompt= 188  out= 43  finish=tool_calls  CALL get_temperature({"city": "Oslo"}),
                                                        get_temperature({"city": "Lisbon"})
          tool  get_temperature -> {"city":"Oslo","celsius":4}
          tool  get_temperature -> {"city":"Lisbon","celsius":19}
  turn 2  prompt= 284  out= 13  finish=stop        TEXT "Oslo is currently warmer than Lisbon
                                                        at 4°C."

Las herramientas funcionaron. La llamada paralela funcionó. El bucle funcionó. La respuesta es falsa, con los dos números correctos sentados en la transcripción. Envolver un modelo en un bucle no lo hace razonar; le da a un modelo que se equivoca la capacidad de actuar sobre su equivocación, que es el Capítulo 30 por adelantado, y la mitad del Capítulo 29.

Ahora elimina el return marcado y deja que el bucle corra hasta su límite. Misma pregunta, mismo modelo:

  turn 1  prompt= 187  out= 21  CALL get_temperature({"city": "Oslo"})
  turn 2  prompt= 238  out= 12  TEXT "The current temperature in Oslo is 4 degrees Celsius."
  turn 3  prompt= 261  out= 30  TEXT "Could you please specify the exact location you're..."
  turn 4  prompt= 302  out= 14  TEXT "Sure! Could you tell me which city you're interested in?"
  turn 5  prompt= 327  out= 35  TEXT "I'm sorry, but I need more details to provide an..."
  turn 6  prompt= 373  out= 12  TEXT "Which city would you like to know the temperature for?"
  => model calls=6  prompt tokens=1,688  output=124  wall=25,261 ms  stopped by: turn cap

Cuatro veces los tokens de entrada, cuatro veces el tiempo de reloj, y un final en el que el agent ha olvidado qué se le preguntó y está interrogando al usuario sobre una pregunta que respondió en el turno uno. La respuesta correcta estaba en pantalla en el turno 2, y cada turno posterior empeoró la transcripción.

Así que un agent no es un bucle. Es un bucle más una regla para salir de él, y este tiene exactamente una regla así. El Capítulo 23 encuentra cinco y muestra qué se rompe cuando falta cada una.

Ambas citadas en vez de parafraseadas, porque en las paráfrasis es donde se fabrica la confusión.

La primera definición sitúa la frontera en quién controla el flujo. Building effective agents, de Anthropic, nombra la ambigüedad y decide sobre ella:

«En Anthropic, categorizamos todas estas variaciones como sistemas agénticos, pero trazamos una distinción arquitectónica importante entre flujos de trabajo y agents: los flujos de trabajo son sistemas en los que los LLM y las herramientas se orquestan mediante rutas de código predefinidas. Los agents, en cambio, son sistemas en los que los LLM dirigen dinámicamente sus propios procesos y uso de herramientas, manteniendo el control sobre cómo realizan las tareas.»⁴

La prueba es una pregunta sobre tu código fuente: ¿quién eligió el siguiente paso? Un switch en tu programa: flujo de trabajo. El modelo: agent. El mismo documento dice que los agents «normalmente son simplemente LLM que usan herramientas a partir de feedback del entorno en un bucle», que es exactamente el listado anterior.

La segunda definición sitúa la frontera en la independencia respecto al usuario. A practical guide to building agents, de OpenAI, abre su página definitoria así:

«Mientras que el software convencional permite a los usuarios agilizar y automatizar flujos de trabajo, los agents pueden realizar esos mismos flujos de trabajo en nombre de los usuarios con un alto grado de independencia. Los agents son sistemas que realizan tareas de forma independiente en tu nombre.»⁵

Dos frases después, en la misma página, excluye:

«Las aplicaciones que integran LLM pero no los usan para controlar la ejecución del flujo de trabajo —piensa en chatbots simples, LLM de un solo turno o clasificadores de sentimiento— no son agents.»⁵

Lee esas citas en orden. Las frases iniciales trazan la línea en la independencia: ¿esto se va y termina el trabajo sin mí? La cuarta la traza en el control de la ejecución, que es exactamente la línea de Anthropic. Pruebas distintas, misma página, y hay sistemas reales en los que no coinciden.

Debajo hay una colisión de vocabulario, y causa discusiones en reuniones reales. En el primer documento, un flujo de trabajo es una arquitectura, y es lo que no es un agent. En el segundo, un flujo de trabajo es «una secuencia de pasos que debe ejecutarse para cumplir el objetivo del usuario»: el trabajo en sí, que todo agent tiene. «Hemos sustituido el flujo de trabajo por un agent» es coherente con la primera definición y casi no significa nada con la segunda.

Tres sistemas que existen en 2026, bajo ambas definiciones.

Dos de los tres cambian de lado. Eso no es un fallo de ninguno de los documentos. Es una advertencia sobre un tipo de reunión en la que dos personas que están completamente de acuerdo sobre lo que hace un sistema pasan una hora discutiendo cómo llamarlo.

Las definiciones chocan porque cada una comprime dos preguntas independientes en una sola palabra. Sepáralas y el desacuerdo se convierte en una tabla, que es más útil que un veredicto.

Cada definición discute una celda distinta, y las otras dos no están en disputa. Así que cuando la etiqueta importa —en un contrato, una revisión de riesgos, un postmortem— las dos frases que merece la pena escribir no son «¿es un agent?», sino quién eligió el siguiente paso y quién estaba mirando. Ambas se responden leyendo código, ninguna necesita la definición de nadie y juntas contienen todas las consecuencias que la etiqueta estaba sustituyendo.

Nada de esto es nuevo. Wooldridge y Jennings estudiaron en 1995 los sentidos competidores de «agent»;⁶ Franklin y Graesser formularon la pregunta de este capítulo en 1996, reunieron las definiciones en circulación y descubrieron que no estaban de acuerdo.⁷ Una encuesta de 2023 todavía define los agents desde primeros principios —«entidades artificiales que perciben su entorno, toman decisiones y ejecutan acciones»⁸— porque no existía nada asentado que citar, y CoALA describe partes en lugar de trazar una frontera.⁹ Treinta años negándose a ponerse de acuerdo dicen que la palabra está haciendo más de un trabajo.

Ahora la consecuencia que llega antes que la filosofía: la factura.

Todas las mediciones aquí tienen la misma forma. La llamada única costó 39 tokens de entrada; la misma pregunta con una herramienta costó 420 en dos llamadas; el bucle sin su regla de parada costó 1.688 en seis. El crecimiento es peor que lineal, porque el turno n lleva consigo todos los turnos anteriores: la columna de prompt de esa ejecución de seis turnos dice 187, 238, 261, 302, 327, 373. El Capítulo 16 derivó que el total es $\Theta(n^2)$ y ajustó la curva en una conversación real. Un agent convierte cada tarea en esa conversación, aunque ningún humano llegue a verla.

Si esos recuentos de tokens medidos hubieran ido a un endpoint comercial con las tarifas que el Capítulo 16 leyó el 6 de septiembre de 2026 —$2.00 por millón de tokens de entrada y $12.00 por millón de salida—, las cuatro ejecuciones salen así:

La segunda fila contra la primera es el número que hay que conservar. Siete veces y media el coste, para una respuesta peor a una pregunta que el modelo ya sabía responder. Nada estaba mal configurado: existía una herramienta, así que el modelo la usó; y el hallazgo del Capítulo 18, que lo que duele es el precio de un catálogo y no su precisión, tiene aquí su demostración más barata con un catálogo de uno.

Por eso la mitad útil de ambos documentos es la mitad sobre no construir esto. El de Anthropic es tajante: encuentra la solución más simple posible y añade complejidad solo cuando haga falta, lo que «podría significar no construir sistemas agénticos en absoluto», ya que los sistemas agénticos «intercambian latencia y coste por mejor rendimiento en la tarea» y «para muchas aplicaciones, optimizar llamadas LLM únicas con retrieval y ejemplos in-context suele bastar».⁴ Su caso a favor de un agent es estrecho: problemas abiertos en los que no puedes predecir el número de pasos ni hardcodear una ruta, en un entorno en el que confías, aceptando «costes más altos y el potencial de errores acumulativos».⁴ La pantalla de OpenAI es la imagen especular —juicio complejo, conjuntos de reglas inmantenibles, datos no estructurados— y acaba igual: «en caso contrario, una solución determinista puede bastar».⁵

Así que, en la taxonomía de este capítulo: un número fijo de pasos en un orden fijo es una canalización, y llamarla agent no la hará más rápida. Si el número de pasos depende de lo que encuentres por el camino, quieres un bucle; y compras esa flexibilidad con N llamadas, una transcripción cuadrática y un sistema que puede equivocarse N veces en vez de una.

Ya tienes la taxonomía, las dos definiciones modernas, los dos ejes que las hacen compatibles y un bucle corto que responde, llama y para.

Ese bucle tiene una forma de terminar: el modelo deja de pedir herramientas. El Capítulo 23 lo rompe a propósito, siete veces, y cada rotura añade una pieza. Una tarea imposible, y nunca termina: un límite de turnos. Una noche ejecutándose, y llega la factura: un presupuesto en dólares. Una herramienta que falla: un error sobre el que el modelo puede actuar. La misma llamada dos veces: una clave de idempotencia. Un archivo que no debería haber tocado: una aprobación humana. Un reinicio a mitad de camino: persistencia de sesión. Una herramienta que tarda tres minutos en silencio: progreso y cancelación. Lo que sale es un harness, el archivo sobre el que corre el resto de este curso.

Lo que deja la pregunta sobre la que trataba realmente la diagonal disputada de este capítulo. Un bucle que decide su propio siguiente paso tiene que decidir cuándo parar, y acabamos de ver qué pasa cuando no puede: seis turnos, cuatro veces la factura y un agent interrogando al usuario sobre una pregunta que ya había respondido. Parar no es una sola condición. ¿Cuántas hay y cuál se dispara primero?

LLM Powered Autonomous Agents (2023), de Lilian Weng, es la descomposición más conocida de un language agent en planificación, memoria y uso de herramientas, y es la siguiente lectura adecuada junto a los dos documentos de proveedores; sus tres componentes son los Capítulos 23, 24 y 18 de este curso, en ese orden.

Todos los números de este capítulo se produjeron en esta máquina y nada se estimó. El pasillo, el plano, los cuatro agents que lo recorren y las tres políticas de patrulla son el TypeScript anterior, ejecutado en Node 22; las cifras del agent aleatorizado son medias sobre 2.000 ejecuciones sembradas cada una, y las cifras de patrulla son ejecuciones sembradas únicas de 4.000 ticks. Las trazas del modelo proceden de Qwen2.5-0.5B-Instruct en float32 sobre CPU con decodificación codiciosa, servido por loopback mediante un pequeño endpoint local en Python que carga los pesos y habla con la forma de chat-completions de OpenAI —la costura otra vez, con los tensores en el lado de Python y el bucle en el de TypeScript—, así que los recuentos de tokens son los del tokenizer de ese modelo y las latencias son las de esa máquina. Las únicas cifras tomadas de otro sitio son los dos precios de la tabla de costes, que son las tarifas que el Capítulo 16 leyó en la página de precios de OpenAI el 6 de septiembre de 2026, aplicadas aquí a recuentos de tokens medidos localmente como ilustración y no como factura observada.