La primera vez que vi a Claude Code refactorizar un módulo entero de TypeScript por sí solo, pensé que estaba viendo magia.
Abrió el archivo. Leyó el código. Identificó el problema. Buscó dependencias en otros archivos. Editó tres ficheros en orden. Ejecutó los tests. Vio que uno fallaba. Corrigió el error. Volvió a ejecutar. Verde. Listo.
Todo eso sin que yo le dijera qué hacer en cada paso. Le di un objetivo y él resolvió el camino.
Lo que estaba viendo no era magia. Era el agentic loop en funcionamiento — el mecanismo que convierte un LLM pasivo en un agente que percibe, decide y actúa de forma continua hasta completar una tarea. Si estás construyendo con IA en 2026, entender cómo funciona este bucle es tan importante como entender cómo funciona el event loop de Node.
Soy Bezael Pérez, developer senior y fundador de Dominicode. Llevo más de 15 años trabajando con software y los últimos dos obsesionado con cómo los agentes de IA cambian la forma de construir productos.
La diferencia que cambia todo: LLM vs. agente
Un LLM por sí solo es una función de texto: le das un input, devuelve un output. Extraordinariamente potente, pero estático. No sabe qué pasó antes. No puede hacer nada en el mundo real. No puede corregirse si se equivoca. Recibe. Responde. Se detiene.
Un agente es diferente en una sola dimensión — pero esa dimensión lo cambia todo: puede actuar sobre su entorno y observar las consecuencias.
Cuando le preguntas a ChatGPT “¿cómo conecto a PostgreSQL desde TypeScript?”, eso es un LLM. Te da la respuesta. Te toca a ti ejecutarla, ver si funciona, corregirla si falla.
Cuando Claude Code abre tu proyecto, lee los archivos, escribe el código, ejecuta los tests y corrige los errores — eso es un agente con agentic loop. La diferencia no está en el modelo. Está en el bucle.
Las fases del agentic loop
El agentic loop no es un concepto abstracto. Es una arquitectura de ejecución con fases concretas que se repiten hasta que el agente completa su objetivo o se queda sin herramientas para avanzar. Este patrón lo formalizaron Yao et al. en el paper ReAct: Synergizing Reasoning and Acting in Language Models (2022) y es hoy la base de la mayoría de frameworks de agentes.
Fase 1: Percibir
El agente recibe información del entorno. Puede ser el mensaje del usuario, el resultado de una herramienta ejecutada en el ciclo anterior, el contenido de un archivo, una respuesta HTTP, el output de un comando de terminal.
Esta fase parece trivial. No lo es. La calidad de lo que el agente percibe determina la calidad de lo que decide a continuación. Un agente que lee mal el contexto toma decisiones incorrectas con total confianza — y eso en producción es mucho más peligroso que un error que falla de forma evidente.
Este fragmento muestra qué recibe el agente al inicio de cada ciclo: el mensaje del usuario, los resultados de herramientas anteriores y el system prompt que define sus capacidades:
// Lo que el agente "percibe" en cada ciclo
const context = {
userMessage: "Refactoriza el módulo de autenticación para usar Signals",
previousToolResults: [
{
tool: "read_file",
output: "// auth.service.ts\nimport { Injectable } from '@angular/core'..."
}
],
systemPrompt: "Eres un assistant que refactoriza código Angular. Tienes acceso a las herramientas: read_file, write_file, execute_command."
};Fase 2: Razonar
El LLM procesa el contexto acumulado y decide qué hacer a continuación. Esta es la fase donde el modelo aplica su capacidad de razonamiento: evalúa el estado actual, compara con el objetivo, identifica el próximo paso.
En modelos modernos como Claude Sonnet o GPT-4o, esta fase incluye razonamiento encadenado — el modelo se habla a sí mismo internamente antes de producir una decisión. En Claude, Anthropic expone este razonamiento explícitamente como “extended thinking” en la respuesta de la API — una feature específica de su plataforma, no un estándar cross-API.
Lo que el agente produce en esta fase no es una respuesta de texto. Es una decisión estructurada: qué herramienta usar, con qué argumentos, por qué.
En lugar de texto libre, el razonamiento del agente produce una llamada estructurada a herramienta. Este pseudocódigo representa esa decisión (el campo thinking es razonamiento interno del modelo — no lo recibes como developer en la respuesta de la API):
// pseudocódigo — thinking es interno al modelo, no un campo de la API
const agentDecision = {
thinking: "Necesito leer el archivo auth.service.ts antes de modificarlo",
toolCall: {
name: "read_file",
arguments: {
path: "src/app/auth/auth.service.ts"
}
}
};Fase 3: Actuar
El agente ejecuta la herramienta que decidió usar. Aquí es donde la IA toca el mundo real: escribe en disco, llama a una API externa, ejecuta SQL, navega una página web, envía un email.
Esta es también la fase más delicada desde el punto de vista de seguridad y control. Una acción ejecutada no se puede deshacer fácilmente. Por eso los sistemas de agentes bien diseñados implementan sandboxes, confirmaciones humanas para acciones irreversibles y límites explícitos en qué herramientas puede usar el agente.
La función executeToolCall implementa esta capa de ejecución: recibe la decisión estructurada del agente y ejecuta la acción real sobre el sistema:
// Ejecución de la herramienta — el agente actúa sobre el entorno
async function executeToolCall(toolCall: ToolCall): Promise<ToolResult> {
switch (toolCall.name) {
case "read_file":
return { output: await fs.readFile(toolCall.arguments.path, "utf-8") };
case "write_file":
await fs.writeFile(toolCall.arguments.path, toolCall.arguments.content);
return { output: "Archivo escrito correctamente" };
case "execute_command":
const result = await exec(toolCall.arguments.command);
return { output: result.stdout, error: result.stderr };
default:
throw new Error(Herramienta desconocida: ${toolCall.name});
}
}Fase 4: Observar
El agente recibe el resultado de la acción ejecutada y lo incorpora a su contexto. Si leyó un archivo, ahora tiene el contenido. Si ejecutó un test, ahora sabe si pasó o falló. Si llamó a una API, tiene la respuesta — o el error.
Esta fase cierra el bucle. El resultado de la observación se convierte en nuevo input para la siguiente iteración de Percibir → Razonar → Actuar. El agente actualiza su modelo interno del estado del mundo y decide si ha completado su objetivo o si necesita otro ciclo.
El resultado de la herramienta vuelve al contexto como un mensaje más. El modelo evalúa si ha terminado o si necesita otra herramienta:
// El resultado se incorpora al contexto para el siguiente ciclo
messages.push({
role: "tool",
content: toolResult.output,
toolCallId: toolCall.id
});
// ¿Ha completado el objetivo? El modelo decide. const nextStep = await llm.complete(messages); // Si devuelve texto sin tool_call → tarea completada // Si devuelve otro tool_call → el bucle continúa
Repetir (o detenerse)
El bucle continúa mientras el agente tenga herramientas que ejecutar y no haya alcanzado su objetivo. Se detiene cuando el modelo produce una respuesta de texto sin invocar ninguna herramienta — lo que indica que considera la tarea completada — o cuando alcanza el límite de iteraciones definido en la configuración.
Ese límite de iteraciones no es un detalle menor. Es una de las decisiones de diseño más importantes en un sistema agéntico. Un agente sin límite puede quedar atrapado en un bucle infinito consumiendo tokens y ejecutando acciones hasta que alguien apague el proceso.
Cómo lo implementan las herramientas reales
No tienes que construir el agentic loop desde cero. Las herramientas que ya existen lo implementan por ti, con tres aproximaciones distintas: ejecución local directa (Claude Code), orquestación de grafos (LangGraph) y no-code visual (n8n). Cada una optimiza para un perfil diferente de developer y caso de uso.
- Claude Code — Loop completo con herramientas del sistema operativo: leer/escribir archivos, ejecutar comandos de terminal, buscar en el codebase. El agente decide autónomamente qué pasos dar y puedes verlo trabajar en tiempo real en la terminal.
- LangChain / LangGraph — Loop como grafo de nodos configurables. Tú defines las transiciones, condiciones de parada y herramientas. Más control y flexibilidad para flujos con ramificaciones complejas.
- n8n — AI Agent nodes que envuelven el loop en un flujo visual. Ideal para automatizaciones de negocio con APIs externas, webhooks y transformaciones de datos sin escribir código.
- AutoGPT / BabyAGI — La primera ola de agentes. Implementaron el loop de forma casi literal: generaban sus propias subtareas, las priorizaban y las ejecutaban. Funcionaban en demos, fallaban en producción por acumulación de errores en cada ciclo y falta de controles.
Si quieres profundizar en cómo construir el harness que envuelve el loop, este análisis sobre harness engineering con agentes de IA cubre la capa de orquestación en detalle.
Por qué los agentes fallan — y no es culpa del modelo
El agentic loop tiene un problema estructural que los developers aprenden a la fuerza: los errores se propagan y se amplifican.
En un LLM normal, si el modelo alucina en la respuesta, el usuario lo ve y puede corregirlo. En un agente con agentic loop, si el modelo toma una decisión incorrecta en el ciclo 2, esa decisión puede contaminar los ciclos 3, 4 y 5 antes de que nadie se dé cuenta. Para cuando el agente termina, puede haber modificado archivos, llamado a APIs y tomado decisiones basadas en una premisa incorrecta del principio.
Hay tres patrones de fallo que aparecen una y otra vez en producción:
Context drift — El contexto acumulado crece ciclo a ciclo. En conversaciones largas, el modelo empieza a perder el hilo de los objetivos originales y se centra en los últimos resultados. El agente puede alcanzar un estado donde “funciona” localmente pero ha perdido el objetivo global.
Tool loop — El agente entra en un ciclo donde ejecuta la misma herramienta con los mismos argumentos repetidamente porque no sabe cómo interpretar el resultado. Sin un límite de iteraciones y sin detección de patrones repetitivos, consume tokens hasta el límite de la sesión.
Overconfidence — El modelo decide con alta confianza en casos donde debería pedir confirmación. Elimina un archivo que creía temporal. Envía un email que debía ser un borrador. Ejecuta una migración de base de datos en producción. La confianza del modelo no tiene correlación con la corrección de la acción.
La solución no es usar un modelo más inteligente. Es diseñar el sistema con los controles correctos: límites de iteración, human-in-the-loop para acciones irreversibles, y observabilidad para saber exactamente qué está haciendo el agente en cada ciclo. Si te interesa la parte de observabilidad, en el post sobre observabilidad en LLMs: traza, mide y depura tus agentes cubrimos cómo instrumentar el loop con trazas y métricas reales.
Cuándo usar el agentic loop (y cuándo no)
El agentic loop resuelve una clase específica de problemas. Usarlo para todo es uno de los errores más comunes que veo en equipos que empiezan con IA.
Úsalo cuando:
- La tarea requiere múltiples pasos que dependen del resultado de los anteriores
- El objetivo está claro pero el camino para alcanzarlo no se puede definir de antemano
- Necesitas interactuar con herramientas externas en función del contexto
- La tarea implica explorar un espacio de posibilidades (búsqueda, refactorización, análisis)
Ejemplos concretos: refactorizar un módulo de código, investigar un bug leyendo múltiples archivos, rellenar formularios complejos a partir de documentos, ejecutar una pipeline de procesamiento de datos donde cada paso depende del anterior.
No lo uses cuando:
- Puedes resolver el problema con un solo prompt bien diseñado
- La latencia importa y el usuario está esperando una respuesta inmediata
- Las acciones son irreversibles y el contexto no garantiza que el agente tomará la decisión correcta
- El problema tiene una solución determinista que no requiere razonamiento iterativo
Un agente que escribe el texto de un email de bienvenida es sobre-ingeniería. Un LLM con el prompt correcto lo hace en un ciclo, sin herramientas, en 200ms. Reserva el agentic loop para los problemas que lo necesitan de verdad.
En el curso Construye con IA abordamos exactamente este criterio de decisión: qué arquitectura elegir para cada problema, cuándo un agente añade valor real y cuándo un prompt bien diseñado es más efectivo, rápido y barato.
El agentic loop en 2026: dónde está el límite real
El límite ya no es la capacidad del modelo. Los LLMs actuales razonan lo suficientemente bien como para completar tareas complejas de múltiples pasos.
El límite es la confianza que puedes depositar en el sistema.
Confiar en que el agente tomará la decisión correcta en cada ciclo, sin supervisión humana, es una apuesta que depende del dominio, del riesgo de las acciones y de la calidad de las herramientas que le has dado. En tareas de desarrollo donde los cambios son reversibles (código en un repositorio con git), puedes darle mucha autonomía. En tareas que afectan a clientes o datos de producción, el loop necesita checkpoints humanos.
El patrón que están adoptando los equipos más avanzados es human-in-the-loop selectivo: el agente actúa de forma autónoma en la mayoría de ciclos, pero solicita confirmación explícita antes de ejecutar acciones que superen un umbral de riesgo definido en el sistema.
No es rendirse al agente ni microgestionar cada paso. Es diseño de sistema con criterio.
Si quieres ver cómo aplico este patrón en proyectos reales — y explorar los proyectos que la comunidad está construyendo con agentes en producción — pásate por Dominicode Labs. Hay recursos, proyectos y discusiones que no publicaré en el blog.
FAQ — Preguntas frecuentes sobre el agentic loop
¿Qué diferencia hay entre un chatbot y un agente con agentic loop?
Un chatbot procesa mensajes y genera respuestas de texto. No ejecuta acciones en el mundo real ni mantiene un estado entre ciclos más allá del historial de conversación. Un agente con agentic loop puede leer archivos, llamar a APIs, ejecutar código y tomar decisiones basadas en los resultados de esas acciones — repitiendo el ciclo hasta completar un objetivo complejo.
¿El agentic loop necesita un modelo específico o funciona con cualquier LLM?
Técnicamente funciona con cualquier LLM que soporte function calling o tool use. En la práctica, la calidad del loop depende mucho de la capacidad del modelo para razonar sobre los resultados de las herramientas y decidir el siguiente paso correcto. Claude Sonnet, GPT-4o y Gemini 2.5 Pro son los modelos que ofrecen resultados más consistentes hoy. Modelos más pequeños fallan con más frecuencia en las fases de razonamiento y en la detección de cuándo el objetivo está completo.
¿Cuántas iteraciones puede hacer un agente antes de fallar o perder el hilo?
Depende del modelo y del tamaño del contexto. Los modelos actuales con ventanas de contexto grandes (200k tokens en Claude) pueden mantener coherencia durante decenas de iteraciones en tareas bien definidas. En la práctica, la degradación empieza a notarse alrededor de las 20-30 iteraciones en tareas complejas con mucho contexto acumulado. Un buen sistema define un maxIterations entre 10 y 50 según el dominio, con lógica de parada anticipada si detecta patrones repetitivos.
¿Claude Code usa un agentic loop?
Sí. Claude Code implementa el agentic loop completo: lee el contexto del proyecto, decide qué herramientas usar (leer archivos, escribir código, ejecutar comandos), observa los resultados y repite hasta completar la tarea. La diferencia con un uso básico de la API de Claude es que Claude Code orquesta este bucle de forma transparente, con acceso al filesystem y al terminal, y con la capacidad de autocorregirse cuando un test falla o un comando devuelve un error.
¿Es el agentic loop lo mismo que el “chain of thought”?
No. Chain of thought es una técnica de prompting donde el modelo razona paso a paso antes de dar una respuesta — todo ocurre dentro de una sola llamada al LLM. El agentic loop es una arquitectura de ejecución que implica múltiples llamadas al modelo, ejecución real de herramientas entre llamadas, y un estado que se actualiza en cada ciclo. Chain of thought puede ser parte de la fase de razonamiento dentro del loop, pero son conceptos de nivel diferente.
Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.
Si este post te ha sido útil, hay más contenido técnico sobre IA aplicada al desarrollo en el canal de YouTube de Dominicode.
