El modelo es stateless; el harness es el que recuerda: lo que el workshop de Meta dijo en voz alta — y lo que dejó para mañana

El 27 de octubre de 2026, en el minuto 30:22 de un taller de 32 minutos, un ingeniero partner de Meta dijo una frase que resume todo lo que este blog viene sosteniendo desde la Tesis del Harness. No la presentó como tesis. La dijo como definición técnica, al pasar, explicando por qué su herramienta guarda el historial de la conversación:

Hay que leerla dos veces, porque tiene dos mitades y la segunda es la que importa. El modelo es stateless. No recuerda, no acumula, no sabe qué pasó hace dos turnos: cada llamada entra limpia y sale limpia. El harness es el que tiene estado, porque es el que graba la conversación. Todo lo que en la industria se vende como «memoria del agente», «contexto persistente» o «que se acuerde de lo que hicimos ayer» no está en el modelo. Está en la capa que alguien construyó alrededor.

Eso, dicho por el equipo que construye el harness oficial del vendor que esta semana nos evalúa, no es una postura editorial. Es una descripción de arquitectura. Y es la primera vez en este blog que la tesis no la sostenemos nosotros contra la industria: la sostiene la industria, describiendo su propio producto.

Hubo una segunda frase, dos minutos antes, que es todavía más incómoda. El agente de demostración —un agente legal que investiga dos empresas ficticias— acababa de terminar su trabajo en 21 turnos y de archivar su memo. Y el ingeniero dijo:

Fijate en la secuencia, porque ahí está todo el artículo. Primero entregan el memo con la palabra «unverified» impresa encima. Segundo admiten que la salida es enteramente generada por IA y que ningún modelo es inmune. Tercero dicen que implementar las verificaciones defensivas «es tan importante como construir el agentic loop». Cuarto —y esto es lo que hay que medir— la verificación quedó explícitamente para el taller de mañana.

Los cuatro pasos son correctos, honestos y profesionales. Y los cuatro pasos, juntos, describen la asimetría estructural de toda esta industria.

Antes de seguir, la advertencia de siempre en este blog: Meta no nos validó a nosotros. No hay endorsamiento, no hay mención, no hay relación. Lo que hay es más interesante y más útil: un equipo de ingeniería de primer nivel describió, desde adentro, el mismo principio que sostenemos desde afuera. Que dos observadores independientes lleguen a la misma arquitectura es evidencia de la arquitectura, no del observador.

Este artículo hace tres cosas. Primero, desarma el taller como lo que fue: una clase magistral de anatomía de harness, con nombres y carpetas. Segundo, mide la asimetría entre lo que se construye en vivo y lo que se posterga, y explica por qué esa asimetría es un incentivo y no un descuido. Tercero, traduce todo eso a lo único que importa si estás construyendo en LATAM: qué piezas necesitás, en qué orden, y cuál de ellas no se puede comprar.

1. Cuatro carpetas alrededor de una llamada

Empecemos por lo más concreto, porque es lo que casi nadie mira: la forma del repositorio. Antes de escribir una sola línea de código de agente, los asistentes clonaron un repo llamado legal-agent-workshop. Y el instructor dijo esto, en el minuto 4:45:

«Cañería». No «el agente», no «la IA». La cañería que el agente va a necesitar. Y cuando uno abre el repo, la cañería tiene una forma muy específica:

Carpeta	Qué contiene	Qué rol cumple en el harness
cases/	Las tareas que el agente va a resolver hoy	Entrada del sistema. El caso, no el prompt: qué hay que resolver y con qué evidencia
agentkit/	Las primitivas: progress.py, case_record.py, document_text.py, client.py, tools/	El harness propiamente tal. Reanudación, registro de evidencia, procesamiento de documentos, cliente de API y herramientas
legal_agent/	loop.py, system_instructions.md, objective.md	La política. El bucle de razonamiento y las instrucciones de comportamiento
ui/	Una consola visual liviana	Observabilidad. Ver qué decidió el modelo, con qué contexto y qué devolvió cada tool

Fijate en la proporción. El modelo no tiene carpeta. Está dentro de client.py, que es —en palabras del propio instructor— «el SDK de OpenAI apuntado a nuestra API». Una llamada HTTP. Una función.

Y hay un detalle de honestidad técnica que vale más que toda la parafernalia: Meta hizo su API compatible con el SDK de OpenAI. El instructor lo dijo sin ningún rodeo en el minuto 24:03:

Leélo con cuidado, porque es una confesión arquitectónica enorme. Si cambiar de proveedor de modelos es cambiar una URL, entonces el proveedor de modelos es una commodity. Y si el proveedor de modelos es una commodity, el valor no está ahí. Está en todo lo que no se puede cambiar con una línea de configuración: el registro de evidencia, la política de reanudación, las herramientas, la observabilidad, la verificación.

De paso, deja una pregunta incómoda para el discurso de la soberanía del vendor: si tu capa de valor es el modelo y tu API es un conector intercambiable con el SDK de tu competidor, tu foso declarado es un conector. Volveremos sobre esto.

2. Las cinco piezas del harness, con el nombre que les puso Meta

Acá está la parte que convierte «harness» de abstracción en checklist. El instructor describió las primitivas de agentkit/ mientras el agente corría, y cada una tiene un nombre, una función y un problema que resuelve. Esta es la tabla que me hubiera ahorrado dos años de blog:

Pieza	Palabras de Meta	El problema que resuelve
Agent loop loop.py	«You're actually seeing the agentic loop in action» — plan, act, observe, repetir	Convertir un modelo de un turno en un proceso que persigue un objetivo hasta terminarlo o agotar presupuesto
Progress progress.py	«If the agent's execution pauses or fails before it completes its assignment, you can use progress to resume»	Que un fallo a mitad de camino no te obligue a empezar de cero — ni a pagar de nuevo por lo ya hecho
Case record case_record.py	«Recording evidence as the agent proceeds through its investigations»	Que cada paso deje rastro auditable: no qué dijo el modelo, sino qué encontró y de dónde
Tools agentkit/tools/	«As the scope of your agent grows, it might need more tools. And this is where you will want to implement some of those»	Que el agente pueda hacer cosas en el mundo en vez de solo describirlas — y que esas cosas sean funciones explícitas, no improvisación
Sandbox	«It actually has its own sandbox environment where it can execute code»	Ejecutar sin darle la máquina: si el agente puede correr código, tiene que poder correrlo en un lugar del que se pueda salir

Cinco piezas. Ninguna es un modelo. Ninguna se resuelve comprando tokens. Y las cinco aparecen en cualquier sistema agéntico que funcione en producción, con estos nombres o con otros.

La pieza que más me interesa es el registro de evidencia, porque es donde la coincidencia se vuelve incómoda. «Recording evidence as the agent proceeds through its investigations» es, palabra por palabra, la definición de lo que construimos en Expediente esta semana: un grafo donde cada afirmación está anclada a la arista que la acredita y a la página que la contiene. No lo copiamos de Meta —el workshop fue hoy— y Meta no lo copió de nosotros. Es la forma que aparece cuando dos ingenieros resuelven el mismo problema en serio.

3. El plan no es una feature: es un interlock

Hay un momento en el taller que un ojo entrenado no puede dejar pasar, porque no es una función del producto: es un mecanismo de control entre el humano y la máquina.

El instructor le pidió al agente que propusiera un plan antes de escribir código —y le prohibió explícitamente ejecutar los tests—. El agente propuso su plan. Entonces el instructor lo corrigió en vivo: «This looks fine, build it. But don't run the helper turns test after you build it.» Y después miró el resultado:

«Did obey.» Obedeció. Pensá en lo que se acaba de demostrar: el humano introdujo una restricción en el plan, y el sistema respetó esa restricción en la ejecución, y el humano pudo verificar que la respetó —solo un archivo modificado, ningún test corrido—. Eso no es «el agente es inteligente». Eso es un interlock: un punto donde la intención de un humano se convierte en una restricción ejecutable y verificable.

Y el instructor explicó por qué lo hizo así, con una frase que debería estar en el README de todo sistema agéntico:

«Para que no te sorprendas después.» Ahí está el propósito real del plan, y no es la calidad del output: es la ausencia de sorpresa. Un plan que podés leer es un punto de control. Un agente que actúa sin plan es un agente cuyo comportamiento solo conocés por el resultado — y si el resultado está mal, ya es tarde.

El harness tiene dos mecanismos más de la misma familia, y los dos son observabilidad pura:

Mecanismo	Cómo funciona	Qué te da que el resultado final no te da
Turn budget	Se fija un máximo de turnos plan-act-observe. En el demo: 30 de presupuesto, consumió ~21	Costo acotado de antemano. No descubrís el gasto en la factura: lo decidís antes de arrancar
Step-through	El agente pausa después de cada turno para que veas qué hizo	La decisión, no el resultado. Ves el contexto exacto que tuvo el modelo, la acción que eligió y la observación que recibió
El plan explícito	Propone y espera aprobación antes de tocar código	Un punto de veto. Podés corregir el rumbo cuando corregirlo cuesta cero

Los números del turno final son, en sí mismos, un argumento sobre por qué estas piezas existen. Al terminar, el run tenía: 1 mensaje de usuario, 20 notas de razonamiento, 20 llamadas a herramientas, 20 resultados de herramientas y 5 mensajes intercalados. Es decir: veinte decisiones, cada una con su contexto, su acción y su observación.

Ahí está la pregunta que separa un demo de un sistema: ¿podés explicar las veinte? Si la respuesta es no, no tenés un agente: tenés un generador de resultados con suerte variable. Y cuando uno de esos veinte turnos esté mal, sin los veinte vas a tener que adivinar cuál fue.

4. La asimetría: 14 minutos de loop, 5 de verificación

Acá está el hallazgo central del artículo, y es una medición, no una opinión. Transcribí el taller completo —411 segmentos, 32 minutos con 3 segundos— y marqué los límites de cada bloque. Esto es lo que salió:

Tramo	Minutos	Qué se vio en pantalla
Intro, setup del repo, tour de carpetas	~4,5	«We've pre-built some of the plumbing»
System prompt, ground rules, presentación de Muse Code	~5	Definición del comportamiento del agente
Construir el agent loop en vivo	~14	Plan → aprobación → código → step-through turno por turno
El memo «unverified» + «tan importante como el loop»	~2	Una advertencia, no una demostración
Q&A sobre verificación, citas y alucinaciones (diferido a mañana)	~3	Conceptos, sin código
Cierre y logística	~2,5	Office hours, grabación

La medición es mía y los límites entre bloques son un juicio: el taller no viene con capítulos. Pero el orden de magnitud no admite discusión.

≈14 minutos construyendo el bucle contra ≈5 minutos de verificación —y de esos 5, la mayor parte fue explicar por qué hace falta, no mostrarla funcionando. La proporción es de casi 3 a 1, y el denominador incluye la parte que se postergó.

Ahora, la parte importante: esto no es una crítica a Meta. Es una serie de dos partes y está honestamente declarada así desde el minuto 1:51 —«tomorrow we're going to focus on verification»—. Lo que estoy midiendo no es la conducta de un equipo, es la forma de un incentivo. Y el incentivo es este:

Y hay un detalle que remata el argumento, y es el uso del verbo. Escuchá otra vez la construcción de la frase: «It's as important as building the agentic loop». Cuando algo es tan importante como otra cosa, en la práctica ya quedó en segundo lugar. Nadie dice «la fundación es tan importante como el techo» y después construye el techo primero. La frase es un acto de reconocimiento —y de jerarquía—.

Por eso el artículo no pide que dejemos de construir loops. Pide algo más simple y más difícil: que el gate deje de ser la segunda sesión. Que la verificación no sea el capítulo que se graba cuando ya todos se fueron, sino una parte del sistema que se construye desde el primer commit, porque —como veremos— hay dominios donde no es opcional.

5. El multiplicador de nicho: por qué en LATAM el gate pesa más

Hay una frase en el Q&A final que, si estás construyendo para un mercado como el chileno, deberías imprimir y pegar en el monitor. El instructor estaba explicando por qué las alucinaciones han bajado en general, y de pronto puso la excepción:

Leélo de nuevo, porque hay dos afirmaciones ahí y la segunda es la que decide arquitecturas. Primera: la mejora de los modelos no es lo único que bajó las alucinaciones — los harnesses, las skills, las instrucciones y las herramientas para auto-verificarse contribuyeron. Segunda: cuanto más nicho y más esotérico el dominio, más sube la probabilidad de alucinación o de tergiversación.

Ahora aplicá eso a lo que hacemos en esta parte del mundo. Los dominios donde una empresa latinoamericana realmente necesita IA son, casi por definición, nicho y esotérico:

Dominio	Por qué es nicho	Qué significa para el harness
Compras públicas chilenas	Mercado Público, Compra Ágil, umbrales de fraccionamiento, tratos directos: normativa local, vocabulario propio, sin corpus público de entrenamiento comparable	El modelo no sabe qué es una «orden de compra fraccionada» en Chile. O lo aprende de tus documentos, o lo inventa
Cumplimiento Ley 21.719	Reglamento en despliegue gradual, criterios que todavía se están fijando	El modelo no tiene jurisprudence que citar: tiene que citar el texto legal, o no tiene nada
Procesos internos de una pyme	Ningún modelo vio jamás el Excel de esa empresa, ni su organigrama, ni sus excepciones	Todo el conocimiento vive en documentos de la empresa: si no hay cita, hay confabulación
Normativa sectorial (agro, pesca, minería)	Regulación específica por rubro, con criterios de servicio que no están en inglés	El dominio de mayor riesgo de tergiversación es exactamente el de mayor valor

La conclusión se escribe sola y es incómoda para todo el discurso del «adoptá IA y listo»: en LATAM el harness de verificación no es un lujo de empresa grande. Es la condición de entrada. Si el dominio es nicho, la probabilidad de error sube. Si la probabilidad de error sube, un sistema sin gate no es un sistema más barato: es un sistema que todavía no sabés si funciona.

Y hay una asimetría adicional, que es local: en estos dominios el revisor humano también es escaso. La promesa del agente es apalancar a un equipo chico. Si el agente alucina un 3% de las veces y no hay cien revisores, sino uno, el 3% se vuelve el 100% de lo que ese revisor no alcanzó a mirar. Ahí el gate no reemplaza al humano: es lo que hace que el humano alcance.

6. Citar no es verificar: detectar vs. no poder exportar

Acá llegamos al punto técnico más fino del taller, y al que más se malinterpreta. Un asistente preguntó por patrones para reducir alucinaciones —forzar plan-execute-verify, usar tool output grounding, o un crítico incorporado—. La respuesta incluyó una frase que hay que leer con precisión quirúrgica:

La frase es correcta y es un avance real. Pero fijate en el verbo: identify. Identificar. Es decir: el propio sistema, mirando sus citas, puede detectar que se tergiversó. Es autoconciencia operativa —y es la mejor respuesta posible dentro del paradigma de «un modelo que se revisa a sí mismo».

El problema es que detectar no es lo mismo que impedir. Si el mecanismo de detección vive dentro del mismo modelo que alucina, entonces:

• El detector tiene el mismo modo de falla que el detectado. Un modelo que confabula una cita puede confabular la verificación de esa cita. No es mala fe: es la misma función, con el mismo tipo de error.
• La detección es probabilística. «Puede identificar» no es «identifica siempre». Y en un dominio nicho —donde según el propio instructor el riesgo sube— la probabilidad es el peor lugar para poner la garantía.
• Detectar antes de exportar no sirve si el export ocurre igual. Si el sistema detecta y aun así entrega, la detección es un log, no un control.

Nuestro diseño invierte el orden, y no por gusto: por una razón de ingeniería que se puede enunciar en una línea. Un modelo puede afirmar cualquier cosa; un gate determinista solo puede hacer siete cosas.

Y esto no es teoría en este blog. Es el estado de un repositorio. El gate de Expediente tiene siete razones de rechazo explícitas y una regla que gobierna todas: si una afirmación no se puede trazar a un documento y una página, se borra. No se marca con asterisco. No se pone en gris. No se entrega «con la advertencia de que es generado por IA». Se borra, y el dossier queda con lo que sobrevivió.

El paso siguiente es chico y es enorme: el identificador del expediente se deriva del contenido (sha256 canónico). Eso significa que dos ejecuciones sobre la misma evidencia producen el mismo expediente, y que si cambia una cita, cambia el id. Un documento que se puede firmar tiene que ser reproducible, no solo convincente.

7. La superficie MCP: dónde se muda el foso

En el minuto 24:34, alguien del chat preguntó si Muse Code soporta servidores MCP personalizados. La respuesta fue corta:

Dos palabras que reordenan el mapa: «I would say so». Traducido: el harness del vendor es extensible por fuera. No estás limitado a las herramientas que vienen en agentkit/tools/; podés conectarle las tuyas, y con eso el agente del vendor usa tu conocimiento.

Pensá en la implicación, porque es simétrica a la del SDK de OpenAI y apunta en la dirección opuesta. Si el modelo es intercambiable (cambiás una URL) pero el harness es extensible (le enchufás tus herramientas), entonces la ecuación de valor queda así:

Capa	¿Es reemplazable?	Dónde queda el valor
El modelo	Sí, trivialmente — misma interfaz, otro host	🔻 Commodity. Se compite por precio
El harness (loop, progreso, evidencia, sandbox, observabilidad)	No — es donde vive el estado y la política	🔺 El foso real, y el que casi nadie construye
Las herramientas MCP y el conocimiento que exponen	No, si son tuyas — son tu dominio, tu grafo, tus datos	🔺🔺 El foso compuesto: harness propio + herramientas propias

Ahí está el movimiento estratégico que esta industria todavía no internaliza. La discusión pública es sobre modelos —quién tiene el mejor benchmark, quién bajó el precio—. Pero el punto de apalancamiento es la intersección entre un harness que controlás y herramientas que solo vos tenés. Un modelo frontier conectado a tu grafo de dominio vale más que un modelo frontier conectado a la nada —y ese delta no lo puede replicar el vendor, porque el grafo no es suyo.

Y hay una razón de fondo para que esa integración importe más de lo que parece: un agente con tus herramientas deja de ser un agente que opina y se convierte en un agente que consulta. La diferencia entre decir «esta municipalidad parece concentrar compras» y decir «estas siete órdenes, en estas fechas, con estos montos, y aquí está el camino en el grafo que las conecta» no es de tono. Es de arquitectura de herramientas: en el primer caso el modelo improvisa; en el segundo, ejecuta una operación determinista sobre datos que no puede inventar.

8. Qué nos llevamos (y los recibos que podemos mostrar)

Si el harness es el producto, la pregunta que sigue es la única que un cliente serio hace: ¿y cómo sé que el tuyo funciona? No con adjetivos. Con números medidos contra la factura. Estos son los nuestros, del último ciclo auditado de nuestra propia operación:

Métrica	Valor medido	Por qué importa
Prompt-cache hit rate	98,99% sobre 12.471 requests	Es la métrica que demuestra si el harness está bien diseñado: el prefijo del prompt es estable, así que el proveedor no re-cobra lo que ya procesó. La referencia pública más fuerte que encontramos es ~92% (Claude Code)
Costo mezclado	$0,0149 por millón de tokens	Un orden de magnitud por debajo de lo que cuesta operar un agente «de juguete» con el mismo modelo
Tokens por turno	~142.000	Contexto grande y cache alto a la vez. Eso no es suerte: es estabilidad de prefijo como requisito de diseño
Verificación	Medida contra la factura de la API, no el dashboard	Porque los dashboards mienten sobre caching, y lo hemos visto

Y en el proyecto que estamos construyendo esta semana, el estado medible es este: 4.950.443 órdenes de compra agregadas desde 13.368.668 filas de 43 archivos (12 semestres, 5 años, 2,0 GB comprimidos), procesadas en 460 segundos. 117 tests sin motor, 124 con el motor de grafo. Y un hallazgo de calidad de datos que solo aparece si mirás en serio: 48 órdenes con dos montos totales distintos en el mismo archivo.

Ese último número merece un párrafo, porque es el tipo de cosa que un agente sin gate se come sin masticar. Si el sistema hubiera sumado esas 48 órdenes dos veces y hubiera construido un «hallazgo de fraccionamiento» sobre la suma inflada, el expediente habría sido impecable en su forma y falso en su fondo. Los datos públicos no son limpios, y el harness es el que tiene que saberlo.

La honestidad que hace que lo anterior valga

Cuatro cosas que este artículo no va a decir, porque no son verdad:

• No diremos que Meta nos dio la razón. Meta no nos mencionó, no nos evaluó y probablemente no nos conoce. Describió un principio de ingeniería que coincide con el nuestro. La coincidencia es la evidencia; el endorsamiento no existe.
• No diremos que su taller fue deficiente. Fue bueno, honesto y bien estructurado. Diferir la verificación a una segunda sesión es una decisión pedagógica legítima y la anunciaron en el minuto 1:51. La crítica es a la asimetría demostrable, no a ellos.
• No diremos que nuestro harness lleva años. En esta forma —con gate, grafo y expediente reproducible— tiene días. Lo que tiene años es el criterio de diseño; la implementación es de esta semana.
• No diremos que el gate nos hace inmunes. Un gate determinista verifica lo que puede verificar: que la cita exista, que la página sea la correcta, que el monto coincida. No verifica que la inferencia sea la correcta. Reduce el espacio de error; no lo elimina. Decir lo contrario sería vender humo con la misma voz con la que criticamos el humo.

El cierre: lo que el workshop dijo en voz alta

Resumamos los 32 minutos en tres frases que no son nuestras y en un número que sí lo es.

Uno. «El modelo es stateless; el harness tiene estado porque graba la conversación.» La memoria no está donde te dijeron que estaba.

Segundo. «Si tenés una aplicación que usa el SDK de OpenAI, solo cambiá el host de la API.» El modelo es un conector.

Tercero. «La verificación es tan importante como construir el agentic loop.» Y el número: 14 minutos de loop contra 5 de verificación en un taller de 32, con la verificación programada para el día siguiente.

Juntá las tres y el mapa queda claro. Lo único que no es intercambiable es la capa que nadie te enseña a construir, y esa capa es la que decide si tu agente sirve el lunes o solo sirve en el demo. El modelo lo vas a poder cambiar el mes que viene por otro más barato y mejor. El harness es lo que tu empresa va a seguir usando en cinco años —o lo que nunca tuvo.

Y hay una última cosa, que es la razón por la que este blog insiste con esto todas las semanas. La frase «el modelo es stateless» suena técnica, pero tiene una consecuencia política: si el estado vive en el harness, entonces quien controla el harness controla la continuidad del sistema. Podés tener el mejor modelo del mundo y, si el harness es de otro, tu operación es alquilada. Podés tener un modelo mediocre y, si el harness es tuyo, tu operación es tuya —y el modelo, cuando salga uno mejor, se cambia en una línea.

Ese es todo el argumento de la soberanía, y no hace falta invocar geopolítica: está en la arquitectura de un repositorio de taller. Cuatro carpetas alrededor de una llamada, y la decisión de quién las escribe.