Qué ocurrió
Agentes de IA · Gobernanza · Ingeniería de software · Evaluación comparativa · Informe de investigaciónartículo del 20 ago 2026 · paquete leído en la versión 0.2.72, 28 ago
arXiv:2608.20622 · una propuesta, y el paquete que nombra
El harness se publica, la gobernanza no
El 20 de agosto de 2026 George Salapa publicó en arXiv una propuesta de arquitectura de 21 páginas: déle a una gran empresa un solo harness (traducción provisional: armazón de agente) de codificación, ejecútelo sin modificar detrás de cada superficie, y toda la flota se vuelve auditable, porque revisar una solución deja de ser una revisión de código y pasa a ser la lectura de un fichero de instrucciones. El artículo nombra su implementación de referencia, que es un paquete de Python real con 83 versiones publicadas. Leer ese paquete es lo que hace este informe. El harness que el artículo describe está ahí, con detalle. Los cuatro servicios en los que descansa su argumento de gobernanza, no — y su licencia prohíbe el fork sobre el que gira el modelo de despliegue.
Las cifras Cada una contada a partir de un registro que cualquiera puede descargar: la API de arXiv, la API de PyPI y la propia distribución de código del paquete
- 83versiones detrás de la única URL que el artículo ofrece como divulgación. No nombra ninguna
- 0veces que
risky— la marca sobre la que gira todo el mecanismo de riesgo del artículo — aparece en el paquete publicado - 8/8referencias de arXiv que resuelven, con cada lista de autores coincidiendo con el registro y en orden — una de ellas de 42 nombres
- 0bancos de pruebas en el artículo, que lo dice él mismo: “Ningún banco de pruebas acompaña a estas afirmaciones”
El registro, graduado Ordenado por cuánto se sostiene cada punto, no por su interés
| Estado | Qué | Cómo se comprobó |
|---|---|---|
| Confirmado | Una propuesta de arquitectura de 21 páginas se envió a arXiv a las 23:44 UTC del 20 de agosto de 2026, en cs.AI y cs.SE, de un solo autor, con nueve referencias y tres figuras | El registro de la API de arXiv y la página de resumen concuerdan con el documento |
| Confirmado | Las ocho referencias de arXiv existen, y cada lista de autores de la sección de referencias coincide exactamente y en orden con el registro — incluida una de 42 autores | Cada identificador consultado en la API de arXiv y comparado nombre por nombre |
| Confirmado | La implementación de referencia que nombra es real y está vigente: 83 versiones del 5 de abril al 28 de agosto de 2026, con el código Python incluido en la distribución | El registro JSON de PyPI, y después la distribución de código descargada y listada |
| Confirmado | Su licencia permite instalarlo y ejecutarlo para uso interno de negocio, y prohíbe copiar, modificar, hacer fork, descompilar, aplicar ingeniería inversa o crear obras derivadas sin permiso escrito | El fichero LICENSE dentro de la distribución; el clasificador de PyPI dice License :: Other/Proprietary License |
| Confirmado | El artículo no nombra ninguna versión. Sesenta y nueve versiones lo precedieron y catorce lo han seguido, así que la URL que cita no ha significado lo mismo dos veces | Marcas de tiempo de subida de las 83 versiones, divididas en el momento de envío del artículo |
| Confirmado | Nada en el paquete nombra la capa de gobernanza: risky, gateway, entitlement, config.yaml y live_skills aparecen cero veces cada uno | Búsqueda sin distinción de mayúsculas en los 231 ficheros. Los 20 aciertos de registry son el registro de alias de modelos, que es otra cosa |
| Confirmado | La barrera de aprobación que el paquete sí implementa se dispara por el nombre de la herramienta, desde un conjunto fijo — {"bash_", "edit_", "write_"} por defecto | Leído en claude_loop_.py, donde la barrera es una comprobación de pertenencia por nombre |
| Confirmado | En los modos desatendidos — la superficie sobre la que descansa el argumento del artículo sobre la columna vertebral por cron — ese conjunto está vacío, así que no se filtra nada | Los puntos de entrada headless y batch pasan un conjunto vacío, y sus propios comentarios dicen “no approval gate” |
| No público | Los proyectos de los que se extrae la arquitectura. Empresas europeas de automoción, fabricación, gran consumo y sanidad, evaluadas sobre Azure | Nadie puede comprobarlo. El artículo dice llanamente que los encargos de clientes o empleadores concretos no se nombran ni se describen, y pide ser juzgado por la arquitectura |
| Conjetura | Que la distancia entre la propuesta y el artefacto publicado es específicamente la capa de gobernanza | Lectura de este informe. Es una observación sobre qué cadenas aparecen en un paquete, y no dice nada sobre lo que existe sin publicar |
| Conjetura | Que el artículo y el estudio empírico publicado cinco días después quizá discrepan sobre el nivel de modelo y no sobre los esquemas | De nuevo, lectura de este informe. Ninguno de los dos artículos lo dice, y ninguno prueba el régimen del otro |
Cronología
Un campo, luego una propuesta, luego una prueba de ella Cada fila es una fecha de publicación o de lanzamiento, y todas son públicas
- 24 mar 2026Anthropic publica su propio trabajo de diseño de harness, llegando a una arquitectura fija de tres agentes: planificador, generador, evaluador
- 31 mar 2026Se publica Terminal Agents Suffice for Enterprise Automation — un agente de terminal y sistema de ficheros que iguala o supera arquitecturas más complejas a una fracción del coste. Revisado a una tercera versión el 5 de agosto
- 5 abr 2026La versión 0.1.0 del harness que el artículo nombrará después llega a PyPI, cuatro meses y medio antes que el artículo
- 10 abr 2026Can Coding Agents Be General Agents? prueba uno contra un ERP de núcleo abierto: tareas simples fiables, las complejas fallando de cuatro maneras características
- 14 abr 2026Dive into Claude Code compara tres harnesses y halla que cada uno responde de forma distinta a las mismas preguntas de diseño
- 7 may 2026Stop Comparing LLM Agents Without Disclosing the Harness sostiene, como artículo de posición, que la configuración del harness puede pesar más que la elección de modelo en tareas de largo horizonte entre modelos de capacidad comparable
- 11 may 2026Beyond Autonomy sostiene que los marcos de agentes priorizan la autonomía sobre la gobernabilidad, y propone una revisión por niveles de riesgo
- 13 may 2026Un estudio de harness sobre descubrimiento de algoritmos halla que, con un presupuesto fijo de tokens, menos algoritmos pensados más a fondo puntúan más que muchos superficiales
- 18 may 2026Code as Agent Harness, una revisión de 42 autores, nombra seis retos abiertos, entre ellos la supervisión humana de acciones críticas para la seguridad
- 12 jun 2026HarnessX defiende el punto estructural opuesto — los harnesses deberían evolucionar a partir de sus propias trazas, no quedarse estáticos — y reporta una ganancia media del 14.5% en cinco bancos de pruebas
- 28 jul 2026SHarD llega a la misma tesis desde la seguridad: la unidad que construir y distribuir es un harness endurecido, diseñado una vez y ejecutado sin modificar en todas partes
- 18 ago 2026Se publica la versión 0.2.58 del harness. Es la sexagésima novena, y la última antes del artículo
- 20 ago 2026El artículo se envía a las 23:44 UTC, nombrando ese paquete como su implementación de referencia y ofreciendo ese acto como su propia divulgación
- 25 ago 2026Cinco días después, un estudio empírico mide exactamente este tipo de envoltura y reporta un resultado mixto — mejor en una de cuatro celdas modelo-tarea, peor en dos
- 28 ago 2026Se publica la versión 0.2.72 — la octogésima tercera, y la leída para este informe
Lo que no tiene fecha alguna Un solo elemento, y es aquel del que se argumentan los cuatro mecanismos
Los encargos. El artículo dice que la arquitectura se nutre de trabajo en grandes empresas europeas de automoción, fabricación, gran consumo y sanidad, y que los encargos de clientes o empleadores concretos no se nombran ni se describen. Da tres ejemplos trabajados — aplicar reglas de política a un registro en un sistema de negocio, clasificar solicitudes entrantes contra un CRM, y una comprobación de fabricación que coteja el certificado de conformidad de un proveedor con una norma de material — y ninguno lleva fecha, nombre ni resultado medido. Es una posición defendible para cualquiera que escriba sobre trabajo con clientes, y está declarada y no escondida, que es lo que importa. Pero significa que la evidencia de campo tras los cuatro mecanismos no puede situarse en la cronología de arriba, y no puede comprobarla nadie.
- 3ejemplos trabajados, ninguno con fecha, cliente ni resultado medido
- 4sectores nombrados, todos en Europa, todos evaluados contra las primitivas de identidad y política de una sola nube
El argumento
La afirmación, y el gozne sobre el que gira Expuesta con las palabras del propio artículo, y luego seguida hasta donde lleva
La aportación del artículo cabe en una frase, y es buena: “Cuando cada solución comparte una base de código idéntica, auditar N soluciones se reduce a revisar N ficheros de instrucciones.” El código a medida justificaba una barrera de aprobación previa porque volver sobre él salía caro; si cada equipo entrega el mismo motor y solo difiere en dos ficheros de texto, ese coste desaparece, y con él la razón de la barrera. El registro pasa a ser un efecto colateral de subir código en vez de un comité al que esperar. Es un argumento real y bien construido.
Gira sobre un gozne que el artículo no nombra. Auditar N soluciones se reduce a N ficheros de texto solo una vez que alguien ha revisado la base de código compartida. Contra esa revisión se toma prestado todo el ahorro, y el artículo nunca dice quién la hace, con qué frecuencia ni contra qué. La literatura que cita lo agudiza en lugar de suavizarlo: el artículo de posición en el que se apoya sostiene que es el harness, y no el modelo, lo que determina el comportamiento, y por eso mismo un harness no leído bajo cada solución es una incógnita mayor que N leídos, no menor.
Para la implementación que nombra, esa revisión está limitada jurídicamente. La licencia permite instalar y ejecutar el paquete para uso interno de negocio, y prohíbe modificar, hacer fork, descompilar, aplicar ingeniería inversa o crear obras derivadas sin permiso escrito. El código Python viaja en la distribución, así que la barrera es legal y no técnica — pero la ingeniería inversa es donde suele acabar la revisión de seguridad de una dependencia, y aquí figura como prohibida. Nada de esto hace que la arquitectura sea errónea. El artículo dice en otro lugar que ya existen harnesses de código abierto y que vale la pena estudiarlos directamente, así que nada del diseño exige uno cerrado. La tensión es con el artefacto, no con la idea.
- 83versiones tras la URL ofrecida como divulgación, y el artículo no nombra ninguna
- 0menciones de
gatewayoentitlementen el código publicado
Tres hallazgos, y lo que dicen los resúmenes citados El exceso está en el propio resumen del campo que hace el artículo; su sección de trabajo relacionado expone los tres correctamente
| Según el resumen | Lo que dice el resumen citado | Veredicto |
|---|---|---|
| Los harnesses bastan a nivel de tarea y superan a arquitecturas más elaboradas en trabajo empresarial — sobre dos citas | El primero dice que los agentes de terminal “igualan o superan” arquitecturas más complejas “a una fracción del coste”. El segundo no compara arquitecturas en absoluto: reporta tareas simples que salen bien y complejas que fallan de cuatro maneras características | Medio sostenido. La primera cita lo respalda, menos el “igualan o” y menos el resultado de coste, que es la mitad más fuerte de ese hallazgo. La segunda no lo respalda |
| La elección de harness explica la mayor parte de la varianza en los resultados de bancos de pruebas, más que la de modelo — y la sección de trabajo relacionado dice que el artículo citado lo “establece” | Empieza con “Este artículo de posición sostiene”. Su afirmación se ciñe a tareas de largo horizonte y a modelos de capacidad frontera comparable, y su redacción es que la varianza inducida por el harness “puede exceder sustancialmente” la inducida por el modelo | Se caen dos matices, y un artículo de posición no es algo que “establezca” un hallazgo |
| La brecha abierta entre ese hallazgo y la adopción empresarial es la gobernanza — sobre dos citas | El primero trata de lleno la gobernabilidad y lo respalda. El segundo es una revisión que enumera seis retos abiertos, de los cuales la supervisión humana de acciones críticas es uno | Justo, algo estirado. Un elemento de una lista de seis no es la brecha que esa lista nombra |
El mecanismo que se describe pero no se publica Y el que sí se publica, que es el diseño contra el que argumenta el artículo
El mecanismo de riesgo del artículo es preciso y poco común. Cada llamada a herramienta lleva {params, risky}; el modelo fija risky a partir de los parámetros que acaba de construir; una llamada que lo omite se rechaza antes de llegar a ningún backend. El artículo insiste en que ahí está la clave: el riesgo tiene alcance de llamada y es autodeclarado, “nunca un nivel estático adjudicado de arriba abajo a una herramienta o a un grupo de herramientas”. Una llamada marcada genera entonces una instancia nueva del mismo harness para juzgarla, de modo que el contexto que compuso la llamada no es el que la califica, y solo se pregunta a una persona cuando ese juez no puede resolverla.
Buscando sin distinguir mayúsculas, la palabra risky aparece cero veces en los 231 ficheros del paquete publicado. Tampoco aparecen gateway, entitlement, config.yaml ni live_skills. Lo que el paquete sí implementa es una barrera de aprobación indexada por el nombre de la herramienta, contrastada con un conjunto que configura el usuario, por defecto shell, edición y escritura — un nivel estático adjudicado de arriba abajo a una herramienta. En los puntos de entrada headless y batch, que son la superficie desatendida de la que depende el argumento sobre cron, ese conjunto se pasa vacío y los comentarios del código lo dicen sin rodeos.
Esto no contradice al artículo, y presentarlo como si lo hiciera sería deshonesto. La arquitectura pone la autorización fuera del harness a propósito, y el paquete se describe como el harness. Lo que sí muestra es dónde cae la línea: todo lo que un lector puede instalar y comprobar es la mitad del harness, que no era la parte nueva. Los cuatro servicios en los que descansa el argumento de gobernanza — pasarela, registro de soluciones, mapa de derechos, endpoint de disparo — existen como prosa y fragmentos breves. La sección de discusión del artículo enumera cinco limitaciones, y es franca en todas. Esta no está entre las cinco.
- 231ficheros revisados, 101 de ellos código Python, ninguno con la palabra
- 5limitaciones que el artículo enumera y asume. Esta no es una de ellas
Lo que añaden otros
Otros cuatro trabajos, y dónde cae cada uno Tres de los cuatro no están en la lista de referencias del artículo; uno es cinco días posterior
25 ago 2026 · no citado
El estudio controlado, publicado cinco días después
- Envolver un agente en una capa determinista mejoró la reproducibilidad en una de cuatro celdas modelo-tarea, la empeoró en dos y no hizo nada en la cuarta
- El diagnóstico a nivel de traza: cuando las secuencias de herramientas y estados ya son consistentes, un paso de planificación en texto libre sin restricciones pasa a ser la fuente dominante de varianza
- Su solución es validar el plan contra un esquema fijo antes de ejecutar herramienta alguna — que es justo lo que este artículo llama un saldo negativo, al defender que los parámetros queden abiertos
- La pega, y es real: sus modelos son uno de 7B y otro de 27B de pesos abiertos sobre tareas sintéticas, mientras que toda la apuesta de este artículo es la capacidad frontera. Ninguno prueba el régimen del otro, así que puede ser una discrepancia sobre nivel de modelo y no sobre esquemas — una lectura que ninguno de los dos ofrece
12 jun 2026 · no citado
La apuesta estructural opuesta
- Su queja es que los harnesses “siguen siendo en gran medida artesanales y estáticos”, y que las trazas que produce una ejecución rara vez se reinyectan para mejorarlos
- Reporta una ganancia media del 14.5%, hasta el 44.0%, en cinco bancos de pruebas, con las mayores ganancias donde la línea base era más débil
- Es un canje directo con el movimiento central de este artículo. Un harness idéntico en todas partes es justo lo que hace auditable la flota; adaptarlo por despliegue es lo que compra el rendimiento
- Ambas pueden ser ciertas a la vez. El artículo simplemente no nombra el canje, y quien sopese la arquitectura debería hacerlo
28 jul 2026 · citado
El artículo de seguridad con el que coincide, y los dos controles que deja fuera
- Nombra tres controles que puede llevar un harness distribuible: aislamiento del sistema operativo, escaneo de skills y restricción de herramientas
- Este artículo desarrolla el tercero, y lo dice. Su propia discusión admite que un contenedor es una garantía más gruesa que el aislamiento que SHarD probó, y que el escaneo de skills no tiene equivalente alguno
- Va más allá, y esta es la admisión más útil de toda la discusión: una skill traída en vivo en cada ejecución ensancha esa brecha en vez de estrecharla, porque no hay paso de reconstrucción donde insertar un escaneo ni imagen que comparar con una buena conocida
24 mar 2026 · no citado
El propio trabajo de harness de Anthropic fija el grafo
- La segunda decisión de diseño del artículo es que no hay grafo fijado en tiempo de diseño: una sola instancia llama al modelo repetidamente y compone su propia orquestación en ejecución
- El trabajo de harness publicado por Anthropic en marzo de 2026 llega a lo contrario: una estructura de tres agentes, decidida de antemano, a la que atribuye ejecuciones autónomas de varias horas
- Los dos no se oponen sin más. El juez del artículo es un evaluador, generado por cada llamada marcada, y el artículo se apoya abiertamente en el escrito multiagente de Anthropic de 2025, que cita con exactitud
- Aún así, un artículo titulado por aplicar las primitivas de un laboratorio toma una decisión estructural que el trabajo de harness publicado por ese laboratorio no toma
Conclusión
Qué se sostiene, qué sigue siendo propuesta, y qué conviene sostener con holgura Un artículo sin banco de pruebas no es un artículo sin evidencia — pero hay que llamar a la evidencia por su nombre
Lo que se sostiene, y es más que en la mayoría
El registro de citas está limpio. Las ocho referencias de arXiv resuelven y cada lista de autores coincide exactamente y en orden con el registro, una de ellas de 42 nombres — no es lo habitual en un preprint de un solo autor. La implementación de referencia es real, está vigente y coincide con el artículo en detalles que un lector puede comprobar: el fichero de estado que sigue a cada hijo generado, la mensajería por socket o buzón entre ellos, la interfaz de navegador, la línea de estado estructurada que cierra cada ejecución, y un registro de modelos cuyo valor por defecto es justo el modelo que nombra el ejemplo de configuración.
Qué sigue siendo una propuesta
Los cuatro servicios en los que descansa el argumento de gobernanza. Una pasarela que decide los derechos, un registro que anota qué se desplegó y quién lo hizo, un mapa de derechos en YAML bajo control de versiones y un endpoint de disparo: cada uno se describe con cuidado, cada uno se ilustra con un fragmento breve, y ninguno está en nada que un lector pueda instalar. Es una forma legítima de publicar una arquitectura — pero la mitad del harness ya era el terreno trillado, así que lo que un lector puede comprobar es justo la parte que no era nueva. El artículo es franco al no haber corrido ningún banco de pruebas y enumera cinco limitaciones. Lectura de este informe, no del artículo: la distancia entre la propuesta y el artefacto es una sexta.
La afirmación que conviene sopesar
“Auditar N soluciones se reduce a revisar N ficheros de instrucciones” vale exactamente lo que valga la única revisión de la base de código compartida contra la que se toma prestado, y el artículo nunca dice quién hace esa revisión. Para la implementación que nombra, la licencia permite instalar y ejecutar pero prohíbe modificar, hacer fork y aplicar ingeniería inversa sin permiso escrito — y la ingeniería inversa es donde suele acabar la revisión seria de una dependencia. El código viaja en la distribución, así que la barrera es legal y no técnica, y nada en la arquitectura exige un harness cerrado. Pero una empresa que adopte este patrón está eligiendo qué harness se sitúa bajo cada solución que llegue a ejecutar, y esa elección merece el mismo escrutinio que el patrón promete abaratar en todo lo demás.
Sostén esto con holgura
Todo lo contado aquí es una instantánea de una versión, leída ocho días después del envío del artículo. Nada en el historial de versiones sugiere que se retirara una capa de gobernanza — no estaba en ninguna de las versiones muestreadas — pero una instantánea es lo que es, y por eso las cifras de arriba llevan fecha. La evidencia de campo es incomprobable por diseño: los sectores se nombran, los clientes no, y el autor lo dice en vez de disimularlo, que es la versión honesta de una afirmación no verificable. Y un artículo que gradúa su propia confianza con cuidado en su sección de discusión, como hace este, se ha ganado una lectura que separe lo que argumenta de lo que ha publicado.