¿Qué es realmente un agente LLM?
Llevo tiempo queriendo escribir sobre agentes. No porque el tema sea nuevo, sino porque cada vez que parece que empezamos a entenderlo, cambia el nivel de abstracción con el que se habla de él.
Y ahí empieza buena parte del problema.
Hoy una persona dice “agente” y se refiere a un sistema con tools, memoria, planificación y control de estado. Otra usa la misma palabra para hablar de un prompt bien diseñado dentro de un archivo .md. Y otra simplemente la usa para describir cualquier flujo donde un modelo hace más de un paso.
Mientras tanto, la adopción en empresas tampoco ocurre al mismo ritmo. Algunas organizaciones todavía están evaluando asistentes de código en grupos pequeños. Otras ya probaron varias herramientas, cambiaron de enfoque más de una vez y ahora están intentando separar qué fue entusiasmo, qué fue utilidad real y qué sí puede sostenerse en producción.
Por eso, cuando en una conversación aparece la pregunta:
¿Qué es un agente?
casi nunca hay una sola respuesta.
Y el problema no es que falten definiciones. El problema es que muchas definiciones son correctas, pero se quedan demasiado arriba y no siempre ayudan a entender qué está pasando en la práctica.
La respuesta corta
Una definición razonable sería esta:
Un LLM común genera texto a partir de su entrenamiento.
Un agente LLM es ese mismo modelo dentro de un ciclo donde puede razonar, usar herramientas, recibir feedback y ajustar su siguiente acción.
Dicho de otra forma:
LLM + tools + memory + planning = agente
No está mal. De hecho, es una buena síntesis.
Pero también es el tipo de respuesta que muchas personas escuchan, entienden de forma parcial y luego repiten sin terminar de visualizar qué significa realmente.
Así que conviene detenerse un poco más.
Una definición más útil
La forma que más me convence de explicarlo es esta:
Un agente LLM es un LLM dentro de un workflow iterativo donde puede razonar, actuar y usar el resultado de sus acciones para decidir qué hacer después.
Ese matiz importa.
Porque el centro de la idea no está solo en el modelo, sino en el ciclo en el que ese modelo opera.
No es magia.
No es una categoría mística de software.
Es un sistema con estructura.
Visual general
La analogía más simple: un desarrollador humano
Una buena forma de aterrizarlo es compararlo con el trabajo cotidiano de un desarrollador.
| Fase humana | Equivalente del agente |
|---|---|
| Recibe un requerimiento | Recibe un prompt o una task |
| Piensa cómo abordarlo | Razona sobre el problema |
| Busca documentación, prueba opciones, escribe código | Usa tools |
| Ejecuta, valida y corrige | Actúa sobre el entorno |
| Ve errores, resultados o confirmaciones | Recibe feedback |
| Ajusta el enfoque | Decide el siguiente paso |
Eso es lo que hace que la idea deje de sonar abstracta.
Un agente no es más que un modelo participando en algo que se parece bastante a un ciclo real de trabajo:
- analizar
- actuar
- observar
- corregir
La diferencia es que, en lugar de hacerlo con navegador, terminal, editor y pruebas como lo haría una persona, lo hace a través de herramientas conectadas al sistema.
Entonces, ¿de dónde sale tanta confusión?
De que hoy la palabra agente se usa para hablar de cosas bastante distintas.
Hay personas que dicen “creé un agente” y, cuando miras más de cerca, en realidad lo que construyeron fue un archivo .md con instrucciones muy claras para que Claude Code, Cursor u otra herramienta se comporte de cierta manera.
Y eso no está mal.
De hecho, muchas veces ese archivo contiene una parte valiosa del diseño:
- el rol
- las reglas
- las restricciones
- el criterio de calidad
- la forma de decidir entre opciones
El problema aparece cuando esa pieza se confunde con el sistema completo.
Un .md puede definir comportamiento. Puede incluso capturar muy bien la intención del flujo. Pero, por sí solo, normalmente no resuelve aspectos fundamentales como:
- ejecución de herramientas
- control de estado
- manejo de errores
- límites operativos
- observabilidad
- validación
- integración con otros sistemas
Por eso, más que decir “eso sí es un agente” o “eso no es un agente”, creo que la distinción más útil es esta:
Un archivo de instrucciones puede ser una parte importante del agente, pero no suele ser suficiente para representar todo el sistema.
Esa diferencia parece pequeña, pero cambia mucho la conversación.
Veamos un ejemplo en código
Para hacerlo más tangible, le pedí a ChatGPT que generara un ejemplo sencillo usando strands-agents, el framework de AWS:
from strands import Agent, Tool
# --- Tools (simuladas) ---
def search_docs(query: str) -> str:
if "CORS" in query:
return "Use API Gateway integrationResponses to handle CORS in AWS CDK."
return "No results found."
def run_tests(code: str) -> str:
if "cors" in code.lower():
return "Tests passed ✅"
return "Tests failed ❌: missing CORS config"
# Registrar tools
tools = [
Tool(name="search_docs", func=search_docs, description="Search technical documentation"),
Tool(name="run_tests", func=run_tests, description="Run code tests")
]
# --- Agente ---
agent = Agent(
tools=tools,
system_prompt="""
You are an autonomous software engineer.
You follow a loop:
1. Think about the problem
2. Decide if you need a tool
3. Act using tools
4. Observe results
5. Iterate until the task is complete
"""
)
# --- Task ---
task = "Implement CORS in AWS API Gateway using CDK and verify it works"
# --- Loop ---
state = {"task": task, "code": ""}
for step in range(5):
print(f"\n--- Step {step + 1} ---")
response = agent.step(state)
print("Thought:", response.thought)
if response.action:
print("Action:", response.action.name)
result = response.action.run()
print("Observation:", result)
state["last_observation"] = result
# Simulación: el agente escribe código
if "CORS" in result:
state["code"] = "const cors = true;"
else:
print("Final Answer:", response.output)
break
Es un ejemplo simple, pero alcanza para mostrar el patrón.
Lo importante no es el framework
Más allá del framework, lo importante es el ciclo:
Think → Act → Observe → Iterate
Eso es lo que le da forma al comportamiento del agente.
No importa demasiado si usas strands-agents, LangGraph, AutoGen, OpenAI Agents SDK o una implementación propia. En casi todos los casos, la lógica de fondo se parece bastante:
- el modelo analiza el problema
- decide si necesita una herramienta
- ejecuta una acción
- observa el resultado
- ajusta el siguiente paso
Cuando lo miras así, el concepto deja de parecer misterioso.
No estamos hablando de una inteligencia separada del resto del sistema. Estamos hablando de un modelo que participa en un flujo iterativo con capacidad de actuar sobre un entorno.
¿Por qué extender LLMs con tools?
Porque un LLM sin tools tiene límites muy claros.
Una analogía útil es imaginar a un desarrollador trabajando en un archivo .txt, sin internet, sin compilador y sin un entorno donde validar nada.
Puede razonar, sí.
Pero no puede:
- buscar información nueva
- verificar si lo que hizo funciona
- ejecutar código
- consultar el estado real del mundo
Ese es el punto clave.
Un modelo sin herramientas puede producir texto muy convincente, pero no tiene cómo contrastarlo con la realidad.
Visual: LLM sin tools vs con tools
Qué cambia cuando agregas tools
Cuando conectas tools, el modelo puede dejar de operar únicamente sobre lo que recuerda y empezar a interactuar con información y sistemas externos.
Por ejemplo, puede:
- buscar documentación
- consultar una base de conocimiento
- ejecutar código
- correr pruebas
- leer archivos
- consultar APIs
- validar una respuesta con datos reales
Ese cambio es mucho más importante de lo que parece.
Porque el valor ya no está solo en que el modelo “sepa” algo, sino en que puede hacer algo, observar lo que ocurrió y usar ese resultado para continuar.
Ahí es donde aparece la parte realmente interesante del comportamiento agéntico.
La idea clave
Un agente no es solamente un modelo.
Es un modelo dentro de un ciclo, conectado a herramientas y expuesto a feedback del entorno.
Esa definición, para mí, es mucho más útil que cualquier explicación grandilocuente.
Porque además ayuda a desmontar una confusión bastante común: pensar que el salto de “LLM” a “agente” es una cuestión de branding o de complejidad artificial.
No lo es.
Lo que cambia no es solo el nombre.
Lo que cambia es la arquitectura del problema.
Entonces, ¿un archivo .md es un agente?
Por sí solo, normalmente no.
Puede ser una pieza excelente de diseño. Puede capturar reglas, intención, tono, restricciones, prioridades e incluso estrategias de decisión. Y en algunos casos, eso ya aporta muchísimo valor.
Pero cuando hablamos de un agente funcionando como sistema, suele hacer falta bastante más:
- un runtime que ejecute acciones
- herramientas reales
- estado
- validación
- manejo de errores
- observabilidad
- integración con otros componentes
Por eso, más que oponer “prompt” contra “agente”, creo que conviene pensar en capas.
Un .md puede ser la capa de comportamiento.
El agente completo incluye además la capa de ejecución, control y operación.
Llevar esto a producción cambia por completo la conversación
Aquí es donde muchas demos dejan de ser suficientes.
En una prueba local, casi todo puede verse ordenado:
- el modelo recibe una instrucción
- llama una tool
- obtiene algo útil
- devuelve una respuesta razonable
Pero producción introduce otro tipo de preguntas.
No preguntas sobre la idea.
Preguntas sobre el sistema.
Por ejemplo:
- ¿qué ocurre si una tool falla?
- ¿cómo evitas loops innecesarios?
- ¿cómo limitas costo y latencia?
- ¿cómo registras las decisiones que tomó el agente?
- ¿cómo auditas lo que hizo?
- ¿cómo validas que una acción sea segura antes de ejecutarla?
- ¿cómo recuperas el estado si el flujo se interrumpe?
- ¿cómo haces retries sin duplicar efectos?
- ¿dónde incorporas aprobación humana?
- ¿cómo pruebas algo cuyo comportamiento depende de contexto, tools y feedback?
Y ahí se vuelve evidente algo importante:
construir una demo con sabor a agente es relativamente fácil; construir un sistema confiable es otra cosa.
Por eso, cuando alguien pregunta si un agente es “solo un prompt con tools”, mi respuesta tiende a ser: a veces eso alcanza para una demo útil, pero no para describir todo lo que implica operarlo bien.
Conclusión
Más que decir que estamos en un momento extraño, diría que estamos en una etapa de ajuste.
Todavía hay equipos que apenas están empezando a explorar asistentes de código. Otros ya pasaron por varias herramientas, frameworks y experimentos con agentes. Y muchos están descubriendo, quizá por primera vez, que bajo una misma palabra se mezclan ideas que conviene separar.
Por eso la pregunta sigue apareciendo:
¿Qué es realmente un agente?
Mi respuesta, hoy, sería esta:
Un agente no es magia.
No es solamente un prompt.
No es simplemente un .md.
Y tampoco es cualquier flujo con varias llamadas a un modelo.
Un agente es un sistema donde un modelo puede:
- razonar
- actuar
- observar resultados
- y decidir qué hacer después en función de ese feedback
Entender eso no resuelve todo, pero sí limpia bastante el terreno.
Y en un momento donde casi todo el mundo usa la palabra “agente” para algo distinto, tener una definición más concreta ya es un muy buen comienzo.
Top comments (1)
Buena entrada Xavier, es importante tener claro todos los conceptos para poder estar a la vanguardia en este cambio de paradigma, buena entrada me suscribi! Saludos y un abrazo