La capa faltante: Estructuración de 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 nuevamente contra 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 la cuenta de un conector pertenece a una persona o a toda la organización, nunca a una rama.

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

1. Anthropic ya construyó 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 una persona. Claude Tag, en Slack, hereda instrucciones y credenciales desde la organización hacia el espacio de trabajo y luego al canal. Ninguno llega hasta el proyecto. El mismo modelo sí puede hacerlo: una capa de línea de trabajo, proyectos que nacen de sus carpetas, tareas tipadas, un compilador que rechaza 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 que se contradecían, en niveles separados 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 definió la redacción, que cualquiera que edite cualquier capa puede cambiar, y no la estructura.

1. 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. Una empresa define políticas, una línea de trabajo establece sus estándares, un proyecto los aplica a un encargo y una tarea entrega algo concreto. Todos los sistemas de calidad en los que he trabajado están armados 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 codifica todo lo anterior.

Los proyectos de IA son planos. Uso a Claude como caso de estudio porque es el producto con el que trabajo todos los días y porque ya implementa 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 solo bloque de hasta 3,000 caracteres que aplica para todos. En Enterprise, los administradores pueden acotar permisos por grupo. En Team, los roles aplican a toda la organización. Nada de lo documentado en el chat o en Cowork transmite instrucciones hacia 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 contra la documentación de Anthropic entre el 29 de septiembre y el 1 de octubre de 2026. Claude tiene cuatro interfaces donde corre el trabajo de un equipo, y cada una tiene su propio modelo de instrucciones:

Los permisos dependen del plan:

Anthropic ya construyó 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 rol efectivo”, con una etiqueta de “Otorgado 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 cercano 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 definido (“configuración de grupo, luego configuración de toda la organización, luego valor predeterminado 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; según la documentación, su configuración de plugins “no tiene configuración de grupo”. Y Team es el plan pensado para empresas pequeñas y medianas.

Anthropic ya construyó 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 administrado en cada máquina o como texto desde la consola de administración (la clave claudeMd). La documentación es honesta 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 de forma arbitraria”.

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 de toda la organización), un espacio de trabajo o un solo 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 configurado por encima”.

• Las credenciales pertenecen a la rama. En los canales, Claude actúa con cuentas de servicio que un administrador adjunta a un ámbito, y “se usa la credencial del ámbito más estrecho: el canal le gana al espacio de trabajo, y este le gana 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 “Adjunto 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 verificación de conflictos entre ámbitos. No hay “un 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 luego los mods que instala una 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 otros se ejecutan siquiera”. Donde se carga la protección (una máquina con configuración administrada, 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 administrado y otras instrucciones administradas”, y no 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 predeterminado, no un candado: quien inicia Claude Code con --safe-mode se ejecuta sin los mods instalados, incluidos los de la organización, mientras que los hooks administrados 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 una línea de trabajo. La configuración entregada desde la consola de administración “aplica de manera uniforme 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 diferente en las máquinas de cada grupo, o ejecutar un gateway autoalojado que “entregue configuraciones administradas por grupo de IdP”.

• No llegan al chat y alcanzan 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 a Cowork y yo no lo he probado. Lo que la organización controla ahí es más débil: en una sesión de Cowork, Claude Code “nunca obtiene configuraciones administradas por 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á lanzando. Cowork se está fusionando con 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, comenzando en Claude Code, con el chat, Cowork, Team y Enterprise por seguir; en ella, “un proyecto es una conversación” que Claude divide en hilos paralelos. Sigue siendo un solo 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 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í lo es. 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 y sin hijos, y su ciclo de vida documentado es archivar y eliminar. 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 distintos clientes convive lado a lado.

La ruta de cargas se rompe. En ingeniería estructural, toda carga necesita una ruta continua hasta la cimentación. Si quitas un elemento, nada de lo que está arriba transfiere hacia abajo. Las reglas se comportan igual. 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. Entonces cada proyecto recibe una copia hecha a mano.

Las copias se desfasan. Corriges una regla en un proyecto y los demás conservan la versión vieja. Cada proyecto sigue pasando su propia validación local. La discrepancia 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 esta falla. En la investigación de Firefly de 2026, cerca de un tercio de los encuestados vinculó 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. Muchas personas trabajan 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 forma, 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 adjunta 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 sola cuenta de Google conectada, y la forma documentada de cambiarla es desconectar y volver a conectar; tres issues abiertos (más abajo) piden 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 les muestra a los administradores un “Ver rol efectivo” para permisos, y /context en Claude Code lista qué archivos de memoria se cargaron. Un mod de Claude Code ahora 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 sugiere “pedirle a Claude que repita sus instrucciones de administrador”. Ninguna interfaz muestra, para una respuesta dada, 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 está pidiendo partes de esto. Issues abiertos en el tracker público de Anthropic (github.com/anthropics/claude-code), verificados el 2026-10-01:

Un séptimo, #47741, pedía un CLAUDE.md administrado por la organización y se cerró porque Claude Code ya tiene uno. Ese es el punto: las capas existen en Code y en Slack, y los issues las piden 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 fijas a menos que se active el uso adicional, y los tokens extra aparecen como miembros que alcanzan su límite semanal antes. Y Claude Code, que se factura con los mismos tokens, ya incluye 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 eso.

3.2 Un ejemplo práctico

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

Primero, lo medido. 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 conteos de instrucciones fueron idénticos. Al restar una ejecución sin ninguna instrucción de proyecto queda lo que cuesta cada esquema:

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 trae overhead, aquí la marca y el 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 overhead. Y Claude Code en realidad cargó entre un 21 % y un 26 % más de lo que estimó el tokenizador público, incluso multiplicado por 1.30; parte de esa brecha es el mismo overhead por archivo. Las proporciones sobreviven a esto; las cifras absolutas en dólares no, así que lee los dólares de la simulación como valores bajos.

Luego, simulado a escala de empresa. Simulé un mes de tokens de instrucción para una firma ilustrativa: 40 personas en tres líneas de trabajo, 250 proyectos activos, seis tipos de informe por línea, 35 mensajes por persona por día laboral 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 legacy público de Anthropic (al que la propia 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 del proyecto.

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

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 advertencias 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á escribiendo, no las seis. El −62 % viene principalmente de compilar primero las capas más compartidas, de modo que cientos de proyectos comparten un prefijo idéntico byte a byte: solo el orden, manteniendo cargadas las seis plantillas, baja el costo de caché compartida 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 solicitudes dentro de un espacio de trabajo; para claude.ai esto no está documentado. No ocurre en Claude Code tal como se entrega: ahí “la caché está efectivamente acotada a una máquina y un directorio”, así que dos personas en dos carpetas de proyecto 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 mueva 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 los proyectos de esa línea. (En Claude Code, una skill en un subdirectorio sí se carga para 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 de la caché. El historial de conversación y la salida dominan las facturas reales. El argumento fuerte a favor del árbol es la exactitud 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 tamaños supuestos: −20 % como cascada y −34 % compilado, frente al −29 % de la simulación. Una línea con un solo tipo de tarea no ahorraría nada con las tareas tipadas.

3.3 La misma respuesta, del 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 pasaba una prueba de densidad de campo en subrasante, con 112.3 pcf contra una densidad seca máxima de 115.8 pcf y un 98 % requerido. Las instrucciones eran o las seis reglas de la firma o 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 %, falla.

Claude Code reporta dos números de salida: los tokens facturados y cuántos de esos fueron razonamiento que el lector nunca ve.

Cuatro hallazgos:

• Las reglas de la firma hicieron que las respuestas fueran 1.4 veces más largas en pantalla y 1.8–1.9 veces más largas en la factura. Lo extra visible 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 firma, más de un tercio de la salida facturada fue invisible. El 37 % de los tokens de salida facturados fueron razonamiento, contra un 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 con una longitud en palabras dentro del 4 % de diferencia. Medidas de la misma forma, las reglas de la firma consumieron 1.53 veces los tokens de entrada cuando se escribieron en español.

• El mismo veredicto se facturó desde 317 hasta 953 tokens, tres veces más para la respuesta más larga que para la más corta. El cobro por token no distingue rigor de relleno. Los criterios de aceptación sí.

Estas proporciones varían entre lotes de cinco. La proporción en pantalla para las reglas de la firma fue de 1.43–1.52 en el primer lote y de 1.27–1.31 en el segundo; la proporción facturada fue de 1.78–1.82 y luego de 1.70–2.05; la proporción del español fue de 1.29–1.38 y luego de 1.14–1.18. La dirección nunca cambió. El tamaño es confiable a 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 prohibió toda herramienta y se excluyeron los archivos personales ~/.claude, así que solo diferían las instrucciones declaradas entre condiciones. Los conteos de tokens son del propio reporte de uso de Claude Code, incluyendo thinking_tokens; el costo 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 cada respuesta los conserva el autor y están disponibles bajo solicitud. La primera versión de este artículo estimó estos números con subagentes y el tokenizador público; esas estimaciones quedaron superadas.

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

La documentación de Anthropic admite que las instrucciones contradictorias pueden resolverse “de forma arbitraria”. Probé un conflicto del tipo que produce 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 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. Luego corrí la misma configuración con la regla de organización marcada como obligatoria, solo con palabras: la etiqueta ENFORCED en su título y una oración agregada: “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 tomó 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 unidades estadounidenses de la firma”, o que anulaba la regla de la firma); cinco citaron solo la regla del proyecto y nunca mencionaron que la regla de la firma la contradecía. Con la obligatoriedad declarada en palabras, la regla de la organización ganó siempre, y cada respuesta dijo que la regla obligatoria de la firma tenía precedencia. 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 menos: nueve de diez respuestas dijeron por qué ganó la regla del proyecto en el primer lote, 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 cualquier 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 modificó 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 momento de escribir 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 una persona y, donde carga la protección integrada, las reglas de denegación superan al mod de una 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 regla de proyecto entran en conflicto, “Claude puede seguir cualquiera de las dos”; y “cuando las instrucciones entran en conflicto, Claude usa su criterio para conciliarlas”. El resultado de veinte sobre veinte es cómo se vio ese criterio aquí. Claude Tag declara un orden para sus tres alcances y llama al resultado “una guía, no una barrera de seguridad obligatoria”. La verificació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 algo llegue a Claude, y enforced es un campo en 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 tokenizer lo comprime menos, y esos tokens adicionales son cómputo real. La solución para eso es un mejor tokenizer 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 reportable, por ejemplo, para informes de sustentabilidad. Y si el coeficiente se fija contra un hardware de referencia, el proveedor conserva sus propias ganancias de eficiencia, lo cual es el incentivo correcto. Hay antecedentes: los proveedores de nube alguna vez vendieron unidades normalizadas como la EC2 Compute Unit.

Pero 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. Y Anthropic no publica la energía por solicitud; solo encontré estimaciones de terceros. Lo más importante: el cómputo sigue siendo un insumo. No dice si la respuesta fue correcta.

Mi conclusión es que hacen falta 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 declarada. La asignación por sesión se indica como “1.25x la asignación de uso por sesión del plan Pro”; el límite semanal no tiene ningún número publicado. Ninguno de los dos se puede presupuestar.

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 ahí 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 reconoce 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. Una preferencia por la memoria y la recuperación en lugar de capas estáticas.

1. Simplicidad pensada primero para el 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 dicho 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 ya se lanzó.

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), políticas 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 hagas que la gente reconstruya su organización dentro del espacio de trabajo de IA. El servidor de archivos o el sistema de documentos 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 que portan reglas, nodos de agrupación, proyectos y tareas

• Nodos que portan 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}_{Name} 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. Solo guarda 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 firma, y un revisor lo acepta. Las Skills son lo más parecido que tiene Claude hoy a los tipos de tareas. 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 organizacional 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: la denegación gana; 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 la mayoría de las jerarquías fallan.

• El contexto se concatena. Las instrucciones y el conocimiento se fusionan desde la raíz hacia abajo, tal como lo 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, tal como lo hacen las Service Control Policies de AWS. Un padre puede marcar una regla como impuesta (enforced), y ningún hijo puede bloquearla, como en la Directiva de grupo.

Mezclar ambas cosas es el error clásico. El contexto orientativo 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. Fusionar el contexto desde la raíz hasta la hoja.

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

1. Respetar las reglas impuestas por los padres.

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

1. Ordenar el bloque según qué tan ampliamente se comparte cada parte, y aplicar 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 mapea a 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, alcance) se adjunta a un nodo, no a una persona. Claude Tag ya funciona así para los canales de Slack: un administrador adjunta una cuenta de servicio a un alcance, y gana la credencial del alcance 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 dueños de ambos lo compartan explícitamente. La primitiva técnica ya existe: la especificación de autorización de 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

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 a los lados. El permiso efectivo en un nodo es lo que otorgan 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 otorga acceso solo a su propio contenido: leer una especificación no abre los proyectos que la usan.

Ciclo de vida.

• Abierto: los roles aplican tal como se concedieron.

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

• Archivado: solo lectura para todos; únicamente el dueño 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. Expiran 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 otorgar más de lo que tiene quien delega. El acceso de emergencia (break-glass) del dueño existe, 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 cargan con 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 anterior hasta que expira, 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ó.

• A través. Una especificación de agencia cambia una sola vez. Los proyectos en 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 de 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 carga a la clave del proyecto.

4.9 La estructura de datos

El aprovisionamiento se basa en eventos: una carpeta nueva que coincide con key_pattern bajo el storage_root de una línea crea el nodo del proyecto. El answer_log da trazabilidad 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 eso 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 cargar a la clave de un proyecto de la misma manera que la mano de obra y los materiales. Algunas piezas 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, de forma manual. Ninguna está vinculada a un proyecto, y ninguna divide por entregables aceptados. Para una firma que factura por número de trabajo, la IA se convierte en un costo directo de 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 Skills y los plugins ya hacen esto”. Una skill carga cuando Claude la considera relevante, lo cual es relevancia, no una garantía. El aprovisionamiento le da una skill a todos; en Enterprise, se puede exigir un plugin que la contenga 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 de tres maneras: es solo para Enterprise, apunta a personas y no a proyectos, y nada fluye de una línea hacia sus proyectos. Una regla que siempre debe aplicar 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 verificació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 menciona. Quedan tres límites. Los mods no se ejecutan en el chat de Claude, y en Cowork no aplican las configuraciones de consola de la organización. Su orden tiene dos dueños, la organización y la persona, sin una línea de trabajo entre ellos; en Enterprise, un plugin exigido para un grupo puede llevarle un mod a ese grupo, pero se ejecuta como uno de los propios mods de la persona, sin precedencia. Y un mod es código sin sandbox: 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 la configuración enviada desde la consola de administración “no puede poner el directorio en una máquina”. Una firma sin gestión de dispositivos puede enviar un mod a todos, pero se ejecuta entre los mods de las personas, no antes que ellos. Una firma 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 dueño 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 construyó eso tres veces: para permisos, con “Ver rol efectivo” y su etiqueta “Concedido por”; para skills 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. Todavía 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 firma 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 verificación de conflictos cuando se escribe una instrucción; los alcances se concatenan y se deja que el modelo los concilie. En todo caso, Claude Tag es la evidencia más fuerte a favor del diseño de este artículo: la misma empresa eligió herencia, credenciales limitadas por alcance y una etiqueta de origen cuando construyó para equipos.

“Las jerarquías agregan 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 que portan 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. La respuesta de la nube aplica: 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: 20 % menos de tokens de instrucción como cascada, 34 % menos compilados, frente a copias planas. Cada archivo extra sí agrega un poco de sobrecarga, así que compilar supera a cascadear. Las tareas tipadas descartan las plantillas que no están en uso, 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é está limitada a una máquina y un directorio.

“Los equipos pueden simplemente mantener sus propios proyectos”. Ese es el parche de hoy, 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 debatir, creé Worktree, una pequeña aplicación de escritorio (Node y Electron, 24 pruebas aprobadas 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 afuera, no un mod. No llama a un modelo propio. Cada chat ejecuta el Claude Code que ya está 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 corrí en una firma 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.

• Verificar. La comprobación en tiempo de escritura se ejecuta primero. La regla SI de la sección 3.4 se rechaza por ser un conflicto con una regla impuesta de la firma, 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 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 una escritura fuera de la carpeta del proyecto se denegó y registró.

• 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ó de $0.08 a $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 las ediciones manuales se marcan. 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 todavía en R-07 v3, y otra donde una regla se había borrado 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 la configuración claudeMdExcludes, además de --strict-mcp-config. En mi máquina, eso bajó 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 al día siguiente de crear la aplicación, así que lo probé. Instalé un mod de un solo hook en mi propio alcance de usuario que agrega 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ó. Agregar disableAllHooks a la configuración de la ejecución lo mantuvo afuera 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 junto con él. Según la documentación, disableAllHooks en la configuración propia 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 sin importar lo que decida hacer Claude. Las instrucciones de CLAUDE.md moldean el comportamiento de Claude, pero no son una capa de imposición rígida”. La aplicación depende de ello. Todo lo que una regla debe garantizar se mapea a permisos de herramientas; todo lo que está 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 vencimiento: 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 valor predeterminado para -p en una versión futura”. Cuando eso ocurra, la aplicación tendrá que pasar el árbol de otra manera; 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 lanzó

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 deniega y mostrar las instrucciones efectivas en un panel. Una organización puede ejecutar ese mod antes que cualquier cosa que instale una persona. No lo he construido; 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 nombre un proyecto padre cuyas instrucciones hereda, igual que un canal de Slack hereda de su workspace en Claude Tag. Compilar ambos en orden, con una etiqueta en cada regla, y agregar un panel de “Ver instrucciones efectivas” junto al actual “Ver rol efectivo”. Solo con eso, cada línea de trabajo tendría un único lugar donde guardar sus reglas.

Después de eso, cada paso es útil por sí solo, empezando por lo que ayuda a los planes Team:

1. Nodos por línea 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 para un grupo entre los mods de la organización y los de la persona, además de configuraciones administradas por grupo.

1. Tipos de tarea como habilidades acotadas a una línea, con criterios de aceptación.

1. Una verificación de conflictos al momento de escribir, para que las contradicciones las rechace el árbol y no las arbitre el modelo.

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

1. Identidades de conectores 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, como Claude Tag ya reporta por canal; un límite semanal publicado en una unidad definida; y divulgación de 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 páginas, junto con los artículos del centro de ayuda citados aquí. Las versiones anteriores de este artículo omitieron por completo a Claude Tag; esta podría pasar algo por alto. 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 escribía esto. Cada afirmación sobre productos aquí está fechada entre el 29 de septiembre y el 1 de octubre de 2026, y deberías volver a verificarla antes de basarte en ella. Los mods tienen un día de vida; leí su documentación y probé un caso, no los usé en producción.

• Las cifras medidas en las secciones 3.1–3.4 provienen de los propios reportes de uso de Claude Code, en dos lotes: Claude Code 2.1.286 el 2026-09-30 y 2.1.287 el 2026-10-01, ambos con Claude Sonnet 5.5. El script, ambos lotes y cada respuesta están en poder del autor y disponibles bajo solicitud. Incluyen el propio prompt de Claude Code (unos 30,200 tokens), que claude.ai y Cowork no comparten, y abarcan un 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 de respuesta variaron entre los dos lotes (sección 3.3); dos lotes separados por un día también difieren por la versión de Claude Code, y no puedo separar eso del azar.

• El tiempo de ejecución, el costo y los tamaños de contexto de la sección 5 provienen del propio registro de respuestas de la app tras tres ejecuciones de demostración y una prueba de aislamiento manual, que son registros del autor.

• Las respuestas del conflicto fueron codificadas por el autor, sin cegamiento, leyendo cada respuesta (unidades reportadas; si la respuesta indicaba qué regla ganó y por qué; si preguntó). Las cuarenta están disponibles bajo solicitud para recodificarlas. La prueba usó una única redacción de “enforced” (aplicado); otras redacciones, modelos y pares de reglas podrían comportarse distinto.

• La prueba de mods en la sección 5 es un mod con un hook, en una sola máquina Linux, con Claude Haiku, sesión iniciada con una suscripción y sin configuraciones administradas. No probé un mod de políticas de una organización, la protección integrada en un inicio de sesión de Team o Enterprise, ni la app de escritorio.

• El modelo de costos en la sección 3.2 es una simulación de una empresa ilustrativa, no una facturación medida. Solo cubre tokens de instrucciones; el historial de conversación, el output y el thinking suelen dominar las facturas reales. Sus tamaños de token usan el tokenizer público legacy de Anthropic × 1.30; en la medición, Claude Code cargó entre un 21 % y un 26 % más que esa estimación, así que sus cifras en dólares quedan bajas. Sus porcentajes son proporciones y se mantienen. Los patrones de sesión y el uso compartido de caché son suposiciones.

• No está documentado si el uso de 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 ahí, pero las páginas de mods no mencionan a Cowork y no lo probé; el 1 de octubre, la app de escritorio todavía incluía Claude Code 2.1.286, una versión anterior a la activación de los mods. La política administrada de un dispositivo llega a las sesiones de Cowork en la máquina del usuario, a menos que la organización las ejecute en un sandbox de VM completa. Dos páginas se contradicen sobre si los archivos ~/.claude propios de una persona llegan a Cowork, por lo que este artículo no afirma nada al respecto. Tampoco probé si los archivos CLAUDE.md en 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 a Cowork en la máquina del usuario. En Pro y Max esa ventana se reduce el 6 de octubre de 2026, cuando las nuevas tareas de Cowork pasen a la nube.

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

• El código y los datos crudos no se publican con este artículo. Un lector no puede reproducir las mediciones solo con el artículo; el video muestra la app funcionando, no cómo está construida.

• La implementación de referencia funciona sobre una empresa inventada. 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 app. El aislamiento desactiva los hooks y mods propios de la persona durante la ejecución; los mods integrados en Claude Code siguen corriendo, y los nombres de los agentes personales aún pueden aparecer en el contexto. La app depende de que claude -p cargue CLAUDE.md, algo que Anthropic dice que dejará de ser el comportamiento predeterminado. La filtración 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, Set organization instructions

• Anthropic, Roles and permissions

• Anthropic, What is the Team plan? · Plans and pricing

• Anthropic, Manage custom roles on Enterprise plans

• Anthropic, Organize your tasks with projects in Claude Cowork

• Anthropic, Use Google Workspace connectors

• Anthropic, Manage groups and group spend limits on Enterprise plans

• Anthropic, What are projects? (nueva versión de proyectos, beta)

• Anthropic, Get started with Claude Cowork(instrucciones globales y de carpeta)

• Anthropic, How Claude remembers your project (CLAUDE.md) · All settings (claudeMdExcludes, disableAllHooks)

• Anthropic, Customize Claude Code with mods (1 de octubre de 2026) · Mods overview · Manage mods for your organization · React to events with a mod · Mods reference

• Anthropic, Claude Tag: What is Claude Tag? · Configure per-channel access · Customize Claude Tag · How agent identity works · Audit · Set a spend limit

• Anthropic, Projects in Claude Code (beta de nuevos proyectos) · Projects in Cowork · How Claude Code uses prompt caching · Run Claude Code programmatically (--bare) · Extend Claude Code · Manage project visibility and sharing · Use connectors · Authorize MCP connectors for your entire organization · Provision and manage skills

• Anthropic, Configure server-managed settings (sin configuración por grupo) · Manage plugins for your organization (disponibilidad de plugins por grupo en Enterprise) · Plugin feature support across platforms (hooks ignorados en el chat, cargados en Cowork) · Deploy managed settings (Cowork ejecuta sus sesiones en Claude Code)

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

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

• Microsoft, Management groups · Landing-zone management group design

• AWS, SCP evaluation · Google Cloud, Hierarchy evaluation

• Microsoft, Group Policy processing · SharePoint fine-grained permissions

• FinOps Foundation, Token economics

• Jaroslawicz et al., How Many Instructions Can LLMs Follow at Once? (IFScale)

• Firefly, 2026 State of IaC research

• MCP, Authorization specification, version 2026-07-28

• GitHub, anthropics/claude-code issues #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 app Worktree, sus pruebas, el script de medición, ambos lotes de resultados y cada respuesta están en poder del autor y disponibles bajo solicitud.