Agent Engineering

Loop Engineering: Construye el Loop que Te Atrapa

El prompt engineering pregunta qué decir. El loop engineering pregunta cómo termina el trabajo un sistema — y, en sus mejores días, cómo te condena a ti.

La versión corta

Durante dos años aprendimos a escribir mejores prompts. Un prompt es un volante. No es un auto.

El trabajo real necesita el resto: una meta que puedas verificar, un lugar donde anotar las cosas, frenos, un termómetro, un mecánico, un adulto que dé el visto bueno, y un cuaderno para que mañana empiece más inteligente que hoy. Eso es un loop, y construir uno es ingeniería.

La parte de la que nadie escribe es la buena: un loop bien construido eventualmente te dirá a ti que estabas equivocado. Mi propio loop lo hizo cuatro veces en una semana. Esas cuatro historias son la evidencia de este texto, y costaron más de conseguir que el diagrama.

La casa del árbol

Tu papá te dice: construye una casa del árbol segura.

No cierras los ojos, dices una frase mágica, y despiertas con una casa en el árbol. Ejecutas un bucle. ¿Qué significa "seguro"? ¿Con qué madera cuento? ¿Encajó la tabla? ¿Se tambalea la escalera? ¿Qué se rompió? ¿Puede mi hermano menor subirse?

Ahora cambia los sustantivos. La casa en el árbol se convierte en software. Las tablas se convierten en código. Los tornillos se convierten en llamadas a la API. El chequeo de seguridad se convierte en tests. Papá se convierte en revisión humana. El cuaderno se convierte en memoria. Los errores se convierten en retroalimentación.

Un agente no es poderoso porque responde una vez. Es poderoso porque puede intentar, observar, juzgar, corregir e intentar de nuevo.

Mapa uno a uno

Esa tabla es toda la arquitectura. Todo lo que sigue es detalle.

Por qué un prompt no basta

Un prompt puede decir arregla este bug. Un agente de programación debe leer el issue, inspeccionar el repositorio, encontrar los archivos, formular una hipótesis, editar, ejecutar las pruebas, leer los fallos, parchar de nuevo, volver a ejecutar, resumir la evidencia, abrir un pull request y esperar la revisión.

Eso no es un prompt. Es un sistema operativo con un volante pegado.

La columna vertebral

User intent → Goal Contract → State Ledger → Planner → Tool Router
→ Policy Gate → Executor → Observer → Evaluator → Recovery
→ Human Gate → Memory → next loop or delivery

Contrato de Objetivo — el ticket de pedido

Un ticket de restaurante dice: mesa 7, pollo, sin maní, picante medio, veinte minutos. Sin eso, la cocina adivina.

Malo: […]arregla el problema del checkout. Bien:

{
  "objective": "Fix timeout during checkout payment confirmation",
  "success_criteria": [
    "Payment confirmation completes under 3 seconds",
    "Existing payment tests pass",
    "No duplicate charges are created",
    "Pull request includes test evidence"
  ],
  "constraints": {
    "max_iterations": 8,
    "max_cost_usd": 10,
    "forbidden_actions": ["deploy_to_production"],
    "requires_human_approval": ["database_migration", "payment_logic_change"]
  }
}

La mayoría de los sistemas de agentes no fallan porque el modelo sea tonto. Fallan porque el objetivo era vago. Objetivo vago, plan vago, uso aleatorio de herramientas, caos costoso.

Registro de estado — la pizarra

Cuando arreglas una bicicleta, anotas lo que intentaste. El modelo es el cerebro; el registro es la pizarra. No le pidas al cerebro que también sea la pizarra: el contexto se degrada, la salida de las herramientas es ruidosa y el razonamiento viejo se vuelve obsoleto.

Registra cada llamada a herramienta con: estado, iteración, hipótesis actual, pasos completados, preguntas abiertas, último error.

Compuerta de política — los frenos

Un adolescente puede usar un cuchillo de cocina. Un adolescente no debería usar una motosierra solo. La compuerta de política es el adulto parado junto a la motosierra, y tiene que ser código:

def policy_gate(tool, args, state):
    if tool == "process_refund":
        if not state.get("verified_customer_id"):
            return {"allowed": False, "next_action": "lookup_verified_customer"}
        if args["amount"] > 500:
            return {"allowed": False, "next_action": "escalate_to_human"}
    if tool == "deploy_to_production":
        return {"allowed": False, "next_action": "request_approval"}
    return {"allowed": True}

Las instrucciones de un prompt son probabilísticas. Las compuertas son deterministas. Si la acción involucra dinero, producción, privacidad, seguridad o exposición legal, la probabilidad no basta.

Evaluador — el termómetro

No adivinas si el pollo está cocido. Prioriza chequeos deterministas —las pruebas pasan, el esquema valida, los tipos verifican, los números cuadran— y usa un modelo para juzgar solo lo que de verdad requiere juicio.

Nunca preguntes ¿esto está bien? Pregunta ¿qué criterios se cumplieron, cuáles no, y qué evidencia respalda el veredicto? Una evaluación que no produce la siguiente acción es solo una opinión.

Recuperación — el mecánico

Se te cae la cadena de la bici. No compras una bici nueva. Primero clasifica, luego actúa: los fallos transitorios se reintentan con espera progresiva, los fallos de validación revisan la entrada, los fallos de permiso solicitan acceso, los fallos de regla de negocio detienen el proceso o lo escalan. Y si el mismo fallo se repite tres veces, toca cambiar de estrategia.

Reintentar no es una estrategia. Es una herramienta. Un buen agente no se esfuerza más; lo intenta distinto.

Detenerse — control, no fracaso

Dejas de construir cuando la estructura es estable, la escalera es segura y papá lo aprueba, no cuando estás cansado. Define cinco puntos de detención antes de ejecutar cualquier cosa: éxito, fracaso, escalamiento, presupuesto, seguridad. Un bucle que no puede detenerse no es autónomo. Está perdido.

Compuerta humana — el adulto responsable

Escalar no es que el agente falle. Es cómo los sistemas serios se mantienen seguros. Pero "need human help" es una escalación inútil. Una buena lleva consigo la decisión requerida, la recomendación, la evidencia, el riesgo y las alternativas — y un humano debería poder decidir en menos de dos minutos.

Memoria — curada, nunca automática

Una mala memoria acumula errores; una buena memoria acumula sabiduría. Por eso la memoria es propuesta por el agente y aprobada por un humano o una compuerta. Guarda solo las lecciones que sean específicas, respaldadas por evidencia, reutilizables y ligadas a una acción futura.

Cuatro veces en que el bucle me atrapó

Aquí está la parte que no habría podido escribir hace un año. Estas historias vienen de una semana construyendo mi propia flota, y cada una es un caso en el que la maquinaria que construí me dijo que estaba equivocado. Ese es el retorno del loop engineering: no velocidad, sino corrección.

1. El primer condenado de la compuerta fue su propio autor

Agregué una nueva regla de bloqueo a un validador, la publiqué, y la compilación se puso en rojo. No porque la regla estuviera mal, sino porque había agregado la regla al código y no a la especificación contra la que se verifica el código, y una prueba de paridad detectó el desfase. Lo primero que condenó mi nueva compuerta fui yo.

Ley: un validador que nunca ha condenado a su propio autor probablemente no está verificando nada.

2. El router que descartó silenciosamente cada raíz

Construí un router determinista que decide a cuál de mis repos beneficiaría un nuevo artículo o repositorio. Se veía correcto y pasaba sus pruebas. Luego lo ejecuté sobre cuatro fuentes reales y solo enrutó una.

La causa fue mía: el registro que lee documenta sus palabras clave como coincidencias de *substring* y varias son raíces deliberadas — self-improv, portfolio rebalanc. Yo había implementado coincidencia de palabra completa, así que una página que describía "self-improving pipelines" no coincidía con nada. Las pruebas pasaban porque yo había escrito las pruebas para que coincidieran con mi implementación, no con los datos.

Ley: ejecuta tu sistema con entradas reales antes de creerle a tu propio verde.

3. El evaluador condenó mi boleta de calificaciones

Cada entrega en mi sistema recibe una boleta de calificaciones, puntuada por un evaluador independiente. Envié una y volvió 0.00 limitada, capped por "significance unstated""significance unstated". Yo había descrito lo que hice, pero nunca dije por qué importaba ni qué número movió.

Más tarde, ese mismo evaluador le condenó un cambio pequeño 1.00 y lo marcó (sandbagged?) — diciéndome que el estándar que me había puesto a mí mismo era demasiado bajo. Ambos veredictos fueron acertados y ninguno fue halagador.

Ley: si tu evaluador no puede darte una mala nota, es decoración.

4. El plan que no podía explicar su propio objetivo

Construí un enrutador de ruta crítica para un plan de ingresos de 360 días. Calculó el plan como cómodamente viable —terminar en cuarenta días frente a un hito de noventa días— mientras los ingresos reales eran cero.

La aritmética estaba bien. El problema era el grafo: ni un solo nodo declaraba que genera ingresos. Era un grafo de dependencias de repositorios disfrazado de plan. Ahora eso es una regla de bloqueo: si el objetivo es medible y nada contribuye a él, no se sirve ninguna ruta.

Ley: un plan que no puede explicar su propio objetivo es un deseo con un diagrama de Gantt.

Las doce leyes

1. Sin un objetivo claro, no hay agente confiable. Un objetivo vago crea un bucle errante.
2. El estado vive fuera del modelo. El modelo piensa; el sistema recuerda.
3. Las herramientas necesitan contratos. Propósito, entradas, salidas, límites, modos de falla.
4. Las reglas críticas necesitan compuertas. Las instrucciones del prompt no son control.
5. La evaluación debe producir evidencia. Sin evidencia, no hay confianza.
6. Reintenta solo los fallos reintentables. Esforzarse más no es recuperarse mejor.
7. Las condiciones de parada son arquitectura. Un bucle que no puede detenerse es un error.
8. La memoria debe ser curada. La mala memoria multiplica el error.
9. Los humanos pertenecen a las compuertas de alto impacto. Eso es responsabilidad, no debilidad.
10. La observabilidad genera confianza. Si no puedes inspeccionarlo, no puedes operarlo.
11. Más agentes no es más inteligencia. La coordinación es la parte difícil.
12. El bucle debe acumularse. Cada corrida debería mejorar la siguiente.

Y la decimotercera, que las cuatro historias de arriba se ganaron a pulso: "build the loop so it can convict you" (Traducción: construye el bucle para que pueda condenarte). Un sistema que solo valida a su autor es un espejo.

Treinta días, etiquetados con honestidad

Todo en esta sección es una meta a la cual apuntar, no un resultado que estoy reportando. No he hecho un estudio controlado; estas son las metas que me puse para mis propias construcciones.

Semana 1 — el bucle mínimo. Contrato de meta, esquema de estado, esquema de resultado de herramienta, controlador, un planificador, dos herramientas, un evaluador, un límite de iteraciones. Meta: que termine tareas simples sin que lo toques.

Semana 2 — confiabilidad. Categorías de error, una is_retryable marca, una política de recuperación, detección de errores repetidos. Objetivo: que distinga entre fallas transitorias, de validación, de permisos y de reglas de negocio.

Semana 3 — los frenos. Niveles de riesgo, una compuerta de política en código, un paquete de aprobación, un registro de auditoría. Objetivo: que toda llamada restringida en la suite de pruebas quede bloqueada.

Semana 4 — acumulación. Candidatos de memoria, revisión humana antes de que algo se vuelva permanente, seguimiento de modos de falla. Objetivo: que la misma falla deje de repetirse.

Lo que este artículo no afirma

• Sin benchmark. No he medido esta arquitectura contra una alternativa. Las cuatro historias son incidentes, no un estudio.
• Los números de arriba son metas. Donde el borrador original de esta pieza sonaba a resultados medidos, eso fue un error — corregido aquí en vez de borrado en silencio.
• Una flota, un operador. Todo lo que he aprendido viene de mis propios repos y de mi propio agente. Tus modos de falla serán distintos.

Fuentes

Mi propia regla es: sin fuente, no hay afirmación. Un borrador anterior de este artículo la rompió — demostró la regla con una afirmación sin citar sobre el paper de Tree-of-Thoughts, que es exactamente la falla que la regla existe para impedir. Así que:

• *Tree of Thoughts: Deliberate Problem Solving with Large Language Models* (Traducción: *Árbol de Pensamientos: Resolución Deliberada de Problemas con Modelos de Lenguaje Extensos*), Yao et al., 2023 — arXiv:2305.10601. Reporta un margen sustancial sobre chain-of-thought en tareas de búsqueda y planificación. Deliberadamente no reproduje aquí las cifras exactas, porque no las reverifiqué al momento de publicar.
• Los cuatro incidentes provienen de mis propios repositorios, en el historial de commits, entre el 2026-08-05 y el 2026-08-11.

La conclusión

El prompt engineering hizo útil a la IA. El loop engineering la hace confiable.

Un prompt puede producir una respuesta; un loop puede producir trabajo. Un prompt puede sonar inteligente; un loop puede ponerse a prueba. Un prompt puede impresionar; un loop puede acumularse.

Construye el objetivo, el estado, las herramientas, la compuerta, el evaluador, la recuperación, el humano, la memoria. Luego construye lo único que casi todos se saltan: la parte que tiene permitido decirte que te equivocaste.