Il Livello Mancante: Strutturare gli Agenti AI per le Gerarchie Organizzative

Un modello di riferimento per come le organizzazioni strutturano il lavoro con l'IA

Jose Martinez · 1 ottobre 2026 · v1.8.1 (misurato in Claude Code; ricontrollato rispetto alla documentazione di Anthropic il 1 ottobre 2026)

In cinque righe.

1. Le organizzazioni sono alberi: azienda, linea di business, progetto, task. I progetti di Claude sono piatti: la chat ha un unico blocco organizzativo da 3.000 caratteri, i progetti nella chat e in Cowork non si annidano né ereditano nulla e, all'interno di un progetto, l'account di un connettore appartiene a una persona o all'intera organizzazione, mai a un ramo.

1. Così ogni progetto riceve una copia artigianale delle regole della propria linea, le copie divergono nel tempo e nessuno riesce a capire quale regola abbia generato una determinata risposta.

1. Anthropic ha già costruito questo albero due volte. Claude Code annida le istruzioni per cartella e, dal 1 ottobre 2026, esegue i mod dell'organizzazione prima di quelli personali. Claude Tag, su Slack, eredita istruzioni e credenziali dall'organizzazione al workspace fino al canale. Nessuno dei due arriva al progetto. Lo stesso modello potrebbe farlo: un livello per la linea di business, progetti che nascono dalle relative cartelle, task tipizzati, un compilatore che scarta i conflitti prima che il modello li veda e permessi per nodo funzionanti su Team.

1. L'ho misurato in Claude Code, due volte. Una regola aziendale e una di progetto in contrasto, su livelli CLAUDE.md separati e nessuna delle due contrassegnata come vincolante: la regola di progetto ha prevalso 20 volte su 20. La stessa regola aziendale indicata come obbligatoria, ma solo a parole: ha vinto 20 volte su 20. La precedenza era dettata dalla formulazione — modificabile da chiunque intervenga su qualsiasi livello — e non dalla struttura.

1. Funziona già oggi. Un'app desktop che ho sviluppato esegue Claude Code all'interno dell'albero. Monta ogni livello come un CLAUDE.md, limita Claude a ciò che la persona può fare su quel nodo, blocca il conflitto nel momento in cui viene scritto e registra ogni risposta con le sue regole, i suoi token e il suo revisore. Dalle misurazioni, l'albero ha caricato il 20-34% di token di istruzione in meno rispetto alle copie piatte.

Le organizzazioni sono alberi. L'azienda definisce le policy, la linea di business stabilisce i propri standard, il progetto li applica a una singola commessa e il task consegna un risultato concreto. Ogni sistema qualità in cui ho lavorato è costruito così, e lo stesso vale per l'albero di cartelle di quasi tutti i file server aziendali: azienda, linea di business, anno e poi una cartella per commessa, nominata con un numero che codifica tutte queste informazioni.

I progetti IA sono piatti. Uso Claude come caso di studio perché è il prodotto con cui lavoro ogni giorno e perché offre già la soluzione in due delle sue interfacce. Nella chat di Claude i progetti non possono essere annidati e le istruzioni aziendali formano un unico blocco di massimo 3.000 caratteri valido per tutti. Su Enterprise, gli amministratori possono definire i permessi per gruppo. Su Team, i ruoli si applicano all'intera organizzazione. Nulla di quanto documentato nella chat o in Cowork fa scendere le istruzioni fino a un reparto o a una linea di business e, da lì, ai relativi progetti. Su Enterprise, competenze e progetti possono essere condivisi con un gruppo, ma si tratta di distribuzione, non di ereditarietà.

È questo il livello mancante: quello tra l'organizzazione e il progetto. Questo articolo spiega cosa manca, perché è importante, quanto costa realmente e propone un modello di riferimento che qualsiasi piattaforma potrebbe implementare, inclusi permessi e struttura dati.

1. Cosa esiste oggi

Verificato sulla documentazione Anthropic tra il 29 settembre e il 1 ottobre 2026. Claude ha quattro interfacce su cui gira il lavoro di un team, ognuna con il proprio modello di istruzioni:

I permessi dipendono dal piano:

Anthropic ha costruito metà dell'albero per i permessi. Su Enterprise, i ruoli personalizzati vengono assegnati ai gruppi; "i ruoli personalizzati controllano anche quali connettori, e quali strumenti su quei connettori, un ruolo può utilizzare"; su tutta la piattaforma, tra i livelli organizzazione, ruolo e utente "vince il livello più restrittivo", mentre i vari ruoli di un membro si sommano; gli amministratori possono "Visualizzare il ruolo effettivo", con un'etichetta "Concesso da"; e i gruppi possono avere limiti di spesa propri. Ma si tratta di gruppi piatti, non di un albero, e nulla di tutto questo tocca le istruzioni. La cosa più vicina sono i plugin: su Enterprise, un owner può rendere un plugin e le relative competenze obbligatori o installati di default per un gruppo, seguendo un ordine dichiarato ("impostazione del gruppo, poi impostazione a livello di org, poi default del marketplace"). Questo si rivolge a un gruppo di persone, non a un progetto, nulla si eredita tra progetti e una competenza continua a caricarsi solo quando Claude la ritiene pertinente. Team prevede ruoli per l'intera organizzazione e condivisioni persona per persona; le impostazioni dei suoi plugin, per usare le parole della documentazione, non hanno "alcuna impostazione di gruppo". E Team è il piano pensato per le piccole e medie imprese.

Anthropic ha costruito l'intero albero due volte, fuori dai progetti.

In Claude Code, per cartella. Claude Code carica i file CLAUDE.md da quattro livelli; "tutti i file individuati vengono concatenati nel contesto anziché sovrascriversi a vicenda", ordinati "dalla radice del file system fino alla directory di lavoro", e i file nelle sottodirectory "si caricano su richiesta". Il blocco di un'organizzazione può arrivare come file gestito su ogni macchina o come testo dalla console di amministrazione (la chiave claudeMd). La documentazione è trasparente sul limite: Claude tratta questi file "come contesto, non come configurazione vincolante" e "se due istruzioni si contraddicono, Claude potrebbe sceglierne una in modo arbitrario".

In Claude Tag, per canale Slack. Claude Tag porta Claude nello Slack di un team, in beta pubblica su Team ed Enterprise. Le sue impostazioni si agganciano a uno scope e "uno scope è il punto in cui si applica un bundle: accesso Slack predefinito (la radice a livello di organizzazione), un workspace o un singolo canale". Tre degli elementi richiesti nel resto di questo articolo sono già presenti:

• Le istruzioni si ereditano. "Le istruzioni personalizzate per scope vengono concatenate: prima l'accesso Slack predefinito, poi il workspace, infine il canale. Le istruzioni di un canale si aggiungono, anziché sostituire, a quelle impostate ai livelli superiori."

• Le credenziali appartengono al ramo. Nei canali, Claude agisce tramite account di servizio che un amministratore associa a uno scope e "viene utilizzata la credenziale dello scope più ristretto: il canale prevale sul workspace, che prevale sull'accesso Slack predefinito".

• Si può vedere da dove deriva un accesso. Ogni riga relativa a connettori, repository e plugin indica "Ereditato da" uno scope più ampio oppure "Associato da" un bundle. La spesa ha un tetto per l'organizzazione e per canale, e viene rendicontata per canale.

Anche i limiti sono documentati. L'albero ricalca la struttura di Slack: tre livelli fissi, e i canali Slack non si annidano. Le istruzioni sono "linee guida, non un guardrail vincolante", e la documentazione non descrive alcun controllo sui conflitti tra scope. Non esiste "nessun log per singola azione di ogni task e di chi lo ha richiesto". E tutto si ferma ai confini del progetto: "I Progetti su claude.ai non si applicano qui; Claude non legge le istruzioni o le conoscenze di un Progetto in Slack, e un canale non può essere collegato a un Progetto".

Cosa è cambiato il 1 ottobre 2026. Claude Code 2.1.287 ha attivato i mod, precedentemente in early access: funzioni all'interno di un plugin che girano dentro Claude Code e possono riscrivere un prompt o una sezione del system prompt, bloccare o modificare una chiamata a uno strumento, approvare o negare una richiesta di permesso e disegnare pannelli nell'interfaccia. Tre aspetti sono rilevanti in questa sede:

• Hanno un ordine dichiarato. Un guard integrato e i mod dell'organizzazione vengono eseguiti per primi, seguiti da quelli installati dall'utente. "Il primo mod è il più esterno: vede l'evento prima degli altri e il risultato dopo di loro, e decide se gli altri debbano essere eseguiti o meno." Dove il guard viene caricato (una macchina con impostazioni gestite, oppure un accesso Team o Enterprise), il mod personale non può alterare "il system prompt, il tuo CLAUDE.md gestito e le altre istruzioni gestite", né può approvare una chiamata a uno strumento rifiutata da una regola di diniego. Questa è una precedenza stabilita dalla struttura, esattamente ciò che questo articolo richiede. È un comportamento predefinito, non un lucchetto: chi avvia Claude Code con --safe-mode lavora senza i mod installati, compresi quelli aziendali, mentre gli hook gestiti e le regole di diniego restano attivi.

• L'ordine ha due proprietari. I mod dell'organizzazione vengono eseguiti prima di quelli personali, o dopo, se l'organizzazione lo preferisce. Non esiste un livello per la linea di business. Le impostazioni distribuite dalla console di amministrazione "si applicano uniformemente a tutti gli utenti dell'organizzazione. Le configurazioni per gruppo non sono ancora supportate". Un'organizzazione che desidera policy diverse per gruppo ha due strade, entrambe passando dall'IT: distribuire un file di impostazioni differente sulle macchine di ciascun gruppo, oppure far girare un gateway self-hosted che "distribuisce impostazioni gestite per gruppo IdP".

• Non raggiungono la chat e arrivano a Cowork in modo disomogeneo. "I mod funzionano nella CLI di Claude Code e nella scheda Code dell'app Claude Desktop." Un mod viene distribuito nel file hooks/hooks.json di un plugin, e la tabella di compatibilità dei plugin di Anthropic indica quel file come "Ignorato" nella chat. La stessa tabella riporta "Caricato" in Cowork, poiché "Cowork nell'app Claude Desktop esegue le sessioni su Claude Code"; le pagine dedicate ai mod non menzionano Cowork e io non l'ho testato. Lì il controllo dell'organizzazione è più debole: in una sessione Cowork, Claude Code "non recupera mai le impostazioni gestite dal server dalla console di amministrazione di claude.ai, nemmeno quando l'utente accede con un account Team o Enterprise", e le sessioni Cowork remote non hanno alcuna policy di dispositivo da leggere.

Cosa sta per essere rilasciato. Cowork sta confluendo in Claude: l'help center ora afferma "Claude Cowork è ora semplicemente Claude", prima su Pro e Max, mentre Team ed Enterprise "mantengono la chat e Claude Cowork come sono oggi". Dal 6 ottobre 2026, i nuovi task Cowork su Pro e Max passano al cloud. Inoltre, una nuova versione dei progetti è in beta pubblica su Pro e Max, partendo da Claude Code, con chat, Cowork, Team ed Enterprise a seguire; in essa, "un progetto è una singola conversazione" che Claude suddivide in thread paralleli. Resta comunque un livello unico: "Un progetto appartiene a un singolo utente" e "non esistono controlli a livello di organizzazione per i progetti durante la beta".

L'albero, dunque, non è un'idea nuova per Anthropic. Esiste per cartella nel codice e per canale su Slack, e in entrambi i casi l'organizzazione viene prima. Il luogo in cui un'azienda archivia il proprio lavoro, il progetto, non ha né un genitore né un livello superiore. Altre due offerte di Anthropic puntano nella stessa direzione, pur restando fuori dall'ambito di questo articolo: Claude for Government risolve le impostazioni attraverso una catena tenant, gruppo e organizzazione, mentre Claude Desktop su provider terzi offre policy per gruppo in beta.

2. Perché è importante

I progetti non sono contenitori. Una vera commessa è un contenitore. Ha una chiave (il numero di commessa), un genitore (la sua linea di business), un ciclo di vita (aperta, chiusa, archiviata per anno), una cartella, un cliente, delle persone, delle regole e dei deliverable. Un progetto Claude ha un nome in testo libero, nessuna chiave, nessun genitore e nessun figlio, e il suo ciclo di vita documentato si limita ad archiviazione ed eliminazione. Cowork può legare un progetto a una cartella locale, ma solo manualmente, un progetto alla volta, senza schemi di chiavi né genitori. Una linea di business può aprire centinaia di commesse all'anno. Restano due pessime opzioni: un progetto Claude artigianale per ogni commessa, ciascuno con la propria copia delle regole, oppure un progetto per linea di business, dove i contesti di clienti diversi convivono fianco a fianco.

Il percorso di carico si interrompe. Nell'ingegneria strutturale, ogni carico necessita di un percorso continuo fino alle fondamenta. Se togli un elemento, nulla di ciò che sta sopra viene trasferito verso il basso. Le regole funzionano allo stesso modo. Quando manca un livello tra l'organizzazione e il progetto, gli standard, i template e le procedure di approvazione di una linea di business non hanno un posto dove stare. Così ogni progetto riceve una copia fatta a mano.

Le copie divergono. Correggi una regola in un progetto e gli altri mantengono la vecchia versione. Ogni progetto supera comunque il proprio controllo locale. La discrepanza emerge solo quando qualcuno confronta i progetti affiancandoli e, nei settori regolamentati, quel qualcuno è di solito un auditor. I team infrastrutturali conoscono bene questo problema. Nella ricerca 2026 di Firefly, circa un terzo degli intervistati ha collegato la configuration drift a costosi incidenti in produzione, e quasi uno su cinque non aveva processi per rilevarla o correggerla.

Anche l'identità è piatta. Molte persone lavorano per più di un'organizzazione e ciascuna richiede un contesto sigillato a sé. All'interno di una qualsiasi di esse, in chat e in Cowork, l'account di un connettore appartiene a una persona, non a un ramo. I ruoli Enterprise possono decidere quali connettori un gruppo può usare e un amministratore può autorizzare un connettore una sola volta per l'intera organizzazione; un connettore personalizzato può persino portare una singola credenziale condivisa per tutti (in beta). In ogni caso l'account è della persona o dell'organizzazione, mai di un ramo: un consulente che serve due clienti non può associare il Drive di ciascuno ai rispettivi progetti. I progetti condivisi aggravano la situazione: "I connettori sono disponibili solo nei progetti privati". Claude Tag dimostra che un design diverso è possibile, con un account di servizio agganciato a un canale Slack, e mostra anche dove si ferma: al progetto. La pagina di Anthropic sul connettore Google descrive un solo account Google collegato, e la procedura documentata per cambiarlo prevede di scollegarlo e ricollegarlo; tre issue aperte (qui sotto) ne richiedono più di uno. Il confine vive nella testa delle persone, che è esattamente il tipo di limite manuale destinato a cedere senza fare rumore.

Nessuno sa quale regola sia stata applicata. Claude Enterprise mostra agli amministratori un "Visualizza ruolo effettivo" per i permessi e il comando /context di Claude Code elenca quali file di memoria sono stati caricati. Oggi un mod di Claude Code può disegnare il proprio pannello, quindi una vista delle istruzioni effettive è qualcosa che chiunque può costruire lì. Claude Tag etichetta ogni connettore e repository con lo scope da cui è stato ereditato, ma per le istruzioni la sua documentazione suggerisce di "chiedere a Claude di ripetere le sue istruzioni di amministrazione". Nessuna interfaccia mostra, per una data risposta, quale istruzione provenga da quale livello. Senza provenienza non c'è tracciabilità e, senza tracciabilità, non c'è sistema qualità.

Le persone stanno chiedendo pezzi di questo puzzle. Issue aperte nel tracker pubblico di Anthropic (github.com/anthropics/claude-code), verificate il 2026-10-01:

Una settima, la #47741, chiedeva un CLAUDE.md gestito dall'organizzazione ed è stata chiusa perché Claude Code ne ha già uno. Il punto è proprio questo: i livelli esistono in Code e in Slack, e le issue li richiedono là dove si trovano i progetti.

3. Quanto costa e cosa nasconde il token

3.1 I token non sono l'ostacolo

Più livelli potrebbero significare più contesto a ogni messaggio, e l'IA si fattura a token. Questa spiegazione è vera solo in parte. Sui piani Enterprise a consumo, l'utilizzo viene fatturato alle tariffe API, quindi più contesto significa più ricavi, non meno. Su Team le licenze hanno un costo fisso, a meno che non venga attivato il consumo extra, e i token aggiuntivi si traducono semplicemente in membri che raggiungono prima il limite settimanale. E Claude Code, fatturato sugli stessi token, offre già una cascata su quattro livelli. Se i token fossero l'ostacolo, non esisterebbe. Come misurato nella sezione 3.2, il system prompt e gli strumenti nativi di Claude Code pesavano circa 30.200 token prima ancora di inserire una nostra istruzione; le istruzioni complete di un progetto aggiungevano un 3,5-5,2%.

3.2 Un esempio pratico

Tag su ogni immagine: REAL = misurato, o verificato rispetto alla documentazione di Anthropic, tra il 29 settembre e il 1 ottobre 2026; EST = simulato; IND = illustrativo.

Prima le misurazioni. Ho sottoposto la stessa domanda in Claude Code (claude -p, Claude Sonnet 5.5) a un progetto demo, cinque volte per ogni condizione, prendendo i token di input riportati da Claude Code stesso. Ho eseguito il test su Claude Code 2.1.286 il 30 settembre e di nuovo sulla 2.1.287 il 1 ottobre: i conteggi delle istruzioni erano identici. Sottraendo un'esecuzione priva di qualsiasi istruzione di progetto, si ottiene il costo di ciascun layout:

Due aspetti che la simulazione seguente non poteva mostrare. La cascata costa 224 token in più rispetto al file compilato per le stesse regole: ogni file aggiuntivo comporta un overhead, in questo caso il marcatore e l'intestazione dell'app sul file di ogni livello, più la cornice che Claude Code costruisce attorno a ogni file caricato. Più livelli significano più overhead. Inoltre, Claude Code ha effettivamente caricato il 21-26% in più rispetto alla stima del tokenizer pubblico, anche moltiplicando × 1,30; parte di questo scarto è dovuta allo stesso overhead per file. I rapporti reggono; le cifre assolute in dollari no, quindi considerate i valori della simulazione come stime per difetto.

Poi la simulazione su scala aziendale. Ho simulato un mese di token di istruzione per un'azienda tipo: 40 persone su tre linee di business, 250 progetti attivi, sei tipi di report per linea, 35 messaggi per persona al giorno lavorativo in sessioni da cinque, per un totale di 29.400 messaggi. Le dimensioni in token sono state calcolate su testi di istruzione campione con il tokenizer legacy pubblico di Anthropic (che la stessa Anthropic definisce "un'approssimazione molto grezza" per Claude 3 e successivi) e scalate di 1,30 per il tokenizer di Claude 4.7+. Il blocco organizzativo è estrapolato da un campione di 597 caratteri fino al limite di 3.000, mentre il manuale di linea è il triplo di un campione di 953 caratteri. I prezzi sono quelli di listino di Claude Sonnet 5.5 (input $2, scrittura cache da 5 minuti $2,50, lettura cache $0,20 per milione di token). La cache del prompt dura cinque minuti e si aggiorna a ogni hit.

• Piatto (il workaround attuale): il blocco organizzativo, poi la copia specifica del manuale di linea per ogni progetto, tutti e sei i template di report e i dettagli del progetto.

• Albero: organizzazione, linea, solo il template di report in uso, poi i dettagli del progetto, compilati mettendo prima gli elementi più condivisi.

Dimensioni dietro la tabella: blocco organizzativo 830 token (3.000 caratteri), manuale di linea 729, un template di report 147, dettagli di progetto 98 (arrotondati; i totali sono stati calcolati prima dell'arrotondamento). La simulazione ignora il system prompt nativo di Claude, che precede il blocco organizzativo.

Due precisazioni doverose. Primo: l'albero non fa risparmiare token di per sé. Il −29% deriva dai task tipizzati: viene caricato solo il template del report in fase di redazione, non tutti e sei. Il −62% nasce soprattutto dalla compilazione mettendo prima i livelli più condivisi, così centinaia di progetti condividono un prefisso identico al byte: il solo riordino, mantenendo caricati tutti e sei i template, porta il costo della cache condivisa da $36 a $18 (−51%), e i task tipizzati fanno il resto. Questo secondo risparmio esiste solo se la cache è condivisa tra gli utenti. Sull'API di Claude le cache sono isolate tra le organizzazioni e, al loro interno, per workspace, quindi i prefissi identici vengono riutilizzati tra le richieste di uno stesso workspace; per claude.ai questo aspetto non è documentato. Non accade nel Claude Code attualmente distribuito: lì "la cache è di fatto limitata a una singola macchina e directory", quindi due persone in due cartelle di progetto diverse non vedono la cache l'una dell'altra. Leggete l'ultima colonna come il potenziale guadagno di un livello nativo nella chat, non come qualcosa di disponibile oggi. Un'obiezione legittima: le Competenze si caricano già su richiesta, quindi un workspace piatto che sposta i propri template nelle Competenze ottiene oggi una parte di quel −29%. Ciò che alle Competenze manca in chat e in Cowork sono lo scope e l'ereditarietà: una competenza non può appartenere a una linea e propagarsi ai progetti di quella linea. (In Claude Code, invece, una competenza in una sottocartella si carica per le sessioni avviate al suo interno o più in basso.) Secondo: questi sono solo token di istruzione e, a questa scala, variano da $14 a $149 al mese a seconda della cache. A dominare le fatture reali sono la cronologia delle conversazioni e l'output. L'argomento forte a favore dell'albero è la correttezza e, su Team, la capacità. Non è la fattura.

La misurazione precedente riproduce l'effetto dei task tipizzati su un albero reale, in Claude Code, invece che su dimensioni ipotizzate: −20% come cascata e −34% compilato, contro il −29% della simulazione. Una linea con un solo tipo di task non otterrebbe alcun risparmio dai task tipizzati.

3.3 La stessa risposta, dal vero Claude

Ho posto a Claude Code la stessa domanda quaranta volte: dieci risposte indipendenti in ciascuna di quattro condizioni, suddivise in due blocchi da cinque a distanza di un giorno. La domanda riguardava il superamento di un test di densità in campo su un sottofondo, a 112,3 pcf rispetto a una densità secca massima di 115,8 pcf con un requisito del 98%. Le istruzioni erano le sei regole dell'azienda oppure un prompt di una riga da "assistente utile", e la lingua era inglese o spagnolo. Tutte e quaranta le risposte sono giunte allo stesso verdetto: 97,0%, non superato.

Claude Code riporta due numeri in output: i token fatturati e quanti di questi fossero ragionamenti invisibili per l'utente.

Quattro evidenze:

• Le regole aziendali hanno reso le risposte 1,4 volte più lunghe a schermo e 1,8-1,9 volte più lunghe in fattura. L'extra visibile corrispondeva alle sezioni di segnalazioni, standard e limitazioni richieste dalle regole. In un sistema qualità, è quella la parte di valore.

• Con le regole aziendali, oltre un terzo dell'output fatturato era invisibile. Il 37% dei token di output fatturati era costituito da ragionamenti, contro il 16% del prompt base. In inglese, l'utente vede 447 token e ne paga 711.

• Lo spagnolo è costato 1,2 volte i token visibili dell'inglese per risposte la cui lunghezza in parole differiva al massimo del 4%. Misurate allo stesso modo, le regole aziendali hanno richiesto 1,53 volte i token di input quando scritte in spagnolo.

• Lo stesso verdetto è stato fatturato da 317 a 953 token, il triplo per la risposta più lunga rispetto alla più breve. La fatturazione a token non distingue il rigore dal riempitivo. I criteri di accettazione sì.

Questi rapporti oscillano tra i blocchi da cinque. Il rapporto a schermo per le regole aziendali era 1,43-1,52 nel primo blocco e 1,27-1,31 nel secondo; il rapporto fatturato era 1,78-1,82 e poi 1,70-2,05; il rapporto dello spagnolo era 1,29-1,38 e poi 1,14-1,18. La direzione non è mai cambiata. L'ordine di grandezza è affidabile a una cifra significativa.

Metodo: Claude Code 2.1.286 il 2026-09-30 e 2.1.287 il 2026-10-01, claude -p --output-format json, Claude Sonnet 5.5. Tutti gli strumenti sono stati disabilitati e i file personali ~/.claude esclusi, così che tra le condizioni variassero solo le istruzioni dichiarate. I conteggi dei token derivano dal report di utilizzo nativo di Claude Code, inclusi i thinking_tokens; il costo mensile applica i $10 per milione di token di output di Sonnet 5.5 alla media fatturata. Lo script di misurazione, entrambi i blocchi, i dati aggregati e ogni singola risposta sono conservati dall'autore e disponibili su richiesta. La prima versione di questo articolo stimava questi numeri con subagent e il tokenizer pubblico; quelle stime sono ora superate.

3.4 Quando le regole vanno in conflitto, decide la formulazione

La documentazione di Anthropic ammette che istruzioni contraddittorie possano essere risolte "in modo arbitrario". Ho testato un conflitto tipico di quello che genera l'assenza di un livello per la linea di business. La regola aziendale imponeva le unità di misura statunitensi; una regola di progetto richiedeva di indicare le densità nel Sistema Internazionale. Le ho posizionate come farebbe un albero: la regola aziendale in un CLAUDE.md alla radice dell'archivio, quella di progetto in un CLAUDE.md nella cartella del progetto, entrambe caricate dalla cascata nativa di Claude Code. Poi ho rieseguito lo stesso setup con la regola aziendale contrassegnata come vincolante, ma solo a parole: il tag ENFORCED nell'etichetta e una frase aggiunta, "Questa regola è vincolante: nessuna regola di linea o di progetto può sovrascriverla". Ogni configurazione è stata eseguita dieci volte il 30 settembre e altre dieci il 1 ottobre.

Non c'era nulla di arbitrario. Senza alcuna dichiarazione, Claude ha scelto ogni volta la regola più vicina e specifica. Quattordici risposte su venti ne hanno spiegato il motivo ("quella regola è più specifica della regola aziendale sulle unità statunitensi", oppure che sovrascriveva la regola dell'azienda); cinque hanno citato solo la regola di progetto senza mai menzionare il contrasto con quella aziendale. Dichiarando il vincolo a parole, la regola aziendale ha prevalso ogni volta e tutte le risposte hanno indicato che la regola vincolante dell'azienda aveva la priorità. Il secondo blocco ha replicato le unità di misura, 10 volte su 10 in entrambi i casi, e la differenza tra le due righe va ben oltre il caso (test esatto di Fisher, p < 0,0001). Le spiegazioni hanno tenuto meno: nove risposte su dieci hanno motivato la vittoria della regola di progetto nel primo blocco, cinque su dieci nel secondo.

Questa è una buona notizia per il modello e una cattiva notizia per il workspace. La precedenza esiste, ma risiede nella formulazione delle regole, che chiunque modifichi un qualsiasi livello può cambiare e che nessuno revisiona come decisione di precedenza. E quando ha prevalso la regola inferiore, in un quarto dei casi le risposte non hanno segnalato al lettore che una regola superiore era stata messa da parte. Un test pilota condotto per la prima versione di questo articolo, con entrambe le regole in un unico prompt anziché a cascata, ha mostrato variazioni anche solo invertendone l'ordine (regola aziendale per prima: SI 5 su 5; regola aziendale per ultima: SI 2 su 5, e 3 su 5 hanno restituito entrambe le unità o chiesto quale applicare).

A nessun modello dovrebbe essere chiesto di arbitrare un conflitto che l'organizzazione avrebbe potuto intercettare nel momento in cui la regola veniva scritta. Claude Code offre due risposte parziali. Il comando /doctor prompt-audit chiede a Claude di cercare file di istruzioni che si contraddicono tra loro, quando viene eseguito da una persona. E dal 1° ottobre un mod può imporre un ordine nel codice: i mod dell'organizzazione vengono eseguiti prima di quelli della persona e, dove entra in gioco la protezione integrata, le regole di negazione prevalgono sul mod della persona. Nessuno dei due copre il testo delle istruzioni. I file di istruzioni vengono ancora concatenati e la documentazione descrive il risultato in tre modi: Claude "potrebbe sceglierne uno arbitrariamente"; quando una regola utente e una regola di progetto sono in conflitto, "Claude potrebbe seguire una delle due"; e "quando le istruzioni sono in conflitto, Claude usa il proprio giudizio per conciliarle". Il risultato di venti su venti è esattamente ciò che quel giudizio ha prodotto in questo caso. Claude Tag dichiara un ordine per i suoi tre ambiti e definisce il risultato "una linea guida, non un guardrail imposto". Il controllo dell'implementazione di riferimento rifiuta questa esatta modifica, "R-22 imposta units.density=SI; R-01 (org:firm) impone US", prima che qualsiasi cosa raggiunga Claude, e "enforced" è un campo della regola, non una frase al suo interno.

La densità delle istruzioni peggiora le cose. Nel benchmark IFScale (2025), l'accuratezza di Claude Sonnet 4 è scesa dal 100% con 10 istruzioni simultanee al 42,9% con 500.

3.5 Il compute o l'energia sarebbero un'unità più equa?

Il token è un proxy ragionevole del compute all'interno di un singolo modello: più token significano davvero più lavoro per l'hardware. Ed è anche per questo che un prezzo basato sul compute o sull'energia non eliminerebbe la penalizzazione linguistica. Lo spagnolo costa di più perché il tokenizer lo comprime meno, e quei token extra corrispondono a compute reale. La soluzione è un tokenizer migliore o una misurazione normalizzata in base al contenuto.

Un'unità di compute normalizzata sarebbe comunque utile sotto tre aspetti. Renderebbe confrontabili modelli e vendor diversi. Sarebbe fisica e rendicontabile, ad esempio per i report di sostenibilità. E se il coefficiente fosse fissato rispetto a un hardware di riferimento, il vendor manterrebbe i propri guadagni di efficienza, creando il giusto incentivo. Esiste un precedente: i cloud provider un tempo vendevano unità normalizzate come l'EC2 Compute Unit.

Ci sono però problemi concreti. Il cliente non può verificarla senza uno standard e un auditor. L'energia effettiva dipende dall'hardware, dall'efficienza del data center, dal batching e dalla rete elettrica. Inoltre Anthropic non pubblica il consumo energetico per richiesta: ho trovato solo stime di terze parti. Soprattutto, il compute resta un input: non dice se la risposta era corretta.

La mia conclusione prevede tre livelli separati:

1. Fatturare in token o in un'unità di compute normalizzata.

1. Dichiarare l'energia per task e per nodo.

1. Gestire in base al costo per risultato verificato.

Per Team, il passo minimo è pubblicare il limite settimanale in un'unità dichiarata. La quota per sessione è indicata come "1,25 volte la quota di utilizzo per sessione del piano Pro"; per il limite settimanale non è pubblicato alcun numero. Nessuno dei due permette di fare budget.

Come afferma la FinOps Foundation, "il token è l'unità di fatturazione, non l'unità di valore". È una gerarchia a rendere definibile il valore, perché è lì che possono risiedere i criteri di accettazione.

3.6 Motivi più probabili per cui non è stato costruito

1. Precedenza implicita. La stessa documentazione di Anthropic ammette che istruzioni direttamente contraddittorie possono produrre comportamenti variabili, e la sezione 3.4 mostra che la precedenza segue semplicemente ciò che dice la formulazione delle regole. Sovrapporre i livelli moltiplica i conflitti e la capacità di seguire le istruzioni peggiora all'aumentare della densità: nel benchmark IFScale (2025), anche i migliori modelli testati hanno raggiunto solo il 68% di accuratezza con 500 istruzioni keyword simultanee (il benchmark citato nella sezione 3.4).

1. Ereditarietà dei permessi. Se la conoscenza si eredita lungo un albero, anche gli accessi devono farlo. Questo significa ricostruire il modello dei permessi sotto ogni livello.

1. Una preferenza per memoria e retrieval rispetto ai livelli statici.

1. Semplicità consumer-first. Gli strumenti di codice ereditano gratuitamente un albero dal file system. I prodotti chat devono inventarselo.

Anthropic non ha spiegato pubblicamente perché la chat di Claude e Cowork siano privi di gerarchia. Tutto ciò che è scritto in questa sezione è dedotto da quanto è stato rilasciato.

4. Il modello di riferimento

Il design prende spunto da sistemi che hanno già risolto questo problema: le gerarchie di risorse cloud (AWS Organizations, Google Cloud Org Policy, i gruppi di gestione di Azure), le policy di directory (Active Directory Group Policy) e la stessa cascata CLAUDE.md di Claude Code. Le relazioni tra i nodi usano cinque parole: contiene, eredita, usa, sigillato e condiviso.

4.1 Monta l'albero che l'organizzazione ha già

Non obbligare le persone a ricostruire la propria organizzazione dentro il workspace AI. Il file server o il sistema documentale è già la fonte di verità. Segui un unico percorso:

Il numero di commessa 26GT301 codifica già l'albero: anno, linea di attività, sequenza. Il workspace dovrebbe montare questa struttura, non copiarla.

4.2 Nodi portatori di regole, nodi di raggruppamento, progetti e task

• Nodi portatori di regole: organizzazione, linea di attività, progetto, task. Ognuno porta le stesse tre cose: contesto (istruzioni e conoscenza), policy (quali strumenti, dati e connettori sono consentiti) e identità (gli account connettore associati).

• Nodi di raggruppamento: serie, anno, area geografica. Non contengono regole. Servono per navigazione, conservazione e ciclo di vita. Separarli mantiene l'albero delle regole poco profondo, tre o quattro livelli, come raccomandano le linee guida Microsoft per i gruppi di gestione ("non più di tre o quattro livelli").

• Il progetto è un contenitore con chiave. Viene creato automaticamente: quando compare una cartella che corrisponde al pattern della chiave della linea (ad esempio {YY}GT{NNN}_{Nome} sotto la root della linea), viene creato un nodo progetto che eredita dalla sua linea e ottiene l'accesso ai connettori limitato esclusivamente a quella cartella. Contiene solo ciò che differisce dalla sua linea: membri, cliente, specifiche. Passa dallo stato aperto a chiuso fino ad archiviato (Diagramma 2).

• Il task è tipizzato. Il suo tipo proviene dal catalogo della linea (un report di densità, un log di perforazione). Il tipo porta con sé un template e dei criteri di accettazione. L'output viene archiviato nella cartella del progetto seguendo le convenzioni di denominazione dello studio, e un revisore lo approva. Le skill sono oggi la cosa più vicina ai tipi di task disponibile in Claude. Su Enterprise possono essere condivise con un gruppo, ma si tratta di distribuzione, non di ereditarietà: nulla scorre lungo un ramo.

La ricorsione è voluta. Il Viable System Model di Stafford Beer lo afferma chiaramente: "In una struttura organizzativa ricorsiva, qualsiasi sistema vitale contiene, ed è contenuto in, un sistema vitale."

4.3 Un genitore principale, più gli overlay

Nel 1965 Christopher Alexander sosteneva che "una città non è un albero". Le strutture reali si sovrappongono. Un cliente, una specifica di un ente o un tipo di task possono attraversare diverse linee di attività. Per questo ogni nodo ha un unico genitore principale, mentre i set di regole trasversali si agganciano come overlay (usa). I conflitti si risolvono sempre allo stesso modo: vince il deny, altrimenti prevale il nodo più vicino.

4.4 Due canali, due semantiche

Questo è il cuore del design, ed è qui che la maggior parte delle gerarchie sbaglia.

• Il contesto si concatena. Istruzioni e conoscenza vengono unite dalla root verso il basso, come fa CLAUDE.md.

• La policy è deny-by-default. Uno strumento o un connettore è consentito solo se esiste un allow lungo tutto il percorso dalla root, e un deny esplicito in qualsiasi punto superiore prevale, come avviene con le AWS Service Control Policies. Un genitore può contrassegnare una regola come imposta (enforced) e nessun figlio può bloccarla, come nelle Group Policy.

Mescolare le due cose è l'errore classico. Il contesto consultivo deve fondersi. L'imposizione no.

4.5 Compila prima che il modello lo legga

Oggi le istruzioni in conflitto vengono risolte dal modello al momento della risposta. La soluzione è un compilatore di istruzioni effettive che gira prima che il modello veda qualsiasi cosa:

1. Unisci il contesto dalla root alla foglia.

1. Applica la policy: il deny vince e un allow deve valere lungo tutto il percorso.

1. Rispetta le regole imposte dai genitori.

1. Contrassegna ogni regola con un ID e il suo livello.

1. Ordina il blocco in base a quanto ampiamente ciascuna parte è condivisa e applica un budget di token per livello.

I conflitti non raggiungono mai questo passaggio: vengono respinti prima, quando una regola viene scritta, e l'approvazione arriva da qualcuno diverso dall'autore (Diagramma 3, corsia inferiore).

Poiché i conflitti si risolvono in fase di compilazione, l'output può essere ordinato in base a quanto ampiamente ciascuna parte è condivisa, e non rigorosamente per profondità: organizzazione, linea, template del tipo di task, poi dettagli del progetto. Quest'ordine massimizza i cache hit (sezione 3.2). Si mappa sui quattro breakpoint di cache di Anthropic, con un budget di token per livello, anche se nella pratica potrebbe servire un breakpoint per la conversazione stessa.

4.6 Identità legate ai rami, non alle persone

L'identità di un connettore (account, tenant, ambito) si aggancia a un nodo, non a una persona. Claude Tag funziona già così per i canali Slack: un admin associa un account di servizio a un ambito e vincono le credenziali dell'ambito più ristretto. Il modello qui proposto chiede la stessa cosa un livello più in basso, su una linea di attività e i suoi progetti. Una persona che lavora in due organizzazioni ha due alberi sigillati: passa da un albero all'altro, non da un account all'altro. Nulla li attraversa a meno che i proprietari di entrambi non lo condividano esplicitamente. La primitiva tecnica esiste già: la specifica di autorizzazione MCP utilizza token OAuth legati all'audience (RFC 8707 resource indicator, RFC 9728 protected resource metadata) e richiede che i server "NON DEVONO accettare o inoltrare altri token" (versione della specifica 2026-07-28).

4.7 I permessi seguono l'albero

Principal: persone, gruppi, account di servizio, ospiti esterni (ad esempio un cliente) e l'agente stesso.

L'agente non supera mai i limiti della persona o del nodo. Claude agisce con i permessi dell'utente che lo invoca, intersecati con la policy del nodo. Non può modificare regole o permessi; può solo proporre cambiamenti. (Oggi Claude può aggiornare autonomamente le istruzioni delle cartelle di Cowork. In questo modello, diventa una proposta che qualcuno deve approvare.)

Valutazione. Le concessioni fluiscono solo verso il basso, mai verso l'alto o lateralmente. Il permesso effettivo su un nodo è ciò che concedono i ruoli lungo il suo percorso, entro quanto la policy consente sull'intero percorso, meno eventuali deny superiori. Un overlay concede l'accesso solo ai propri contenuti: leggere una specifica non apre i progetti che la utilizzano.

Ciclo di vita.

• Aperto: i ruoli si applicano come concessi.

• Chiuso: nessun nuovo task, ma le revisioni in sospeso possono essere completate.

• Archiviato: sola lettura per tutti; solo il proprietario può ripristinarlo e il ripristino viene registrato.

• Albero sigillato: nulla lo attraversa senza una condivisione esplicita.

Eccezioni e deleghe. Le eccezioni hanno una durata limitata e una motivazione, e vengono approvate da qualcuno diverso dal richiedente. Scadono da sole e vengono conteggiate, perché ogni override è un'isola di manutenzione permanente; i limiti di ereditarietà interrotta di SharePoint sono un monito. Una delega non può mai concedere più di quanto possiede chi delega. L'accesso break-glass del proprietario esiste, viene sempre registrato e successivamente revisionato.

Su Team, questo funziona senza gruppi: la concessione risiede sul nodo, quindi un'organizzazione con quattro ruoli ottiene comunque permessi per ramo.

4.8 Come interagiscono i livelli

Costruire un albero ha senso solo se le modifiche lo attraversano. Tre interazioni svolgono la maggior parte del lavoro (Diagramma 5):

• Push verso il basso. Il responsabile di una linea pubblica una nuova versione di una regola. Ogni progetto della linea la legge alla successiva compilazione. Un'eccezione approvata mantiene la vecchia versione fino alla scadenza, e gli artefatti già archiviati conservano la versione con cui sono stati creati.

• Pull verso l'alto. Un membro migliora un template all'interno di un progetto e lo propone. È il responsabile della linea, non chi lo propone, ad approvarlo, e i progetti fratelli lo ereditano. Oggi quel miglioramento resta nel progetto in cui è nato.

• Trasversale. Una specifica di un ente cambia una volta sola. I progetti in tre linee vengono ricompilati includendola, mentre le linee restano invariate. Un conflitto con una regola di linea viene respinto nel momento in cui l'aggiornamento viene scritto.

Una singola richiesta mostra tutti i livelli contemporaneamente (Diagramma 6): l'albero verifica la concessione del membro e lo stato del progetto, il compilatore costruisce il blocco, Claude legge i dati di campo tramite un'identità limitata alla cartella di quel progetto, archivia un artefatto tipizzato nella cartella e un revisore che non lo ha scritto lo approva. Ogni passaggio finisce nel log e il costo viene addebitato alla chiave del progetto.

4.9 La struttura dati

Il provisioning è event-driven: una nuova cartella che corrisponde a key_pattern sotto lo storage_root di una linea crea il nodo progetto. L'answer_log fornisce la provenienza per ogni risposta e il costo per nodo.

4.10 Misura i risultati, non i token

Ogni tipo di task porta con sé dei criteri di accettazione: la definizione di completamento. Con questi elementi in campo, diventa misurabile un'unità migliore per il lavoro AI:

costo per risultato verificato = (costo in token + tempo di revisione) ÷ deliverable accettati

Poiché ogni risposta viene registrata su un nodo, il costo AI può essere addebitato a una chiave di progetto esattamente come manodopera e materiali. Alcuni pezzi esistono già: Claude Tag segnala e limita la spesa per canale, e la telemetria di Claude Code può essere etichettata manualmente per dipartimento, centro di costo o repository. Nessuno è agganciato a un progetto e nessuno divide per i deliverable accettati. Per uno studio che fattura per numero di commessa, l'AI diventa un costo diretto di commessa anziché un costo generale. Nell'ingegneria paghi per il deliverable verificato e sigillato, non per la mina della matita. Il lavoro AI andrebbe misurato allo stesso modo.

4.11 Obiezioni e risposte

"Skill e plugin lo fanno già." Una skill viene caricata quando Claude la ritiene pertinente, il che significa probabilità, non garanzia. Il provisioning assegna una skill a tutti; su Enterprise, un plugin che la contiene può essere reso obbligatorio per un gruppo. È la cosa più vicina a una linea di attività oggi disponibile in chat e Cowork, ma pecca sotto tre aspetti: è solo per Enterprise, punta alle persone e non ai progetti, e nulla scorre da una linea ai suoi progetti. Una regola che deve applicarsi sempre in una linea non può dipendere dal rilevamento di pertinenza.

"I mod lo fanno già." In Claude Code, in parte, dal 1° ottobre 2026. Un mod può riscrivere il system prompt, rifiutare una chiamata a uno strumento e disegnare un pannello, e i mod dell'organizzazione vengono eseguiti prima di quelli della persona. Quindi il compilatore, il controllo in fase di scrittura e la vista delle istruzioni effettive descritti in questo articolo potrebbero essere costruiti oggi come un mod, e la sezione 6 lo conferma. Restano tre limiti. I mod non girano nella chat di Claude e in Cowork le impostazioni della console dell'organizzazione non si applicano. Il loro ordine ha due proprietari, organizzazione e persona, senza alcuna linea di attività tra loro; su Enterprise, un plugin obbligatorio per un gruppo può portare un mod a quel gruppo, ma viene eseguito come uno dei mod personali dell'utente, senza precedenza. E un mod è codice non sandboxato: per girare prima dei mod personali, il mod di un'organizzazione deve trovarsi in una directory su ogni macchina, e le impostazioni distribuite dalla console di amministrazione "non possono inserire la directory su una macchina". Uno studio senza gestione dei dispositivi può distribuire un mod a tutti, ma verrà eseguito insieme ai mod personali degli utenti, non prima di essi. Uno studio non dovrebbe dover scrivere TypeScript per dire che un dipartimento usa unità di misura diverse nei report.

"La memoria imparerà le regole." La memoria è scritta principalmente da Claude, per una singola persona o un singolo progetto, e un proprietario non può leggere né modificare i ricordi di un membro. Un auditor ha bisogno di regole scritte da una persona, versionate, approvate e tracciabili per ogni risposta. Anthropic lo ha già costruito tre volte: per i permessi, con "View effective role" e la sua etichetta "Granted by"; per skill e plugin, con la cronologia delle versioni e un passaggio di revisione in cui "non puoi approvare te stesso"; e per gli accessi di Claude Tag, con le sue etichette "Inherited from". Le istruzioni in un progetto non hanno nessuna di queste tre cose.

"Claude Tag lo fa già." Per i canali Slack, in gran parte sì, e la sezione 1 lo conferma. Mancano ancora tre cose. Un canale non è un progetto: non ha cartella, né chiave, né ciclo di vita, e "un canale non può essere puntato a un Progetto". L'albero ha tre livelli fissi, quindi uno studio con linee di attività e centinaia di commesse deve appiattire due dei suoi livelli nei nomi dei canali. Inoltre la documentazione non descrive alcun controllo dei conflitti quando un'istruzione viene scritta: gli ambiti vengono concatenati e si lascia al modello il compito di conciliarli. Semmai, Claude Tag è la prova più forte a favore del design di questo articolo: la stessa azienda ha scelto ereditarietà, credenziali legate all'ambito ed etichetta di origine quando ha costruito per i team.

"Le gerarchie aggiungono complessità." Solo se la loro profondità è illimitata. Le linee guida Microsoft per i gruppi di gestione dicono "non più di tre o quattro livelli". Questo modello fissa quattro livelli portatori di regole, e le cartelle di raggruppamento come serie e anno non contengono alcuna regola.

"L'ereditarietà è un rischio per la sicurezza." Lo è, se gli accessi vengono ereditati con leggerezza. Vale la risposta del cloud: un allow deve esistere a ogni livello, un deny ovunque prevale, Claude agisce come l'utente intersecato con il nodo, e le modifiche alle regole fatte da Claude stesso diventano proposte.

"Più livelli costano più token." La sezione 3.2 ha misurato l'opposto in Claude Code: il 20% in meno di token di istruzione come cascata, il 34% in meno se compilati, rispetto alle copie piatte. Ogni file aggiuntivo introduce un po' di overhead, quindi compilare batte la cascata. I task tipizzati scartano i template non utilizzati e i prefissi compilati sono identici al byte tra i progetti, quindi il prompt caching può riutilizzarli. Sull'API di Claude le cache sono isolate per workspace, quindi un workspace per organizzazione si mappa sulla root dell'albero. Oggi Claude Code non ce l'ha: la sua cache è limitata a una singola macchina e directory.

"I team possono semplicemente gestire i propri progetti." È il workaround di oggi, e il prototipo della sezione 5 ha misurato cosa produce: due copie incollate su sei non aggiornate in una piccola demo.

5. Funziona già oggi: un'implementazione di riferimento

Per dimostrare che il modello è realizzabile, e non solo teorizzabile, ho creato Worktree, una piccola app desktop (Node ed Electron, 24 test superati su Windows e Linux) strutturata come Claude Desktop. Il video qui sopra è un'esecuzione reale, accorciata solo nei punti in cui Claude stava elaborando. È un'app separata che controlla Claude Code dall'esterno, non un mod. Non chiama un modello proprio. Ogni chat esegue il Claude Code già installato sul computer (claude -p), con qualsiasi login abbia Claude Code: un abbonamento Claude o una chiave API. L'ho testata su uno studio inventato con tre linee di attività e sei progetti. Quando qualcuno invia un messaggio:

• Autorizzazione. Chi agisce deve avere una concessione sul progetto o a un livello superiore, e il progetto deve essere aperto. Un admin senza concessione sulla linea è stato bloccato prima che partisse Claude.

• Controllo. Il controllo in fase di scrittura viene eseguito per primo. La regola SI della sezione 3.4 viene respinta perché in conflitto con una regola aziendale imposta, quindi non raggiunge mai un CLAUDE.md.

• Mount. L'albero viene scritto nelle cartelle reali del progetto come un CLAUDE.md per livello (organizzazione alla root di storage, poi linea, poi progetto) e la cascata nativa di Claude Code li carica. Una modalità compilata scrive invece un solo file per progetto. I file senza il marcatore dell'app non vengono mai sovrascritti.

• Esecuzione. Il template del task finisce in --append-system-prompt-file. Ciò che Claude può fare è imposto da Claude Code, non da CLAUDE.md: --allowedTools è il ruolo della persona intersecato con la policy di ogni livello, le scritture sono limitate alla cartella del progetto e --permission-mode dontAsk rifiuta tutto il resto. Nelle esecuzioni reali, una ricerca web è stata rifiutata perché la policy della linea non consente il web, e una scrittura fuori dalla cartella del progetto è stata negata e registrata.

• Log e revisione. Ogni risposta viene registrata con la persona, il nodo, ogni tag di regola, le regole citate da Claude e i token di input, cache e output riportati da Claude Code. Un revisore che non ha scritto la risposta la approva o la rimanda indietro. Un'esecuzione reale del report di densità nella demo ha richiesto circa 30 secondi; su tre esecuzioni, Claude Code ha riportato 0,08–0,22 $ per risposta ai prezzi di listino. Claude ha citato le regole applicate, ha segnalato i risultati vicini al limite di accettazione e ha lasciato vuoti i campi riservati all'ingegnere.

• Drift. Ogni CLAUDE.md montato viene confrontato con l'albero e le modifiche manuali vengono segnalate. Un precedente prototipo a riga di comando ha eseguito lo stesso confronto su copie incollate in progetti piatti e ne ha trovate due su sei non aggiornate: una ancora su R-07 v3 e una in cui una regola era stata cancellata a mano.

Tre scoperte emerse durante lo sviluppo, tutte utili per chiunque stratifichi istruzioni su Claude Code:

1. Le tue istruzioni personali finiscono nelle esecuzioni aziendali. Per impostazione predefinita, ogni esecuzione caricava anche il mio ~/.claude/CLAUDE.md personale, con regole, agenti e server MCP. Ora l'app li esclude con l'impostazione claudeMdExcludes, oltre a --strict-mcp-config. Sulla mia macchina, questo ha ridotto il contesto di un'esecuzione da 29,6k a 21,4k token. L'alternativa ovvia, --setting-sources project,local, ha fatto l'opposto di ciò che serviva in Claude Code 2.1.284 su Windows: ha mantenuto il file personale e scartato i file CLAUDE.md delle cartelle superiori che contengono l'organizzazione e la linea.

1. Anche i mod personali si intromettono. I mod sono arrivati il giorno dopo la creazione dell'app, quindi li ho testati. Ho installato un mod con un solo hook nel mio ambito utente che aggiunge una riga a ogni prompt. Ha raggiunto le esecuzioni dell'app: le tre regole aziendali sono state caricate, così come la mia riga personale, e la risposta l'ha seguita. Aggiungere disableAllHooks alle impostazioni dell'esecuzione l'ha tenuto fuori lasciando intatti i tre livelli di CLAUDE.md; ora l'app lo fa di default. --safe-mode non è un sostituto: ha rimosso il mod e con esso l'intera cascata CLAUDE.md. Secondo la documentazione, disableAllHooks nelle impostazioni personali lascia in esecuzione ciò che gestisce l'organizzazione.

1. CLAUDE.md è contesto, l'imposizione è configurazione. La documentazione di Anthropic lo dice chiaramente: "Le regole delle impostazioni sono imposte dal client indipendentemente da ciò che Claude decide di fare. Le istruzioni in CLAUDE.md modellano il comportamento di Claude ma non costituiscono un livello di imposizione rigido." L'app si basa su questo. Tutto ciò che una regola deve garantire è mappato sui permessi degli strumenti; tutto ciò che sta in CLAUDE.md è una linea guida con un tag.

Funziona sul Claude Code di oggi e il testo compilato può essere incollato in una chat o nelle istruzioni di un progetto Cowork su qualsiasi piano. Una dipendenza ha i giorni contati: l'app si basa sul fatto che claude -p carichi i file CLAUDE.md, ma la documentazione di Anthropic indica che --bare, che li salta, "diventerà il comportamento predefinito per -p in una release futura". Quando succederà, l'app dovrà passare l'albero in un altro modo; la modalità compilata e --append-system-prompt-file lo fanno già. È una specifica funzionante per la versione nativa, non un confine di sicurezza: "acting as" è un interruttore per le demo, non un accesso.

6. Un percorso a partire da ciò che è già disponibile

In Claude Code, adesso. Dal 1° ottobre l'albero può essere distribuito come mod: compila le regole del nodo in una sezione del system prompt, rifiuta le chiamate agli strumenti che la policy del nodo nega e mostra le istruzioni effettive in un pannello. Un'organizzazione può eseguire quel mod prima di qualsiasi cosa installata da un utente. Non l'ho costruito io; è il primo punto nella roadmap dell'implementazione di riferimento. Coprirebbe Claude Code e, possibilmente, le sessioni Cowork sulla macchina dell'utente, che girano sullo stesso motore. Non coprirebbe la chat.

La versione a 30 giorni, per chat e Cowork. Anthropic ha già tutti i pezzi. Permetti a un progetto di indicare un progetto padre da cui ereditare le istruzioni, proprio come un canale Slack eredita dal proprio workspace in Claude Tag. Compila i due elementi in ordine, con un tag su ogni regola, e aggiungi un pannello "Visualizza istruzioni effettive" accanto all'esistente "Visualizza ruolo effettivo". Già solo questo offre a ogni linea di lavoro un unico posto in cui conservare le proprie regole.

Dopo di che, ogni passaggio è utile di per sé, a partire da ciò che aiuta i piani Team:

1. Nodi per linea di lavoro e provisioning basato su pattern chiave, riutilizzando la semantica di CLAUDE.md che funziona già nel codice. In Claude Code stesso, il passaggio di matching rappresenta un livello per un gruppo posizionato tra i mod dell'organizzazione e quelli personali, oltre a impostazioni gestite per singolo gruppo.

1. Tipi di task come competenze limitate a una specifica linea di lavoro, con relativi criteri di accettazione.

1. Un controllo dei conflitti in fase di scrittura, così che le contraddizioni vengano scartate dall'albero anziché essere risolte dal modello.

1. Grant sui nodi, che funzionano su Team senza gruppi ed estendono i ruoli personalizzati di Enterprise.

1. Identità dei connettori vincolate al branch per i progetti, esattamente come Claude Tag vincola già un account di servizio a un canale Slack.

1. Contabilizzazione per nodo agganciata al progetto, come Claude Tag fa già per canale; un limite settimanale pubblicato in un'unità definita; e la dichiarazione dei consumi energetici per task.

7. Limitazioni

• Copertura. Il 1° ottobre 2026 gli indici completi delle pagine di code.claude.com/docs e claude.com/docs sono stati analizzati per titolo (466 pagine) e circa 150 pagine sono state lette, insieme agli articoli del centro assistenza qui citati. Le versioni precedenti di questo articolo non menzionavano affatto Claude Tag; questa potrebbe tralasciare qualcos'altro. Claude for Government e Claude Desktop su provider di terze parti vengono citati ma non analizzati.

• Le funzionalità della piattaforma cambiano ogni mese, e una è cambiata mentre scrivevo questo testo. Ogni affermazione sul prodotto riportata qui è datata 29 settembre–1° ottobre 2026 e andrebbe ricontrollata prima di farvi affidamento. I mod esistono da un giorno; ne ho letto la documentazione e testato un caso, ma non li ho usati in produzione.

• I numeri misurati nelle sezioni 3.1–3.4 provengono dai report di utilizzo di Claude Code stesso, raccolti in due batch: Claude Code 2.1.286 il 2026-09-30 e 2.1.287 il 2026-10-01, entrambi su Claude Sonnet 5.5. Lo script, entrambi i batch e tutte le risposte sono conservati dall'autore e disponibili su richiesta. Includono il prompt interno di Claude Code (circa 30.200 token), che claude.ai e Cowork non condividono, e riguardano un solo modello, un progetto demo e una sola domanda. I campioni sono ridotti: dieci risposte per condizione per la lunghezza delle risposte, venti per condizione per il test sui conflitti. I rapporti di lunghezza delle risposte sono variati tra i due batch (sezione 3.3); inoltre, due batch raccolti a un giorno di distanza differiscono anche per versione di Claude Code, e non riesco a separare questo fattore dal caso.

• I tempi di esecuzione, i costi e le dimensioni del contesto nella sezione 5 derivano dal log delle risposte dell'app relativo a tre esecuzioni demo e un test di isolamento manuale, ovvero dagli appunti personali dell'autore.

• Le risposte relative ai conflitti sono state classificate dall'autore, senza cecità, leggendo ogni singola risposta (unità riportate; se la risposta indicava quale regola prevaleva e perché; se poneva domande). Tutte e quaranta sono disponibili su richiesta per una nuova codifica. Il test ha utilizzato una specifica formulazione di "enforced"; altre formulazioni, modelli e coppie di regole potrebbero comportarsi diversamente.

• Il test dei mod nella sezione 5 riguarda un singolo mod con un hook, su una macchina Linux, con Claude Haiku, accesso effettuato tramite abbonamento e nessuna impostazione gestita. Non ho testato il mod di policy di un'organizzazione, il sistema di protezione integrato in un accesso Team o Enterprise, né l'app Desktop.

• Il modello di costo nella sezione 3.2 è una simulazione di un'azienda fittizia a scopo illustrativo, non una fatturazione misurata. Copre esclusivamente i token delle istruzioni; la cronologia delle conversazioni, l'output e il thinking dominano solitamente le fatture reali. Le dimensioni dei token utilizzano il tokenizer legacy pubblico di Anthropic × 1,30; durante la misurazione, Claude Code ha caricato il 21-26% in più rispetto a tale stima, quindi le cifre in dollari risultano sottostimate. Le percentuali sono rapporti e restano valide. I pattern di sessione e la condivisione della cache sono assunzioni.

• Non è documentato se l'utilizzo della chat su Enterprise riceva i prezzi della cache API e se le cache siano condivise tra gli utenti su claude.ai. Cowork esegue le sue sessioni su Claude Code, e gli hook dei plugin vengono caricati lì, ma le pagine dei mod non elencano Cowork e io non l'ho testato; il 1° ottobre l'app desktop includeva ancora Claude Code 2.1.286, una versione precedente all'attivazione dei mod. La policy gestita di un dispositivo raggiunge le sessioni Cowork sulla macchina dell'utente, a meno che l'organizzazione non le esegua in una sandbox VM completa. Due pagine si contraddicono sul fatto che i file ~/.claude personali raggiungano Cowork, quindi questo articolo non prende posizione in merito. Non ho nemmeno verificato se i file CLAUDE.md nelle cartelle superiori vengano caricati in una sessione Cowork; in tal caso, l'albero montato dell'implementazione di riferimento raggiungerebbe Cowork sulla macchina dell'utente già oggi. Su Pro e Max questa finestra si restringe il 6 ottobre 2026, quando i nuovi task Cowork passeranno al cloud.

• Le motivazioni sono dedotte. Anthropic non ha spiegato pubblicamente perché la chat di Claude e Cowork abbiano una struttura piatta.

• Il codice e i dati grezzi non sono pubblicati insieme a questo articolo. Un lettore non può riprodurre le misurazioni basandosi solo sull'articolo; il video mostra l'app in funzione, non come è costruita.

• L'implementazione di riferimento gira su un'azienda inventata. Non è integrata con claude.ai o Cowork, e "acting as" è un interruttore demo, non un accesso. I permessi sono applicati dalle liste degli strumenti di Claude Code, non dall'app. L'isolamento disattiva gli hook e i mod personali per quell'esecuzione; i mod integrati in Claude Code continuano a funzionare e i nomi degli agenti personali possono comunque comparire nel contesto. L'app dipende dal caricamento di CLAUDE.md da parte di claude -p, che secondo Anthropic non sarà più il comportamento predefinito. La perdita di dati dai file personali e il risultato di --setting-sources sono stati testati su Windows; le misurazioni e il test dei mod sono stati eseguiti su Linux.

Fonti

• Anthropic, Impostare le istruzioni dell'organizzazione

• Anthropic, Ruoli e autorizzazioni

• Anthropic, Cos'è il piano Team? · Piani e prezzi

• Anthropic, Gestire i ruoli personalizzati nei piani Enterprise

• Anthropic, Organizzare i task con i progetti in Claude Cowork

• Anthropic, Utilizzare i connettori di Google Workspace

• Anthropic, Gestire i gruppi e i limiti di spesa dei gruppi nei piani Enterprise

• Anthropic, Cosa sono i progetti? (nuova versione dei progetti, beta)

• Anthropic, Iniziare a usare Claude Cowork(istruzioni globali e per cartella)

• Anthropic, Come Claude ricorda il tuo progetto (CLAUDE.md) · Tutte le impostazioni (claudeMdExcludes, disableAllHooks)

• Anthropic, Personalizzare Claude Code con i mod (1° ottobre 2026) · Panoramica dei mod · Gestire i mod per la tua organizzazione · Reagire agli eventi con un mod · Riferimento sui mod

• Anthropic, Claude Tag: Cos'è Claude Tag? · Configurare l'accesso per canale · Personalizzare Claude Tag · Come funziona l'identità dell'agente · Audit · Impostare un limite di spesa

• Anthropic, Progetti in Claude Code (beta dei nuovi progetti) · Progetti in Cowork · Come Claude Code utilizza la cache dei prompt · Eseguire Claude Code a livello programmatico (--bare) · Estendere Claude Code · Gestire visibilità e condivisione dei progetti · Utilizzare i connettori · Autorizzare i connettori MCP per l'intera organizzazione · Fornire e gestire le competenze

• Anthropic, Configurare le impostazioni gestite dal server (nessuna configurazione per gruppo) · Gestire i plugin per la tua organizzazione (disponibilità dei plugin per gruppo su Enterprise) · Supporto alle funzionalità dei plugin sulle diverse piattaforme (gli hook vengono ignorati nella chat e caricati in Cowork) · Distribuire le impostazioni gestite (Cowork esegue le sue sessioni su Claude Code)

• Anthropic, Prezzi (tariffe di Sonnet 5.5, nota sul tokenizer) · Cache dei prompt (cache isolate per organizzazione e per workspace sulle API)

• Anthropic, @anthropic-ai/tokenizer(tokenizer pubblico utilizzato per i conteggi)

• Microsoft, Gruppi di gestione · Progettazione dei gruppi di gestione della landing zone

• AWS, Valutazione delle SCP · Google Cloud, Valutazione della gerarchia

• Microsoft, Elaborazione dei Criteri di gruppo · Autorizzazioni granulari di SharePoint

• FinOps Foundation, Token economics

• Jaroslawicz et al., Quante istruzioni possono seguire contemporaneamente gli LLM? (IFScale)

• Firefly, Ricerca State of IaC 2026

• MCP, Specifica di autorizzazione, versione 2026-07-28

• GitHub, issue di 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)

• Implementazione di riferimento e dati: l'app Worktree, i suoi test, lo script di misurazione, entrambi i batch di risultati e tutte le risposte sono conservati dall'autore e disponibili su richiesta.