Stafford Beer e il Viable System Model

Ogni organizzazione che sopravvive da sola nel suo ambiente possiede, che lo sappia o no, cinque funzioni cibernetiche. Il Viable System Model le nomina, e diventa una lente per leggere le aziende, gli Stati e i sistemi di agenti.

Perché questo capitolo

Un sistema multi-agente esegue benissimo il task per cui è stato scritto. Poi l’ambiente cambia — l’API che chiamava si aggiorna, il formato dei dati si sposta, l’obiettivo dell’utente si raffina — e il sistema continua a eseguire benissimo il task vecchio. Ottimizza un piano che non serve più. Non è rotto: è cieco al futuro. Gli manca una funzione.

C’è un vocabolario per dire esattamente quale funzione gli manca, e non viene dall’ingegneria del software. Viene dal management cybernetics di Stafford Beer, teorico britannico della cibernetica gestionale (1926-2002), che negli anni Sessanta e Settanta si pose una domanda diversa da quella dell’organigramma.

Non “come è disegnata l’azienda”, ma “che cosa deve necessariamente fare un sistema per restare in piedi nel suo ambiente”. La risposta è il Viable System Model: cinque sottosistemi funzionali che ogni organizzazione capace di sopravvivere autonomamente possiede, pena il collasso.

Per chi costruisce sistemi di agenti, il VSM non è folklore manageriale. È una checklist diagnostica. Dato un sistema che si comporta male, quale dei cinque ruoli è mancante o atrofico?

Chi coordina gli agenti che oscillano? Chi guarda al futuro mentre gli altri ottimizzano il presente? Chi tiene insieme l’identità del sistema? Il VSM dà un nome a domande che altrimenti restano vaghe, e una struttura — la ricorsività — che descrive quasi alla lettera il pattern di un agente che orchestra sotto-agenti.

C’è anche una ragione di onestà intellettuale per studiarlo. Il VSM è una delle idee più suggestive della cibernetica organizzativa, e per questo è anche una delle più facili da usare male. Trasportato sui sistemi di AI senza cautela, diventa una tassonomia che si appiccica a tutto e non spiega niente. Studiarlo bene significa anche imparare dove finisce la sua validità: è una lente, potente finché la si tratta da lente, ingannevole appena la si scambia per una legge di natura.

Contesto

Il management classico di metà Novecento descrive l’organizzazione con l’organigramma: caselle collegate da linee di comando. Quel disegno risponde a una sola domanda, “chi riporta a chi”, e tace su tutto il resto. Non dice come l’azienda si coordina internamente, come assorbe le sorprese dell’ambiente, come decide se cambiare.

Beer parte da un’insoddisfazione verso questo disegno e da una formazione diversa: lavora nella siderurgia britannica (United Steel) e nella consulenza di operational research, la disciplina che applica metodi quantitativi alle decisioni gestionali, prima di sistematizzare il modello.

Beer appartiene alla tradizione cibernetica britannica del dopoguerra, quella di W. Ross Ashby — psichiatra e pioniere della cibernetica, autore della legge della varietà necessaria — e di Gordon Pask, e ne eredita il vocabolario: feedback, varietà, informazione, regolazione. Il Viable System Model è cibernetica spostata dal laboratorio al management.

Il modello compare in tre libri che ne formano la trilogia: Brain of the Firm (1972), che fonda il modello derivandolo per analogia col sistema nervoso; The Heart of Enterprise (1979), che lo rideriva una seconda volta partendo direttamente dalla varietà di Ashby; e Diagnosing the System for Organizations (1985), manuale per applicarlo a un’azienda reale.

Il termine chiave del modello è viabile. Un sistema viabile è un sistema capace di mantenere un’esistenza separata, di sopravvivere autonomamente nel suo ambiente nonostante le perturbazioni — interne ed esterne, attese e impreviste. Non “efficiente”, non “ben organizzato”: vivo nel senso di capace di continuare a esistere. La tesi di Beer è che la viabilità non è un caso fortunato. Ha una struttura precisa, e quella struttura ha cinque parti.

Il VSM di Beer è la cibernetica di prima generazione — quella nata dalle Macy Conferences, gli incontri interdisciplinari che tra il 1946 e il 1953 misero allo stesso tavolo matematici, neurologi e ingegneri — portata fino alla sua conclusione più ambiziosa.

Non descrivere come un termostato regola una stanza, ma come un’organizzazione intera regola sé stessa: Beer prende il vocabolario del feedback e della varietà e lo spinge fino al livello del management e dello Stato. È, nell’ordine di questa Parte, il punto in cui la cibernetica smette di parlare di dispositivi e comincia a parlare di istituzioni.

Questo capitolo arriva dopo la legge della varietà necessaria, e non a caso. Il VSM è, come vedremo, in buona parte ingegneria della varietà: chi conosce la legge di Ashby ha già metà del modello in mano. Se la frase “solo la varietà può assorbire la varietà” non dice ancora niente, conviene partire da La legge della varietà necessaria.

Vale la pena fissare il personaggio, perché il VSM non si capisce del tutto senza di lui. Anthony Stafford Beer non è un accademico. È un consulente, un uomo d’industria, e una figura per molti versi eccentrica: lavora come dirigente nella siderurgia, fonda una società di consulenza in operational research, e negli ultimi anni della sua vita si ritira in una casa quasi senza elettricità nel Galles, dedicandosi alla pittura e alla poesia tanto quanto alla teoria.

Questa biografia conta perché spiega un tratto del modello: il VSM nasce dentro le aziende, da chi le gestiva, non dentro un dipartimento universitario. È cibernetica con le mani sporche, costruita per essere usata da chi deve decidere lunedì mattina, non per essere dimostrata. Lo si vede nel suo lessico, mezzo matematico e mezzo organizzativo, e nella sua trilogia di libri, scritti per i manager prima che per gli studiosi.

Il momento storico aggiunge un secondo strato. Gli anni in cui il modello matura — fine anni Cinquanta, anni Sessanta e Settanta — sono gli stessi in cui la cibernetica di prima generazione perde terreno nel mondo accademico, mentre l’intelligenza artificiale simbolica, quella delle regole e della logica, conquista i finanziamenti e l’attenzione.

Il VSM è, in parte, la cibernetica che cerca un nuovo territorio: scende dal laboratorio al consiglio di amministrazione per restare viva. Non è un dettaglio ironico. È il motivo per cui un’intera tradizione di pensiero sul feedback e sul controllo è sopravvissuta fuori dall’AI per poi tornarle utile decenni dopo, quando i sistemi di agenti hanno reso di nuovo urgente la domanda su come un insieme di parti possa governarsi.

L’intuizione

Primo angolo: l’organismo che sopravvive

Beer arriva al modello per un’analogia esplicita, e quell’analogia resta il modo più rapido per afferrarlo. Brain of the Firm costruisce i cinque sistemi mappandoli sul sistema nervoso umano.

Va marcata subito la classe dell’affermazione: per Beer questa non è una metafora decorativa, è un’analogia strutturale forte, usata come euristica per derivare il modello. Non è una filiazione — l’azienda non discende dal cervello — e non è un teorema. È l’idea che lo stesso schema cibernetico si presenti in due substrati diversi, e che studiarlo nel corpo aiuti a vederlo nell’organizzazione.

Guarda un corpo che sopravvive. Ha organi che fanno il lavoro: i muscoli che muovono, il fegato che metabolizza, i polmoni che ossigenano. Sono le unità operative, quelle che realizzano la trasformazione per cui il corpo esiste.

Ma gli organi, lasciati a sé, si pesterebbero i piedi: il battito cardiaco e il ritmo respiratorio devono stare in fase, non contendersi le stesse risorse nello stesso istante. Serve uno strato che smorza queste collisioni, e nel corpo lo fanno i riflessi spinali e i ritmi autonomi.

Sopra c’è il sistema nervoso autonomo, che regola l’interno momento per momento: pressione, glicemia, temperatura. È il management del qui-e-ora del corpo, e include i propriocettori — sensori che misurano direttamente lo stato di un muscolo, senza fidarsi solo dei segnali che arrivano per la via principale.

Poi c’è il cervello che guarda fuori e anticipa: vedere il predatore prima che attacchi, scegliere dove andare a cercare cibo domani. E infine una funzione di livello più alto che decide chi sei — cosa conta, quali valori, e come arbitrare tra il riflesso immediato (“mangia ora”) e il piano (“conserva per l’inverno”).

Cinque livelli. Tolto uno qualsiasi, il corpo non diventa “meno efficiente”: diventa non-viabile. Un organismo senza il livello che guarda avanti reagisce in modo perfetto al presente e muore al primo cambiamento d’ambiente. Questa è l’intuizione di Beer: la sopravvivenza non è un singolo organo, è la presenza simultanea di cinque funzioni.

Secondo angolo: l’ingegneria della varietà

Il secondo angolo lega il VSM al resto della cibernetica e spiega perché The Heart of Enterprise riderivi il modello da zero, questa volta senza l’analogia neurale, partendo solo dalla varietà.

La varietà è il numero di stati distinti che un sistema può assumere — la misura, vista nel capitolo sulla legge della varietà necessaria, di quanto un sistema può essere diverso da sé stesso. La legge di Ashby dice che un regolatore può assorbire la varietà di ciò che governa solo se ne ha altrettanta.

Ora guarda un’organizzazione con questa lente. L’ambiente ha una varietà enorme: le cose che possono succedere a un’azienda sono innumerevoli. Le unità operative ne hanno meno. Il management ne ha ancora meno: una manciata di persone non può avere in testa tutti gli stati del mercato.

C’è uno squilibrio di varietà a ogni confine, e un sistema non governa ciò di cui non eguaglia la varietà. Il VSM, visto da qui, è un dispositivo per far quadrare i conti della varietà a ogni livello, con tre operazioni.

Attenuare: la varietà che sale va filtrata e riassunta — un’unità operativa non riversa sul management ogni dettaglio, gli manda indici sintetici. Amplificare: la varietà che scende va espansa — una direttiva di una riga si traduce in migliaia di azioni concrete sul campo. Bilanciare: ai punti di contatto, la varietà attenuata da un lato deve eguagliare quella amplificata dall’altro, o il confine diventa un collo di bottiglia o una falla.

Dove l’organigramma vede caselle e linee di comando, Beer vede flussi di varietà che devono bilanciarsi. I cinque sistemi e i canali che li collegano sono, ciascuno, un punto dove la varietà va attenuata o amplificata perché i due lati combacino.

Il VSM è in buona parte ingegneria della varietà, e questo è il motivo per cui dipende così strettamente da Ashby. Qui la classe del legame va detta con precisione: è filiazione, non analogia. Beer cita Ashby, ne applica esplicitamente la legge, costruisce il modello sopra di lui. Il VSM non somiglia alla cibernetica della varietà: ne discende.

Terzo angolo: presente contro futuro

C’è un terzo modo di entrare nel modello, e prende un solo asse di tensione invece dei cinque sistemi nel loro insieme. Ogni sistema che dura nel tempo deve fare due cose che tirano in direzioni opposte: deve funzionare bene adesso, e deve restare adatto domani. Le due cose competono per le stesse risorse — soldi, attenzione, persone, tempo di calcolo — e ogni unità spesa per una è un’unità tolta all’altra.

Funzionare bene adesso significa ottimizzare ciò che già si fa. Restare adatti domani significa, invece, mettere da parte risorse per cose che oggi non rendono niente: ricerca, esperimenti, capacità che servirà solo se l’ambiente cambia in un certo modo. Un sistema che dimentica il primo lato collassa subito per inefficienza. Un sistema che dimentica il secondo collassa più tardi, ma con una sorpresa: era diventato bravissimo a fare una cosa che il mondo non chiede più.

Questo asse — presente contro futuro, sfruttare contro esplorare — è l’ossatura del VSM. Sistema 3 è il presente, Sistema 4 è il futuro, e quasi tutto il resto del modello esiste per tenere insieme questi due senza che uno schiacci l’altro. Chi tiene a mente solo questo terzo angolo ha già il nocciolo: i cinque sistemi sono l’apparato che permette a un’organizzazione di non sacrificare il domani all’oggi né l’oggi al domani.

I tre angoli non sono in competizione: dicono la stessa cosa da tre lati. L’organismo dà l’immagine concreta — cinque livelli che un corpo vivo possiede. L’ingegneria della varietà dà il fondamento formale — perché quei livelli servono, in termini di conti che devono quadrare. L’asse presente-futuro dà la tensione centrale — il conflitto che il modello esiste per gestire. Chi entra nel VSM da uno qualsiasi dei tre e poi recupera gli altri due ha il modello completo; chi ne tiene uno solo ne ha una caricatura.

La meccanica

I cinque sistemi

Il modello descrive ogni organizzazione viabile come cinque sistemi che interagiscono — e qui sta il primo punto da fissare: non sono cinque reparti né cinque persone, sono cinque funzioni. In una piccola azienda la stessa persona può svolgerne tre in ore diverse della giornata. Il VSM afferma che le funzioni devono esserci, non che servano cinque caselle distinte.

I numeri da 1 a 5 non sono un ordine gerarchico nel senso del comando — non è che Sistema 5 “comanda” Sistema 1. Sono piuttosto un ordine di astrazione e di orizzonte temporale: Sistema 1 è il più concreto e il più immediato, attaccato al lavoro e al presente; salendo di numero ci si allontana dall’azione diretta e ci si avvicina al lungo termine e all’identità. Tenere a mente questa scala — dal concreto-immediato all’astratto-duraturo — aiuta a non confondere il VSM con l’organigramma, dove invece i livelli alti comandano i bassi.

Sistema 1 — Operazioni. Le unità che fanno il lavoro primario, quelle che realizzano la trasformazione per cui l’organizzazione esiste: produrre, vendere, curare, erogare. Sono le uniche parti del sistema che toccano direttamente l’ambiente operativo. Il punto cruciale, che torna nella sezione sulla ricorsività: ogni unità di Sistema 1 è essa stessa un sistema viabile completo, con i propri cinque sistemi interni.

Sistema 2 — Coordinamento. Lo strato anti-oscillazione. Le unità di Sistema 1, se lasciate da sole, entrano in conflitto sulle risorse condivise e oscillano: due reparti che si contendono lo stesso magazzino, due turni che si rimpallano un macchinario. Sistema 2 smorza queste oscillazioni con scheduling, standard condivisi, calendari, protocolli. La sua natura cibernetica è importante: Sistema 2 non comanda, armonizza. Non dice a un’unità cosa produrre; le impedisce di collidere con un’altra. È uno smorzatore, come quelli visti nel capitolo su overshoot, ritardo, oscillazioni: toglie energia all’oscillazione invece di aggiungere un comando.

Sistema 3 — Controllo interno. L’ottimizzazione del qui-e-ora. Sistema 3 guarda l’insieme delle unità di Sistema 1 dall’alto, alloca risorse tra loro, negozia obiettivi, cerca le sinergie — “an explosion of potential”, la chiama Beer, il di più che nasce dal far cooperare unità che da sole renderebbero meno. È il dentro-e-adesso del management: dato ciò che l’organizzazione già fa, farlo bene.

Sistema 3 ha un canale accessorio che merita un nome proprio, il Sistema 3* (three-star). È un canale di audit sporadico: ogni tanto, irregolarmente, Sistema 3 bypassa la linea di comando ufficiale e va a misurare direttamente lo stato di un’unità di Sistema 1.

La ragione è cibernetica. Il canale ufficiale che porta informazioni da Sistema 1 a Sistema 3 attenua la varietà — riassume, filtra, e nel filtrare può nascondere. Sistema 3* è il rimedio: un secondo canale, stretto e occasionale, che non passa per la sintesi. Sono i propriocettori dell’organizzazione, il modo in cui il controllo verifica che i report che riceve corrispondano alla realtà.

Sistema 4 — Intelligence e adattamento. Mentre Sistema 3 ottimizza il presente noto, Sistema 4 guarda fuori e avanti: l’ambiente futuro, le minacce che non sono ancora arrivate, le opportunità che non esistono ancora. Fa ricerca, costruisce modelli, simula scenari, propone piani.

È la funzione che prepara il sistema a un futuro che il presente non contiene. Un’organizzazione senza Sistema 4 è quella dell’apertura di questo capitolo: esegue benissimo, e ottimizza un piano che il mondo ha già reso obsoleto. La differenza tra Sistema 3 e Sistema 4 è la differenza tra “dato ciò che facciamo, facciamolo meglio” e “ciò che facciamo è ancora la cosa giusta da fare?”.

Sistema 5 — Policy e identità. Stabilisce identità, valori, scopo: chi è l’organizzazione, cosa conta, quali sono le sue regole non scritte. Beer è preciso su come Sistema 5 lo fa: “Rules come from System 5: not so much by stating them firmly, as by creating a corporate ethos — an atmosphere” — le regole vengono dal Sistema 5 non tanto enunciandole con fermezza, quanto creando un ethos, un’atmosfera.

Ma la sua funzione cibernetica più precisa è un’altra, ed è il cuore del modello: Sistema 5 arbitra la tensione tra Sistema 3 e Sistema 4. Non fa né operazioni né strategia; fa l’unica cosa che né Sistema 3 né Sistema 4, presi da soli, possono fare — decidere quanto peso dare a ciascuno dei due.

L’omeostato Sistema 3 – Sistema 4

Il cuore dinamico del VSM è la coppia Sistema 3 – Sistema 4, e Beer la chiama omeostato: una coppia di parti accoppiate in feedback reciproco, che si regolano a vicenda. Le due spinte sono in tensione strutturale, non per cattiva volontà di nessuno.

Sistema 3 spinge per ottimizzare ciò che già si fa: efficienza, sfruttamento delle risorse note, miglioramento del processo esistente. Sistema 4 spinge per cambiare in vista del futuro: ricerca, scenari, investimenti che oggi non rendono nulla.

Lasciate a sé, le due spinte divergono. Se Sistema 3 domina, l’organizzazione ottimizza sé stessa fino a diventare obsoleta — diventa sempre più brava a fare ciò che il mondo non vuole più. Se Sistema 4 domina, insegue ogni novità e non consolida mai niente, brillante e fallimentare.

Il termine “omeostato” non è scelto a caso. Richiama l’Homeostat di Ashby — il dispositivo che, descritto nel capitolo su Ashby, omeostato e adattamento, trova da sé un equilibrio tra forze opposte. Beer prende quell’idea e la usa al livello dell’organizzazione: Sistema 3 e Sistema 4 sono due forze che si tirano, e l’equilibrio non è un punto fisso ma uno stato che va continuamente ritrovato man mano che l’ambiente cambia.

Sistema 5 è l’arbitro di questo omeostato. Non fa operazioni, non fa strategia: monitora l’equilibrio tra Sistema 3 e Sistema 4 e interviene quando pende troppo da un lato. In una riga: Sistema 3 contro Sistema 4 è il trade-off tra sfruttare e esplorare, sollevato dal livello della singola decisione a quello dell’intera organizzazione, e Sistema 5 è la funzione che lo regola.

I canali e il segnale algedonico

I sistemi sono collegati da canali informativi, e Beer impone su di essi vincoli precisi, formulati in The Heart of Enterprise come assiomi. Due contano anche in una trattazione introduttiva.

Primo: ogni canale deve poter trasportare più varietà di quella che la sorgente genera nel tempo di transito, altrimenti il canale satura e l’informazione si accumula non trasmessa. Secondo: ogni traversata di un confine — Beer la chiama trasduzione, il passaggio di un segnale da un sistema a un altro che parla un linguaggio diverso — deve preservare la varietà, altrimenti l’informazione si degrada al passaggio. Sono vincoli aritmetici sui flussi, non buone pratiche da appendere al muro.

Un canale ha un nome e una funzione speciali: il segnale algedonico. Il termine viene dal greco algos, dolore, e hedos, piacere. È un allarme che salta tutta la gerarchia e arriva dritto a Sistema 5 quando la performance reale devia in modo grave dalla capacità attesa.

Tutti gli altri canali rispettano i livelli: Sistema 1 parla a Sistema 3 attraverso Sistema 2, Sistema 3 parla a Sistema 5 attraverso Sistema 4. Il segnale algedonico no: è un canale fuori-banda, e la sua ragione d’essere è il tempo. Se qualcosa va davvero male in un’unità operativa, aspettare che il problema risalga livello per livello significa scoprirlo troppo tardi. Il dolore non aspetta il prossimo report mensile.

Attenuatori e amplificatori: un conto concreto

Conviene rendere meno astratto il discorso sulla varietà, perché è qui che il modello smette di essere una metafora e diventa un conto. Prendi il confine tra un’unità di Sistema 1 e il Sistema 3 che la sorveglia.

Non serve un numero esatto: serve l’ordine di grandezza, e il punto è proprio che gli ordini di grandezza, ai due lati di un confine, raramente coincidono da soli.

L’unità operativa, giorno per giorno, può trovarsi in un numero enorme di stati distinti: combinazioni di ordini ricevuti, guasti, ritardi, livelli di scorta, umore della squadra. Diciamo, per fissare un ordine di grandezza, che la varietà di ciò che succede in quell’unità sia nell’ordine di migliaia di stati distinguibili al giorno.

Il Sistema 3, dall’altro lato, è una persona o un piccolo gruppo: può tenere in testa, e agire su, forse qualche decina di situazioni distinte. C’è uno squilibrio di tre ordini di grandezza, e la legge di Ashby dice che quello squilibrio non si può ignorare: o lo si chiude, o la regolazione fallisce nella misura della differenza.

Il VSM lo chiude in due modi, uno per direzione. Verso l’alto, un attenuatore comprime: l’unità non manda a Sistema 3 i suoi mille stati, ne manda una manciata di indici sintetici — produzione del giorno, scostamento dalla norma, un paio di allarmi. La varietà che sale viene tagliata di proposito.

Verso il basso, un amplificatore espande: una decisione di Sistema 3 — “riducete del dieci per cento” — non è un singolo bit, viene espansa dall’unità in centinaia di micro-azioni concrete che ne realizzano il senso. La varietà che scende viene moltiplicata, di proposito.

Il punto cibernetico è che attenuatore e amplificatore vanno progettati, non lasciati al caso. Un attenuatore mal fatto butta via proprio l’informazione che serviva: comprime mille stati in tre indici che non distinguono il guasto grave dal rumore. Un amplificatore mal fatto trasforma una direttiva sensata in mille azioni incoerenti.

La maggior parte dei fallimenti di regolazione, dice il VSM, non è nei sistemi: è nei trasduttori tra i sistemi, nei punti dove la varietà attraversa un confine e qualcuno ha scelto male cosa tenere e cosa scartare. Il segnale algedonico, da questo punto di vista, è un attenuatore speciale: lascia passare quasi tutto sotto silenzio e fa scattare un solo bit — “dolore” — quando la deviazione supera una soglia.

Questo spostamento dell’attenzione, dai sistemi ai canali tra i sistemi, è uno dei contributi più pratici del modello. L’organigramma classico disegna le caselle con cura e tratta le linee tra loro come dettagli ovvi. Il VSM fa il contrario: assume che le caselle, prese una a una, siano sane, e va a cercare il guasto nei collegamenti.

Per chi progetta un sistema di agenti, l’indicazione è diretta. Il punto fragile non è quasi mai il singolo agente — un modello capace fa il suo lavoro. Il punto fragile è cosa passa tra un agente e l’altro: quanto del contesto sopravvive al passaggio, cosa viene riassunto e cosa perso, se l’orchestratore riceve abbastanza informazione per decidere o solo un resoconto levigato. I trasduttori, in agent coding, sono i prompt di hand-off e i formati di scambio, e sono esattamente dove va guardato per primo.

La ricorsività

La proprietà più caratteristica del VSM, e quella che lo rende interessante per chi pensa sistemi di agenti, è la ricorsività. È già stata anticipata parlando di Sistema 1, ora va guardata in faccia.

Ogni Sistema 1 è a sua volta un sistema viabile completo, con i propri cinque sistemi interni. E l’organizzazione intera, presa come un tutto, è un Sistema 1 di un sistema viabile più grande che la contiene. Beer lo formula come recursive system theorem: in una struttura organizzativa ricorsiva, ogni sistema viabile contiene, ed è contenuto in, un sistema viabile, descritto dallo stesso identico schema cibernetico.

Una squadra dentro un reparto dentro una divisione dentro un’azienda dentro un settore industriale: a ogni livello dell’annidamento, gli stessi cinque sistemi. La struttura è frattale, autosimile — zoom su qualunque parte e ritrovi la forma del tutto. Beer sosteneva che il modello si applica con gli stessi principi a ogni scala, dal gruppo di lavoro allo Stato nazionale.

Da questa proprietà discendono due conseguenze concrete. La prima: lo stesso strumento diagnostico vale a ogni livello. Le domande “chi fa Sistema 4 qui? chi arbitra Sistema 3 e Sistema 4?” si pongono identiche per una squadra e per una multinazionale.

La seconda è più profonda: l’autonomia è incassata per costruzione. Ogni unità operativa, essendo un sistema viabile a tutti gli effetti, ha il diritto cibernetico di gestire il proprio dentro-e-adesso — non è un esecutore passivo, è un sistema che si autoregola. L’autonomia non è una concessione che il livello superiore fa con benevolenza, è una proprietà strutturale del modello.

Il solo limite a quell’autonomia è la coesione del tutto: tanta autonomia quanta ne è compatibile con la viabilità del livello che la contiene. È questo che separa il VSM da una gerarchia di comando — su cui torneremo nella sezione “Dove si rompe”, perché è anche il punto su cui il modello viene più frainteso.

Conviene rendere concreta questa idea, perché è la più scivolosa del capitolo. Prendi un agente orchestratore che spawna tre sotto-agenti per tre parti di un compito. Per il VSM, l’orchestratore è un sistema viabile, e i tre sotto-agenti sono il suo Sistema 1.

Ma ciascuno dei tre, se deve gestire un compito non banale, è a sua volta un sistema viabile: ha bisogno di un proprio Sistema 3 — qualcosa che alloca il suo budget interno — e idealmente di un proprio Sistema 4 — qualcosa che si accorge se il suo pezzo di compito è cambiato.

La domanda diagnostica che la ricorsività impone è esattamente questa: a quale livello dell’annidamento la struttura a cinque sistemi smette di essere replicata? Spesso la risposta è “subito sotto la radice”.

L’orchestratore è ben fatto; i sotto-agenti sono esecutori puri, senza Sistema 4, e quando l’ambiente locale di uno di loro cambia, nessuno se ne accorge finché il danno non risale. Il recursive system theorem non garantisce che la replicazione avvenga: dice solo che, se non avviene, il livello dove si interrompe è il livello dove la viabilità si assottiglia.

Conviene aggiungere una precisazione, perché la ricorsività si presta a un eccesso opposto. Non ogni sotto-agente deve essere un sistema viabile pieno. Un sotto-agente a cui si chiede un compito chiuso e breve — formatta questo file, esegui questo test — non ha bisogno di un Sistema 4: il suo ambiente non cambierà durante l’esecuzione. La regola di Beer non è “replica i cinque sistemi a ogni livello a tutti i costi”, è “replica i cinque sistemi a ogni livello che deve essere viabile, cioè sopravvivere autonomamente a un ambiente che cambia”. Un esecutore di un compito atomico non deve sopravvivere a niente: deve solo finire. La ricorsività si applica dove c’è viabilità da garantire, non dappertutto per simmetria.

Cosa succede quando un sistema manca

Il modo più rapido per capire perché servono tutti e cinque i sistemi è chiedersi, per ciascuno, cosa accade se è assente o atrofico. Il VSM non è una lista di buone funzioni: è la tesi che la mancanza di una qualsiasi di esse rompe la viabilità in un modo riconoscibile.

Senza Sistema 1, non c’è organizzazione: non sta facendo niente. È il caso banale. Senza Sistema 2, le unità operative oscillano: si contendono le risorse, si rimpallano il lavoro, e l’energia del sistema si consuma in attriti interni invece che in produzione. Il sintomo è il caos di basso livello, lo spreco che nessun comando dall’alto riesce a fermare perché il problema è laterale, fra pari.

Senza Sistema 3, le unità operative vanno ciascuna per conto proprio: ottimizzano localmente, e la somma è incoerente. Manca chi vede l’insieme e cerca la sinergia. Senza Sistema 3*, Sistema 3 governa alla cieca: agisce solo sui report che gli arrivano per il canale ufficiale, e quando quei report sono ottimistici o filtrati, il controllo scopre i problemi quando sono già gravi.

Senza Sistema 4 — il caso dell’apertura di questo capitolo — l’organizzazione è cieca al futuro: esegue bene, e ottimizza un piano che il mondo ha reso obsoleto. È il fallimento lento, quello che non si vede finché non è tardi. Senza Sistema 5, infine, manca l’arbitro: Sistema 3 e Sistema 4 tirano in direzioni opposte senza che nessuno componga la tensione, e l’organizzazione o si paralizza nel conflitto o lascia che il più rumoroso dei due vinca sempre.

Cinque modi distinti di non essere viabili. È questa la forma della tesi di Beer: non “questi cinque ruoli aiutano”, ma “togline uno e il sistema fallisce in un modo che si può prevedere”.

La forza diagnostica del modello sta tutta qui: a ciascun sintomo corrisponde un sistema mancante, e a ciascun sistema mancante corrisponde un rimedio. È una mappa dal guasto osservato alla funzione assente.

Vale la pena notare la struttura temporale di questi fallimenti, perché è informativa. La mancanza di Sistema 1 o di Sistema 2 si vede subito: il sistema o non fa niente o si impantana in attriti. La mancanza di Sistema 3 o di Sistema 3* si vede a medio termine: l’incoerenza tra le unità o i problemi nascosti dai report ci mettono un po’ a emergere. La mancanza di Sistema 4 e di Sistema 5 si vede tardi, a volte troppo tardi: un’organizzazione senza occhi sul futuro e senza un arbitro può funzionare bene per anni, e poi fallire di colpo.

Questa scala temporale è una guida pratica. I buchi che fanno più male sono i meno visibili, perché non danno sintomi finché il danno non è grande. Un sistema di agenti che gira bene oggi non è per questo viabile: potrebbe semplicemente non aver ancora incontrato il cambiamento d’ambiente che il suo Sistema 4 mancante non saprà gestire.

Esempi

Esempio 1: una catena di librerie

Un’organizzazione concreta, mappata sui cinque sistemi. Una catena con dieci librerie cittadine.

Sistema 1 sono le dieci librerie: ciascuna vende libri, e ciascuna è un sistema viabile — ha un suo direttore, un suo modo di gestire gli scaffali, un suo rapporto col quartiere.

Sistema 2 è ciò che impedisce alle dieci di pestarsi i piedi: il sistema gestionale condiviso che evita che due negozi ordinino l’intero stock di un titolo lasciando gli altri otto a secco, il calendario comune delle promozioni.

Sistema 3 è la direzione operativa: alloca il budget tra le dieci librerie, sposta personale dove serve, confronta le performance per trovare sinergie. Il suo canale Sistema 3* è l’ispettore che ogni tanto entra in un negozio senza preavviso e guarda gli scaffali con i propri occhi, invece di leggere il report del direttore.

Sistema 4 è la funzione che chiede: i lettori compreranno ancora libri di carta tra cinque anni? Conviene aprire un canale online? Cosa fanno i concorrenti? Sistema 4 non gestisce nessun negozio: studia un futuro in cui i negozi attuali potrebbero non bastare.

Sistema 5 è la funzione che decide se questa catena è “la libreria di quartiere che resiste” o “un retailer che massimizza il margine” — e quando Sistema 3 chiede di tagliare i tre negozi meno redditizi mentre Sistema 4 chiede di investirci sopra trasformandoli, è Sistema 5 ad arbitrare. Una catena dove nessuno fa davvero Sistema 4 sopravvive finché il mercato non si muove, e poi non capisce perché sta affondando.

Esempio 2: l’omeostato in numeri

Un esempio volutamente numerico, per togliere all’omeostato Sistema 3 – Sistema 4 ogni vaghezza. La catena di librerie ha un budget annuale di cento unità da ripartire tra due voci: il presente — rifornire gli scaffali, pagare il personale, tenere aperti i negozi che già rendono — e il futuro — l’esperimento del canale online, la ricerca su cosa vorranno i lettori.

Sistema 3, lasciato solo, propone una ripartizione di 100 a 0: ogni unità spesa nel presente rende subito, ogni unità spesa nel futuro è un costo certo contro un ricavo incerto. La sua logica, presa in isolamento, è impeccabile. Sistema 4, lasciato solo, propone l’opposto: 40 al futuro, perché vede che fra cinque anni i negozi attuali renderanno la metà. Anche la sua logica, in isolamento, regge.

Le due proposte non si possono entrambe realizzare: la somma fa 140, e il budget è 100. Qui entra Sistema 5. Non calcola la ripartizione “giusta” — non esiste una ripartizione giusta in astratto. Sceglie in base all’identità: se la catena vuole durare dieci anni, una ripartizione tipo 80 a 20 tiene in vita il presente senza ipotecare il futuro; se vuole massimizzare il profitto del prossimo trimestre, sceglie 100 a 0 e accetta di scommettere che il mercato non si muova.

Il numero esatto conta meno della struttura. L’omeostato è il punto del modello dove due logiche localmente corrette confliggono, e dove serve un terzo livello che decida — non con un calcolo, ma con un valore. È esattamente la forma del trade-off tra sfruttare ed esplorare, e il valore di Sistema 5 è ciò che, in un sistema di agenti, corrisponde a una policy esplicita sul budget di esplorazione.

C’è un corollario che vale la pena estrarre. Quando un’organizzazione — o un sistema di agenti — non ha un Sistema 5 esplicito, la ripartizione tra presente e futuro non sparisce: viene decisa comunque, ma di default. E il default ha quasi sempre la stessa direzione: vince Sistema 3, vince il presente, perché il presente ha ricavi immediati da mostrare e il futuro no. Un sistema senza arbitro non sta in equilibrio: scivola verso l’ottimizzazione del breve termine, lentamente, finché il mondo non lo coglie impreparato. Rendere Sistema 5 esplicito non è eleganza architetturale: è l’unico modo di evitare che quel default decida al posto tuo.

Esempio 3: Cybersyn, il VSM cablato in un Paese

Il caso storico più affascinante non è un’azienda: è uno Stato. Nel luglio 1971 Fernando Flores, giovane funzionario della CORFO — l’agenzia statale cilena per lo sviluppo economico — sotto il governo socialista di Salvador Allende, scrive a Beer. Il Cile ha appena nazionalizzato gran parte dell’industria e si trova a doverla gestire dal centro.

Flores chiede a Beer di applicare la cibernetica gestionale all’economia nazionale. Beer arriva a Santiago il 4 novembre 1971, e nasce Project Cybersyn (in spagnolo Synco): un tentativo di gestire un’intera economia quasi in tempo reale usando il VSM come schema — lo Stato come sistema viabile, le imprese come Sistema 1.

Il progetto ebbe quattro moduli, e la mappatura sul VSM è quasi diretta.

Cybernet era una rete di telex — le telescriventi, macchine di comunicazione testuale dell’epoca — che collegava le imprese statali a un unico mainframe a Santiago. Beer riutilizzò telex già esistenti, non c’era budget per altro: era il canale informativo del modello, dati di produzione che fluivano ogni giorno invece che ogni trimestre.

Cyberstride era il software statistico che sorvegliava gli indici di produzione e lanciava un allarme quando un indicatore usciva dai limiti attesi — l’idea algedonica resa codice, con un dettaglio cibernetico raffinato: l’allarme saliva di livello solo se la deviazione persisteva, lasciando prima all’unità il tempo di auto-correggersi.

CHECO, CHilean ECOnomic simulator, era un modello di simulazione per prevedere gli effetti delle decisioni economiche: un Sistema 4 computazionale, un modo per provare una decisione prima di prenderla.

E la opsroom, la sala operativa: esagonale, sette poltrone bianche in vetroresina in cerchio, schermi che proiettavano lo stato dell’economia, braccioli con grandi pulsanti e niente tastiere — pensata perché potessero usarla anche decisori non tecnici, inclusi gli operai. La disegnò il team di Gui Bonsiepe; somigliava a un set di Star Trek, e i designer giurarono che non era voluto.

A coordinare il progetto sul campo c’era Raul Espejo, ingegnere cileno che ne fu il direttore operativo e che, negli anni successivi, sarebbe diventato uno dei principali divulgatori del VSM.

La sua presenza segnala un punto su cui Beer insisteva: Cybersyn, nelle intenzioni, non doveva essere uno strumento di controllo centralizzato dello Stato sulle fabbriche, ma un modo per dare a ciascuna fabbrica abbastanza informazione per autoregolarsi — l’autonomia di Sistema 1 incassata nella ricorsività. Quanto questa intenzione fosse realizzabile, e quanto invece il progetto rischiasse comunque di scivolare verso il controllo dall’alto, è il nodo che la sezione sulle critiche riprende.

La ricorsività del VSM è cablata dentro questa scelta progettuale. Lo Stato cileno era pensato come un sistema viabile; ciascun settore industriale come un Sistema 1 dello Stato e insieme come un sistema viabile a sé; ciascuna impresa come un Sistema 1 del proprio settore. Lo stesso schema a cinque sistemi, replicato dall’impresa singola fino al Paese intero.

La opsroom era la stanza dove Sistema 3, Sistema 4 e Sistema 5 dello Stato avrebbero dovuto incontrarsi: il presente dell’economia sugli schermi di stato, le simulazioni di CHECO come Sistema 4, le decisioni di policy come Sistema 5. Una sala dove i tre livelli alti del modello prendevano forma fisica.

La prova reale arrivò nell’ottobre 1972, con lo sciopero dei camionisti — un blocco dei trasporti che minacciava di paralizzare il Paese. Il governo usò la rete telex di Cybersyn per coordinare la logistica quasi in tempo reale e tenere in piedi i rifornimenti con circa 200 camion rimasti operativi.

Fu l’infrastruttura informativa, più che il modello completo, a dimostrare il suo valore. Il progetto finì di colpo: l’11 settembre 1973 il colpo di Stato di Pinochet rovesciò Allende, i militari abbandonarono Cybersyn e distrussero la opsroom.

Cybersyn va guardato con onestà, senza la nostalgia retrofuturista che lo circonda. Non fu un sistema maturo: alla fine solo una ventina di imprese erano state pienamente modellate e connesse alla rete. Il lavoro di mappare un processo produttivo — Beer lo chiamava quantified flowcharting — era lento, e il sistema dipendeva pesantemente dalla conoscenza pratica degli operatori di fabbrica, che andava raccolta a mano.

Cybersyn fu un prototipo profondo, interrotto prima di poter mostrare se la sua tesi reggeva. Resta, comunque, il primo tentativo serio di governare un’economia con la cibernetica in tempo quasi reale, vent’anni prima che Internet rendesse l’idea ovvia — e il caso storico che mostra il VSM applicato non a un’azienda, ma a un intero Paese.

Esempio 4: un sistema multi-agente di coding

Un esempio operativo, e qui la marcatura della classe è obbligatoria: ciò che segue è un’analogia di progettazione, non un’affermazione che i sistemi di agenti “siano” sistemi viabili nel senso di Beer. Il VSM è una lente per leggerli, non un teorema su di loro.

Un sistema di agenti che lavora su una codebase. Gli agenti che scrivono codice, eseguono test, modificano file sono il Sistema 1: fanno il lavoro primario, toccano l’ambiente — il repository.

Se due di loro modificano lo stesso file senza coordinarsi, oscillano: uno sovrascrive l’altro, e il lavoro rimbalza avanti e indietro. Ciò che lo impedisce — lock sui file, uno scheduler che serializza gli accessi, un protocollo inter-agente — è Sistema 2.

Chi alloca il budget di token e di compute tra i sotto-agenti attivi, decide quale task viene servito prima, cerca di far rendere l’insieme più della somma, è Sistema 3. E un controllo che ogni tanto ispeziona direttamente l’output di un agente invece di fidarsi del suo resoconto è Sistema 3*.

Sistema 4 è la funzione che si accorge che l’intero approccio non sta funzionando — che la strategia scelta porta in un vicolo cieco — e propone di cambiare piano: è la funzione di re-planning e di riflessione.

Sistema 5 è il livello che tiene i vincoli e l’identità del sistema — il system prompt, la lista di ciò che è permesso, i valori di base — e arbitra tra “continua a sfruttare l’approccio che sta dando risultati” e “fermati e esplora un’alternativa”.

Un sistema di agenti che si comporta male di solito ha un buco localizzabile: spesso è Sistema 4 — nessuno guarda avanti, il sistema ottimizza con cura un piano sbagliato — oppure Sistema 2, gli agenti che oscillano perché niente li coordina.

Una cosa che questa mappatura rende visibile è quanto i sistemi reali siano sbilanciati. La maggior parte dei sistemi di agenti costruiti oggi ha un Sistema 1 forte — i modelli sono capaci — e un Sistema 3 decente — gli orchestratori esistono e funzionano. Sistema 2, Sistema 3* e Sistema 4 sono invece spesso assenti o rudimentali. Il VSM, letto come bilancio, dice che lo sforzo di ingegneria è concentrato dove il modello è già forte e scarseggia dove è debole. Non perché nessuno ci pensi, ma perché senza un vocabolario per nominare quelle funzioni è facile non accorgersi che mancano.

Esempio 5: una diagnosi passo-passo

Vale la pena vedere il VSM all’opera come strumento, non solo come mappa. Prendi un sistema multi-agente reale che si comporta male, e applica i cinque sistemi come una griglia di domande, una alla volta.

Il sintomo osservato: il sistema gira a lungo, consuma molto budget, e produce un risultato che non risolve il problema.

Prima domanda, Sistema 1: gli agenti operativi fanno effettivamente il lavoro? Sì — scrivono codice, lanciano test, gli strumenti rispondono. Sistema 1 funziona. Seconda domanda, Sistema 2: gli agenti collidono? Si controlla la trace e si vede che due agenti hanno riscritto lo stesso modulo tre volte a vicenda. Primo buco trovato: manca un Sistema 2, non c’è niente che serializzi gli accessi.

Terza domanda, Sistema 3: qualcosa alloca il budget e arbitra tra gli agenti? Sì, c’è un orchestratore che distribuisce i task. Ma — quarta domanda, Sistema 3* — quell’orchestratore verifica mai direttamente l’output, o si fida solo dei resoconti degli agenti? Si scopre che si fida: ogni agente dichiara “fatto”, e l’orchestratore lo prende per buono. Secondo buco: nessun Sistema 3*, nessun audit.

Quinta domanda, Sistema 4: c’è qualcosa che, vedendo il sistema girare a vuoto, rivede l’intera strategia? No. Il sistema esegue il piano iniziale fino a esaurire il budget. Terzo buco, e il più grave: manca Sistema 4. Sesta domanda, Sistema 5: c’è una policy che impone un limite di budget e fa fermare il sistema quando lo supera senza progresso? Anche questa è assente — il sistema gira finché qualcosa, di fuori, non lo interrompe.

La diagnosi non è “il sistema è scritto male”. È precisa: mancano Sistema 2, Sistema 3*, Sistema 4 e un Sistema 5 con i denti. E ognuno dei buchi corrisponde a un intervento concreto — un lock o uno scheduler, un passo di verifica indipendente, un agente di revisione del piano, un limite di budget che fa scattare uno stop.

Questo è il VSM come si usa davvero: non per progettare da zero, ma per trasformare un malessere vago — “il sistema si comporta male” — in una lista di funzioni mancanti, ciascuna con un rimedio identificabile. La mappa non risolve i problemi, ma dice dove sono.

Applicazioni pratiche

L’uso più diretto del VSM in agent coding è diagnostico. Non “implementa i cinque sistemi”, ma: dato un sistema multi-agente che funziona male, passa i cinque ruoli come checklist e cerca quello mancante o atrofico.

C’è qualcosa che coordina gli agenti, o oscillano liberamente? C’è qualcosa che rivede il piano quando l’ambiente cambia, o il sistema esegue all’infinito una strategia superata? Chi arbitra tra sfruttare e esplorare? Spesso il malfunzionamento non è un bug in un agente, è un ruolo che nessuno ricopre. Il VSM trasforma “il sistema si comporta male” in “manca il Sistema 4”, che è una diagnosi su cui si può agire.

Il secondo uso riguarda l’osservabilità. La opsroom di Cybersyn — schermi con lo stato del sistema quasi in tempo reale, allarmi che salgono quando un indicatore esce dai limiti — è l’antenata concettuale dei dashboard di osservabilità per sistemi agentici: trace, eventi, metriche, allarmi sui budget.

Il segnale algedonico, in particolare, è un pattern di design preciso e ancora valido: un canale di alert fuori-banda che bypassa il flusso normale e arriva direttamente all’operatore umano, ma solo sopra una soglia di gravità, e con un ritardo crescente che lascia al sistema il tempo di auto-correggersi prima di disturbare una persona. È, riconoscibilmente, lo schema dell’escalation verso l’umano nei sistemi agentici moderni.

Il dettaglio del ritardo crescente merita attenzione, perché è il punto in cui Cybersyn era più raffinato di molti sistemi di alert odierni. Un allarme che scatta al primo scostamento sommerge l’operatore di falsi positivi e lo addestra a ignorarlo. Un allarme che non scatta mai è inutile. La soluzione di Beer — far salire l’allarme solo se la deviazione persiste, e dare a ogni livello il tempo di rimediare prima di passare la palla a quello sopra — è una calibrazione esplicita tra reattività e rumore. Per chi progetta l’escalation in un sistema agentico, è esattamente la decisione da prendere con cura: quanto a lungo lasciare che l’agente provi a recuperare da solo, prima di chiamare l’umano.

Il terzo uso è architetturale, e va preso con la cautela che merita un’analogia: la ricorsività del VSM descrive bene il pattern orchestrator-worker, l’agente che spawna sotto-agenti che a loro volta possono spawnarne altri.

Pensare ogni livello dell’annidamento come un sistema che dovrebbe avere le sue cinque funzioni — chi coordina i suoi figli, chi rivede il loro piano — è un modo per accorgersi di quali funzioni si stanno dimenticando man mano che si scende di livello. Spesso un orchestratore di alto livello ha un buon Sistema 4, e i sotto-agenti che spawna non ne hanno nessuno: eseguono e basta, e quando il loro pezzo di task cambia, non se ne accorgono.

C’è anche un uso che il VSM rende esplicito e che è facile trascurare: il bilanciamento Sistema 3 – Sistema 4 come scelta di progetto. Quanto compute un sistema agentico spende a sfruttare la soluzione corrente, quanto a esplorare alternative, non è un parametro da lasciare implicito. È l’omeostato del modello, e dargli un arbitro esplicito — una regola che dice quando smettere di esplorare e quando smettere di sfruttare — è progettare il Sistema 5 invece di subirlo.

Cinque domande da porre a un sistema di agenti

In concreto, il VSM si riduce a cinque domande da fare a un sistema multi-agente prima di metterlo in produzione, o quando comincia a comportarsi male. Non sono un modello da implementare: sono un controllo da eseguire.

La prima, su Sistema 1: c’è qualcosa che fa davvero il lavoro primario, e quel qualcosa tocca l’ambiente reale o solo una sua rappresentazione obsoleta? La seconda, su Sistema 2: due agenti possono interferire — sullo stesso file, sulla stessa risorsa, sullo stesso stato condiviso — e se sì, cosa lo impedisce? Se la risposta è “niente”, il sistema oscillerà sotto carico.

La terza, su Sistema 3 e Sistema 3*: c’è qualcosa che alloca le risorse tra gli agenti e ne verifica l’output in modo indipendente, o l’orchestratore si fida dei resoconti che riceve? La quarta, su Sistema 4: c’è qualcosa che, mentre il sistema gira, si chiede se il piano è ancora quello giusto? La quinta, su Sistema 5: esiste una policy esplicita — un budget, un limite, un valore — che dice quando fermarsi, e che arbitra tra continuare a sfruttare e ricominciare a esplorare?

Un sistema che risponde “sì” a tutte e cinque non è per questo un buon sistema — il VSM non garantisce la qualità. Ma un sistema che risponde “no” a una qualsiasi ha un punto di fragilità identificato, e questo è già più di quanto la maggior parte dei progetti sappia dire di sé.

Dove si rompe

Il VSM è uno strumento di pensiero potente, e proprio per questo va maneggiato sapendo dove cede. Le critiche sono di quattro tipi, tutte legittime, e nessuna lo demolisce — ma insieme delimitano con precisione dove il modello smette di valere.

Il rischio tecnocratico. La critica più frequente: il VSM si legge facilmente come un modello di controllo dall’alto, una gerarchia di comando mascherata da cibernetica. Cinque sistemi che “regolano” Sistema 1 suonano come supervisione centralizzata, e il caso Cybersyn — uno Stato che osserva la sua economia da una sala di controllo — alimenta questa lettura.

Beer rispondeva che il modello massimizza l’autonomia: ogni Sistema 1 è viabile, decide il proprio dentro-e-adesso, e Sistema 5 crea un ethos invece di impartire ordini. La replica è solida ma non chiude il dibattito. La lettura tecnocratica resta una lettura possibile del modello, e una sezione della letteratura organizzativa la sostiene. Il punto onesto è che il VSM si presta a entrambe le interpretazioni, e che quale delle due si realizzi dipende da chi lo applica.

La vaghezza applicativa. Critica più tecnica e più scomoda. Il VSM poggia interamente sulla nozione di varietà, ma Beer non mostra mai come misurare la varietà in pratica, né come operazionalizzarla in un numero. La terminologia — algedonico, trasduttore, omeostato, recursive system theorem — è ostica per chi non viene dalla cibernetica, e tiene lontani molti praticanti.

La conseguenza concreta: il modello funziona benissimo come lente diagnostica e malissimo come procedura ripetibile. Due analisti competenti possono mappare la stessa azienda sul VSM in modi diversi, e non c’è un criterio meccanico per dire chi ha ragione. È una lente, e le lenti dipendono da chi guarda.

Il dubbio sulla falsificabilità. La critica più profonda. La tesi centrale — “ogni sistema viabile ha cinque sistemi” — rischia di non essere confutabile. Se trovi un sistema che sopravvive senza Sistema 4, puoi sempre rispondere che non era davvero viabile, o che il suo Sistema 4 era nascosto da qualche parte.

Una proposizione che nessun controesempio può smentire non è un teorema empirico: è una definizione travestita da scoperta. Parte della letteratura contesta che il VSM, malgrado l’apparato matematico, sia scienza nel senso pieno. La risposta più equa è che il VSM va valutato per ciò che fa bene — costringere a porre domande precise su un’organizzazione — e non per ciò che promette di essere, una teoria predittiva e misurabile.

Il rischio della tassonomia a forza. C’è una quarta debolezza, specifica di chi usa il VSM sui sistemi di AI, e va detta a parte perché non riguarda il modello in sé ma il modo in cui viene maneggiato. Un modello che ha cinque caselle e si dichiara universale è una tentazione: si può prendere qualsiasi sistema di agenti e, con un po’ di buona volontà, infilare ogni sua parte in una delle cinque.

Quando questo accade, il VSM smette di insegnare. Diventa un’etichettatura a posteriori: “questo è Sistema 3, quello è Sistema 4”, senza che la mappatura riveli niente che non si sapesse già. La cartina di tornasole è semplice: se applicare il VSM a un sistema non ti fa scoprire una funzione mancante, non lo stai usando come lente diagnostica, lo stai usando come decorazione concettuale. Una lente che conferma sempre non sta mettendo a fuoco niente.

Da queste critiche discende l’avvertenza più importante per chi porta il VSM nei sistemi di AI, ed è una questione di classe di affermazione. Beer presenta il modello come un teorema sui sistemi viabili — biologici e organizzativi. Quando lo si trasporta sui sistemi multi-agente, quel teorema non viene con sé.

Sui sistemi di agenti il VSM è un’analogia strutturale e una lente di progettazione, niente di più: non esiste alcuna dimostrazione che un sistema multi-agente debba avere cinque sistemi per funzionare. Scrivere o pensare “il VSM dimostra che un sistema di agenti ha bisogno dei cinque sistemi” è uno scivolamento da analogia a teorema — esattamente l’errore contro cui le linee guida di questa wiki, nella sezione sulle classi di affermazione, mettono in guardia.

Il VSM è prezioso per i sistemi di agenti perché fa porre buone domande — chi fa Sistema 4? chi arbitra Sistema 3 e Sistema 4? — non perché fornisca risposte dimostrate. La differenza non è pedanteria: una lente usata come teorema porta a forzare l’architettura per farla combaciare con il modello, invece di usare il modello per scoprire cosa manca all’architettura.

Un ultimo fraintendimento, più banale ma diffuso: leggere i cinque sistemi come cinque reparti, o cinque persone, o cinque agenti distinti. Sono cinque funzioni. Possono coincidere — una persona, un processo, un singolo agente che svolge più ruoli — e quasi sempre coincidono nei sistemi piccoli.

Il VSM dice che le funzioni devono essere presenti e in equilibrio, non che vadano disegnate come cinque scatole separate. Allo stesso modo, Sistema 5 non è “il capo”: un dirigente che passa la giornata a fare ottimizzazione operativa sta facendo Sistema 3, qualunque sia il suo titolo sul biglietto da visita.

E un sistema di agenti può avere tutti e cinque i ruoli concentrati in un solo agente sufficientemente capace — il VSM non chiede di moltiplicare gli agenti, chiede di non dimenticare le funzioni.

L’eredità: cosa è rimasto

Il VSM non è diventato lo standard del management. Gli organigrammi e i framework di processo hanno vinto la battaglia della diffusione, e Beer è rimasto una figura di culto più che un classico citato nei manuali. Vale la pena chiedersi cosa, di quel lavoro, è sopravvissuto e perché.

Quello che è sopravvissuto è la struttura concettuale, non la procedura. L’idea che un sistema, per durare, debba bilanciare ottimizzazione del presente e adattamento al futuro è oggi senso comune, anche presso chi non ha mai sentito nominare Beer. La distinzione tra “exploit” ed “explore”, che in questa wiki incontri nei bandit, è la stessa tensione che il VSM colloca tra Sistema 3 e Sistema 4 — espressa in due vocabolari diversi, nati indipendentemente.

È sopravvissuta anche la ricorsività. L’idea che la stessa struttura di governo si ripeta a ogni scala — squadra, reparto, azienda — è oggi un riflesso comune di chi pensa a sistemi annidati, e ha un parente diretto nell’architettura del software, dove un modulo ben fatto ha la stessa forma di organizzazione interna a ogni livello di zoom.

C’è poi un’eredità più indiretta, ed è il modo di pensare l’osservabilità. Cybersyn anticipava, con telex e schermi a vetri, l’idea che un sistema complesso vada reso visibile in tempo quasi reale a chi lo governa, e che gli allarmi vadano filtrati per gravità invece di sommergere chi guarda. Quell’idea, oggi, è il fondamento dei dashboard di osservabilità — non per filiazione diretta, perché chi costruisce dashboard non legge Beer, ma perché lo stesso problema, posto bene, produce la stessa risposta.

È sopravvissuto, soprattutto, il valore del VSM come lente. Beer stesso lo chiamava “an insight machine”, una macchina per generare intuizioni, e questa è la chiave per usarlo bene. Non è un teorema da applicare, non è un blueprint da copiare. È un set di domande che, poste a un’organizzazione o a un sistema di agenti, fanno emergere ciò che manca. La sua forza non sta nelle risposte, sta nelle domande che costringe a non saltare.

Per chi costruisce sistemi agentici, questa è la lezione più concreta. Non “adotta il VSM”, ma: quando un sistema multi-agente si comporta male, hai un vocabolario per dire dove. Non “il sistema è rotto”, ma “manca chi guarda avanti”, “manca chi coordina”, “manca chi arbitra tra sfruttare ed esplorare”. È un avanzamento, e viene da un consulente britannico che cinquant’anni fa cercava di descrivere cosa rende un’azienda capace di sopravvivere.

C’è un ultimo motivo per cui il VSM merita di essere conosciuto da chi lavora con l’AI, e non è tecnico. Beer affrontava un problema che oggi torna sotto un’altra forma: come si governa un sistema che è troppo complesso, troppo veloce e troppo distribuito perché una mente sola lo tenga tutto in testa. La sua risposta — non un controllore unico, ma cinque funzioni distribuite e ricorsive, con canali progettati e allarmi che escalano — è una risposta che chi disegna sistemi multi-agente sta riscoprendo, spesso senza sapere che era già stata formulata. Il VSM non risolve quei problemi, ma li ha nominati bene, e nominare bene un problema è metà del lavoro.

Collegamenti

La legge della varietà necessaria — il VSM è in buona parte ingegneria della varietà: ogni canale è un punto dove la varietà va attenuata o amplificata. La legge di Ashby è il prerequisito concettuale del modello.
Wiener: comunicazione e controllo — il VSM è cibernetica applicata al management; feedback e controllo come fondamento dichiarato.
Anatomia di un anello: errore, setpoint, guadagno, ritardo — l’omeostato Sistema 3 – Sistema 4 è una coppia di anelli in feedback reciproco; il segnale algedonico è un canale di errore fuori-banda.
Overshoot, ritardo, oscillazioni, divergenza — Sistema 2 esiste per smorzare le oscillazioni tra le unità operative: è lo strato anti-oscillazione del modello.
Ashby, omeostato e adattamento — la viabilità di Beer è una forma di omeostasi organizzativa; l’omeostato del VSM porta lo stesso nome dell’Homeostat di Ashby e ne eredita l’idea.
Von Foerster: l’osservatore dentro il sistema — Beer e von Foerster appartengono alla stessa generazione cibernetica; la varietà relativa all’osservatore percorre entrambi.
Autopoiesi: i sistemi che si fanno da sé — viabilità e autopoiesi sono due modi distinti di formalizzare “un sistema che si mantiene”: il confronto chiarisce entrambi.
multi-agent (in preparazione) — il ponte principale: i cinque sistemi come lente diagnostica per architetture multi-agente.
orchestrazione (in preparazione) — la ricorsività del VSM descrive il pattern orchestrator-worker, gli agenti che orchestrano sotto-agenti.
Bandits e trade-off esplorazione-sfruttamento — l’omeostato Sistema 3 – Sistema 4 è il dilemma exploitation/exploration sollevato al livello dell’architettura organizzativa.
agent-observability (in preparazione) — la opsroom di Cybersyn e il segnale algedonico come antenati dei dashboard di osservabilità e degli alert fuori-banda.
human-in-the-loop (in preparazione) — il segnale algedonico è, riconoscibilmente, lo schema dell’escalation verso l’operatore umano.

Per andare oltre

Beer ha scritto molto e in uno stile personale, a tratti aforistico: i suoi libri si leggono meglio se si accetta che siano insieme trattato e manifesto. Le fonti qui sotto bilanciano la voce dell’autore con due sguardi esterni — uno storico, uno critico.

Stafford Beer, Brain of the Firm (1972), Wiley. Il libro fondativo: deriva il VSM per analogia col sistema nervoso. Da leggere per capire da dove nasce il modello.
Stafford Beer, The Heart of Enterprise (1979), Wiley. La seconda derivazione del VSM, a partire dalla legge della varietà necessaria; contiene gli assiomi della managerialità e il recursive system theorem.
Eden Medina, Cybernetic Revolutionaries: Technology and Politics in Allende’s Chile (2011), MIT Press. Lo studio storico di riferimento su Project Cybersyn: rigoroso, ricco di contesto politico, lontano dalla nostalgia retrofuturista.
Metaphorum — staffordbeer.com / metaphorum.org. L’organizzazione che cura l’eredità di Beer: descrizioni dei cinque sistemi e di Cybersyn vicine alle fonti primarie.
Michael C. Jackson, Critical Systems Thinking and the Management of Complexity (2019), Wiley — capitolo sull’Organizational Cybernetics. Valutazione critica equilibrata del VSM: ne riconosce la forza diagnostica e ne espone i limiti di operazionalizzazione e di rigore.