Ratchet Pattern — Cómo hacer que un agente termine el trabajo

Ratchet Pattern

Si tu agente de IA dice “ya terminé” pero en realidad no ha terminado, si el agente sigue saltándose las tareas difíciles, si quieres que sea la máquina – no una persona – quien juzgue si algo está completo – este artículo explica esa estructura.

“Ya terminé”

Le pedí a un agente de IA que escribiera tests para 527 funciones. El agente terminó su trabajo e informó:

“Listo.”

Funciones que realmente obtuvieron tests: 40.

No mintió. Después de 40, decidió que “era suficiente”. Cuando encontraba una función difícil, la saltaba. Tras unas cuantas más, concluyó que “el resto sigue un patrón similar, así que estamos bien”.

Los LLM son excelentes generando. Pero no se puede confiar en ellos para juzgar si terminaron. Huang et al. demostraron experimentalmente que la autocorrección del LLM sin retroalimentación externa puede incluso degradar el rendimiento[1].

El trinquete

Una llave de trinquete tiene dientes que engranan en una sola dirección. Al girarla avanza. Al soltarla se detiene, pero nunca retrocede.

El Ratchet Pattern aplica este mecanismo al control de agentes. El codigo de verificacion escrito con este patron se llama ratchet code — codigo que nunca permite una regresion por debajo de un nivel de verificacion previamente aprobado.

Item 1: verificación mecánica → PASS → siguiente
Item 2: verificación mecánica → FAIL → reintentar (con feedback)
Item 2: verificación mecánica → PASS → siguiente
...
Item N: PASS → completo. Detener.

Tres reglas:

Mostrar solo un item a la vez.
Un item debe pasar antes de que se abra el siguiente.
Cuando todos los items pasan, detenerse.

Implementa estas reglas como CLI y el agente solo necesita conocer un comando: next. La máquina decide el resto.

El agente que se detuvo en 40 vs. el trinquete que completó 527

Mismo modelo. Mismo proyecto. Las mismas 527 funciones.

Agente autónomo:  40 / 527  (7.6%)  — el agente declaró "listo"
Trinquete CLI:   527 / 527 (100%)  — la máquina declaró "quedan 487"

La diferencia no es el rendimiento del modelo. Es quién decide cuándo se termina.

Con un agente autónomo, el LLM decide cuándo parar. Los LLM son optimistas. Después de 40, sienten que es suficiente. En el análisis de trazas de 1,600 ejecuciones de agentes de Cemri et al., la terminación prematura — declarar el objetivo logrado antes de que realmente lo fuera — representó el 6.2% de todos los modos de fallo[2]. Con un trinquete, la máquina decide cuándo parar. La máquina no siente. Declara “todavía no” hasta que el conteo restante llega a cero.

Definición en una frase

Colocar un agente probabilístico dentro de una máquina de estados determinista.

Rol	Responsable
Generación	LLM
Juicio	verifier
Control de progreso	ratchet

Muchos sistemas delegan la generación, el juicio y la decisión de terminación al LLM. El Ratchet los separa.

Cinco principios

1. La condición de terminación es mecánica

pass/fail. No “looks good”. Si go test pasa, es PASS. Si el coverage llega a 100%, es PASS. No hay espacio para el juicio subjetivo.

2. Un PASS es inmutable

Un item aprobado no se reabre. No se revierte. El número de items restantes decrece monótonamente.

remaining_work(t+1) ≤ remaining_work(t)

Lo que construyes hoy no se deshace mañana. Solo hacia adelante. Esta es la diferencia fundamental con un “agente de 24 horas”. Un agente sin condición de terminación agrega una abstracción hoy, la elimina mañana y la vuelve a agregar pasado mañana. El trinquete no permite esa oscilación.

3. El LLM solo genera

Generar código, escribir tests, proponer correcciones: ese es el rol del LLM. Qué corregir, si pasó o no, cuál es el siguiente, si terminó o no: todo eso lo decide la máquina. El LLM no es un planner, es un constrained generator.

4. Despojar al agente de su derecho a declarar que terminó

Si el LLM dice “listo”, se detiene en 40. Si la máquina dice “listo”, se detiene en 527. La razón de existir del trinquete se resume en esta única línea.

5. El verifier debe ser determinista

No cualquier cosa puede ser un verifier.

Puede ser verifier	No puede ser verifier
`go test`	“looks cleaner”
medición de coverage	“seems better”
AST validation	“more scalable”
schema diff	“clean architecture”

Condiciones del verifier: deterministic, machine-checkable, resumable, localized feedback. Si no se cumplen estas cuatro, los dientes del trinquete no enganchan.

El feedback como gradient signal

Si el trinquete solo devuelve “pasó/falló”, el LLM corrige sin dirección. Cuanto más específico el feedback, más precisas las correcciones del LLM.

Feedback débil:   "test falló"                → LLM corrige sin dirección
Feedback medio:   "coverage 65%"              → LLM refuerza aproximadamente
Feedback fuerte:  "line 41, 44, 70 sin cubrir" → LLM cubre exactamente esas ramas

Números verificados en un proyecto real:

Sin feedback:   coverage estancado en 60~70%
Con feedback:   100% alcanzado (para funciones alcanzables)

Mismo modelo. Una sola línea — “line 41 not covered” — actúa como gradient signal. La investigación Self-Debug de Chen et al. demostró que la depuración iterativa alimentando mensajes de error del compilador/runtime al modelo mejora drásticamente la precisión del código[3].

A mayor resolución del feedback, mayor precisión de corrección del LLM, menos iteraciones del loop y menor costo.

Los agentes mueren. El progreso sobrevive.

Los agentes inevitablemente se caen. Límite de tokens, errores de red, desconexión de sesión. Si el trinquete persiste el progreso en almacenamiento, cuando un agente muere, el siguiente continúa donde el anterior lo dejó.

Agente A: procesa funciones 1-200 → muere
Agente B: next → continúa desde 201
Agente C: next → continúa desde 401

Los agentes son desechables. El progreso se acumula.

Cambia el verifier, obtienes otra herramienta

El trinquete no está atado a ningún verificador específico. Cambia el verificador y obtienes una herramienta diferente.

Trinquete + Verificador	Uso
Trinquete + `go test` + coverage	Generación de tests por función
Trinquete + validator de reglas estructurales	Limpieza de estructura de código
Trinquete + hurl pass/fail	Verificación de endpoints API
Trinquete + validación cruzada de specs	Consistencia SSOT
Trinquete + Toulmin verdict	Aplicación de reglas definidas por el usuario

Un solo patrón. El verificador determina el dominio.

Preguntas

¿Cuántos items completó tu agente antes de decir “ya terminé”?

¿Realmente terminó?

¿Quién decidió “fin” — el agente o la máquina?

Fuentes

[1] Jie Huang, Xinyun Chen, Swaroop Mishra, Huaixiu Steven Zheng, Adams Wei Yu, Xinying Song, Denny Zhou. “Large Language Models Cannot Self-Correct Reasoning Yet.” ICLR 2024. arXiv:2310.01798

[2] Mert Cemri, Melissa Z. Pan, Shuyi Yang, Lakshya A. Agrawal, Tanay Chopra, Aditya Tiwari, Kurt Keutzer, Aditya Parameswaran, et al. “Why Do Multi-Agent LLM Systems Fail?” NeurIPS 2025 Datasets and Benchmarks Track. arXiv:2503.13657

[3] Xinyun Chen, Maxwell Lin, Nathanael Scharli, Denny Zhou. “Teaching Large Language Models to Self-Debug.” ICLR 2024. arXiv:2304.05128

[4] Noah Shinn, Federico Cassano, Ashwin Gopinath, Karthik Narasimhan, Shunyu Yao. “Reflexion: Language Agents with Verbal Reinforcement Learning.” NeurIPS 2023. arXiv:2303.11366

[5] Aman Madaan, Niket Tandon, Prakhar Gupta, Skyler Hallinan, Luyu Gao, Sarah Wiegreffe, Uri Alon, Nouha Dziri, Shrimai Prabhumoye, Yiming Yang, et al. “Self-Refine: Iterative Refinement with Self-Feedback.” NeurIPS 2023. arXiv:2303.17651

[6] Yujia Li, David Choi, Junyoung Chung, Nate Kushman, Julian Schrittwieser, Remi Leblond, Tom Eccles, et al. “Competition-Level Code Generation with AlphaCode.” Science 378(6624): 1092-1097, 2022. DOI:10.1126/science.abq1158

[7] Carlos E. Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, Karthik R. Narasimhan. “SWE-bench: Can Language Models Resolve Real-World GitHub Issues?” ICLR 2024. arXiv:2310.06770