Por qué las reglas de los agentes de IA fallan sin el contexto del SO

Una regla como «ejecuta la suite completa de pruebas antes de hacer commit» suena sencilla. En la práctica, ActPlane sostiene que no lo es en absoluto: permitir o no un git commit depende de qué archivos cambiaron después de la última ejecución de pruebas, de si los resultados siguen siendo válidos y de lo que permita la tarea actual.

Esa es la conclusión central de un estudio empírico de 64 repositorios populares que contienen archivos CLAUDE.md y AGENTS.md, capturados el 2026-05-23. A lo largo de 84 archivos de instrucciones y 2.116 enunciados individuales, el artículo encuentra que los desarrolladores ya escriben numerosas reglas para agentes. La parte difícil es convertir esas instrucciones en lenguaje natural en algo que un sistema pueda observar y aplicar de forma fiable a lo largo del tiempo.

Los investigadores clasifican cada enunciado de forma independiente en lugar de por archivo o sección. Informan que el 64% de los enunciados son políticas que requieren, prohíben o condicionan una acción del agente, mientras que el 36% son contexto descriptivo como notas de arquitectura o antecedentes del proyecto. La densidad de políticas varía notablemente, del 0% al 97% entre repositorios, y el 70,1% de los repositorios contienen más enunciados de política que descriptivos.

De las 1.361 políticas identificadas, solo el 17% son únicamente semánticas, es decir, dependen del razonamiento del modelo o del estilo de salida. El 83% restante son observables por el sistema:

Recomendado

La IA está poniendo fin al modelo de 'talla única' en los centros de datos

• 38% requieren inspección de contenido
• 29% coinciden con un único evento del SO
• 16% requieren estado entre eventos

Solo las categorías por evento y entre eventos —45% en conjunto— son directamente aplicables por el SO. Las políticas entre eventos son especialmente comunes en el Proceso de Desarrollo, que representa el 39,5% de todas esas políticas.

Esas reglas a menudo dependen de la secuencia y del estado, no solo de una acción aislada. El artículo destaca patrones recurrentes como el orden temporal, la consistencia entre archivos, los flujos de trabajo de varios pasos y los disparadores condicionales. Un sistema debe recordar qué se ejecutó, en qué orden y qué cambió desde entonces.

El contexto es otro obstáculo importante. De las 1.127 políticas observables por el sistema, solo el 26,4% son autónomas. La mayoría —64,2%— requieren contexto del proyecto, y otro 9,4% necesitan contexto de la tarea, como una aprobación explícita. El problema empeora para las reglas entre eventos: el 95% de ellas dependen del contexto, frente al 58% de las políticas de contenido.

La respuesta de ActPlane es un modelo de políticas que el agente puede escribir pero que el SO puede hacer cumplir. Sus reglas combinan una fuente gobernada, una operación objetivo como exec, write o connect, un efecto, una puerta temporal opcional y una cadena de motivo para la retroalimentación. El ejemplo del artículo es:

kill exec “git” “commit” unless after exec “go” “test” exits 0 since write “*/.go”

Eso terminaría un git commit a menos que go test haya terminado con éxito después de la edición de código fuente más reciente relevante.

La implementación es relativamente pequeña: aproximadamente 3,2 K líneas de Rust en espacio de usuario y 1,8 K líneas de C BPF para el motor de aplicación eBPF. Soporta hasta 128 reglas concurrentes, por encima de las 66 políticas del repositorio más grande observado. En el conjunto de datos de 607 políticas usado para probar el DSL, el 66% de las cláusulas son notify, el 29% son block y el 5% son kill. Los hooks se centran principalmente en exec (60%) y write (37%), mientras que las operaciones de red y de limpieza representan cada una menos del 1%.

La idea general del artículo es sencilla: las reglas para agentes no escasean. Lo que escasea es la aplicación que pueda transportar el contexto del repositorio, rastrear el estado entre eventos y aun así tomar decisiones deterministas en la capa del SO.