Hace tres semanas un suscriptor me pasó el repositorio de su primer agente. Orgulloso, y con motivos: cuatrocientas líneas limpias, herramientas declaradas, tool calling funcionando.
Le hice una sola pregunta. ¿Cuántas veces llama al modelo cuando lo ejecutas?
Siempre tres. Las mismas tres, en el mismo orden, pasara lo que pasara.
Eso no era un agente. Era un pipeline con tres llamadas a un LLM dentro. Y funcionaba perfectamente, que es lo que vuelve incómoda la conversación. Porque la respuesta habitual a qué es un agente de IA —"un sistema autónomo que usa herramientas para cumplir un objetivo"— describe igual de bien su script que Claude Code.
Y no son la misma categoría de software.
La diferencia no es semántica: decide qué tienes que instrumentar antes de dejarlo suelto y qué ocurre el día que se equivoca a las tres de la mañana.
Aquí va la definición operativa que uso: un test que aplicas a tu código en dos minutos, la anatomía real, los grados de autonomía y —lo más importante— cuándo no deberías montar un agente.
Resumen rápido
- Un agente de IA es un sistema donde el modelo decide el flujo de control: qué acción viene después y cuántas. No lo define la autonomía ni el uso de herramientas.
- El test: si el número de llamadas al modelo es fijo y puedes dibujar el camino antes de ejecutar, es un workflow con un LLM dentro. Y suele ser la opción correcta.
- La anatomía real son cinco piezas: objetivo, política de decisión, herramientas, contexto y verificador con criterio de parada. La quinta es la que casi nadie monta.
- Un límite de iteraciones no es un criterio de parada. Es un timeout.
- Cruzar la línea es binario; lo que hay al otro lado, no. Hay grados de autonomía, y cada grado exige instrumentación distinta. Los incidentes suelen ser un grado 3 con instrumentación de grado 1.
- No son agentes: un chatbot con herramientas, un pipeline determinista con un nodo de IA, un RAG clásico.
Qué es un agente de IA: la definición que sí se puede verificar
Un agente de IA es un sistema en el que el modelo decide el flujo de control: qué acción se ejecuta a continuación, con qué argumentos y cuándo parar. No lo define la autonomía ni el uso de herramientas, sino quién elige el siguiente paso.
No es el que usa herramientas. No es el que parece inteligente. Es el que decide qué pasa después.
La definición de marketing —"autónomo", "usa herramientas", "cumple objetivos"— es inútil precisamente porque no excluye nada: bajo ese paraguas cabe un cron con un prompt dentro.
Anthropic lo formuló bien en Building effective agents (diciembre de 2024): los workflows son "sistemas donde los LLM y las herramientas se orquestan mediante caminos de código predefinidos"; los agentes, "sistemas donde los LLM dirigen dinámicamente sus propios procesos y su uso de herramientas, manteniendo el control sobre cómo realizan las tareas".
Traducido a algo que puedas usar hoy: el diagrama de flujo de un workflow existe antes de ejecutarlo. El de un agente no existe hasta que termina.
Si puedes dibujar en una pizarra todo lo que va a pasar, no has construido un agente. Has construido un programa que llama a un modelo. Que, insisto, suele ser mejor decisión.
El test: ¿agente o workflow con un LLM dentro?
Tres preguntas. Se contestan mirando tu código, no leyendo documentación.
- ¿El número de llamadas al modelo es fijo? Si siempre son tres, es un workflow.
- ¿La salida de una herramienta cambia cuál se llama después? Si el orden lo escribiste tú, es un workflow.
- ¿Hay un bucle del que el modelo puede decidir no salir? Si no hay bucle, no hay agente.
Abre el archivo, busca la llamada al modelo y mira qué tiene alrededor. Esto es un workflow:
// Workflow: el camino está escrito. Siempre estos tres pasos, en este orden.
const intencion = await modelo.clasificar(email)
const resumen = await modelo.resumir(email)
const respuesta = await modelo.redactar(intencion, resumen)
await enviar(respuesta)
Y esto es un agente:
// Agente: el modelo elige la siguiente acción con lo que acaba de observar.
const mensajes: Mensaje[] = [{ role: 'user', content: objetivo }]
let pasos = 0
while (pasos++ < LIMITE) { // LIMITE es un timeout, no un criterio de parada
const decision = await modelo.responder({ mensajes, tools })
if (decision.tipo === 'final') break // ojo: aquí para el modelo, no un verificador
const observacion = await ejecutar(decision.tool, decision.args)
mensajes.push(decision, observacion) // lo observado entra en la siguiente decisión
}
Toda la diferencia está en una palabra: while. En el primero, un await va detrás de otro y el orden lo pusiste tú. En el segundo hay un bucle, y dentro del bucle el que elige es el modelo.
Fíjate en los dos comentarios que he dejado en el segundo bloque, porque ese ejemplo todavía está incompleto a propósito: para cuando el modelo dice que ha terminado, y eso no es un criterio de parada. Volvemos a ello en la anatomía.
Si en tu repositorio no aparece ese bucle —ni explícito, ni dentro de la librería que uses—, no tienes un agente. Y si el while solo reintenta la misma llamada cuando falla la red, tampoco: eso es un retry.
Ese bucle tiene nombre propio, fases y modos de fallo documentados: lo desmonté pieza a pieza en Agentic loop: el mecanismo detrás de los agentes de IA.
La anatomía real: cinco piezas, y casi nadie monta la quinta
Un agente de IA se compone de cinco piezas: objetivo, política de decisión, herramientas, contexto y verificador con criterio de parada. Las cuatro primeras salen en cualquier tutorial. La quinta es la que separa una demo de un sistema.
| Pieza |
Qué es |
Qué pasa si falta |
| Objetivo |
El resultado esperado, no la instrucción |
Optimiza para parecer útil, no para terminar |
| Política de decisión |
El modelo eligiendo la siguiente acción |
No hay agente: hay script |
| Herramientas |
La superficie de acción sobre el mundo real |
Razona precioso y no cambia nada |
| Contexto |
Lo que sabe en cada iteración |
Repite trabajo hecho y se contradice |
| Verificador y criterio de parada |
La señal que dice si el trabajo está bien |
Para cuando cree que ha acabado |
Estas cinco son las piezas del agente. El andamiaje que lo envuelve —registro de herramientas, guardrails, gestión de contexto— es otra capa distinta, y la desglosé en qué es un agent harness.
Las herramientas son donde más gente se pasa de frenada: doce tools disponibles, descripciones ambiguas y un modelo eligiendo mal. No es fallo del modelo, es fallo de diseño, y lo desarrollé en cómo evitar que los agentes elijan mal sus herramientas.
El contexto arruina ejecuciones largas en silencio. Qué recuerda entre iteraciones, qué recuerda entre sesiones y qué debe olvidar es arquitectura, no implementación: las cuatro capas del modelo CoALA están en implementación de memoria en agentes de IA.
Y llegamos a la quinta, que es donde está el problema de verdad.
Un límite de iteraciones no es un criterio de parada
Casi todo el mundo cree que tiene verificador porque ha escrito esto:
while (pasos < 10) { /* ... */ }
Eso es un timeout. Dice cuándo dejar de gastar dinero. No dice nada sobre si el trabajo está bien hecho.
El criterio de parada es un comando o una función que responde sí o no sin que intervenga tu criterio. Los tests en verde. El typecheck limpio. Un eval puntuado contra casos conocidos. Un schema que valida la salida.
Y aquí se resuelve la tensión que quizá te haya chirriado antes: dije que el modelo decide cuándo parar, y ahora digo que el criterio tiene que ser externo. Las dos cosas. El modelo propone que ha terminado; el verificador confirma o lo devuelve al bucle. Un agente que se autoevalúa no tiene criterio de parada: tiene una opinión.
La diferencia se nota el día que el agente sale del bucle en la iteración 4 y te devuelve algo roto. Salió porque el modelo dijo "listo", y el modelo dijo "listo" porque no había nada delante que le llevara la contraria.
Un agente sin verificador no es autónomo. Es no supervisado, que es otra cosa. Montar esa señal es lo que separa una demo de un sistema, y está en evaluaciones automatizadas para agentes de IA.
El verificador tiene un hermano que se olvida igual de rápido: el perímetro. Contenedor aislado, rama nueva, credenciales de solo lectura. Nunca ejecución de código generado sobre el servidor real. Cuanta más autonomía das, más estrecho tiene que ser el perímetro, no al revés.
Los grados de autonomía: cuánto decide el modelo
El test de arriba te dice si has cruzado la línea. No te dice cuánto la has cruzado, y eso es exactamente lo que decide qué tienes que montar debajo. Hay cinco grados, del 0 al 4, y cada uno exige una instrumentación distinta.
La escala que viene es mía, no un estándar de la industria. La uso para decidir qué instrumentación exige cada salto antes de darlo. Si te sirve, róbala; si no, calibra la tuya y quédate con la última columna.
| Grado |
Lo decide tu código |
Lo decide el modelo |
Ejemplo típico |
Mínimo que exige |
| Grado 0 |
El flujo y la ejecución completa |
El texto que devuelve |
Chat, autocompletado |
Nada. El bucle eres tú |
| Grado 1 |
Qué acciones existen y cuándo se ejecutan |
Cuál encaja en este caso |
Tool calling de un salto, routing |
Validación de argumentos |
| Grado 2 |
El catálogo y el permiso de cada acción |
El orden y cuántas hacen falta |
Agente con aprobación por acción |
Un humano revisando cada acción antes de ejecutarla, no el resumen final |
| Grado 3 |
El perímetro y el criterio de parada |
El plan completo dentro del perímetro |
Un agente arreglando un test en CI |
Verificador automático, sandbox y trazas |
| Grado 4 |
Solo el perímetro |
El plan y sus propias herramientas |
Self-improving loop |
Todo lo anterior más evals de regresión |
La línea del test está entre el grado 1 y el grado 2. Por debajo, el orden lo escribiste tú: workflow. Del grado 2 hacia arriba, el orden lo decide el modelo, y ahí empieza el agente. Ser agente es sí o no. Cuánta cuerda le das, no.
Mira solo la última columna. Es la única que importa de verdad.
Subir de grado no es cambiar de modelo ni instalar un framework con la palabra "agent" en el nombre. Es tener montado lo que ese grado exige antes de subir.
El incidente típico no lo provoca un agente malo. Lo provoca un grado 3 corriendo con instrumentación de grado 1: sin trazas para reconstruir qué decidió, sin sandbox y sin señal automática de si aquello estaba bien. Qué capturar de cada ejecución para poder auditarla está en cómo monitorear agentes de IA en producción.
El grado 4 es el techo actual y el más malinterpretado. Un agente que escribe sus propias herramientas al detectar una tarea que no sabe hacer no es magia: es un bucle que compila, testea en aislamiento y solo incorpora la habilidad si los tests pasan. Lo tienes entero en Self-Improving Loop.
Una vez sabes que has cruzado la línea, la pregunta útil ya no es "¿esto es un agente?". Es "¿en qué grado corre y qué he puesto debajo?"
Qué no es un agente, aunque lo llamen así
Un chatbot con herramientas. Buscar en la web y devolverte el resultado sigue siendo un salto único. La prueba es si puede reintentar por su cuenta a partir de lo que acaba de observar. Si no puede, es un chat con herramientas conectadas.
Un pipeline determinista con un nodo de IA. Un flujo de n8n, Zapier o Make con una caja que dice "AI" es un workflow: el camino está dibujado en el canvas y el modelo rellena huecos. Cuando un paso falla, el flujo se rompe; no reformula la estrategia.
Un RAG clásico. Recuperar, inyectar en el prompt, responder. Camino fijo, una llamada. Se vuelve agéntico solo cuando el modelo decide si vuelve a buscar, con qué query y cuándo parar. Ese "decide" es toda la diferencia.
Y una que se ha puesto de moda: más agentes no es más agente. Cinco LLM encadenados suelen ser un workflow caro con pérdida de contexto en cada salto. Cuándo compensa y cuándo es autolesión lo analicé en cuándo usar multi-agente sin orquestador.
Ninguna de las cuatro es peor que un agente. Suelen ser mejores: más baratas, más rápidas y depurables. Cuando un workflow falla, sabes en qué paso.
Cuándo NO deberías montar un agente
Para que compense tienen que darse tres condiciones. Las tres. No dos de tres.
Que exista una señal automática de si el trabajo está bien. Si el único verificador eres tú leyendo el resultado, no has delegado el bucle: lo has movido a tu bandeja de entrada.
Que el camino no sea siempre el mismo. Esta es la que más se ignora. Si el flujo es idéntico en el 95% de las ejecuciones, estás pagando a un modelo por redescubrir cada vez un orden que ya conoces. Escríbelo en código. Anthropic, en el artículo que cité arriba, recomienda buscar siempre la solución más simple posible y añade que eso "puede significar no construir sistemas agénticos en absoluto".
Y si tu duda de fondo es cuál de tus tareas merece un agente y cuál no, esa clasificación —tarea por tarea— está en cómo clasificar tareas de desarrollo para delegarlas a la IA y, con los números de coste al lado, en IA generativa vs IA agéntica.
Que el error sea reversible dentro del perímetro. Migraciones sobre datos de producción, borrados, despliegues sin rollback, correos a clientes reales. Ahí no se sube a grado 3: ahí el modelo propone y tú apruebas, que es para lo que existe el grado 2.
Falla una de las tres y la respuesta correcta es un workflow. No es una derrota: es ingeniería.
La ruta: por dónde empezar y cómo subir de nivel
Con esto claro, aprender agentes deja de ser una lista de herramientas y pasa a ser una progresión de grados.
Etapa 1 — Usa un agente antes de construir uno (grados 0-1)
Trabaja unas semanas con un harness ya hecho —Claude Code, Codex CLI, el que prefieras— sobre tu repositorio real. No para aprender la herramienta: para ver de primera mano dónde decide mal y qué información le faltaba cuando lo hizo. Eso es lo que después no sabrás diseñar si nunca lo has sufrido.
Y haz dos cosas desde el primer día, porque cambian el resultado más que el modelo que elijas.
Escribe el contrato: un CLAUDE.md en la raíz convierte al agente de invitado que improvisa en ejecutor con reglas explícitas, y cómo redactarlo está en CLAUDE.md: el contrato entre tú y el agente.
Y especifica antes de dejarle editar, porque un agente al que le pides que programe a ciegas rellena con invención todo lo que no escribiste. La metodología está en Spec-Driven Development: evita el caos de la IA, y completa, con plantillas y flujo de trabajo, en el libro de Spec-Driven Development.
Etapa 2 — Construye uno pequeño de verdad (grado 2)
No un framework: un bucle. Un objetivo, dos herramientas, argumentos validados y un criterio de parada que no sea un contador. Doscientas líneas enseñan más que cualquier tutorial, porque ves dónde se rompe.
Valida los argumentos con un schema desde la primera línea: la frontera entre el texto probabilístico del modelo y tus tipos tiene que ser explícita, y es lo que enseño en el curso de Zod. El stack mínimo completo —SDK, Zod y un bucle explícito— está en construye un agente de IA en TypeScript.
Cuando quieras que esas herramientas dejen de estar acopladas a tu código y las consuma cualquier cliente compatible, entra MCP: el recorrido completo, servidor y agente incluidos, está en cómo construir un agente de IA y su MCP server paso a paso.
Si prefieres hacer este salto acompañado y llegar de la idea a un producto funcionando, es el camino del curso Construye con IA.
Etapa 3 — Sube al grado 3 con la instrumentación por delante
Aquí se separa el proyecto de fin de semana del sistema que corre solo. Ya sabes qué exige el grado 3, así que la pregunta no es cuáles son las piezas: es en qué orden se montan. Va este, y el orden importa.
Primero el sandbox. Es la única que te protege del peor día, y es la más barata de todas: un contenedor y una rama nueva. Montarla la última es como ponerse el cinturón al llegar.
Después las trazas. Sin ellas no puedes depurar nada de lo que viene después, porque no sabrás qué decidió el agente ni con qué información.
Luego el verificador. Ahora sí puedes construirlo, porque las trazas te enseñan en qué se equivoca de verdad y contra qué merece la pena verificar.
Y por último los evals. Son el verificador aplicado a un conjunto de casos conocidos, así que llegan cuando ya tienes uno.
La memoria persistente no está en esa lista a propósito: es una optimización de coste y de continuidad, no una condición de seguridad. Se monta cuando el agente ya corre bien, no antes. Ese error de orden —memoria elegante y cero trazas— lo he visto más veces de las que me gustaría, y es también el que describo en loop engineering.
Y cuando quieras montar esto como disciplina profesional y no como proyecto suelto, el roadmap de carrera está en qué es un Agentic Engineer y cómo convertirte en uno.
Lo único que tienes que hacer hoy
Abre el repositorio de eso que llamas agente y busca la llamada al modelo.
Si alrededor no hay un bucle donde la salida de una herramienta cambia la siguiente decisión, tienes un workflow. Deja de intentar convertirlo en agente y hazlo mejor workflow: será más barato y no te despertará de madrugada.
Si sí lo hay, contesta la segunda pregunta: ¿qué señal automática le dice que ha terminado? Si la respuesta es un número de iteraciones, acabas de encontrar el trabajo de esta semana. Y es el que más te va a rentar.
Si quieres el esqueleto ya montado para no empezar de cero —bucle, herramientas y criterio de parada—, lo he empaquetado gratis en el Hermes Agent Kit.
Y si prefieres discutir arquitecturas concretas con gente que ya tiene agentes corriendo en producción, te espero en Dominicode Labs.
Preguntas frecuentes
¿Qué es un agente de IA exactamente?
Un agente de IA es un sistema en el que el modelo decide el flujo de control: qué acción se ejecuta a continuación, con qué argumentos y cuándo detenerse. No lo define la autonomía ni el uso de herramientas, sino quién elige el siguiente paso. Si el orden de las acciones está escrito en tu código, tienes un workflow con un LLM dentro. Si ese orden se decide en tiempo de ejecución a partir de lo que el sistema acaba de observar, tienes un agente.
¿Cuál es la diferencia entre un agente de IA y un workflow con un LLM?
El diagrama de flujo. El de un workflow existe antes de ejecutarlo, porque los caminos están predefinidos en código; el de un agente no existe hasta que la ejecución termina. Se comprueba con dos señales: si el número de llamadas al modelo es fijo, es un workflow; si la salida de una herramienta puede cambiar cuál se llama después, es un agente. El workflow no es una versión inferior: es más barato, más rápido y más fácil de depurar.
¿Un chatbot con herramientas es un agente de IA?
No mientras no cierre el bucle. Un chatbot que busca en la web y te devuelve el resultado ejecuta un salto único: no comprueba si lo que obtuvo resuelve el objetivo ni cambia de estrategia cuando no lo resuelve. La prueba está en el código, no en la interfaz: si no existe una iteración en la que la observación de una herramienta determine cuál se llama después, tienes un chat con herramientas conectadas.
¿ChatGPT o Claude son agentes de IA?
Por sí solos no: son modelos servidos tras una interfaz de chat, y ahí el bucle lo cierras tú al leer la respuesta y escribir la siguiente instrucción. Se convierten en la política de decisión de un agente cuando los envuelves en un sistema que ejecuta sus llamadas a herramientas y le devuelve el resultado para que decida el siguiente paso: eso es lo que hacen Claude Code o Codex CLI. El agente no es el modelo; es el modelo más el bucle, las herramientas y el criterio de parada.
¿Qué ejemplos reales de agentes de IA hay hoy?
Los más maduros en 2026 son los agentes de programación que corren sobre un repositorio: Claude Code, Codex CLI de OpenAI, Cursor en modo agente y Gemini CLI. Todos comparten la misma estructura: un bucle que lee ficheros, ejecuta comandos, observa la salida y decide la siguiente acción, con los tests como criterio de parada. Fuera del código, los casos que funcionan son los que tienen verificación automática: triaje de incidencias, migraciones de datos validadas contra un schema y control de calidad de contenido.
¿Necesito LangChain o un framework de agentes para construir el mío?
No. El núcleo de un agente son unas doscientas líneas: un bucle, un catálogo de herramientas con argumentos validados, el historial de observaciones y un criterio de parada. Escribirlo a mano una vez enseña más que LangChain, Mastra o el Vercel AI SDK juntos, porque ves exactamente dónde se rompe. El framework empieza a compensar después: cuando necesitas persistencia entre ejecuciones, orquestación de varios procesos o trazabilidad estándar.
¿Por qué un límite de iteraciones no sirve como criterio de parada?
Porque es un timeout: evita que el agente gaste tokens sin fin, pero no dice nada sobre la calidad del resultado. El criterio de parada es una señal externa al modelo que responde sí o no sobre si el objetivo está cumplido: tests en verde, typecheck limpio, un schema que valida la salida o un eval puntuado. Sin esa señal, el agente termina cuando cree que ha terminado, y esa creencia no se puede auditar.
¿Cuándo no conviene usar un agente de IA?
Cuando falla alguna de estas tres condiciones. Que exista una señal automática capaz de decir si el trabajo está bien hecho sin que lo revises tú. Que el camino no sea siempre el mismo, porque si el flujo es idéntico en casi todas las ejecuciones estás pagando por redescubrir un orden que ya conoces. Y que el error sea reversible: sobre datos de producción, borrados o despliegues sin rollback, el modelo propone y tú apruebas.
¿Es lo mismo un agente de IA que un sistema multi-agente?
No, y encadenar varios modelos no hace el sistema "más agéntico". Un sistema multi-agente reparte el trabajo entre varias instancias con roles distintos, y cada salto pierde contexto, suma latencia y multiplica el coste. Muchas veces lo que se ha modelado como un segundo agente debería haber sido una herramienta del primero. Empieza con un solo agente y varias herramientas.
Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.
