La regla de la fábrica es escribir la evaluación antes del prompt. La extensión natural, que casi nadie ha llevado a producción todavía, es meter la evaluación dentro del loop. No como gate de release. Como gate de runtime. Un segundo modelo, más pequeño y especializado, sentado entre el modelo frontier y cualquier efecto colateral irreversible, verificando el trabajo antes de que se envíe.
A esto le venimos llamando loops de agentes con verificador. El patrón es directo. La literatura está convergiendo en él. El tooling apenas existe. Es una de las apuestas de mayor convicción que estamos haciendo sobre cómo van a operar los sistemas agentic para fines de 2026.
La forma del loop
Un modelo frontier propone una acción. La acción está bien formada — una llamada a tool con argumentos, una query SQL, una respuesta en borrador, un patch de código, un correo a cliente. Antes de que la acción se ejecute, corre un verificador.
El verificador no es el mismo modelo. Es más pequeño, más rápido, a menudo un modelo open-weights pequeño afinado sobre los modos de falla que importan en tu dominio. Su único trabajo es scorear la acción propuesta contra una rúbrica acotada y escrita: ¿está esta query dentro del alcance, está este correo factualmente anclado en el contexto recuperado, es este patch de código consistente con el test que dice arreglar?
Si el verificador aprueba, la acción se ejecuta. Si rechaza, el loop reintenta con el modo de falla como feedback, escala a un humano o aborta. El modelo frontier nunca causa directamente un efecto colateral. El verificador sí.
Por qué un modelo separado y no el mismo auto-verificándose
La autocrítica del mismo modelo es un gate débil conocido. Atrapa las fallas obvias y se le escapan las que comparten su sesgo — que son precisamente las fallas que importan en producción. Un verificador con una distribución de entrenamiento distinta, a menudo un modelo más pequeño, a menudo afinado sobre los casos de falla reales que tu sistema produjo, ve lo que el proposer no vio.
La economía también cierra. El modelo frontier corre una vez por paso. El verificador corre una vez por paso. El verificador es aproximadamente un orden de magnitud más barato. El costo total por paso sube entre diez y quince por ciento. El blast radius de una acción equivocada baja a casi cero.
Qué necesitas antes de poder enviar uno
El verificador es un modelo. Un modelo necesita un set de entrenamiento. Un set de entrenamiento necesita ejemplos de falla. La mayoría de los equipos no tiene un registro limpio de las fallas pasadas de su agente porque no las estaba capturando. El trabajo previo para los loops con verificador son seis a ocho semanas de captura disciplinada de fallas en el pipeline de evaluación antes de entrenar verificador alguno.
Una vez que tienes eso, el verificador es pequeño, enfocado y entrenable en días. Hemos enviado verificadores en el rango de siete a trece mil millones de parámetros que igualan la calidad de gate de una autocrítica de clase GPT-4 a una veinteava parte del costo.
Hacia dónde va esto
Dos tendencias van a hacer que este patrón sea rutina en menos de dieciocho meses. Los vendors frontier van a empezar a ofrecer modelos verificadores como producto de primera clase, igual que ofrecieron modelos de embedding en 2023. Y el costo de los fine-tunes pequeños va a seguir bajando, lo que significa que el verificador se vuelve un activo por proyecto, no compartido.
Los equipos que envíen loops con verificador en 2026 se van a ver como los equipos que enviaban CI en 2010: haciendo algo que el resto de la industria va a tratar como obvio en tres años y trata como exótico hoy. La evaluación pasó de ser un gate de release a ser un gate de runtime. Es el mismo movimiento que hizo CI hace veinte años, y va a aterrizar con la misma fuerza.
Lo que todavía no hacemos
No corremos loops con verificador en tareas donde el verificador mismo es el cuello de botella de la calidad. Algunos dominios — razonamiento estratégico de horizonte largo, trabajo creativo abierto — todavía no tienen un modelo verificador que scoree de forma confiable. Para esos, seguimos manteniendo al humano en el loop. El verificador no es magia. Es una evaluación con interfaz de runtime.