Miércoles 28 de octubre de 2026. Día 3 de 10. A la hora del almuerzo, el equipo de Meta abrió la segunda parte del taller del hackatón con una frase que no tenía nada de ambigua: «Today we'll focus on verification». Treinta y dos minutos y quince segundos después, la sesión terminaba sin haber escrito una sola línea del agente. Todo el tiempo se fue en la capa que la primera parte había dejado para el final.
La víspera, el mismo equipo había construido en vivo un agente multimodal completo —loop, herramientas, documentos, un memo legal— y había dedicado dos minutos a explicar que la verificación se vería «mañana». Lo anunciaron en el minuto 01:51 como una serie de dos partes, y no era una excusa: era una promesa con fecha.
La segunda parte cumplió la promesa de una manera que no esperábamos. No agregó una herramienta. Agregó una propiedad al sistema. Y en el camino dejó medido el precio exacto de esa propiedad: diez turnos más de ejecución para el mismo encargo, sobre un caso de juguete, en una demo.
Este artículo es la comparación de esas dos sesiones —medida, no impresionista— y el recibo de lo que esa propiedad hizo en nuestro propio repositorio mientras el taller corría: 43 commits, 264 tests y un número de líneas que no vamos a presumir.
La industria sigue tratando la verificación como una capacidad del modelo: se le pide al agente que revise su trabajo, se le da una herramienta que puede llamar, se confía en que la va a llamar. Yash —partner engineer de Meta, la persona que la industria pone al frente de su propio taller de verificación— dijo lo contrario, con todas las letras: «the verification should not be added as a choice to the agent».
Si la verificación es una herramienta, entonces la decisión de verificar pertenece al sistema que estás auditando. Eso no es un control: es una sugerencia. Un gate que el agente puede esquivar no es un gate, es un linter con autoaprobación.
La verificación no es una herramienta que el agente usa. Es una propiedad del harness: obligatoria, incorporada, imposible de saltar y —esto es lo que casi nadie dice en voz alta— con un costo medible en latencia. En la demo de Meta, ese costo fue del 50%.
Antes de entrar, la advertencia de siempre, porque es la regla de esta casa: Meta no nos validó. No hay endorsamiento, no hay reunión, no hay correo. Lo que hay es una transcripción pública de un taller abierto a 20.000 participantes, un cronómetro, y la coincidencia —incómoda para nuestra vanidad— de que el vocabulario de la segunda sesión es el que nosotros venimos usando desde septiembre. La coincidencia es la evidencia. El padrinazgo no existe.
Y una segunda advertencia, de método: este artículo compara dos transcripciones propias (411 y 536 segmentos, 4.382 y 5.251 palabras), no dos productos. Un taller es una demo, y una demo tiene licencias que una operación no tiene. Cuando el propio expositor dice «elegí 80% para la demo, no hay razonamiento detrás», corresponde citarlo tal cual y no convertirlo en metodología.
1. Los dos minutos que se convirtieron en treinta y dos
Empecemos por el dato que ordena todo lo demás. La primera sesión duró 32:20 y la segunda 32:15. Prácticamente el mismo tiempo. Pero no contenía lo mismo:
| Bloque | Taller 1 · 27-oct | Taller 2 · 28-oct |
|---|---|---|
| Construir el agent loop | ~14 min | 0 min (ya existía) |
| Verificación | ~2 min (prometida para mañana) | ~32 min |
| Duración total | 32:20 | 32:15 |
| Segmentos transcritos | 411 | 536 (+30%) |
| Palabras | 4.382 | 5.251 (+20%) |
| Relación loop : gate | 7 : 1 | 0 : 1 |
Leé la última fila despacio, porque es el hallazgo de este artículo. En la primera sesión, la construcción del loop y la verificación se repartieron el tiempo siete a uno. En la segunda, la verificación ocupó todo el tiempo disponible y el loop no apareció ni de pasada —porque ya estaba construido y funcionando—.
Los dos minutos que se postergaron no eran dos minutos de contenido menor: eran la mitad del problema, comprimida en un cierre de sesión. Cuando por fin se abrió esa mitad, no cupo en menos de una sesión completa.
«Today we'll focus on verification and helping your agent check its work, catch unsupported answers and recognize when it needs more information.»
Hay una lectura cómoda de esto: «el equipo de Meta se dio cuenta de que la verificación importa». Y una lectura más incómoda, que es la que sostengo: la verificación importa tanto que no se puede enseñar en un bloque de cierre. No es una sección del taller del loop. Es un taller aparte, con sus propias herramientas, sus propios umbrales y su propio presupuesto de latencia.
Eso, para cualquiera que esté comprando o construyendo agentes, tiene una traducción comercial inmediata: si tu proveedor te muestra un agente espectacular y la verificación aparece en el minuto 30 de 32, no estás viendo el sistema completo. Estás viendo la parte que se puede filmar.
2. El linaje medido: cómo cambió el vocabulario entre las dos sesiones
Antes de mirar el contenido, miré la forma. Descargué las dos transcripciones completas y conté ocurrencias de los términos que definen de qué se está hablando. No es análisis de sentimiento ni topic modeling: es un conteo de palabras, reproducible, sobre texto propio.
| Término | Taller 1 | Taller 2 | Variación |
|---|---|---|---|
| «verif…» (verification, verify, verified) | 3 | 77 | ×26 |
| «check…» | 11 | 91 | ×8,3 |
| «threshold» | 0 | 10 | — |
| «deterministic» | 0 | 9 | — |
| «human» | 0 | 8 | — |
| «ground truth» | 0 | 5 | — |
| «retr…» (retry, retries) | 0 | 2 | — |
| «hallucin…» | 7 | 3 | −57% |
| «citation / source» | 6 | 0 | — |
| «harness» | 5 | 1 | −80% |
| «loop» | 15 | 14 | ≈ |
Tres cosas se ven en esta tabla, y las tres importan.
Primero: el centro de gravedad se movió de la sospecha al procedimiento. En el taller 1, «alucinación» aparecía siete veces y «threshold», «deterministic» y «ground truth» cero. El problema estaba nombrado como fenómeno —«los modelos alucinan»— sin una sola pieza de maquinaria para tratarlo. En el taller 2, la alucinación baja a tres menciones y aparecen, con nombre propio: umbrales, chequeos deterministas, verdad de referencia, reintentos y humano en el loop. Nombrar el problema no lo resuelve; el problema se resuelve con piezas.
Segundo: «citation» desapareció. Seis menciones en el taller 1, cero en el taller 2. Es el hueco más interesante de toda la comparación, y vuelvo a él más adelante, porque es exactamente donde nuestro sistema hace algo distinto.
Tercero: «harness» bajó de cinco a una. Suena paradójico, y tiene una explicación que es la tesis entera. En el taller 1 el harness era el tema: se hablaba de él como concepto, se lo nombraba, se lo explicaba. En el taller 2 el harness se volvió el lugar donde se hacen las cosas: no se lo menciona, se lo opera. La respuesta más importante del taller —la del minuto 19:27, sobre qué hacer si el agente llama una herramienta que no existe— termina con siete palabras que son, literalmente, una definición de harness: «you just discard that request».
3. «La verificación no puede ser una elección del agente»
El minuto 08:35 contiene la frase más importante del taller, y llegó como respuesta a una objeción que el propio expositor se hizo. La objeción es esta, y es buena:
Si la verificación hace falta, ¿por qué no darle al agente una herramienta verify_memo y que la llame cada vez que termina de escribir un memo?
Es la solución obvia. Es la que implementaría el 90% de los equipos. Y la respuesta de Yash fue:
«The verification should not be added as a choice to the agent. It should be inbuilt to whatever system we are building. So there should be some kind of mandatory verification checks which is part of the system which the agent cannot skip, the agent cannot change.»
Leé la frase otra vez, porque tiene tres cláusulas y cada una mata una ilusión distinta:
| Cláusula | Qué prohíbe | Por qué importa |
|---|---|---|
| «not a choice» | La verificación como herramienta opcional del catálogo | Si el agente elige, el sistema auditado controla el control |
| «inbuilt» | La verificación como paso externo, orquestado por el prompt | Un prompt se olvida; el código, no |
| «cannot skip, cannot change» | La verificación configurable, desactivable, «modo rápido» | Todo gate con bypass se usa con bypass |
La implementación concreta es lo que hace la frase creíble: el chequeo vive dentro de la herramienta de envío. En el archivo submit_memo.py, en la línea 80, se ejecuta verify_memo antes de que el memo pueda salir. El agente no tiene una herramienta de verificación que puede llamar: tiene un camino de salida que no puede atravesar sin pasar por el control.
Ese detalle de arquitectura —siete líneas de código dentro de una tool, presentadas en veinte segundos de un taller de treinta y dos minutos— es la diferencia entre un sistema que puede verificar y un sistema que verifica. Y es la misma distinción que separa un linter que se corre en CI de uno que se puede omitir con --no-verify: el primero es una propiedad del repositorio, el segundo es una cortesía del desarrollador.
En los últimos dieciocho meses, la forma más común de «agregar verificación» a un agente fue agregar una herramienta más: review_code, verify_output, check_facts. Se anota en el catálogo, se describe en el system prompt, y se confía en que el modelo la invoque cuando corresponda.
Eso no es verificación. Es verificación sujeta al criterio del verificado. El mismo componente que decide cuándo terminó decide cuándo revisarse, y esas dos decisiones nunca se pelean: un modelo que cree que su salida está bien no tiene motivo para pedir que la revisen. El resultado es un sistema con verificación en el menú y cero verificaciones en el log.
Hay una consecuencia que va más allá del código y que conviene decir sin rodeos, porque es el corazón de todo lo que escribimos: si la verificación depende del juicio del modelo, entonces el juicio del modelo es la frontera de seguridad del sistema. Y ya sabemos, con evidencia firmada por un regulador y por un vendor, que un modelo puede declarar correctamente que una acción es dañina y ejecutarla en la misma corrida. Un gate que depende de ese juicio no es un gate. Es una encuesta.
4. Las tres capas: determinista, juez-LLM y un abogado
La segunda mitad del taller es la parte que casi ningún proveedor publica, porque es aburrida y es exactamente donde se decide si el sistema sirve. La verificación no es una cosa: son tres capas con costos y garantías distintas.
| Capa | Qué verifica | Qué NO puede verificar | Quién puede saltarla |
|---|---|---|---|
| 1 · Determinista (min. 11:06) |
Completitud (¿todos los ítems del checklist quedaron probados?), formato (¿es JSON válido?), presencia de cifras, allowlist de herramientas | Si la afirmación es verdadera | Nadie. Es código |
| 2 · Juez-LLM (min. 11:47) |
Corrección semántica: ¿el claim sostiene el ítem que dice probar? ¿la cita respalda lo afirmado? | Nada de forma garantizada: hereda el modo de falla del modelo — probabilístico | Nadie, si está incorporado |
| 3 · Humano (min. 16:26, 28:13) |
Responsabilidad legal. Firma final del experto de dominio (en la demo, un abogado) | Escala: es el recurso más caro del sistema | Nadie, pero puede colapsar la operación si la capa 2 no filtra |
La demo tiene una elegancia que se entiende mejor cuando la ves fallar. El checklist que propone el agente se valida contra un checklist de referencia construido por un experto de dominio —en el caso del taller, un abogado— y se acepta si cubre al menos el 80% de los ítems de esa referencia. Ese 80% es, en palabras del propio expositor, arbitrario:
Y ahí hay que detenerse, porque es la parte del taller que más respeto me dio: el expositor declaró el número arbitrario de su propia demo, en vivo, sin que nadie se lo preguntara con mala intención. Eso es raro. La mayoría de los talleres presentan el umbral como si hubiera salido de un paper.
Y también hay que decir lo otro, que es donde nosotros no podemos simplemente aplaudir. Un umbral arbitrario y un umbral medido producen el mismo demo y empresas distintas. Nuestro equivalente —el corte que decide si dos razones sociales distintas son la misma entidad legal— no salió de una demo: salió de construir 1.249 pares etiquetados por RUT (no por un modelo), muestrear los negativos desde la cola alta de similitud, y medir. El resultado fue incómodo y es el de ayer: ningún umbral de coseno separa los estratos; a 0,86 los 150 negativos difíciles pasaban enteros. Con una segunda etapa, el corte de 0,90 deja precisión 0,991 con recall 0,226; el corte de 0,30 deja precisión 0,925 con recall 0,634. Por eso tenemos dos umbrales y no uno: uno para proponer candidatos a revisión humana, otro para afirmar una relación.
La honestidad obliga a completar la frase en el otro sentido: nuestro benchmark tampoco es la verdad. Los positivos son fáciles (mayúsculas y sufijos societarios), los negativos difíciles son hostiles por construcción, y las 1.249 muestras vienen de 863 entidades efectivas, no de 1.249 casos independientes. Un 0,991 medido en esa cancha no es un 0,991 en la naturaleza. Lo único que compra es que el umbral tiene un recibo y el de la demo tiene una confesión.
Las dos cosas me parecen mejores que la alternativa habitual, que es un umbral sin recibo y sin confesión.
5. El precio: veinte turnos contra treinta
Aquí está el dato que convierte todo lo anterior en una decisión de ingeniería y no en una arenga moral. La verificación no es gratis, y el taller lo midió sin querer queriendo. Al final de la sesión, comparando con la anterior, el propio expositor lo dijo:
Veinte turnos sin verificar. Treinta con verificar. Un 50% más de trabajo para el mismo encargo. Y ese 50% no es un defecto del taller: es el precio del producto, dicho en voz alta en un evento con 20.000 participantes.
El recorrido completo del caso, con los números que aparecen en pantalla, es todavía más elocuente que el titular:
| Iteración | Cobertura del checklist | Umbral | Resultado |
|---|---|---|---|
| 1ª propuesta del agente | 50% (min. 20:05) | 80% | Rechazado |
| 2ª propuesta (con el feedback) | 67% (min. 22:10) | 80% | Rechazado |
| 3ª propuesta | 83% (min. 22:54) | 80% | Aceptado |
| Memo · intento 1 | — | — | Rechazado por verify_memo |
| Memo · intento 2 | — | — | Rechazado |
| Memo · intento 3 | — | — | Aceptado — y luego firmado por un humano |
Ese 50 → 67 → 83 es la única curva del taller que prueba algo. No prueba que el modelo sea bueno: prueba que el feedback del gate se convirtió en trabajo útil del agente. Cada rechazo fue información que el sistema devolvió al sistema, y la tercera propuesta fue mejor que la primera por 33 puntos de cobertura. En una demo de treinta y dos minutos, esa curva es el argumento comercial completo.
Y también es el argumento contra el optimismo fácil, porque hay dos confesiones que viajan con la curva. La primera: el memo pasó a la tercera, y el expositor lo describió con una palabra que no es un tecnicismo —
—«tuvo suerte». No «convergió», no «optimizó»: tuvo suerte. Es la frase más honesta del taller y la que casi ningún vendor pronuncia. Un sistema que pasa a la tercera con suerte necesita las otras dos capas: la determinista para que la suerte no toque la forma, y la humana para que la suerte no firme.
La segunda confesión es el costo mismo. Lo dijo explícito en el minuto 21:06:
Y de ahí sale la decisión de diseño que casi nadie explicita: no se verifica todo, se verifica en los puntos críticos. La regla que dio para elegirlos es de una simplicidad brutal y es correcta: si el paso siguiente depende del resultado del paso actual, la verificación tiene que bloquear; si no hay dependencia, puede diferirse a un batch posterior.
Eso convierte la verificación en lo que realmente es: un problema de presupuesto. Tenés una cantidad finita de latencia tolerable, y cada chequeo compra precisión con tiempo. La pregunta no es «¿verificamos?» sino «¿en qué tres puntos de este flujo se decide el resultado, y cuánto de mi presupuesto de latencia pongo ahí?».
Cuando compares dos sistemas que se dicen «con verificación», hacé la única pregunta que separa el producto del folleto: ¿cuánto más lento es, medido, y en qué puntos bloquea?
Un sistema que duplica la latencia y bloquea en los tres puntos correctos es un producto. Uno que la duplica y bloquea en todos es un impuesto. Uno que no la cambia y dice que verifica está mintiendo en algún lado, y ese lado es siempre el mismo: el gate no se ejecuta.
6. Las tres preguntas del chat que eran, en realidad, de harness
El tramo de preguntas del taller 2 es más valioso que la demo, porque las preguntas las hizo gente que estaba construyendo. Tres de ellas, y sus respuestas, son la clase de harness que venimos documentando desde septiembre.
a) «¿Cómo pruebo que el agente no inventó un número?» (min. ~18:00). La respuesta salió del marco correcto: no se resuelve con más criterio del modelo, se resuelve con un chequeo determinista. Si no querés que el agente emita cifras, verificá la presencia de cifras en la salida y regenerá. La frase que ordena todo: hay que mantener un equilibrio entre lo determinista y el juez-LLM, porque cada uno ataja lo que el otro no ve.
b) «¿Qué impide que el agente reemplace un documento después de pasar la verificación?» (min. 19:27). Es la mejor pregunta del taller, porque describe el ataque exacto: presentar una versión saneada para la aprobación y sustituirla por otra. Y la respuesta es una definición de perímetro:
Ahí está la frase que bajó el conteo de «harness» de cinco a uno: el harness es la lista de lo permitido y el código que rechaza todo lo demás. No es un diagrama. Es un if que dice no.
c) «¿Se pueden correr los chequeos en batch, después de que el agente respondió?» (min. ~30:00). La respuesta —depende de si el paso siguiente depende del actual— es la misma regla del presupuesto, aplicada al tiempo. Y agregó una idea para el problema inverso, el de los resultados que se conocen días después: poner hitos chicos en el medio, para que el feedback llegue antes de que sea tarde.
Esa última idea es la que más nos sirvió a nosotros, y no por lo que dijo, sino por lo que confirma: un agente con un objetivo a diez días no se corrige al final. Se corrige cada vez que cruza un hito verificable. Es la diferencia entre un proyecto con un examen final y un proyecto con veinte exámenes cortos.
7. «Una sesión de constructor y otra de revisor» — o por qué el taller cerró con nuestro septiembre
La última pregunta del taller fue también la más directa: ¿recomendás una segunda sesión de Muse Code que actúe como verificador? La respuesta, en el minuto 31:08, fue la única vez en treinta y dos minutos en que el expositor se entusiasmó con una idea ajena:
Dos agentes. El mismo modelo. Uno escribe, el otro revisa y no puede tocar nada. Separación de funciones aplicada a un agente: el que produce no es el que aprueba.
Eso lo construimos en septiembre, después de una derrota. La versión 2 de nuestro harness le pedía al worker que resolviera un bug de TypeScript: escribió cero archivos en dieciséis minutos. La versión 3 separó los roles —worker que produce, verifier que revisa el diff y devuelve un veredicto— y el mismo modelo, con el mismo prompt de tarea, produjo un fix verificado con tsc -b en EXIT 0 en unos diez minutos: tres archivos, 495 líneas añadidas, 194 eliminadas. Y el verifier encontró algo que ni el worker ni el compilador veían: una llamada a requestFrame que solo existía en Chromium.
No cambió el modelo. Cambió el sistema alrededor. Eso lo publicamos el 6 de septiembre y lo volvimos a publicar el 27 de octubre con el taller de Meta como prueba externa. Hoy, el equipo de Meta recomienda exactamente esa arquitectura como respuesta a la última pregunta de su propio taller.
Tres cosas para decir sobre eso, en orden de honestidad:
Primero: no es un endorsamiento. Es convergencia. Llegamos al mismo lugar por caminos distintos y con un año de diferencia en la motivación: ellos porque tienen que vender un producto que no sea un generador de alucinaciones; nosotros porque teníamos un worker que no escribía nada.
Segundo: la convergencia es la señal. Cuando dos actores con incentivos opuestos llegan a la misma arquitectura, la arquitectura deja de ser una opinión. Es el mismo argumento que usamos con el harness de NVIDIA a 30% → 100%: no importa que lo diga un proveedor, importa que lo diga mientras describe su producto.
Tercero, y el más importante: una recomendación no es una implementación. «Dos sesiones, una que revisa y no puede cambiar nada» suena simple y tiene cuatro decisiones detrás —quién define el criterio de revisión, qué pasa cuando el revisor se equivoca, cómo se corta el bucle, quién firma— y ninguna de las cuatro estaba en la respuesta. Nosotros llevamos dos meses peleando con la cuarta.
8. Y mientras eso pasaba, el repo: 43 commits, 264 tests y un número que no voy a presumir
El taller 2 cayó el día 3 de nuestro hackatón, y sería fácil contar este artículo solo con la transcripción. Pero hay una segunda fuente, y es más incómoda porque es nuestra: el repositorio. Estos son los números reales del proyecto al momento de escribir esto, medidos con git log y pytest --collect-only.
| Métrica | Valor medido |
|---|---|
| Commits | 43 en tres días → 27-oct 25 · 28-oct 7 · 29-oct 11 |
| Líneas añadidas / borradas | 75.733 / 236 |
| De esas, JSON de datos y benchmarks | 55.936 — el 73,9% |
| Python escrito (sin tests) | 13.374 líneas · 94 archivos |
| Tests | 264 en 23 archivos · 3.575 líneas |
| Ratio tests / código | 26,7% |
| Archivos tocados | 133 |
| Endpoints en producción | 2 · portal público + /network/{rut} — ambos HTTP 200 |
Hay tres maneras de leer esta tabla y solo una me parece honesta.
La primera es la del marketing: «setenta y cinco mil líneas en tres días». Es verdad y es basura. 55.936 de esas líneas son archivos JSON de benchmarks —pares etiquetados, índices de nombres, muestras de proveedores— que no escribimos a mano: los generamos con un script. El número real de código es 13.374 líneas de Python, y las otras 1.400 son JavaScript del portal, 1.649 de documentación, 368 de CSS. Un tercio de lo que presumiríamos es dato, no ingeniería.
La segunda es la de la vanidad técnica: «264 tests». También es verdad, y también necesita contexto. 264 tests no significan 264 comportamientos probados: hay tests que verifican normalizadores de RUT, hay tests de ida y vuelta de serialización, y hay tests que existen porque el motor de grafos tiene un dialecto con nueve maneras distintas de devolver cero aristas sin lanzar una excepción. La cifra correcta es menos épica: un cuarto del código es test, y ese cuarto es la razón por la que el sistema se puede tocar sin miedo.
La tercera es la que me interesa, y es una coincidencia que no voy a convertir en causalidad:
El 28 de octubre, el día del taller de verificación, el repositorio tenía 142 tests. El 29 de octubre, al cerrar el día siguiente, tenía 264: +122 tests en un día, un +86%.
No voy a decir que el taller causó eso. La causa fue aburrida y local: ese día entraron la cadena de evidencia, el parser de PDFs y el portal, y cada uno trajo sus tests. Lo que sí puedo decir es que la única métrica del repositorio que se movió en la dirección correcta el día que hablamos de verificación fue la que mide verificación. Si eso no es causalidad, al menos es un buen recordatorio de dónde se pone el esfuerzo cuando el problema se nombra bien.
Y hay un cuarto número que no está en la tabla porque no es un número: los tests no son el gate del producto. Los tests verifican que el código hace lo que dijimos que hace. No verifican que lo que dijimos que hiciera sea lo correcto. Es la misma distinción de las tres capas del taller, aplicada a nosotros: la capa determinista (tests) es necesaria, la capa de criterio (revisión, evidencia, humano) es la que decide si el sistema sirve. Un repositorio con 264 tests verdes y una pregunta mal formulada sigue siendo un repositorio con la pregunta mal formulada.
9. Lo que este taller no resuelve
Un artículo que solo celebra la coincidencia no sirve. Estas son las cuatro cosas que el taller dejó abiertas, y que a nosotros nos tocan de cerca.
| Hueco | Por qué importa | Qué hacemos nosotros |
|---|---|---|
| «Citation» desapareció (6 → 0 menciones) | Verificar corrección semántica no es verificar procedencia. Un juez-LLM puede aprobar una afirmación cuya fuente no existe | Regla propia: si no se puede trazar a documento y página, se borra. La cita no es evidencia de estilo: es la condición de existencia del claim |
| El gate no valida la inferencia | El chequeo confirma que la cita existe; no que la conclusión se siga de ella | Lo declaramos como límite en el artículo anterior y lo repetimos acá: nuestro gate no nos hace inmunes |
| El juez-LLM hereda el modo de falla | Un verificador probabilístico comparte el error del verificado, y puede ser persuadido por el mismo texto | De ahí la obsesión con lo determinista: forma, completitud, allowlist, existencia de la cita. El criterio humano queda para lo que el código no puede ver |
| El 80% era arbitrario | Un umbral sin justificación es una política disfrazada de parámetro | Umbrales medidos sobre pares etiquetados — y la declaración explícita de que el benchmark tampoco es la verdad |
Y una quinta, que no es un hueco del taller sino del mercado: nadie está publicando el costo del gate en dinero. Se publica en turnos (20 → 30), se publica en latencia, no se publica en pesos por tarea. Nosotros tenemos el número por el otro lado —98,99% de cache hit y US$0,0149 por millón de tokens mezclados en el último ciclo auditado— y aun así no sabemos cuánto cuesta verificar en nuestro propio sistema, porque nunca lo separamos en la contabilidad. Es una métrica que deberíamos tener antes del 9 de noviembre y todavía no tenemos.
10. Cierre: el gate es lo que no se puede filmar
Volvamos a la asimetría que ordenó la primera parte de este taller, porque la segunda la resolvió de una manera que no esperábamos. Dijimos entonces que el loop se puede filmar y el gate no, porque el éxito del gate es invisible por diseño: produce una resta, no un artefacto. La segunda sesión lo confirma con una ironía perfecta: para demostrar que existe un gate, hay que mostrar un rechazo. Los tres momentos más didácticos del taller fueron tres fracasos del agente —50%, 67%, memo rechazado dos veces—. La verificación se enseña mostrando lo que impidió.
De ahí sale la frase que me llevo, y que no es del taller sino de la aritmética del taller:
Y esa diferencia, para quien está comprando esto en una empresa, se traduce en una pregunta que se puede hacer en una reunión y que desarma casi cualquier propuesta:
«Muéstrame un rechazo.» No la arquitectura, no el diagrama de capas, no el benchmark del modelo. Un rechazo: el momento en que el sistema se negó a entregar algo, con la razón y el log. Si no hay un rechazo en la demo, no hay gate en el sistema. Y si no hay gate, lo que estás comprando es velocidad con una capa de confianza que nadie firmó.
Quedan seis días para el cierre del hackatón y no vamos a llegar con el sistema completo. Vamos a llegar con lo que sí podemos sostener: un gate que rechaza, dos umbrales con recibo, y la lista de lo que no construimos. El 9 de noviembre publicamos el post-mortem con todos los números —gane o pierda—, incluida la cuenta de verificación que hoy no tenemos.
El post-mortem completo, el 9 de noviembre — gane o pierda
El 4 de noviembre cierra el hackatón de Meta. El 9 publicamos el cierre con todo: cuántas señales sobrevivieron al gate final, cuántas cayeron, cuánto costó verificar en pesos por tarea, y qué partes del sistema no llegamos a construir. Incluido lo que salió mal.
Si estás construyendo agentes que producen algo que alguien va a firmar —compliance, compras públicas, salud, datos regulados— la conversación útil no es sobre el modelo. Es sobre qué puede rechazar tu sistema, en qué punto del flujo lo hace, y cuánto te cuesta en latencia. Escríbenos.
Hablemos →Nota metodológica: las cifras de las dos sesiones provienen de transcripciones propias (411 y 536 segmentos; 4.382 y 5.251 palabras) de los talleres públicos del hackatón de Meta del 27 y 28 de octubre de 2026; los conteos de términos son literales sobre ese texto y los timestamps indican el inicio del segmento citado. Las cifras del repositorio son mediciones directas con git log --numstat y pytest --collect-only sobre el proyecto Expediente, y se declaran los límites: las líneas de datos JSON se contabilizan aparte porque no son código escrito a mano. Los números de la demo (20 y 30 turnos, 50/67/83% de cobertura, umbral 80%) son los que el expositor mostró y verbalizó en vivo; no son un benchmark del producto. Meta no ha validado, revisado ni endorsado este análisis.