El loop secreto de un agente | Mike Bermeo

En el post anterior vimos que Claude Code no es un chat: por fuera parece una conversación, pero por dentro se comporta como un sistema que observa, actúa y decide. Y al final dejamos una pregunta abierta.

¿Cuál es el mecanismo que hace posible ese comportamiento?

Si el sistema no resuelve todo en una sola pasada, tiene que existir alguna estructura que conecte cada paso. Una estructura que le permita mirar algo, actuar, ver qué pasó, y volver a decidir.

Esa estructura es el loop. Y vale la pena abrirlo.

La secuencia que mueve todo

Un agente no recibe una instrucción y la resuelve de un golpe. Entra en un ciclo. La secuencia básica tiene cuatro momentos:

Interpreta — lee el contexto disponible y entiende dónde está.
Decide — elige cuál es la siguiente acción más útil.
Actúa — ejecuta esa acción usando una herramienta.
Evalúa — mira el resultado y decide si ya tiene suficiente, o si necesita otra vuelta.

Si no tiene suficiente, vuelve al principio. Si tiene suficiente, responde.

flowchart LR
  I(["🧠 Interpreta"]):::model --> D
  D{{"¿Qué hacer?"}}:::decision --> A
  A(["🔧 Actúa"]):::tool --> E
  E(["📋 Evalúa"]):::result --> G
  G{{"¿Suficiente?"}}:::decision
  G -->|"No"| I
  G -->|"Sí"| R(["💬 Responde"]):::output

  classDef model    fill:#312e81,stroke:#818cf8,color:#e2e2f0,stroke-width:2px
  classDef decision fill:#1c1917,stroke:#f59e0b,color:#fbbf24
  classDef tool     fill:#164e63,stroke:#22d3ee,color:#e2e2f0
  classDef result   fill:#1c1917,stroke:#78716c,color:#a8a29e
  classDef output   fill:#14532d,stroke:#4ade80,color:#e2e2f0

  linkStyle 4 stroke:#818cf8,stroke-width:2px,stroke-dasharray:5
  linkStyle 5 stroke:#4ade80,stroke-width:2px

La flecha que vuelve hacia atrás es la pieza más importante de este diagrama. Sin ella no hay loop, hay solo generación de texto. Con ella, el sistema puede salir de sí mismo, tocar una herramienta, mirar el mundo, y volver con información nueva.

Ahí es donde deja de girar únicamente sobre lo que ya sabía.

Lo que pasa de verdad en una tarea

La teoría es una cosa. El comportamiento concreto, otra.

Imagina que le pides al agente: “encuentra por qué esta función está fallando”. No es una pregunta que se pueda responder con intuición. Hay que buscar. Hay que mirar. Hay que comparar.

Así se vería el loop en acción para esa tarea:

sequenceDiagram
  actor U as Usuario
  participant M as 🧠 Modelo
  participant RF as readFile
  participant GR as grep
  participant BA as bash

  U->>M: "encuentra por qué falla handleAuth"

  Note over M: Vuelta 1 — necesito ver el código
  M->>RF: readFile("src/auth/handleAuth.ts")
  RF-->>M: código de la función (espera 2 args)

  Note over M: Vuelta 2 — quién la llama y cómo
  M->>GR: grep("handleAuth(", "src/")
  GR-->>M: 3 referencias encontradas

  Note over M: Vuelta 3 — hay una llamada con 1 arg, sospechosa
  M->>BA: bash("npm test -- --filter=auth")
  BA-->>M: FAIL: expected 2 arguments, got 1

  Note over M: Ya tengo evidencia concreta
  M->>U: "El problema está en api/routes.ts línea 47..."

Cuatro intercambios. Tres herramientas distintas. Cada vuelta cambia lo que el modelo sabe, y ese cambio determina qué hace en la siguiente.

En código, cada una de esas vueltas se ve algo así:

// El agente decide: necesito ver qué recibe handleAuth
const archivo = await tool.readFile("src/auth/handleAuth.ts")

// Observa: la función espera (userId: string, token: string)
// Decisión: ¿suficiente? No. Necesito ver quién la llama.

// El agente decide: necesito ver cómo se llama en el proyecto
const refs = await tool.grep("handleAuth(", "src/")

// Observa: 3 resultados. Uno en api/routes.ts pasa solo 1 argumento.
// Decisión: ¿suficiente? Casi. Necesito confirmar que ese es el fallo.

// El agente decide: corro el test para verificar
const test = await tool.bash("npm test -- --filter=auth")

// FAIL: handleAuth expected 2 arguments, got 1 at routes.ts:47
// Decisión: ¿suficiente? Sí. Tengo evidencia concreta.

Nótalo: el agente no inventó la respuesta en la vuelta 1. Tampoco en la vuelta 2. La construyó con pasos. Solo respondió cuando tenía algo más que una suposición.

Eso es lo que cambia el loop.

Cada vuelta es una decisión

Hay algo fácil de perder en este mecanismo: el loop no es una repetición mecánica.

Un for itera un número fijo de veces. Un while sigue hasta que una condición cambia. El loop de un agente se parece mucho más al segundo, pero la condición no es un contador ni un booleano simple. Es una evaluación de contexto.

En cada vuelta, el agente responde implícitamente a una pregunta:

Si la respuesta es “me falta”, elige una acción nueva y vuelve. Si la respuesta es “tengo suficiente”, sale del ciclo y responde.

En pseudocódigo, la lógica se ve así:

async function resolverTarea(tarea: string) {
  let contexto = analizar(tarea)

  while (!tengoSuficiente(contexto)) {          // evalúa en cada vuelta
    const accion = decidirSiguientePaso(contexto)
    const resultado = await ejecutar(accion)    // toca el mundo
    contexto = incorporar(contexto, resultado)
  }

  return redactarRespuesta(contexto)
}

Las dos líneas resaltadas son el corazón del sistema. La primera es la pregunta. La segunda es la acción. Todo lo demás es contexto que se acumula vuelta a vuelta.

El loop no es infinito

Entender el loop también significa entender sus límites.

El ciclo no existe para que el agente dé vueltas sin fin. Existe para que pueda repetir solo lo necesario. Y eso implica moverse entre dos riesgos reales:

flowchart TD
  T(["📥 Tarea recibida"]):::neutral --> P & S & E

  P(["⚡ Responde ya"]):::bad
  P --> PB(["Sin evidencia"]):::bad
  PB --> PR(["❌ Error probable"]):::danger

  S(["✅ Loop sano 2-5 vueltas"]):::good
  S --> SB(["Evidencia verificada"]):::good
  SB --> SR(["✓ Respuesta fundamentada"]):::success

  E(["🌀 Sigue buscando"]):::bad
  E --> EB(["10+ vueltas sin converger"]):::bad
  EB --> ER(["❌ Sin respuesta"]):::danger

  classDef neutral fill:#1e1b4b,stroke:#818cf8,color:#e2e2f0
  classDef bad     fill:#1c1917,stroke:#78716c,color:#a8a29e
  classDef danger  fill:#450a0a,stroke:#f87171,color:#fca5a5
  classDef good    fill:#1a2e1a,stroke:#4ade80,color:#86efac
  classDef success fill:#14532d,stroke:#4ade80,color:#e2e2f0

  linkStyle 1,2 stroke:#f87171,stroke-dasharray:4
  linkStyle 3,4 stroke:#4ade80,stroke-width:2px
  linkStyle 5,6 stroke:#f87171,stroke-dasharray:4

El fallo por la izquierda es responder antes de mirar: el agente devuelve algo plausible, pero sin evidencia real detrás. El fallo por la derecha es seguir investigando sin converger: el agente sigue abriendo archivos, buscando patrones, corriendo comandos, y nunca decide que tiene suficiente.

El número de vueltas no es lo que mide la calidad del trabajo. Lo que mide es la calidad de cada decisión de continuar o parar.

Corrección, no sofisticación

Hay una tendencia a ver el loop como una señal de que el sistema es “más sofisticado”. Más pasos, más impresionante.

Pero eso invierte la causalidad.

El loop no existe para parecer más capaz. Existe para poder corregirse. Cada vuelta es una oportunidad de contrastar lo que el modelo supone contra lo que el mundo muestra. En vez de inventar, puede revisar. En vez de asumir, puede verificar.

	Sin loop	Con loop
Fuente de la respuesta	Intuición del modelo	Evidencia acumulada
Manejo de errores	Los ignora o los inventa	Los descubre y corrige
Base de confianza	”Creo que es así"	"Lo verifiqué así”
Qué pasa si falla	La respuesta falla en silencio	El ciclo lo detecta y ajusta
Calidad en tareas complejas	Degrada rápido	Se mantiene con más pasos

La columna de la derecha no requiere un modelo más inteligente. Requiere la estructura para poder revisarse.

Eso es lo que agrega el loop: no inteligencia, sino corrección.

Lo que cambia cuando lo ves así

Cuando entiendes que Claude Code trabaja con un ciclo interno, varias cosas que antes podían parecer raras empiezan a tener sentido.

Entiendes por qué a veces avanza en etapas y no responde de inmediato. Entiendes por qué lee un archivo antes de contestar algo que parecería obvio. Entiendes por qué una respuesta buena suele ser el resultado de varias microdecisiones que no ves.

Y te cambia la forma de leer lo que pasa en pantalla.

Ya no miras solo el output. Empiezas a ver el proceso que lo produce.

Lo que viene después

El loop te dice cómo trabaja el agente.

Pero todavía no abrimos la pregunta más concreta que viene después: qué significa exactamente “actuar”. Porque ya vimos que el agente puede leer archivos, buscar texto, correr comandos. Pero no lo hemos mirado de cerca.

Qué pasa cuando decide usar una herramienta. Qué es una tool, de dónde vienen, cómo las elige.

Eso es lo que toca abrir en el próximo episodio.