Nuestra regla de siempre es escribir el eval antes que el prompt. La extensión natural, que casi nadie ha llevado a producción, es meter el eval dentro del loop. No como gate de release, sino como gate de runtime: un segundo modelo, más pequeño y especializado, sentado entre el modelo frontier y cualquier efecto irreversible, verificando el trabajo antes de que salga.
Lo llamamos loops de agentes con verificador. El patrón es simple. La literatura converge hacia él. El tooling apenas existe. Y es una de las apuestas en las que más convicción tenemos sobre cómo van a operar los sistemas agénticos a finales de 2026.
La forma del loop
Un modelo frontier propone una acción. La acción está bien formada: una tool call con argumentos, una query SQL, una respuesta en borrador, un patch de código, un correo a un cliente. Antes de que se ejecute, corre el verificador.
El verificador no es el mismo modelo. Es más pequeño, más rápido y suele ser un modelo open-weights afinado sobre los modos de fallo que importan en tu dominio. Su único trabajo es puntuar la acción propuesta contra una rúbrica corta y escrita: ¿esta query está dentro del alcance?, ¿este correo se apoya de verdad en el contexto recuperado?, ¿este patch es coherente con el test que dice arreglar?
Si el verificador aprueba, la acción se ejecuta. Si rechaza, el loop reintenta con el modo de fallo como feedback, escala a un humano o aborta. El modelo frontier nunca provoca un efecto directamente. El verificador sí.
Por qué un modelo aparte y no el mismo autoverificándose
La autocrítica del propio modelo es un gate notoriamente débil: un modelo no puede corregir su propia tarea. Atrapa los fallos evidentes y deja pasar los que comparten su sesgo, que son justamente los que importan en producción. Un verificador con otra distribución de entrenamiento —a menudo más pequeño, a menudo afinado sobre los fallos reales de tu sistema— ve lo que el proponente no vio.
Las cuentas también salen. El modelo frontier corre una vez por paso. El verificador corre una vez por paso. El verificador cuesta alrededor de un orden de magnitud menos. El costo total por paso sube entre un 10 % y un 15 %. El radio de daño de una acción equivocada baja casi a cero.
Qué necesitas antes de poder entregar uno
El verificador es un modelo. Un modelo necesita un set de entrenamiento. Un set de entrenamiento necesita ejemplos de fallo. Casi ningún equipo tiene un registro limpio de los fallos anteriores de su agente, sencillamente porque no los estaba capturando. El trabajo previo son seis u ocho semanas de captura disciplinada de fallos dentro del pipeline de evaluación, antes de entrenar verificador alguno: la misma disciplina que decide si un agente está listo para producción.
Con eso encima, el verificador es pequeño, acotado y entrenable en días. Hemos entregado verificadores de entre siete y trece mil millones de parámetros que igualan la calidad de gate de una autocrítica de clase GPT-4 a la vigésima parte del costo.
Hacia dónde va esto
Dos tendencias van a volver rutinario este patrón en menos de dieciocho meses. Los vendors frontier empezarán 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 cayendo, con lo que el verificador pasa a ser un activo por proyecto en lugar de algo compartido.
Los equipos que entreguen loops con verificador en 2026 se van a parecer a los que entregaban CI en 2010: haciendo algo que el resto de la industria dará por obvio en tres años y que hoy considera exótico. El eval pasó de gate de release a gate de runtime. Es el mismo movimiento que hizo CI hace veinte años, y va a caer con la misma fuerza.
Lo que todavía no hacemos
No usamos loops con verificador en tareas donde el propio verificador es el techo de calidad. Algunos dominios —razonamiento estratégico de horizonte largo, trabajo creativo abierto— aún no tienen un modelo verificador que puntúe de forma fiable. Ahí seguimos manteniendo al humano dentro del loop. El verificador no es magia: es un eval con interfaz de runtime.