La capa faltante: Estructurando agentes de IA para jerarquías organizacionales

Un modelo de referencia sobre cómo las organizaciones estructuran su trabajo con IA

Jose Martinez · 1 de octubre de 2026 · v1.8.1 (medido en Claude Code; verificado de nuevo con la documentación de Anthropic el 1 de octubre de 2026)

En cinco líneas.

1. Las organizaciones son árboles: empresa, línea de trabajo, proyecto, tarea. Los proyectos de Claude son planos: el chat tiene un único bloque de organización de 3.000 caracteres, los proyectos en el chat y en Cowork no se anidan ni heredan entre sí y, dentro de un proyecto, una cuenta de conector pertenece a una persona o a toda la organización, nunca a una rama.

1. Así que cada proyecto recibe una copia hecha a mano de las reglas de su línea, esas copias divergen con el tiempo y nadie puede ver qué regla generó una respuesta.

1. Anthropic ya ha construido el árbol dos veces. Claude Code anida las instrucciones por carpeta y, desde el 1 de octubre de 2026, ejecuta los mods de la organización antes que los de la persona. Claude Tag, en Slack, hereda instrucciones y credenciales desde la organización al espacio de trabajo y de ahí al canal. Ninguno llega al proyecto. El mismo modelo sí podría hacerlo: una capa de línea de trabajo, proyectos que nacen de sus carpetas, tareas tipadas, un compilador que rechace conflictos antes de que el modelo los vea y permisos por nodo que funcionen en Team.

1. Lo medí en Claude Code, dos veces. Una regla de organización y una regla de proyecto contradictorias, en niveles distintos de CLAUDE.md y sin que ninguna estuviera marcada como vinculante: la regla del proyecto ganó 20 de 20 veces. La misma regla de organización marcada como obligatoria, pero solo con palabras: ganó 20 de 20. La precedencia la definía una redacción que cualquiera que edite cualquier capa puede cambiar, no la estructura.

1. Y ya funciona hoy. Una aplicación de escritorio que desarrollé ejecuta Claude Code dentro del árbol. Monta cada capa como un CLAUDE.md, limita a Claude a lo que la persona puede hacer en ese nodo, rechaza el conflicto en el momento en que se escribe y registra cada respuesta con sus reglas, sus tokens y su revisor. En las mediciones, el árbol cargó entre un 20 % y un 34 % menos de tokens de instrucción que las copias planas.

Las organizaciones son árboles. La empresa define la política, la línea de trabajo fija sus estándares, el proyecto los aplica a un encargo concreto y la tarea entrega una cosa específica. Todos los sistemas de calidad en los que he trabajado se construyen así, igual que el árbol de carpetas de casi cualquier servidor de archivos corporativo: empresa, línea de trabajo, año y luego una carpeta por encargo, nombrada con un número de trabajo que lo codifica todo.

Los proyectos de IA son planos. Uso a Claude como ejemplo porque es el producto con el que trabajo a diario y porque ya incluye la solución en dos de sus propias interfaces. En el chat de Claude, los proyectos no se pueden anidar y las instrucciones de la organización son un único bloque de hasta 3.000 caracteres que se aplica a todos. En Enterprise, los administradores pueden acotar los permisos por grupo. En Team, los roles se aplican a toda la organización. Nada de lo documentado en el chat o en Cowork transmite instrucciones hacia abajo, a un departamento o línea de trabajo, y de ahí a sus proyectos. En Enterprise, las habilidades y los proyectos se pueden compartir con un grupo, pero eso es distribución, no herencia.

Esa es la capa que falta: la que está entre la organización y el proyecto. Este artículo explica qué falta, por qué importa, cuánto cuesta realmente y propone un modelo de referencia que cualquier plataforma podría implementar, incluidos sus permisos y su estructura de datos.

1. Qué existe hoy

Verificado con la documentación de Anthropic entre el 29 de septiembre y el 1 de octubre de 2026. Claude tiene cuatro interfaces donde se ejecuta el trabajo de un equipo, y cada una con su propio modelo de instrucciones:

Los permisos dependen del plan:

Anthropic ha construido medio árbol para los permisos. En Enterprise, los roles personalizados se asignan a grupos; “los roles personalizados también controlan qué conectores, y qué herramientas de esos conectores, puede usar un rol”; en toda la plataforma, entre los niveles de organización, rol y usuario “gana el nivel más restrictivo”, mientras que los distintos roles de un miembro se suman; los administradores pueden “Ver el rol efectivo”, con una etiqueta de “Concedido por”; y los grupos pueden tener sus propios límites de gasto. Pero son grupos planos, no un árbol, y nada de esto llega a las instrucciones. Lo más parecido son los plugins: en Enterprise, un propietario puede hacer que un plugin y sus habilidades sean obligatorios o se instalen por defecto para un grupo, con un orden declarado (“configuración del grupo, luego configuración global de la organización, luego valor por defecto del marketplace”). Eso apunta a un grupo de personas, no a un proyecto; nada se hereda entre proyectos, y una habilidad sigue cargándose solo cuando Claude la considera relevante. Team tiene roles para toda la organización y comparte persona por persona; la configuración de sus plugins, según la documentación, “no tiene configuración de grupo”. Y Team es precisamente el plan pensado para empresas pequeñas y medianas.

Anthropic ha construido el árbol completo dos veces, fuera de los proyectos.

En Claude Code, por carpeta. Claude Code carga archivos CLAUDE.md desde cuatro niveles; “todos los archivos descubiertos se concatenan en el contexto en lugar de sobrescribirse entre sí”, ordenados “desde la raíz del sistema de archivos hasta tu directorio de trabajo”, y los archivos en subdirectorios “se cargan bajo demanda”. El bloque de una organización puede llegar como un archivo gestionado en cada máquina o como texto desde la consola de administración (la clave claudeMd). La documentación es transparente sobre el límite: Claude trata estos archivos “como contexto, no como configuración obligatoria”, y “si dos instrucciones se contradicen, Claude puede elegir una arbitrariamente”.

En Claude Tag, por canal de Slack. Claude Tag es Claude dentro del Slack de un equipo, en beta pública para Team y Enterprise. Su configuración se asocia a un ámbito, y “un ámbito es donde se aplica un paquete: acceso predeterminado a Slack (la raíz global de la organización), un espacio de trabajo o un único canal”. Tres cosas que el resto de este artículo pide ya están ahí:

• Las instrucciones se heredan. “Las instrucciones personalizadas por ámbito se concatenan: primero el acceso predeterminado a Slack, luego el espacio de trabajo y después el canal. Las instrucciones de un canal se suman, en lugar de reemplazar, a lo definido por encima”.

• Las credenciales pertenecen a la rama. En los canales, Claude actúa con cuentas de servicio que un administrador asocia a un ámbito, y “se usa la credencial del ámbito más estrecho: el canal supera al espacio de trabajo, que supera al acceso predeterminado a Slack”.

• Puedes ver de dónde viene el acceso. Cada fila de conector, repositorio y plugin indica “Heredado de” un ámbito superior o “Asociado desde” un paquete. El gasto tiene un tope para la organización y por canal, y se reporta por canal.

Los límites también están documentados. El árbol tiene la forma de Slack: tres niveles fijos, y los canales de Slack no se anidan. Las instrucciones son “una guía, no una barrera obligatoria”, y la documentación no describe ninguna comprobación de conflictos entre ámbitos. No hay “ningún registro por acción de cada tarea y quién la pidió”. Y se detiene en el borde de un proyecto: “Los proyectos en claude.ai no aplican aquí; Claude no lee las instrucciones ni el conocimiento de un proyecto en Slack, y un canal no puede apuntar a un proyecto”.

Qué cambió el 1 de octubre de 2026. Claude Code 2.1.287 activó los mods, que estaban en acceso anticipado: funciones dentro de un plugin que se ejecutan en Claude Code y pueden reescribir un prompt o una sección del prompt del sistema, bloquear o reescribir una llamada a herramienta, aprobar o denegar una solicitud de permiso y dibujar paneles en la interfaz. Tres cosas sobre ellos importan aquí:

• Tienen un orden declarado. Primero se ejecuta una protección integrada y los mods propios de la organización, y después los mods que instala la persona. “El primer mod es el más externo: ve el evento antes que los demás y el resultado después de ellos, y decide si los demás se ejecutan siquiera”. Donde se carga la protección (una máquina con configuración gestionada o un inicio de sesión de Team o Enterprise), el mod de una persona no puede cambiar “el prompt del sistema, tu CLAUDE.md gestionado y otras instrucciones gestionadas”, ni puede aprobar una llamada a herramienta que una regla de denegación rechaza. Esa es una precedencia definida por la estructura, que es exactamente lo que pide este artículo. Es un valor por defecto, no un candado: quien inicia Claude Code con --safe-mode se ejecuta sin los mods instalados, incluidos los de la organización, aunque los hooks gestionados y las reglas de denegación siguen aplicando.

• El orden tiene dos dueños. Los mods de la organización se ejecutan antes que los de la persona, o después si la organización así lo decide. No hay un nivel para la línea de trabajo. La configuración entregada desde la consola de administración “se aplica uniformemente a todos los usuarios de la organización. Las configuraciones por grupo aún no son compatibles”. Una organización que quiera una política distinta por grupo tiene dos caminos, ambos por TI: desplegar un archivo de configuración distinto en las máquinas de cada grupo o ejecutar un gateway autoalojado que “entregue configuraciones gestionadas por grupo de IdP”.

• No llegan al chat y llegan a Cowork de forma desigual. “Los mods funcionan en la CLI de Claude Code y en la pestaña Code de la app de escritorio de Claude”. Un mod se distribuye en hooks/hooks.json de un plugin, y la tabla de compatibilidad de plugins de Anthropic marca ese archivo como “Ignorado” en el chat. La misma tabla lo marca como “Carga” en Cowork, porque “Cowork en la app de escritorio de Claude ejecuta sus sesiones en Claude Code”; las páginas de mods no mencionan Cowork y yo no lo he probado. Lo que la organización controla allí es más limitado: en una sesión de Cowork, Claude Code “nunca obtiene la configuración gestionada por el servidor desde la consola de administración de claude.ai, incluso cuando el usuario inicia sesión con una cuenta de Team o Enterprise”, y las sesiones remotas de Cowork no tienen ninguna política de dispositivo que leer.

Qué se está desplegando. Cowork se está integrando en Claude: el centro de ayuda ahora dice “Claude Cowork ahora es simplemente Claude”, primero en Pro y Max, mientras que Team y Enterprise “mantienen el chat y Claude Cowork tal como están hoy”. El 6 de octubre de 2026, las nuevas tareas de Cowork en Pro y Max pasan a la nube. Y una nueva versión de los proyectos está en beta pública en Pro y Max, empezando por Claude Code, y luego le seguirán el chat, Cowork, Team y Enterprise; en ella, “un proyecto es una conversación” que Claude divide en hilos paralelos. Sigue siendo un único nivel: “Un proyecto pertenece a un usuario” y “no hay controles a nivel de organización para los proyectos durante la beta”.

Así que el árbol no es una idea nueva para Anthropic. Existe por carpeta para el código y por canal para Slack, y en ambos casos la organización va primero. El lugar donde una empresa archiva su trabajo, el proyecto, no tiene padre ni una línea por encima. Otras dos ofertas de Anthropic apuntan en la misma dirección y quedan fuera del alcance de este artículo: Claude for Government resuelve la configuración mediante una cadena de tenant, grupo y organización, y Claude Desktop en proveedores externos tiene políticas por grupo en beta.

2. Por qué importa

Los proyectos no son contenedores. Un encargo real sí es un contenedor. Tiene una clave (el número de trabajo), un padre (su línea de trabajo), un ciclo de vida (abierto, cerrado, archivado por año), una carpeta, un cliente, personas, reglas y entregables. Un proyecto de Claude tiene un nombre de texto libre, sin clave, sin padre ni hijos, y su ciclo de vida documentado consiste en archivarlo y borrarlo. Cowork puede vincular un proyecto a una carpeta local, pero solo a mano, un proyecto a la vez, sin patrón de clave y sin padre. Una línea de trabajo puede abrir cientos de encargos al año. Eso deja dos malas opciones: un proyecto de Claude hecho a mano por cada encargo, cada uno con su propia copia de las reglas, o un proyecto por línea de trabajo, donde el contexto de clientes distintos convive codo con codo.

La ruta de cargas se rompe. En ingeniería estructural, toda carga necesita una ruta continua hasta la cimentación. Quita un elemento y nada de lo que está por encima se transmite hacia abajo. Con las reglas pasa lo mismo. Cuando no hay una capa entre la organización y el proyecto, los estándares, plantillas y reglas de aprobación de una línea de trabajo no tienen dónde vivir. Así que cada proyecto recibe una copia hecha a mano.

Las copias divergen. Corriges una regla en un proyecto y los demás se quedan con la versión antigua. Cada proyecto sigue superando su propia comprobación local. El desfase solo aparece cuando alguien compara proyectos lado a lado y, en trabajos regulados, esa persona suele ser un auditor. Los equipos de infraestructura conocen bien este fallo. En la investigación de Firefly de 2026, cerca de un tercio de los encuestados relacionaba la desviación de configuración con incidentes costosos en producción, y aproximadamente uno de cada cinco no tenía ningún proceso para detectarla o corregirla.

La identidad también es plana. Mucha gente trabaja en más de una organización, y cada una necesita su propio contexto aislado. Dentro de cualquiera de ellas, en el chat y en Cowork, la cuenta de un conector pertenece a una persona, no a una rama. Los roles de Enterprise pueden decidir qué conectores puede usar un grupo, y un administrador puede autorizar un conector una sola vez para toda la organización; un conector personalizado incluso puede llevar una credencial compartida para todos (en beta). De cualquier modo, la cuenta es de la persona o de la organización, nunca de una rama: un consultor que atiende a dos clientes no puede vincular el Drive de cada cliente a los proyectos de ese cliente. Los proyectos compartidos lo hacen más evidente: “Los conectores solo están disponibles en proyectos privados”. Claude Tag demuestra que el otro diseño es posible, con una cuenta de servicio asociada a un canal de Slack, y también muestra dónde se detiene: en el proyecto. La página del conector de Google de Anthropic describe una única cuenta de Google conectada, y la forma documentada de cambiarla es desconectar y volver a conectar; tres issues abiertas (más abajo) piden poder usar más de una cuenta. El límite vive en la cabeza de la persona, que es exactamente el tipo de frontera manual que falla sin hacer ruido.

Nadie puede ver qué regla se aplicó. Claude Enterprise muestra a los administradores un “Ver rol efectivo” para los permisos, y /context de Claude Code enumera qué archivos de memoria se cargaron. Ahora un mod de Claude Code puede dibujar su propio panel, así que una vista de instrucciones efectivas es algo que cualquiera puede construir ahí. Claude Tag etiqueta cada conector y repositorio con el ámbito del que se heredó, pero para las instrucciones su documentación dice que hay que “pedirle a Claude que repita sus instrucciones de administrador”. Ninguna interfaz muestra, para una respuesta concreta, qué instrucción vino de qué capa. Sin procedencia no hay pista de auditoría, y sin pista de auditoría no hay sistema de calidad.

La gente ya está pidiendo piezas de esto. Issues abiertas en el tracker público de Anthropic (github.com/anthropics/claude-code), consultado el 2026-10-01:

Una séptima, la #47741, pedía un CLAUDE.md gestionado por la organización y se cerró porque Claude Code ya tiene uno. Ese es justamente el punto: las capas existen en Code y en Slack, y las issues las piden allí donde están los proyectos.

3. Cuánto cuesta y qué oculta el token

3.1 Los tokens no son la barrera

Más capas podrían significar más contexto con cada mensaje, y la IA se cobra por token. Esa explicación solo es cierta a medias. En los planes Enterprise basados en uso, el consumo se factura a tarifas de API, así que más contexto significa más ingresos, no menos. En Team, las licencias son una tarifa plana salvo que se active el uso adicional, y los tokens extra se traducen en miembros que alcanzan antes su límite semanal. Y Claude Code, que se factura con esos mismos tokens, ya distribuye una cascada de cuatro niveles. Si los tokens fueran la barrera, no existiría. Según lo medido en la sección 3.2, el prompt del sistema y las herramientas propias de Claude Code sumaban unos 30.200 tokens antes de cualquier instrucción nuestra; las instrucciones completas de un proyecto añadían entre un 3,5 % y un 5,2 % a esa cifra.

3.2 Un ejemplo práctico

Etiquetas en cada imagen: REAL = medido, o verificado con la documentación de Anthropic, entre el 29 de septiembre y el 1 de octubre de 2026; EST = simulado; IND = ilustrativo.

Primero, las mediciones. Ejecuté la misma pregunta en Claude Code (claude -p, Claude Sonnet 5.5) contra un proyecto de demostración, cinco veces por condición, y tomé los tokens de entrada que el propio Claude Code reportó. Lo corrí en Claude Code 2.1.286 el 30 de septiembre y de nuevo en 2.1.287 el 1 de octubre; los recuentos de instrucciones fueron idénticos. Al restar una ejecución sin ninguna instrucción de proyecto queda lo que cuesta cada disposición:

Dos cosas que la simulación de abajo no podía mostrar. La cascada cuesta 224 tokens más que el archivo compilado para las mismas reglas: cada archivo extra lleva su sobrecarga, aquí el marcador y encabezado propios de la app en el archivo de cada nivel más el encuadre que hace Claude Code alrededor de cada archivo que carga. Más niveles significa más sobrecarga. Y Claude Code cargó en realidad entre un 21 % y un 26 % más de lo que estimó el tokenizador público, incluso multiplicando por 1,30; parte de esa diferencia es esa misma sobrecarga por archivo. Los ratios sobreviven a esto; las cifras absolutas en dólares no, así que lee los dólares de la simulación como valores a la baja.

Después, la simulación a escala de empresa. Simulé un mes de tokens de instrucción para una empresa ilustrativa: 40 personas en tres líneas de trabajo, 250 proyectos activos, seis tipos de informe por línea, 35 mensajes por persona y día laborable en sesiones de cinco, 29.400 mensajes en total. Los tamaños en tokens se contaron sobre textos de instrucción de muestra con el tokenizador público heredado de Anthropic (al que el propio Anthropic llama “una aproximación muy burda” para Claude 3 y posteriores) y se escalaron por 1,30 para el tokenizador de Claude 4.7+. El bloque de organización se extrapoló de una muestra de 597 caracteres al límite de 3.000 caracteres, y el manual de línea es tres veces una muestra de 953 caracteres. Los precios son los de lista de Claude Sonnet 5.5 (entrada $2, escritura en caché de 5 minutos $2,50, lectura de caché $0,20 por millón de tokens). La caché de prompts dura cinco minutos y se refresca con cada acierto.

• Plano (la solución temporal de hoy): el bloque de organización, luego la copia propia de cada proyecto del manual de línea, las seis plantillas de informe y los detalles específicos del proyecto.

• Árbol: organización, línea, solo la plantilla de informe en uso y luego los detalles del proyecto, compilados poniendo primero lo más compartido.

Tamaños detrás de la tabla: bloque de organización 830 tokens (3.000 caracteres), manual de línea 729, una plantilla de informe 147, detalles del proyecto 98 (redondeados; los totales se calcularon antes de redondear). La simulación ignora el prompt del sistema propio de Claude, que va antes del bloque de organización.

Dos salvedades honestas. Primera: el árbol no ahorra tokens por sí solo. El −29 % viene de las tareas tipadas: solo se carga la plantilla del informe que se está redactando, no las seis. El −62 % viene sobre todo de compilar primero las capas más compartidas, de modo que cientos de proyectos comparten un prefijo idéntico byte a byte: solo con el orden, manteniendo cargadas las seis plantillas, el coste con caché compartida baja de $36 a $18 (−51 %), y las tareas tipadas aportan el resto. Ese segundo ahorro solo existe si la caché se comparte entre usuarios. En la API de Claude, las cachés están aisladas entre organizaciones y, dentro de una, por espacio de trabajo, así que los prefijos idénticos se reutilizan entre peticiones dentro de un mismo espacio de trabajo; para claude.ai esto no está documentado. No ocurre en el Claude Code que se distribuye hoy: ahí “la caché está efectivamente acotada a una máquina y un directorio”, así que dos personas en dos carpetas de proyecto distintas no aprovechan la caché de la otra. Lee la última columna como lo que podría lograr una capa nativa en el chat, no como algo disponible hoy. Una objeción justa: las Skills ya se cargan bajo demanda, así que un espacio de trabajo plano que pase sus plantillas a Skills consigue hoy parte de ese −29 %. Lo que les falta a las Skills en el chat y en Cowork es ámbito y herencia: una skill no puede pertenecer a una línea y fluir hacia abajo hasta los proyectos de esa línea. (En Claude Code, una skill en un subdirectorio sí se carga para las sesiones iniciadas en él o por debajo). Segunda: estos son solo tokens de instrucción y, a esta escala, van de $14 a $149 al mes dependiendo del uso de caché. El historial de conversación y la salida dominan las facturas reales. El argumento fuerte a favor del árbol es la corrección y, en Team, la capacidad. No es la factura.

La medición anterior reproduce el efecto de las tareas tipadas sobre un árbol real, en Claude Code, en lugar de usar tamaños supuestos: −20 % como cascada y −34 % compilado, frente al −29 % de la simulación. Una línea con un único tipo de tarea no ahorraría nada con las tareas tipadas.

3.3 La misma respuesta, con un Claude real

Le hice la misma pregunta a Claude Code cuarenta veces: diez respuestas independientes bajo cada una de cuatro condiciones, en dos lotes de cinco separados por un día. La pregunta era si un ensayo de densidad de campo sobre una subrasante pasaba, con 112,3 pcf frente a una densidad seca máxima de 115,8 pcf y un 98 % exigido. Las instrucciones eran o bien las seis reglas de la empresa o bien un prompt de una línea de “asistente útil”, y el idioma era inglés o español. Las cuarenta respuestas llegaron al mismo veredicto: 97,0 %, no pasa.

Claude Code reporta dos cifras de salida: los tokens facturados y cuántos de ellos fueron razonamiento que el lector nunca ve.

Cuatro hallazgos:

• Las reglas de la empresa hicieron que las respuestas fueran 1,4 veces más largas en pantalla y entre 1,8 y 1,9 veces más largas en la factura. Lo visible extra eran las secciones de banderas, estándares y limitaciones que pedían las reglas. En un sistema de calidad, esa es la parte valiosa.

• Con las reglas de la empresa, más de un tercio de la salida facturada era invisible. El 37 % de los tokens de salida facturados fueron razonamiento, frente al 16 % con el prompt simple. En inglés, el lector ve 447 tokens y paga por 711.

• El español costó 1,2 veces los tokens visibles del inglés para respuestas cuya longitud en palabras difería menos de un 4 %. Medido de la misma forma, las reglas de la empresa consumieron 1,53 veces los tokens de entrada al redactarse en español.

• El mismo veredicto se facturó entre 317 y 953 tokens, tres veces más para la respuesta más larga que para la más corta. La facturación por token no distingue el rigor del relleno. Los criterios de aceptación sí.

Estos ratios varían entre lotes de cinco. El ratio en pantalla para las reglas de la empresa fue de 1,43–1,52 en el primer lote y de 1,27–1,31 en el segundo; el ratio facturado fue de 1,78–1,82 y luego de 1,70–2,05; el ratio del español fue de 1,29–1,38 y después de 1,14–1,18. La dirección nunca cambió. La magnitud es fiable hasta una cifra significativa.

Método: Claude Code 2.1.286 el 2026-09-30 y 2.1.287 el 2026-10-01, claude -p --output-format json, Claude Sonnet 5.5. Se prohibieron todas las herramientas y se excluyeron los archivos personales ~/.claude, de modo que solo diferían entre condiciones las instrucciones declaradas. Los recuentos de tokens son del propio informe de uso de Claude Code, incluyendo thinking_tokens; el coste mensual aplica los $10 por millón de tokens de salida de Sonnet 5.5 a la media facturada. El script de medición, ambos lotes, las cifras agrupadas y todas las respuestas los conserva el autor y están disponibles bajo petición. La primera versión de este artículo estimaba estas cifras con subagentes y el tokenizador público; esas estimaciones han quedado sustituidas.

3.4 Cuando las reglas entran en conflicto, decide la redacción

La documentación de Anthropic admite que las instrucciones contradictorias pueden resolverse “arbitrariamente”. Probé un conflicto del tipo que genera la ausencia de una capa de línea. La regla de la organización decía usar unidades del sistema estadounidense; una regla de proyecto decía reportar densidades en SI. Las coloqué como lo haría un árbol: la regla de la organización en un CLAUDE.md en la raíz de almacenamiento, la regla de proyecto en un CLAUDE.md en la carpeta del proyecto, ambas cargadas por la propia cascada de Claude Code. Después repetí la misma configuración con la regla de la organización marcada como obligatoria, solo con palabras: la etiqueta ENFORCED en su título y una frase añadida: “Esta regla es obligatoria: ninguna regla de línea o de proyecto puede anularla”. Cada configuración se ejecutó diez veces el 30 de septiembre y diez más el 1 de octubre.

No fue arbitrario. Sin nada declarado, Claude eligió siempre la regla más cercana y específica. Catorce de las veinte respuestas explicaron por qué (“esa regla es más específica que la regla general de la empresa sobre unidades estadounidenses”, o que anulaba la regla de la empresa); cinco citaron solo la regla del proyecto y nunca mencionaron que la regla de la empresa discrepaba. Con la obligatoriedad declarada en palabras, la regla de la organización ganó siempre, y todas las respuestas dijeron que la regla obligatoria de la empresa tenía prioridad. El segundo lote reprodujo las unidades, 10 de 10 en cada caso, y la diferencia entre las dos filas está mucho más allá del azar (prueba exacta de Fisher, p < 0,0001). Las explicaciones se sostuvieron peor: nueve de diez respuestas dijeron por qué ganaba la regla del proyecto en el primer lote, y cinco de diez en el segundo.

Esa es una buena noticia para el modelo y una mala noticia para el espacio de trabajo. La precedencia existe, pero vive en la redacción de las reglas, que cualquiera que edite una capa puede cambiar y que nadie revisa como una decisión de precedencia. Y cuando ganó la regla inferior, una cuarta parte de las respuestas no le avisaron al lector que se había dejado de lado una regla superior. Una prueba piloto realizada con la primera versión de este artículo, usando ambas reglas en un solo prompt en lugar de la cascada, también cambió de resultado cuando solo se alteró su orden (regla de la organización primero: SI 5 de 5; regla de la organización al final: SI 2 de 5, y 3 de 5 dieron ambas unidades o preguntaron cuál aplicaba).

A ningún modelo se le debería pedir que arbitre un conflicto que la organización podría haber detectado al redactar la regla. Claude Code tiene dos respuestas parciales. /doctor prompt-audit le pide a Claude que busque archivos de instrucciones que se contradigan entre sí, cuando lo ejecuta una persona. Y desde el 1 de octubre, un mod puede imponer un orden en el código: los mods de la organización se ejecutan antes que los de la persona y, donde carga la protección integrada, las reglas de denegación superan al mod de la persona. Ninguno cubre el texto de las instrucciones. Los archivos de instrucciones siguen concatenándose, y la documentación describe el resultado de tres maneras: Claude «puede elegir uno arbitrariamente»; cuando una regla de usuario y una de proyecto entran en conflicto, «Claude puede seguir cualquiera de las dos»; y «cuando las instrucciones entran en conflicto, Claude usa su criterio para reconciliarlas». El resultado de veinte sobre veinte es cómo se vio ese criterio aquí. Claude Tag declara un orden para sus tres ámbitos y llama al resultado «una guía, no una barrera obligatoria». La comprobación de la implementación de referencia rechaza exactamente este cambio, «R-22 establece units.density=SI; R-01 (org:firm) impone US», antes de que nada llegue a Claude, y enforced (impuesto) es un campo de la regla, no una frase dentro de ella.

La densidad de instrucciones empeora las cosas. En el benchmark IFScale (2025), la precisión de Claude Sonnet 4 cayó del 100 % con 10 instrucciones simultáneas al 42,9 % con 500.

3.5 ¿Sería más justo usar el cómputo o la energía como unidad?

El token es un indicador razonable del cómputo dentro de un mismo modelo: más tokens realmente significan más trabajo para el hardware. Esa es también la razón por la que un precio basado en cómputo o energía no solucionaría la penalización por idioma. El español cuesta más porque el tokenizador lo comprime menos, y esos tokens extra son cómputo real. La solución a eso es un mejor tokenizador o una medición normalizada por contenido.

Una unidad de cómputo normalizada seguiría ayudando de tres maneras. Permite comparar distintos modelos y proveedores. Es física y auditable, por ejemplo, para los informes de sostenibilidad. Y si el coeficiente se fija respecto a un hardware de referencia, el proveedor conserva sus propias ganancias de eficiencia, lo cual es el incentivo correcto. Hay precedentes: los proveedores de nube alguna vez vendieron unidades normalizadas, como la EC2 Compute Unit.

Tiene problemas reales. El cliente no puede verificarlo sin un estándar y un auditor. La energía real depende del hardware, la eficiencia del centro de datos, el procesamiento por lotes y la red eléctrica. Además, Anthropic no publica la energía por solicitud; solo encontré estimaciones de terceros. Y lo más importante: el cómputo sigue siendo un insumo. No dice si la respuesta fue correcta.

Mi conclusión son tres capas separadas:

1. Facturar en tokens o en una unidad de cómputo normalizada.

1. Divulgar la energía por tarea y por nodo.

1. Gestionar según el costo por resultado verificado.

Para Team, el paso mínimo es publicar el límite semanal en una unidad definida. La cuota por sesión se indica como «1,25 veces la cuota de uso por sesión del plan Pro»; el límite semanal no tiene ninguna cifra publicada. Ninguno de los dos permite hacer un presupuesto.

Como dice FinOps Foundation: «el token es la unidad de facturación, no la unidad de valor». Una jerarquía es lo que hace que el valor se pueda definir, porque es donde pueden vivir los criterios de aceptación.

3.6 Razones más probables por las que no se ha construido

1. Precedencia implícita. La propia documentación de Anthropic admite que las instrucciones directamente contradictorias pueden producir comportamientos variables, y la sección 3.4 muestra que la precedencia sigue lo que diga la redacción de las reglas. Apilar capas multiplica los conflictos, y el seguimiento de instrucciones se degrada con la densidad: en el benchmark IFScale (2025), incluso los mejores modelos evaluados alcanzaron solo un 68 % de precisión con 500 instrucciones de palabras clave simultáneas (el benchmark citado en la sección 3.4).

1. Herencia de permisos. Si el conocimiento se hereda hacia abajo en un árbol, el acceso también tiene que heredarse. Eso significa reconstruir el modelo de permisos debajo de cada capa.

1. Preferencia por la memoria y la recuperación frente a las capas estáticas.

1. Simplicidad orientada al consumidor. Las herramientas de código heredan un árbol gratis del sistema de archivos. Los productos de chat tienen que inventar uno.

Anthropic no ha explicado públicamente por qué el chat de Claude y Cowork carecen de jerarquía. Todo lo que hay en esta sección es una inferencia a partir de lo que se ha lanzado.

4. El modelo de referencia

El diseño toma prestado de sistemas que ya resolvieron este problema: jerarquías de recursos en la nube (AWS Organizations, Google Cloud Org Policy, grupos de administración de Azure), directivas de directorio (Directiva de grupo de Active Directory) y la propia cascada CLAUDE.md de Claude Code. Las relaciones entre nodos usan cinco palabras: contiene, hereda, usa, sellado y compartido.

4.1 Monta el árbol que la organización ya tiene

No obligues a la gente a reconstruir su organización dentro del espacio de trabajo de IA. El servidor de archivos o el sistema documental ya es la fuente de verdad. Toma una ruta:

El número de trabajo 26GT301 ya codifica el árbol: año, línea de trabajo, secuencia. El espacio de trabajo debería montar esta estructura, no copiarla.

4.2 Nodos con reglas, nodos de agrupación, proyectos y tareas

• Nodos con reglas: organización, línea de trabajo, proyecto, tarea. Cada uno lleva las mismas tres cosas: contexto (instrucciones y conocimiento), política (qué herramientas, datos y conectores están permitidos) e identidades (las cuentas de conector vinculadas a él).

• Nodos de agrupación: serie, año, región. No llevan reglas. Existen para la navegación, la retención y el ciclo de vida. Separarlos mantiene el árbol de reglas poco profundo, de tres a cuatro niveles, tal como recomienda la propia guía de Microsoft para grupos de administración («no más de tres a cuatro niveles»).

• El proyecto es un contenedor con clave. Se crea automáticamente: cuando aparece una carpeta que coincide con el patrón de clave de la línea (por ejemplo, {YY}GT{NNN}_{Nombre} bajo la raíz de la línea), se crea un nodo de proyecto, hereda de su línea y obtiene acceso de conector limitado solo a esa carpeta. Contiene únicamente lo que difiere de su línea: miembros, cliente, especificaciones. Pasa de abierto a cerrado y luego a archivado (Diagrama 2).

• La tarea tiene tipo. Su tipo proviene del catálogo de la línea (un informe de densidad, un registro de perforación). El tipo lleva una plantilla y criterios de aceptación. El resultado se archiva de vuelta en la carpeta del proyecto siguiendo la convención de nombres de la empresa, y un revisor lo acepta. Las habilidades (skills) son lo más parecido que tiene Claude hoy a los tipos de tarea. En Enterprise se pueden compartir con un grupo, pero eso es distribución, no herencia: nada fluye hacia abajo por una rama.

La recursividad es intencional. El Modelo de Sistema Viable de Stafford Beer lo dice directamente: «En una estructura organizativa recursiva, cualquier sistema viable contiene, y está contenido en, un sistema viable».

4.3 Un padre principal, más superposiciones

Christopher Alexander argumentó en 1965 que «una ciudad no es un árbol». Las estructuras reales se superponen. Un cliente, la especificación de una agencia o un tipo de tarea pueden abarcar varias líneas de trabajo. Por eso, cada nodo tiene un padre principal, y los conjuntos de reglas transversales se adjuntan como superposiciones (usa). Los conflictos se resuelven siempre de la misma manera: gana la denegación; de lo contrario, gana el nodo más cercano.

4.4 Dos canales, dos semánticas

Este es el núcleo del diseño, y es donde fallan la mayoría de las jerarquías.

• El contexto se concatena. Las instrucciones y el conocimiento se fusionan desde la raíz hacia abajo, como hace CLAUDE.md.

• La política es de denegación por defecto. Una herramienta o conector solo se permite si existe una autorización en toda la ruta desde la raíz, y una denegación explícita en cualquier punto superior gana, como ocurre con las Service Control Policies de AWS. Un padre puede marcar una regla como impuesta (enforced), y ningún hijo puede bloquearla, igual que en las Directivas de grupo.

Mezclar ambas cosas es el error clásico. El contexto consultivo debe fusionarse. La imposición, no.

4.5 Compila antes de que el modelo lo lea

Hoy, las instrucciones contradictorias las resuelve el modelo al momento de responder. La solución es un compilador de instrucciones efectivas que se ejecute antes de que el modelo vea algo:

1. Fusiona el contexto desde la raíz hasta la hoja.

1. Aplica la política: la denegación gana, y una autorización debe mantenerse en toda la ruta.

1. Respeta las reglas impuestas por los padres.

1. Sella cada regla con un ID y su capa.

1. Ordena el bloque según qué tan ampliamente se comparte cada parte y aplica un presupuesto de tokens por capa.

Los conflictos nunca llegan a este paso: se rechazan antes, cuando se escribe una regla, y la aprobación viene de alguien distinto al autor (Diagrama 3, carril inferior).

Como los conflictos se resuelven en tiempo de compilación, el resultado se puede ordenar según qué tan ampliamente se comparte cada parte, no estrictamente por profundidad: organización, línea, plantilla de tipo de tarea y luego detalles del proyecto. Ese orden maximiza los aciertos de caché (sección 3.2). Se corresponde con los cuatro puntos de interrupción de caché de Anthropic, con un presupuesto de tokens por capa, aunque en la práctica puede necesitarse un punto de interrupción para la conversación en sí.

4.6 Identidades vinculadas a ramas, no a personas

Una identidad de conector (cuenta, tenant, ámbito) se adjunta a un nodo, no a una persona. Claude Tag ya funciona así para los canales de Slack: un administrador vincula una cuenta de servicio a un ámbito, y gana la credencial del ámbito más estrecho. El modelo que presentamos aquí pide lo mismo un nivel más abajo, en una línea de trabajo y sus proyectos. Una persona que trabaja en dos organizaciones tiene dos árboles sellados; cambia de árbol, no de cuentas. Nada cruza entre ellos a menos que los propietarios de ambos lo compartan explícitamente. La primitiva técnica ya existe: la especificación de autorización MCP usa tokens OAuth vinculados a audiencia (indicadores de recurso RFC 8707, metadatos de recurso protegido RFC 9728) y exige que los servidores «NO DEBEN aceptar ni transitar ningún otro token» (versión de la especificación 2026-07-28).

4.7 Los permisos siguen el árbol

Entidades principales: personas, grupos, cuentas de servicio, invitados externos (por ejemplo, un cliente) y el propio agente.

El agente nunca supera a la persona ni al nodo. Claude actúa con los permisos del usuario que lo invoca, cruzados con la política del nodo. No puede cambiar reglas ni permisos; solo puede proponer cambios. (Hoy, Claude puede actualizar por su cuenta las instrucciones de carpetas de Cowork. En este modelo, eso se convierte en una propuesta que alguien aprueba).

Evaluación. Las concesiones fluyen solo hacia abajo, nunca hacia arriba ni lateralmente. El permiso efectivo en un nodo es lo que conceden los roles en su ruta, dentro de lo que permite la política en toda la ruta, menos cualquier denegación superior. Una superposición concede acceso solo a su propio contenido: leer una especificación no abre los proyectos que la usan.

Ciclo de vida.

• Abierto: los roles se aplican tal como se concedieron.

• Cerrado: no hay tareas nuevas, pero las revisiones pendientes pueden terminarse.

• Archivado: solo lectura para todos; únicamente el propietario puede restaurarlo, y la restauración queda registrada.

• Árbol sellado: nada cruza sin una acción explícita de compartir.

Excepciones y delegación. Las excepciones tienen un plazo definido y una justificación, y alguien distinto al solicitante las aprueba. Caducan por sí solas y se contabilizan, porque cada excepción es una isla de mantenimiento permanente; los límites de herencia rota de SharePoint son el cuento de advertencia. La delegación nunca puede conceder más de lo que tiene quien delega. Existe un acceso de emergencia (break-glass) para el propietario, siempre se registra y se revisa después.

En Team, esto funciona sin grupos: la concesión vive en el nodo, así que una organización con cuatro roles igual obtiene permisos por rama.

4.8 Cómo interactúan las capas

Un árbol solo vale la pena construirse si los cambios viajan a través de él. Tres interacciones hacen la mayor parte del trabajo (Diagrama 5):

• Empujar hacia abajo. Un líder de línea publica una nueva versión de una regla. Cada proyecto de la línea la lee en su próxima compilación. Una excepción aprobada conserva la versión antigua hasta que caduca, y los artefactos ya archivados mantienen la versión con la que se crearon.

• Tirar hacia arriba. Un miembro mejora una plantilla dentro de un proyecto y la propone. El líder de la línea, no quien la propuso, la aprueba, y los proyectos hermanos la heredan. Hoy, esa mejora se queda en el proyecto donde ocurrió.

• Transversal. La especificación de una agencia cambia una sola vez. Los proyectos de tres líneas se recompilan con ella, y las líneas en sí no cambian. Un conflicto con una regla de línea se rechaza cuando se escribe la actualización.

Una sola solicitud muestra todas las capas a la vez (Diagrama 6): el árbol verifica la concesión del miembro y el estado del proyecto, el compilador construye el bloque, Claude lee los datos del campo mediante una identidad limitada a la carpeta de ese proyecto, archiva un artefacto tipado de vuelta en la carpeta y un revisor que no lo escribió lo acepta. Cada paso queda en el registro, y el costo se imputa a la clave del proyecto.

4.9 La estructura de datos

El aprovisionamiento se basa en eventos: una nueva carpeta que coincide con key_pattern bajo el storage_root de una línea crea el nodo del proyecto. El answer_log da procedencia para cada respuesta y costo por nodo.

4.10 Mide resultados, no tokens

Cada tipo de tarea lleva criterios de aceptación: la definición de terminado. Con ellos en su lugar, se vuelve medible una mejor unidad de trabajo de IA:

costo por resultado verificado = (costo de tokens + tiempo de revisión) ÷ entregables aceptados

Como cada respuesta se registra contra un nodo, el costo de IA se puede imputar a una clave de proyecto igual que la mano de obra y los materiales. Partes de esto ya existen: Claude Tag reporta y limita el gasto por canal, y la telemetría de Claude Code se puede etiquetar por departamento, centro de costos o repositorio, a mano. Pero ninguna está vinculada a un proyecto, y ninguna divide entre entregables aceptados. Para una empresa que factura por número de trabajo, la IA se convierte en un costo directo del trabajo en lugar de un gasto general. En ingeniería, pagas por el entregable revisado y sellado, no por la mina del lápiz. El trabajo de IA debería medirse de la misma manera.

4.11 Objeciones respondidas

«Las habilidades y los plugins ya hacen esto». Una habilidad se carga cuando Claude la considera relevante, lo cual es relevancia, no una garantía. El aprovisionamiento da una habilidad a todo el mundo; en Enterprise, un plugin que la lleve puede ser obligatorio para un grupo. Eso es lo más parecido a una línea de trabajo en el chat y en Cowork hoy, y se queda corto en tres aspectos: es solo para Enterprise, apunta a personas y no a proyectos, y nada fluye desde una línea hacia sus proyectos. Una regla que siempre debe aplicarse en una línea no puede depender de la detección de relevancia.

«Los mods ya hacen esto». En Claude Code, en parte, desde el 1 de octubre de 2026. Un mod puede reescribir el prompt del sistema, rechazar una llamada a herramienta y dibujar un panel, y los mods de una organización se ejecutan antes que los de una persona. Así que el compilador, la comprobación en tiempo de escritura y la vista de instrucciones efectivas de este artículo podrían construirse hoy como un mod, y la sección 6 lo explica. Quedan tres límites. Los mods no se ejecutan en el chat de Claude, y en Cowork no se aplican los ajustes de la consola de la organización. Su orden tiene dos dueños, organización y persona, sin una línea de trabajo entre ellos; en Enterprise, un plugin obligatorio para un grupo puede llevar un mod a ese grupo, pero se ejecuta como uno de los mods propios de la persona, sin precedencia. Y un mod es código sin entorno aislado: para ejecutarse antes que los mods de las personas, el mod de una organización debe estar en un directorio de cada máquina, y los ajustes enviados desde la consola de administración «no pueden colocar el directorio en una máquina». Una empresa sin gestión de dispositivos puede enviar un mod a todos, pero se ejecutará entre los mods propios de las personas, no antes que ellos. Una empresa no debería tener que escribir TypeScript para decir que un departamento reporta en unidades distintas.

«La memoria aprenderá las reglas». La memoria la escribe principalmente Claude, para una persona o un proyecto, y un propietario no puede leer ni editar los recuerdos de un miembro. Un auditor necesita reglas escritas por una persona, versionadas, aprobadas y trazables hasta cada respuesta. Anthropic ya ha construido eso tres veces: para permisos, con «Ver rol efectivo» y su etiqueta «Concedido por»; para habilidades y plugins, con historial de versiones y un paso de revisión donde «no puedes aprobar lo tuyo»; y para el acceso de Claude Tag, con sus etiquetas «Heredado de». Las instrucciones en un proyecto no tienen ninguna de las tres.

«Claude Tag ya hace esto». Para los canales de Slack, en gran medida sí, y la sección 1 lo menciona. Aún faltan tres cosas. Un canal no es un proyecto: no tiene carpeta, ni clave, ni ciclo de vida, y «un canal no puede apuntarse a un Proyecto». El árbol tiene tres niveles fijos, así que una empresa con líneas de trabajo y cientos de trabajos tiene que aplanar dos de sus niveles en nombres de canales. Y la documentación no describe ninguna comprobación de conflictos cuando se escribe una instrucción; los ámbitos se concatenan y se deja que el modelo los reconcilie. En todo caso, Claude Tag es la evidencia más sólida a favor del diseño de este artículo: la misma empresa eligió herencia, credenciales vinculadas a ámbito y una etiqueta de origen cuando construyó para equipos.

«Las jerarquías añaden complejidad». Solo si su profundidad es ilimitada. La propia guía de Microsoft para grupos de administración dice «no más de tres a cuatro niveles». Este modelo fija cuatro niveles con reglas, y las carpetas de agrupación, como serie y año, no llevan ninguna regla.

«La herencia es un riesgo de seguridad». Lo es, si el acceso se hereda sin cuidado. Aplica la respuesta de la nube: debe existir una autorización en cada nivel, una denegación en cualquier punto gana, Claude actúa como el usuario cruzado con el nodo, y las propias ediciones de reglas de Claude se convierten en propuestas.

«Más capas cuestan más tokens». La sección 3.2 midió lo contrario en Claude Code: un 20 % menos de tokens de instrucciones como cascada y un 34 % menos compiladas, frente a copias planas. Cada archivo adicional suma un poco de sobrecarga, por lo que compilar supera a la cascada. Las tareas tipadas descartan las plantillas que no se usan, y los prefijos compilados son idénticos byte a byte entre proyectos, así que el almacenamiento en caché de prompts puede reutilizarlos. En la API de Claude, las cachés están aisladas por espacio de trabajo, así que un espacio de trabajo por organización se mapea a la raíz del árbol. Claude Code no tiene esto hoy: su caché se limita a una máquina y un directorio.

«Los equipos pueden simplemente mantener sus propios proyectos». Ese es el parche actual, y el prototipo de la sección 5 midió lo que produce: dos de seis copias pegadas estaban desactualizadas en una pequeña demostración.

5. Funciona hoy: una implementación de referencia

Para demostrar que el modelo se puede construir, y no solo defender en teoría, creé Worktree, una pequeña aplicación de escritorio (Node y Electron, 24 pruebas superadas en Windows y Linux) organizada como Claude Desktop. El video de arriba es una ejecución real, recortada solo donde Claude estaba trabajando. Es una aplicación independiente que controla Claude Code desde fuera, no un mod. No llama a un modelo propio. Cada chat ejecuta el Claude Code ya instalado en la computadora (claude -p), con la sesión que tenga Claude Code: una suscripción de Claude o una clave de API. Lo probé con una empresa inventada con tres líneas de trabajo y seis proyectos. Cuando alguien envía un mensaje:

• Permitir. La persona que actúa necesita una concesión en el proyecto o por encima de él, y el proyecto debe estar abierto. Un administrador sin concesión en la línea fue detenido antes de que empezara Claude.

• Comprobar. La comprobación en tiempo de escritura se ejecuta primero. La regla SI de la sección 3.4 se rechaza por entrar en conflicto con una regla impuesta de la empresa, así que nunca llega a un CLAUDE.md.

• Montar. El árbol se escribe en las carpetas reales del proyecto como un CLAUDE.md por nivel (organización en la raíz de almacenamiento, luego línea, luego proyecto), y la propia cascada de Claude Code los carga. Un modo compilado escribe un solo archivo por proyecto en su lugar. Los archivos sin el marcador de la aplicación nunca se sobrescriben.

• Ejecutar. La plantilla de la tarea entra en --append-system-prompt-file. Lo que Claude puede hacer lo impone Claude Code, no CLAUDE.md: --allowedTools es el rol de la persona cruzado con la política de cada nivel, las escrituras se limitan a la carpeta del proyecto y --permission-mode dontAsk rechaza todo lo demás. En ejecuciones reales, se rechazó una búsqueda web porque la política de la línea no permite web, y se denegó y registró una escritura fuera de la carpeta del proyecto.

• Registrar y revisar. Cada respuesta se registra con la persona, el nodo, cada etiqueta de regla, las reglas que citó Claude y los tokens de entrada, caché y salida que reportó Claude Code. Un revisor que no escribió la respuesta la acepta o la devuelve. Una ejecución real de informe de densidad en la demostración tomó unos 30 segundos; en tres ejecuciones, Claude Code reportó entre $0,08 y $0,22 por respuesta a precios de lista. Claude citó las reglas que aplicó, marcó los resultados cercanos al límite de aceptación y dejó en blanco los campos del ingeniero.

• Desviación. Cada CLAUDE.md montado se compara con el árbol y se marcan las ediciones manuales. Un prototipo anterior de línea de comandos hizo la misma comparación en copias pegadas en proyectos planos y encontró dos de seis desactualizadas: una seguía en R-07 v3, y otra donde se había borrado una regla a mano.

Tres hallazgos al construirlo, todos relevantes para cualquiera que apile instrucciones sobre Claude Code:

1. Tus instrucciones personales se filtran a las ejecuciones de la organización. Por defecto, cada ejecución también cargaba mi ~/.claude/CLAUDE.md personal, reglas, agentes y servidores MCP. La aplicación ahora los excluye con el ajuste claudeMdExcludes, además de --strict-mcp-config. En mi máquina, eso redujo el contexto de una ejecución de 29,6k a 21,4k tokens. La alternativa obvia, --setting-sources project,local, hizo lo contrario de lo necesario en Claude Code 2.1.284 en Windows: conservó el archivo personal y descartó los archivos CLAUDE.md de la carpeta superior que llevan la organización y la línea.

1. Los mods de una persona también se filtran. Los mods llegaron el día después de crear la aplicación, así que lo probé. Instalé un mod de un solo gancho en mi propio ámbito de usuario que añade una línea a cada prompt. Llegó a las ejecuciones de la aplicación: se cargaron las tres reglas de la organización, y también mi línea personal, y la respuesta la obedeció. Añadir disableAllHooks a los ajustes de la ejecución lo mantuvo fuera y dejó intactos los tres niveles de CLAUDE.md; la aplicación ahora hace esto. --safe-mode no es un sustituto: eliminó el mod y toda la cascada de CLAUDE.md con él. Según la documentación, disableAllHooks en los ajustes propios de una persona deja funcionando lo que gestiona la organización.

1. CLAUDE.md es contexto, la imposición es configuración. La documentación de Anthropic lo dice: «Las reglas de configuración las impone el cliente independientemente de lo que decida hacer Claude. Las instrucciones de CLAUDE.md moldean el comportamiento de Claude, pero no son una capa de imposición estricta». La aplicación depende de ello. Todo lo que una regla debe garantizar se mapea a permisos de herramientas; todo lo que hay en CLAUDE.md es orientación con una etiqueta.

Funciona con el Claude Code de hoy, y el texto compilado se puede pegar en un chat o en las instrucciones de un proyecto de Cowork en cualquier plan. Una dependencia tiene fecha de caducidad: la aplicación confía en que claude -p cargue los archivos CLAUDE.md, y la documentación de Anthropic dice que --bare, que los omite, «se convertirá en el comportamiento predeterminado para -p en una versión futura». Cuando eso ocurra, la aplicación tendrá que pasar el árbol de otra forma; el modo compilado y --append-system-prompt-file ya pueden hacerlo. Es una especificación funcional para la versión nativa, no un límite de seguridad: «actuar como» es un interruptor de demostración, no un inicio de sesión.

6. Un camino desde lo que ya se ha lanzado

En Claude Code, ahora mismo. Desde el 1 de octubre, el árbol puede distribuirse como un mod: compilar las reglas del nodo en una sección del system prompt, rechazar las llamadas a herramientas que la política del nodo deniegue y mostrar las instrucciones efectivas en un panel. Una organización puede ejecutar ese mod antes que cualquier cosa que instale un usuario. Yo no lo he desarrollado; es el primer punto en la hoja de ruta de la implementación de referencia. Cubriría Claude Code y, posiblemente, las sesiones de Cowork en la máquina del usuario, que funcionan con el mismo motor. No cubriría el chat.

La versión de 30 días, para chat y Cowork. Anthropic ya tiene las piezas. Permitir que un proyecto designe un proyecto padre del que herede sus instrucciones, igual que un canal de Slack hereda de su workspace en Claude Tag. Compilar ambos en orden, con una etiqueta en cada regla, y añadir un panel de «Ver instrucciones efectivas» junto al actual «Ver rol efectivo». Solo con eso, cada área de trabajo tendría un único lugar donde guardar sus reglas.

Después, cada paso resulta útil por sí solo, empezando por lo que beneficia a los planes Team:

1. Nodos por área de trabajo y aprovisionamiento de patrones clave, reutilizando la semántica de CLAUDE.md que ya funciona en código. En el propio Claude Code, el paso de coincidencia actúa como un nivel intermedio para un grupo entre los mods de la organización y los del usuario, además de configuraciones gestionadas por grupo.

1. Tipos de tarea como habilidades acotadas a un área, con criterios de aceptación.

1. Una comprobación de conflictos en tiempo de escritura, para que las contradicciones las rechace el árbol y no tenga que arbitrarlas el modelo.

1. Permisos (grants) en los nodos, que funcionan en Team sin necesidad de grupos y amplían los roles personalizados de Enterprise.

1. Identidades de conector vinculadas a ramas para proyectos, tal como Claude Tag ya asocia una cuenta de servicio a un canal de Slack.

1. Contabilidad por nodo asociada al proyecto, igual que Claude Tag ya informa por canal; un límite semanal publicado en una unidad definida; y divulgación del consumo energético por tarea.

7. Limitaciones

• Cobertura. El 1 de octubre de 2026 se clasificaron por título los índices completos de code.claude.com/docs y claude.com/docs (466 páginas) y se leyeron unas 150, además de los artículos del centro de ayuda citados aquí. Versiones anteriores de este artículo pasaron por alto Claude Tag por completo; esta podría omitir algo más. Se menciona, pero no se analiza, Claude for Government ni Claude Desktop en proveedores externos.

• Las funciones de la plataforma cambian cada mes, y una cambió mientras redactaba esto. Cada afirmación sobre productos está fechada entre el 29 de septiembre y el 1 de octubre de 2026, y conviene volver a verificarla antes de darla por buena. Los mods tienen un día de vida; he leído su documentación y probado un caso, no los he usado en producción.

• Las cifras medidas en las secciones 3.1–3.4 proceden de los propios informes de uso de Claude Code, en dos lotes: Claude Code 2.1.286 el 30/09/2026 y 2.1.287 el 01/10/2026, ambos con Claude Sonnet 5.5. El script, los dos lotes y todas las respuestas están en poder del autor y disponibles bajo petición. Incluyen el propio prompt de Claude Code (unos 30 200 tokens), que claude.ai y Cowork no comparten, y abarcan un único modelo, un proyecto de demostración y una pregunta. Las muestras son pequeñas: diez respuestas por condición para la longitud de respuesta, veinte por condición para la prueba de conflicto. Las proporciones de longitud variaron entre los dos lotes (sección 3.3); dos lotes separados por un día también difieren en la versión de Claude Code, y no puedo aislar ese efecto del azar.

• El tiempo de ejecución, el coste y los tamaños de contexto de la sección 5 provienen del registro de respuestas de la propia aplicación tras tres ejecuciones de demostración y una prueba manual de aislamiento, que constan en los archivos del autor.

• Las respuestas del conflicto fueron codificadas por el autor, sin cegamiento, leyendo cada respuesta (unidades indicadas; si la respuesta señalaba qué regla prevalecía y por qué; si preguntaba). Las cuarenta están disponibles bajo petición para recodificarlas. La prueba usó una única formulación de «aplicado» (enforced); otras formulaciones, modelos y pares de reglas podrían comportarse de forma distinta.

• La prueba de mods de la sección 5 consiste en un mod con un hook, en una sola máquina Linux, con Claude Haiku, sesión iniciada mediante suscripción y sin configuraciones gestionadas. No probé un mod de políticas de organización, el control integrado en un inicio de sesión de Team o Enterprise, ni la aplicación de escritorio.

• El modelo de costes de la sección 3.2 es una simulación de una empresa ilustrativa, no una facturación real medida. Solo cubre tokens de instrucciones; el historial de conversación, la salida y el razonamiento suelen dominar las facturas reales. Sus tamaños de token usan el tokenizer público heredado de Anthropic × 1,30; en la medición, Claude Code cargó entre un 21 % y un 26 % más que esa estimación, por lo que sus cifras en dólares quedan a la baja. Sus porcentajes son proporciones y se mantienen válidos. Los patrones de sesión y el uso compartido de caché son suposiciones.

• No está documentado si el uso del chat en Enterprise recibe precios de caché de API ni si las cachés se comparten entre usuarios en claude.ai. Cowork ejecuta sus sesiones en Claude Code, y los hooks de plugins se cargan allí, pero las páginas de mods no mencionan Cowork y no lo probé; el 1 de octubre, la aplicación de escritorio aún incluía Claude Code 2.1.286, una versión anterior a la activación de los mods. La política gestionada de un dispositivo llega a las sesiones de Cowork en la máquina del usuario salvo que la organización las ejecute en un sandbox de VM completa. Dos páginas se contradicen sobre si los archivos ~/.claude del propio usuario llegan a Cowork, así que este artículo no afirma nada al respecto. Tampoco comprobé si los archivos CLAUDE.md de carpetas superiores se cargan en una sesión de Cowork; si lo hacen, el árbol montado de la implementación de referencia llegaría hoy mismo a Cowork en la máquina del usuario. En Pro y Max esa ventana se estrecha el 6 de octubre de 2026, cuando las nuevas tareas de Cowork pasen a la nube.

• Los motivos son inferencias. Anthropic no ha explicado públicamente por qué el chat de Claude y Cowork son planos.

• El código y los datos brutos no se publican con este artículo. Un lector no puede reproducir las mediciones solo con el texto; el vídeo muestra la aplicación funcionando, no cómo está construida.

• La implementación de referencia opera sobre una empresa ficticia. No está integrada con claude.ai ni con Cowork, y «actuar como» es un interruptor de demostración, no un inicio de sesión. Los permisos los aplican las listas de herramientas de Claude Code, no la aplicación. El aislamiento desactiva los hooks y mods personales del usuario durante la ejecución; los mods integrados en Claude Code siguen funcionando, y los nombres de los agentes personales aún pueden aparecer en el contexto. La aplicación depende de que claude -p cargue CLAUDE.md, algo que Anthropic dice que dejará de ser el comportamiento predeterminado. La fuga de archivos personales y el resultado de --setting-sources se probaron en Windows; las mediciones y la prueba de mods se ejecutaron en Linux.

Fuentes

• Anthropic, Establecer instrucciones de la organización

• Anthropic, Roles y permisos

• Anthropic, ¿Qué es el plan Team? · Planes y precios

• Anthropic, Gestionar roles personalizados en planes Enterprise

• Anthropic, Organiza tus tareas con proyectos en Claude Cowork

• Anthropic, Usar conectores de Google Workspace

• Anthropic, Gestionar grupos y límites de gasto de grupos en planes Enterprise

• Anthropic, ¿Qué son los proyectos? (nueva versión de proyectos, beta)

• Anthropic, Primeros pasos con Claude Cowork (instrucciones globales y de carpeta)

• Anthropic, Cómo Claude recuerda tu proyecto (CLAUDE.md) · Todas las configuraciones (claudeMdExcludes, disableAllHooks)

• Anthropic, Personalizar Claude Code con mods (1 de octubre de 2026) · Descripción general de mods · Gestionar mods para tu organización · Reaccionar a eventos con un mod · Referencia de mods

• Anthropic, Claude Tag: ¿Qué es Claude Tag? · Configurar el acceso por canal · Personalizar Claude Tag · Cómo funciona la identidad del agente · Auditoría · Establecer un límite de gasto

• Anthropic, Proyectos en Claude Code (beta de nuevos proyectos) · Proyectos en Cowork · Cómo usa Claude Code el almacenamiento en caché de prompts · Ejecutar Claude Code mediante programación (--bare) · Ampliar Claude Code · Gestionar la visibilidad y el uso compartido de proyectos · Usar conectores · Autorizar conectores MCP para toda tu organización · Aprovisionar y gestionar habilidades

• Anthropic, Configurar ajustes gestionados por servidor (sin configuración por grupo) · Gestionar plugins para tu organización (disponibilidad de plugins por grupo en Enterprise) · Compatibilidad de funciones de plugins en distintas plataformas (los hooks se ignoran en el chat, se cargan en Cowork) · Implementar ajustes gestionados (Cowork ejecuta sus sesiones en Claude Code)

• Anthropic, Precios (tarifas de Sonnet 5.5, nota sobre el tokenizer) · Almacenamiento en caché de prompts (cachés aisladas por organización y por workspace en la API)

• Anthropic, @anthropic-ai/tokenizer (tokenizer público utilizado para los recuentos)

• Microsoft, Grupos de administración · Diseño de grupos de administración de zonas de aterrizaje

• AWS, Evaluación de SCP · Google Cloud, Evaluación de jerarquías

• Microsoft, Procesamiento de directivas de grupo · Permisos detallados de SharePoint

• FinOps Foundation, Economía de tokens

• Jaroslawicz et al., ¿Cuántas instrucciones pueden seguir los LLM a la vez? (IFScale)

• Firefly, Investigación sobre el estado de IaC en 2026

• MCP, Especificación de autorización, versión 2026-07-28

• GitHub, incidencias de anthropics/claude-code #68262, #14467, #30554, #27567, #30250, #27302, #47741

• Beer, S. (1979), The Heart of Enterprise; Alexander, C. (1965), “A City is Not a Tree,” Architectural Forum; Simon, H. (1962), “The Architecture of Complexity,” Proc. Am. Phil. Soc.106(6)

• Implementación de referencia y datos: la aplicación Worktree, sus pruebas, el script de medición, ambos lotes de resultados y todas las respuestas están en poder del autor y disponibles bajo petición.