Bucle de agentes: qué es y por qué importa más que el prompt

El ángulo que nadie está contando

La narrativa popular es que estamos entrando en la era del agente autónomo. Suena bien. Pero lo que está pasando de verdad es algo menos glamuroso y mucho más útil: estamos profesionalizando el feedback loop.

No es casualidad que casi todos los ejemplos serios de agentes que funcionan en producción compartan estructura. Hay una tarea acotada. Hay herramientas claras. Hay una comprobación externa. Hay un máximo de iteraciones. Y hay un punto donde el sistema escala al humano o termina. Eso no se parece a una inteligencia autónoma general. Se parece a un pipeline con esteroides.

El giro importante aquí es que Peter no está diciendo “deja de usar prompts”. Está diciendo algo más incómodo: si sigues trabajando prompt a prompt, estás operando al nivel equivocado. El trabajo valioso ya no es escribir la frase perfecta para que el agente acierte. El trabajo valioso es diseñar el entorno donde pueda equivocarse barato, corregirse rápido y parar a tiempo.

Por eso casi toda la conversación pública sobre “multi-agent” está un poco torcida. Mucha gente enseña flotas de agentes porque venden mejor en una demo. Pero en la práctica, el salto de valor no suele venir de meter cinco agentes. Viene de meter una evaluación seria. Un worker sin evaluador produce una salida. Un worker con evaluador produce iteración. Y esa diferencia pesa más que añadir tres especialistas decorativos.

Volviendo al suelo

Esto no significa que los prompts hayan muerto ni que mañana todo deba ser una arquitectura de agentes. Un montón de tareas siguen resolviéndose mejor con una sola instrucción buena y un humano atento. Tampoco significa que cualquier loop sea útil. Si la evaluación es floja, el sistema solo automatiza errores con más eficiencia.

También conviene reconocer lo bueno de la narrativa optimista: sí, los agentes actuales ya pueden recorrer ciclos muy útiles de plan → ejecutar → revisar → corregir. La mejora es real. Lo que no conviene comprar sin pensar es la parte mesiánica de “ya no supervises nada”. Hoy, en trabajo real, la mayoría de los sistemas buenos siguen siendo closed loops: acotados, medibles y aburridamente fiables.

A quién le importa esto

Esto te importa de verdad si trabajas con tareas repetibles donde la primera salida rara vez es suficiente. Tres perfiles claros:

• Si usas agentes de código para features pequeñas, tests, refactors o debugging.
• Si produces contenido técnico, landings o research y luego siempre acabas reescribiendo tú.
• Si operas procesos con checklist clara: soporte, QA, clasificación, enrichments, síntesis de fuentes.

El umbral práctico es sencillo: si hoy haces dos o más rondas manuales casi siempre, ya tienes un candidato a loop. Si en cambio tu tarea es un one-shot y la respuesta sale suficientemente bien a la primera, no compliques nada. Ahí el loop sobra.

La pieza que te llevas

Empieza por el diseño más humilde que funciona: worker + evaluator + máximo 3 iteraciones.

No montes una flota. No montes memoria compartida. No montes ocho roles porque has visto un gráfico bonito en X. Monta esto:

La lógica es esta:

1. defines un objetivo claro
2. el worker produce
3. el evaluator puntúa
4. si falla, vuelve con cambios concretos
5. repites 2 o 3 veces como máximo

En OpenClaw esto se puede montar con una sesión principal y subagentes separados por rol. En Claude también puedes simularlo en un solo prompt por fases, pero pierdes parte del control porque el juez y el ejecutor viven en la misma cabeza.

La lección importante no es “usa más agentes”. Es esta: deja de pensar en prompts sueltos y empieza a pensar en circuitos de mejora.

Ese es el cambio de nivel. Y el siguiente paso natural no es teorizar más, sino enseñar cómo se construye uno bien: con orquestador, evaluación, límites, memoria y criterio de salida. Pero eso merece tutorial propio.