¿Qué es un 'turno' en reins?

¿Qué es un ’turno’ en reins? Imagen: generada por IA

Cualquiera que le haya confiado un trabajo grande a un agente de IA lo sabe. El bucle siempre se derrumba en el mismo punto: el momento en que el modelo declara por su cuenta “ya terminé” — cuando en realidad no ha terminado.

reins es un framework de quest CLI que le quita a la IA esa autoridad de declarar la finalización y se la entrega a una máquina. Divide una lista de trabajo en ítems individuales, como las misiones de un videojuego, se los da a la IA de uno en uno, y decide “¿está terminado?” no por la palabra de la IA sino por inspección mecánica. Y en su corazón vive una unidad pequeña llamada turno (turn).

Dos palabras van a repetirse todo el tiempo, así que asegurémoslas primero.

Gate — un inspector que examina mecánicamente lo entregado y dictamina PASS o FAIL. No es la impresión de una persona ni la autoevaluación de la IA.
Ratchet — un engranaje de trinquete que gira en una sola dirección. Lo usamos para decir que un ítem bloqueado por un pase nunca se reabre.

Este artículo sigue un turno de principio a fin, a través de exactamente lo que atraviesa. El turno parece pequeño, pero al desarmarlo, es reins entero en miniatura.

Los seis elementos centrales de Reins Engineering

Si comprimimos en una línea la ingeniería sobre la que se sostiene reins, dice así: la ingeniería de trasladar la autoridad de declarar la finalización desde la IA hacia un gate mecánico determinista. Aquí “determinista” no es una palabra difícil. Significa que la misma entrada produce siempre el mismo resultado. Un test pasa o falla, y el veredicto de ayer no difiere del de hoy según el estado de ánimo.

En el linaje prompt engineering (elegir las palabras) → context engineering (suministrar el contexto) → harness engineering (levantar las cercas), Reins es la rienda que marca la dirección. Esta ingeniería se ensambla a partir de seis elementos.

#	Elemento	En una línea	Frase canónica
1	Finalización juzgada por la máquina	La condición de finalización debe poder responderse con sí/no por una máquina, y es la máquina quien juzga — a la IA se le retira la autoridad de decidir que ha terminado	“La finalización no se afirma: la dictamina el gate”
2	Feedback determinista	Hechos, no opiniones — “dónde, qué debía ser, qué fue en realidad” se vuelve la señal que apunta hacia la corrección	“Dale opiniones y adula; dale hechos y corrige”
3	Contexto direccional (manual + ejemplos)	Si el feedback es una señal de corrección, el manual y los ejemplos son señales de dirección — ninguno puede sustituir al otro	“El cuello de botella no es la inteligencia sino el contexto”
4	Ratchet Pattern (bloqueo por contrato)	Un ítem que pasó es inmutable; el trabajo restante solo se reduce — que el trabajo termine queda garantizado por la estructura	`remaining(t+1) ≤ remaining(t)`
5	Persistencia del progreso	El progreso vive fuera del proceso (en disco) — aunque la IA muera, el progreso permanece	“Agents are disposable; progress is cumulative.”
6	Defensa contra el cheese (gates de dominio)	Incluso una comprobación mecánica se deja engañar si solo inspecciona la cáscara — el gate debe reverificar los hechos reales de su dominio	“Un gate tiene un dominio”

No pasa nada si los términos de la tabla todavía suenan ajenos. El turno es la unidad mínima donde estos seis se encuentran dentro de un mismo ciclo, así que seguir un turno completo hasta el final reúne los seis elementos, cada uno en su lugar. Dibujemos el mapa por adelantado: compose, el primer paso del turno, ensambla el contexto direccional y el feedback determinista; judge emite el veredicto mecánico (la defensa contra el cheese es la calidad de diseño de ese gate); record bloquea el ratchet y persiste el progreso.

¿Qué es un Reins Turn?

Un Reins Turn es la unidad mínima de ejecución de reins, en la que un intento sobre un ítem de un quest concluye como generación → juicio → registro. Un bucle no es más que la repetición de turnos, y el progreso de un quest no es más que la acumulación de turnos. Por eso la definición cabe en una línea.

Turn N = el N-ésimo Attempt registrado. Lo que no está registrado no es un turno.

Un Attempt es “un registro de un intento”. Aquí hay un matiz sutil — un turno no es “se llamó una vez al LLM”. La condición de existencia de un turno no es la llamada sino el registro. Si se llamó al LLM pero el resultado nunca quedó registrado en el ratchet, ese turno nunca existió. A la inversa, un resultado que una persona entregó a mano, una vez registrado, es un turno. Incluso sin LLM. Quien cuenta los turnos no es el modelo sino el ratchet.

Esta única definición es la raíz de todas las propiedades que vienen — independencia del driver, resistencia al reinicio, auditabilidad. Por ahora, dejemos que los nombres solo pasen de largo. Volveremos a encontrar cada uno en su lugar.

Un turno son exactamente cuatro pasos

Un turno atraviesa cuatro pasos en orden. Los pasos llevan nombres en inglés, pero lo que hacen es simple — ensamblar (compose), generar (generate), juzgar (judge), registrar (record).

Paso	Qué hace	Propiedad
① compose	Lee el registro de todos los turnos previos (el Log) y ensambla el prompt para el LLM	Función pura
② generate	Llama al LLM una vez para producir el resultado	El único paso probabilístico
③ judge	El gate dictamina sobre el resultado (PASS / REVIEW / FAIL)	Determinista
④ record	Aplica el veredicto al ratchet y guarda en disco	El único paso irreversible

“Función pura” significa que la misma entrada produce siempre la misma salida sin otros efectos secundarios, e “irreversible” significa que una vez ejecutado no puede deshacerse. Entonces el núcleo de la tabla se hace visible — de los cuatro pasos, solo ② es probabilístico, y solo ④ es irreversible. La generación no puede juzgar, y el juicio no puede generar. La incertidumbre de la IA queda confinada en una celda, y la decisión que no puede deshacerse, en otra.

Vale la pena señalar una decisión de diseño peculiar. Esta cascada de cuatro pasos no está implementada como dos juegos de código Go. Está definida en un único documento legible por humanos llamado pkg/cli/turn.md (un documento TANGEUL), incrustado en el binario (go:embed) e interpretado en tiempo de ejecución. La fuente canónica de “cómo corre un turno” no es código sino un documento legible — la razón de esta elección regresa al final de este artículo.

① compose — el contexto viene solo del Log

El Log es el libro mayor, guardado en disco, donde queda registrado cada turno hasta ahora. Y la entrada para ensamblar el prompt del turno N es exactamente una: este Log. Un estado que se esconde en algún rincón de la memoria del programa y se desvanece cuando el proceso muere — eso no existe.

El prompt que se ensambla desde el Log tiene tres capas.

Qué hacer — qué debe producirse para este ítem (las instrucciones de escritura y el contexto de verificación)
Manual — el prompt de sistema global, más, si el turno anterior fue un FAIL, el coaching de la regla que lo causó (el manual por regla)
Cola de feedback — los hechos del FAIL anterior. “Dónde, qué debía ser, qué fue en realidad”

En el lenguaje de los seis elementos de arriba, el manual es el contexto direccional y la cola de feedback es el feedback determinista. Ambos se ensamblan mecánicamente desde el Log, en cada turno.

Hay una regla sutil pero importante. Lo que compose toma como referencia no es el último Attempt sino el último Attempt que fue juzgado (judged) — llevado hasta un veredicto. Aunque en medio se cuele un error de generación, como una caída del servidor del LLM, lo que ve el reintento no es el mensaje de error de infraestructura sino el feedback basado en hechos del FAIL anterior. Las fallas operativas no contaminan el contexto del trabajo.

② generate — el LLM solo genera

El prompt ensamblado va al backend de LLM en una sola llamada. No importa si el backend es una API HTTP (ollama/xai/gemini) o una herramienta de línea de comandos (claude/grok/codex/geminicli). En cualquier caso, su papel está fijado: generador. El framework no expone ninguna API mediante la cual pudiera concederse a un LLM la autoridad de dar PASS. No es que el framework haya “decidido no conceder” la autoridad de juzgar — es que no hay manera de concederla. Así es como el elemento 1 de los seis (finalización juzgada por la máquina) se vuelve estructura.

Incluso qué backend usar se recalcula desde el Log en cada turno. Un ítem que sigue fallando con el modelo por defecto se envía hacia arriba, a uno más fuerte (escalación), y también esta decisión se lee del Log en cada turno — “entre las reglas causantes de los FAIL pasados, ¿hay alguna que sea objetivo de escalación?”. No hay ningún interruptor encendido en alguna parte, ninguna variable local dentro del bucle. Mismo programa, mismo Log — mismo backend seleccionado. La propiedad de comportarse idéntico después de matar y reiniciar el proceso — la resistencia al reinicio — viene gratis.

③ judge — solo el gate juzga

Quien dictamina sobre el resultado es el gate. Un gate es un conjunto de reglas de detección de violaciones. Cada regla se dispara cuando encuentra el problema del que es responsable, y deja tras de sí un hecho — dónde (Where), qué debía ser (Expected), qué fue en realidad (Actual).

La agregación es determinista. Si se dispara aunque sea una regla Fail, FAIL. Si no, y se dispara una regla Review, REVIEW (una zona gris para que la revise un humano). Si no se dispara nada, PASS. Misma entrega, mismas reglas — siempre el mismo veredicto. Aquí no hay ningún inspector cuya respuesta cambie cada vez que se le pregunta.

En dominios complejos donde las reglas se entrelazan — donde una violación vuelve irrelevante otra comprobación — el veredicto puede elevarse a un grafo de argumentación (toulmin), y la lógica de juicio misma puede trasladarse a un documento auditable (gate.md). Sea cual sea la forma, una cosa no cambia: quien juzga es una máquina.

④ record — el único paso irreversible

Aplicar el veredicto al ratchet, guardar en disco y exportar los ítems que han concluido. Este es el único punto de un turno que no puede deshacerse.

PASS / REVIEW / SKIPPED / BLOCKED → bloqueo. El ratchet es unidireccional; no gira hacia atrás.
FAIL → el contador de intentos (Tries) aumenta en 1 y el ítem permanece como TODO. Al alcanzar el máximo de intentos (3 por defecto), se bloquea como DONE. “Este ítem no funciona por esta vía” también es una forma de conclusión — no se permite que un ítem atascado tenga secuestrado el bucle entero para siempre.
Error de generación → queda registrado en el Log como un Attempt (se conserva el rastro de lo que pasó), pero no consume un intento. Que el servidor del LLM se caiga no es culpa del ítem; es una falla operativa. Si la falla persiste, una salvaguarda aparte detiene el bucle (parada tras N fallos de generación consecutivos — un circuit breaker).

Solo con este paso existe el Log que el compose del siguiente turno va a leer. record es la conclusión del turno y el generador del turno siguiente.

El fallo es un hecho, no una opinión

En qué forma regresa un FAIL — esta es la clave de que un turno converja (que con cada reintento se acerque más a la respuesta). No una opinión como “la calidad deja algo que desear”, sino esto:

FAIL. root cause = who-anchor-present
  Fact: where=who.anchors expected="source substring" actual="el subgerente Carlos Ramírez"

Leerlo es simple. Qué campo (where), qué debía ser (expected — una cadena que existe de verdad en el original), qué fue en realidad (actual). Ubicación + valor esperado + valor real. Para el LLM, este es un feedback sin nadie a quien adular — los números y las ubicaciones no son emociones. Es este hecho estructurado el que conduce a un modelo adulador no a la discusión sino a la convergencia.

Un extra encima. El texto del FAIL que se le da al modelo es exactamente el mismo renderizado que la cadena impresa en pantalla cuando un humano ejecuta el comando submit (feedback parity). El feedback que ve el humano y el que ve el modelo nunca divergen. El misterio de “¿qué diablos le habrán mandado a la IA para que lo arreglara así?” está estructuralmente ausente.

Tres puntos de entrada, un solo turno

Llamemos driver a quien conduce el turno. reins tiene tres: next, donde un humano recibe el prompt directamente; submit, donde un humano entrega el resultado; y el loop automático sin supervisión. Pero estos no son tres implementaciones separadas. Son tres puntos de entrada al mismo documento del turno. Lo que separa lo manual de lo automático es exactamente una regla dentro del documento.

La propiedad práctica que esto produce: cambia de driver a mitad de un quest y el prompt sigue siendo idéntico byte a byte. Corre el loop automático ayer, deja que un humano tome el relevo con next hoy — con el mismo estado del Log, sale el mismo prompt. Es posible porque el contexto viene solo del Log (lo vimos en el paso ①), y es una propiedad demostrada, no una esperanza — un golden test de intercambio de drivers (driver-swap) verifica la identidad byte a byte comparando las salidas entre drivers.

Siguiendo un turno hasta el final

Se acabó la teoría. Veamos un turno real de principio a fin. Es un ítem de un quest que extrae direcciones de correo de documentos, en su segundo intento después de que el turno anterior diera FAIL con “no es un formato de email válido”.

[Comprobación de entrada al turno]  ¿El ítem es TODO? ¿Quedan intentos? → proceder
① compose      Busca en el Log el último Attempt judged → FAIL, causa = email-format
               Manual = prompt global + el coaching de la regla email-format
               Prompt = qué hacer + "FAIL. Fact: where=email
                        expected='valid email format' actual='kim at example'"
② generate     Llamada al LLM → {"email":"kim@example.com", ...}
③ judge        Barrido de reglas: email-format pasa, source-lacks-email pasa, freemail pasa
               → ninguna regla Fail disparada → PASS
④ record       El ratchet bloquea (irreversible) → Attempt #2 registrado → guardado → export

El modelo, alimentado con el hecho del fallo anterior (“kim at example no es un formato de email válido”), corrigió exactamente ese punto; el gate confirmó el pase; el ratchet lo bloqueó. Este ítem ahora es PASS para siempre. El turno siguiente se lo salta, y el trabajo restante solo se reduce. Cuando todos los ítems alcanzan un estado concluido (PASS, REVIEW o máximo de intentos), el bucle termina. No “cuando la IA siente que terminó”, sino cuando los ítems restantes llegan a cero. La convergencia queda garantizada por la estructura.

Loop Engineering — la industria le puso nombre al mismo problema

En junio de 2026, un cambio en la manera de manejar agentes recibió un nombre. Peter Steinberger escribió: “You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents” (ya no deberías estar escribiendo prompts para agentes de código; deberías estar diseñando los bucles que les dan los prompts a tus agentes), y a comienzos de ese mes Boris Cherny, de Anthropic, quien construyó Claude Code, dijo en un evento: “I don’t prompt Claude anymore. I have loops running… My job is to write loops” (ya no le escribo prompts a Claude; tengo bucles corriendo… mi trabajo es escribir bucles). Unos días después, Addy Osmani, de Google, le puso nombre a la corriente: Loop Engineering — de una persona que escribe prompts para agentes a una persona que diseña los sistemas que les dan los prompts a los agentes.

Este discurso dibuja una única narrativa de transición. Prompt engineering (elegir las palabras) → context engineering (elegir qué información mostrar) → harness engineering (construir el entorno de ejecución) → loop engineering (diseñar el ciclo mismo de observar-actuar-verificar-recuperar). La palanca se ha movido hacia afuera capa por capa: de las palabras a la información, de la información al entorno, del entorno al ciclo.

La anatomía de un buen bucle según Osmani debería resultarle familiar a quien haya leído hasta aquí. Externaliza el estado a disco o a un tablero, no a la conversación. Separa el agente que construye del agente que verifica. Que la terminación la confirme un adjudicador aparte, no la autodeclaración del agente de código. Puesta junto al turno, la correspondencia es nítida.

Recomendación del Loop Engineering	Estructuración en el turno de reins
Externaliza el estado a disco o a un tablero (el modelo olvida)	El Log no es una ayuda de memoria sino la única entrada del turno — compose es una función pura del Log
Separa al que construye del que verifica (subagentes)	El verificador no es otro LLM sino un gate determinista — no existe siquiera una API para conceder PASS
Define condiciones de terminación testeables	La monotonía del ratchet garantiza la convergencia como invariante — estructura, no condición
Distingue los fallos recuperables de los fatales	Incorporado en las reglas de record — un FAIL consume un intento; los errores de generación son asunto del circuit breaker

El corazón de la diferencia es la distancia entre recomendación y estructura. La propia literatura del loop engineering concede la jerarquía de la verificación — el LLM-as-judge, confiar el veredicto a una IA, “can be gamed or can collude with the actor” (puede ser engañado o coludirse con el actor), así que donde sea posible una comprobación determinista, pon una comprobación determinista. Pero eso queda como buena práctica — una recomendación confiada a la buena voluntad del diseñador. Si el subagente verificador es, al final, también un LLM, la puerta a la colusión sigue abierta. reins cierra esa puerta por diseño. Solo el gate juzga, y el framework no expone ninguna vía para darle un PASS a un LLM.

Y donde el loop engineering habla del bucle entero, reins convierte una vuelta de ese bucle en un contrato. Para ir un paso más allá del “mi trabajo es escribir bucles” de Cherny, primero debe estar definido qué hace un bucle en una vuelta — qué es probabilístico, qué es determinista, qué es irreversible. El nombre de esa definición es el turno.

Por qué esta unidad

Al apretar así el turno se ganan tres cosas. Los nombres que antes pasaron de largo encuentran aquí su lugar.

Auditabilidad — la respuesta a “¿en qué difiere el loop automático del next manual?” no es un trabajo de comparar dos bases de código sino una sola regla en un documento. Puedes confirmar con tus propios ojos que en el documento hay exactamente una ruta capaz de bloquear un PASS. Por eso la fuente canónica del turno es un documento legible, no código.
Resistencia al reinicio — cada entrada de un turno deriva del Log en disco, así que aunque el proceso muera, el mismo Log reproduce el mismo turno.
Desechabilidad de los agentes — cambia los agentes (LLM, drivers) y el progreso sigue acumulándose sin retroceder jamás. “Agents are disposable; progress is cumulative.”

Dicho al revés: un sistema donde el turno es borroso — donde el contexto se esconde en la memoria de sesión, el modelo autodeclara la finalización y los reintentos se apoyan en el historial de la conversación — pierde las tres.

El turno parece pequeño. Pero como la unidad mínima que separa y serializa la generación (probabilidad), el juicio (determinismo) y el registro (irreversibilidad) dentro de un mismo ciclo, entender el turno es entender todo reins.

Lecturas recomendadas (externas)

Building Effective Agents — Anthropic — el clásico del diseño de bucles de agentes. Su distinción entre “workflows (orquestación determinista) y agentes (dirigidos por el modelo)” resuena con la separación generación/juicio de este artículo.
Agentic Loops: From ReAct to Loop Engineering — Data Science Dojo — un repaso del linaje de los bucles de agentes, de ReAct al loop engineering.
The Anthropic leader who built Claude Code says he ditched prompting — now he just writes loops — The New Stack — la cobertura de la industria sobre el giro de Boris Cherny.

Referencias

Loop Engineering — Addy Osmani — 2026-06. El bautizo del término y la anatomía de un buen bucle (automatización, worktrees, skills, subagentes, adjudicadores separados, externalización del estado).
What Is Loop Engineering? A Complete Guide from Prompt to Harness Engineering — Tosea.ai — la transición en cuatro etapas prompt→contexto→harness→loop, la jerarquía de verificación con el determinismo primero, y el riesgo de colusión del LLM-as-judge.
Claude Code’s Creators Explain Agent Loops — The Neuron — Boris Cherny y Cat Wu sobre la operación de bucles en detalle: /loop y /goal, la externalización del estado a disco y Linear, la separación entre quien construye y quien verifica.