Tres definiciones, tres fronteras
Hoy la palabra «agent» se usa con tres fronteras distintas, y conviene saber cuál te están contando.
| Dónde pone la frontera | ¿Un chatbot es un agent? | |
|---|---|---|
| Uno de los grandes desarrolladores de modelos | quién controla el camino de ejecución: código escrito de antemano o el modelo | no, si lo dirige una ruta de código |
| Otro | si hace el trabajo solo, en tu lugar | explícitamente no |
| El equipo universitario del benchmark | si existe un bucle siquiera | no, porque no hay bucle |
La segunda formulación es la más útil porque delimita en negativo: una aplicación que usa un modelo de lenguaje pero no le cede el control del flujo de trabajo —un chatbot simple, una consulta de un solo turno, un clasificador de sentimiento— no es un agent.
En la primera, en cambio, workflow y agent no son opuestos, sino los dos extremos de una misma escala. No es una sutileza: si alguien te vende un «agent», merece la pena preguntar según qué definición lo dice.
Lo que comparten las tres: bucle, herramientas y realimentación del entorno.
El bucle: cien líneas que lo cuentan todo
Existe un agent público, en producción, que usan tanto grupos de investigación como grandes empresas tecnológicas, y su descripción oficial dice que supera el 74 % en un benchmark conocido de desarrollo de software. Todo su control son unas cien líneas.
Resumido, a partir del código real:
run():
mensajes = [system prompt, tarea] # arranca con dos mensajes
bucle:
paso()
si el último mensaje es "salir" -> fin
paso():
ejecutar(preguntar())
preguntar():
si llegaste al límite de pasos -> parada
si llegaste al presupuesto -> parada
si llegaste al límite de tiempo -> parada
respuesta = modelo(mensajes) # LLAMADA AL MODELO
coste += respuesta.coste
añadir_mensaje(respuesta)
ejecutar(respuesta):
salida = entorno.ejecutar(resp.acciones) # EJECUCIÓN
añadir_mensaje(observación(salida)) # vuelve la OBSERVACIÓN
De aquí salen cuatro cosas, y las cuatro importan.
La primera: la historia es lineal. Cada paso añade su resultado a los anteriores. Nada desaparece, nada se comprime solo: el contexto crece de forma monótona.
La segunda: hay tres condiciones de parada, y todas se llaman límite. Número de pasos, coste, tiempo. El presupuesto por defecto de este sistema es de tres dólares por tarea, y es el número publicado más concreto que hay sobre cuánto está dispuesto a gastar un equipo serio en una sola ejecución.
La tercera: hay también una cuarta salida. Tras tres errores de formato seguidos, el sistema se rinde. No lo intenta indefinidamente.
La cuarta, que aporta el system prompt: el modelo tiene que emitir exactamente una orden en cada respuesta, y tiene que escribir antes un pensamiento que explique por qué. Esta pareja «pensamiento–acción» no es el comportamiento natural del modelo. Hay que forzarla.
Un paso, de cerca
Merece la pena mirar qué ocurre en la red durante una sola llamada a herramienta. El ejemplo normativo del estándar de observabilidad describe justo esto:
arranca la ejecución del agent
|
+-- llamada al modelo <- «¿qué hago?»
|
+-- llamada a herramienta (cliente) <- sale la petición
| |
| +-- herramienta (servidor) <- la operación se ejecuta
|
+-- llamada al modelo <- «esto recibí, ¿y ahora?»
Una llamada a herramienta son dos llamadas al modelo. Una antes y otra después. Es lo más importante que hay que saber sobre el coste de los agents, y la razón de que una tarea de diez pasos llame al modelo veinte veces y no diez.
Junto a la llamada, el estándar registra además el nombre de la herramienta, con qué argumentos se llamó, qué devolvió y con qué versión del protocolo. Si registras eso, dentro de un mes la ejecución todavía se puede reconstruir; si no, ya no.
¿Cuánto es esto en números?
Cifras concretas y publicadas. Cuando el dato viene del fabricante lo digo, porque de ninguno se dio el tamaño de muestra ni el protocolo de medición.
- Según la medición propia de un desarrollador de modelos, los agents consumen unas cuatro veces más tokens que una conversación, y los sistemas multi-agent quince veces más.
- Su propia recomendación de escalado: para una pregunta simple, un agent y de 3 a 10 llamadas a herramienta; para una comparación, de 2 a 4 subagents con 10-15 llamadas cada uno; para una investigación compleja, más de diez subagents.
- Un subagent gasta normalmente decenas de miles de tokens, y de ahí devuelve un resumen comprimido de 1.000 a 2.000 tokens.
- Y el presupuesto de tres dólares de arriba: a precios de hoy son del orden de 1,5 millones de tokens de entrada o 300.000 de salida. Eso es lo que cabe en una ejecución.
De dónde viene el nombre: el patrón ReAct
Alternar pensamiento y acción no es un invento de 2025. El artículo que describe el patrón se publicó en octubre de 2022, y en 2023 también en actas de congreso.
La idea es sencilla: el modelo no separa el pensar del actuar, sino que los alterna. El pensamiento corrige el plan, la acción trae información de una fuente externa, y ambos se mejoran mutuamente.
Los resultados medidos entonces: 34 puntos porcentuales de mejora absoluta en un conjunto de tareas de simulación doméstica y 10 puntos porcentuales en una tarea de compra web frente a los métodos anteriores, esto último con apenas uno o dos ejemplos en el prompt.
El patrón sigue vivo: varias herramientas de automatización no-code traen un nodo «ReAct agent» aparte.
¿Qué no sabe hacer un agent?
Esta es la parte más importante, y detrás de cada afirmación hay una medición.
No es consistente. Hay un benchmark que no mide si la tarea sale bien una vez, sino si sale bien ocho veces de ocho. Cuando apareció, en 2024, los mejores sistemas del momento quedaban por debajo del 50 % incluso a un solo intento, y por debajo del 25 % ocho de ocho veces.
Desde entonces ha mejorado mucho, pero no sabemos cuánto. Los líderes actuales llegan al 85-88 % a un solo intento en ese mismo conjunto de tareas. La cifra de ocho de ocho, en cambio, hoy no la publica nadie. Es decir, la capacidad ha crecido de forma demostrable, mientras que sobre la consistencia no hay dato público, y es justo lo segundo lo que decide si puedes dejar algo sin vigilancia.
Donde la tarea es nueva sigue rondando el 50 %. En una variante más difícil de la misma familia de benchmarks, basada en recuperación de conocimiento, los mejores sistemas quedan entre el 48 % y el 55 %.
La duración de la tarea es el factor decisivo. Según una medición de marzo de 2025, los modelos resuelven casi el 100 % de lo que a una persona le lleva menos de cuatro minutos, y menos del 10 % de lo que lleva más de cuatro horas. Esa misma medición concluyó además que la duración de tarea manejable se duplica aproximadamente cada siete meses: es una estimación de tendencia de marzo de 2025, no un hecho de hoy.
Y una razón mecánica de que la ejecución larga se degrade. Como el bucle añade lo anterior en cada paso, la entrada crece de forma monótona. Y según un estudio sobre 18 modelos, la salida es cada vez menos fiable a medida que la entrada se alarga, y un solo elemento distractor ya empeora el resultado frente al caso limpio. Por eso «dejémoslo correr un rato más» no es la solución.
Un último límite muy tangible, sacado del prompt de ese mismo agent en producción: el cambio de directorio y las variables de entorno no se conservan, porque cada operación corre en una subshell nueva. El agent solo «recuerda» lo que le devolvieron escrito como texto.
Malentendidos habituales
- «El agent piensa y luego actúa.» Alterna las dos cosas, y el pensamiento hay que forzarlo en el prompt: por su cuenta no responde así.
- «Si lo dejo correr más, tarde o temprano lo resuelve.» Una ejecución más larga es una entrada más larga, y una entrada más larga da, medidamente, una salida menos fiable.
- «Un paso es una llamada al modelo.» Son dos: una antes de la operación y otra después del resultado.
- «Si lo resolvió una vez, sabe resolverlo.» La consistencia es una métrica aparte, y es justo de la que hoy no hay dato público.
- «El agent recuerda lo que hizo.» Solo lo que está ahí en el texto. Lo que pasó en el entorno y no volvió como texto, para él no existe.
- «Un chatbot también es un agent, solo que más listo.» La diferencia son el bucle, el uso de herramientas y la realimentación del entorno, no el tamaño del modelo.
Lo que conviene llevarse
Un agent es un bucle con tres condiciones de parada y un texto que crece de forma monótona. Si te quedas con esa frase, lo demás se deduce: por qué es caro, por qué se degrada en tareas largas y por qué necesita límites.
El orden práctico que sale de ahí: ponle límites (pasos, coste, tiempo), dale herramientas en vez de dejar que trabaje de memoria, y registra cada paso que da, porque después solo desde ahí se puede reconstruir lo ocurrido.
Cómo se relacionan el número de pasos y la fiabilidad —y por qué un encargo de veinte pasos falla incluso con un 98 % de acierto por paso— lo calcula el post la matemática de la fiabilidad , número a número; y del mecanismo de la llamada a herramienta se ocupa en detalle el post tool use y function calling , campo por campo.