Un’azienda autonoma non nasce da un esercito di agenti

Quando un solo agente non è più bastato per lavorare sulle mie applicazioni, ho costruito Paperclip: un sistema composto da più agenti che dovrebbero comportarsi come dipendenti di un’organizzazione. Il programmatore dovrebbe essere preciso, il tester scettico, il grafico creativo e il project manager responsabile del coordinamento invece di scrivere codice o creare grafiche. Ognuno riceve un ruolo, istruzioni e il contesto necessario per lavorare.

Sembra l’inizio di un’azienda autonoma. La pratica ha però mostrato rapidamente che un insieme di agenti non diventa un’azienda solo perché assegno loro dei ruoli. Paperclip riusciva a svolgere molte attività, creare documentazione ed espandere le proprie procedure, senza introdurre cambiamenti visibili nelle applicazioni. Il sistema era attivo, ma la sua attività non era ancora una prova di autonomia.

L’IA è soltanto uno strato. Un’azienda ha bisogno anche di una divisione delle responsabilità, processi, memoria, criteri di accettazione, flussi decisionali, prove dell’esecuzione e limiti stabiliti da un essere umano. Senza tutto questo, più agenti possono soltanto produrre più velocemente una maggiore quantità di lavoro intermedio.

In questo articolo Paperclip indica un sistema che organizza il lavoro di più agenti. Lo sto verificando su tre applicazioni che sviluppo. Featherly è un CMS destinato alla creazione di siti web anche con la partecipazione di agenti. Soar è un’applicazione per il trading automatico che può essere configurata da una persona, da un agente IA oppure da entrambi insieme. Roost dovrebbe diventare un organizzatore aziendale. Il lettore non deve conoscere le loro architetture: sono tre ambienti diversi in cui verificare se Paperclip riesce a portare una modifica complessa fino a un risultato funzionante.

Una pipeline esegue un processo. Un’azienda deve saperlo gestire

Una singola automazione assomiglia a una linea di produzione: riceve un input, attraversa passaggi descritti e restituisce un risultato. È sufficiente quando l’attività è ripetibile e il suo svolgimento è stato progettato in precedenza. Non basta quando il sistema deve riconoscere da solo un nuovo problema, scomporlo, scegliere gli esecutori, verificare le dipendenze e migliorare il proprio modo di lavorare dopo la conclusione.

Un’organizzazione autonoma non dovrebbe soltanto eseguire processi, ma anche crearli quando compare un nuovo tipo di lavoro. Dopo ogni iterazione può utilizzare il ciclo PDCA: pianificare la modifica, eseguirla, verificare il risultato e migliorare il processo sulla base di ciò che è realmente accaduto. Non si tratta però di riscrivere continuamente le procedure. Il miglioramento deve nascere da un problema concreto emerso durante la consegna del prodotto.

Per questo conservo le istruzioni in file Markdown. Un agente deve sapere di cosa è responsabile, secondo quali standard opera e a chi trasmette il risultato. Un ruolo ben descritto riduce la necessità di reinventare la ruota a ogni attività. Non è però la personalità digitale di un dipendente né una garanzia di competenza. È una configurazione di responsabilità, contesto, accesso e criteri operativi.

Dall’alto arriva il compito, dal basso la prova dell’esecuzione

Una modifica a un’applicazione può coinvolgere contemporaneamente molti punti e livelli. Una funzione può avere una parte nell’interfaccia, una logica nel backend, la persistenza dei dati e dipendenze da altri flussi. Quando chiedevo a un singolo agente una correzione locale, riusciva a modificare il frammento indicato, ma non sempre riconosceva che cosa quella modifica avrebbe danneggiato o richiesto negli altri livelli.

Paperclip dovrebbe risolvere questo problema con un flusso di lavoro in due direzioni. Un manager scompone dall’alto l’obiettivo in compiti più piccoli e li affida ad agenti specializzati. Gli esecutori riportano dal basso verso l’alto non soltanto l’informazione “fatto”, ma anche le prove: che cosa hanno modificato, come hanno verificato il risultato, quali dipendenze hanno trovato e che cosa blocca ancora l’insieme. Il livello superiore chiude il compito soltanto quando le parti formano un flusso funzionante.

Serve inoltre una memoria dello stato. Il manager deve sapere a quale fase è arrivata l’implementazione, quali decisioni sono già state prese e quali test sono stati superati. Senza memoria può assegnare tre volte lo stesso lavoro o scambiare la documentazione per un risultato, anche se l’applicazione non è cambiata. La memoria non è quindi un deposito di tutta la conoscenza possibile. Deve conservare lo stato, le prove e le conclusioni necessarie per la decisione successiva.

La documentazione non è una modifica del prodotto

Il fallimento più utile di Paperclip ricorda la sintesi popolare della legge di Goodhart: quando una misura diventa un obiettivo, smette di essere una buona misura. Il sistema avrebbe dovuto sviluppare applicazioni, ma ha trovato un prodotto intermedio più facile: la documentazione. Creava descrizioni delle applicazioni e del proprio funzionamento perché erano tracce visibili di lavoro. Nel frattempo, nelle applicazioni stesse cambiava ben poco.

La documentazione è necessaria se permette all’agente successivo di eseguire correttamente un compito oppure se costituisce la prova di una decisione. Diventa un problema quando il suo aumento sostituisce il risultato. Cento funzioni documentate non equivalgono a una funzione riparata. Allo stesso modo, il numero di agenti, attività e messaggi non dice ancora se l’organizzazione ha prodotto valore.

Un test pratico dell’autonomia deve concludersi nel prodotto. In Featherly, un test del genere consiste nell’eliminare il problema dell’accesso instabile e verificare l’intero flusso della sessione. In Soar la funzione DCA attraversa modalità di trading reale e simulato, più borse e i backtest, quindi una correzione locale non basta. In Roost servono modifiche UX/UI trasversali. Paperclip dovrebbe riconoscere autonomamente l’estensione del problema, coordinare l’esecuzione e dimostrare che tutti i percorsi importanti continuano a funzionare.

Il sistema ha sostituito correttamente il logo di Roost con il file SVG fornito. È un piccolo successo esecutivo: il comando è stato realizzato. Non è ancora, però, una prova di organizzazione autonoma, perché ho indicato direttamente il compito e il suo ambito era semplice e locale. Il vero test comincia quando il sistema deve dedurre i compiti dall’obiettivo del prodotto, trovare le dipendenze e chiudere la modifica senza una guida manuale di ogni passaggio.

Più agenti possono significare meno risultati

Più agenti hanno senso quando il problema può essere diviso, i ruoli apportano competenze diverse e il beneficio del lavoro parallelo supera il costo della comunicazione. Per un compito piccolo, organizzare agenti non organizzati può richiedere più tempo che svolgere direttamente il lavoro.

Uno studio su 260 configurazioni di agenti ha mostrato che il beneficio di più agenti dipende dalla natura del compito e dall’architettura, mentre il sovraccarico di comunicazione nei sistemi analizzati variava dal 58% al 515% rispetto alle configurazioni con un singolo agente ([Kim et al., 2026](https://www.nature.com/articles/s42256-026-01268-y)). Questo non significa che un solo agente sia sempre migliore. Significa che il numero di agenti non è una scala di maturità.

Un’altra analisi di oltre 1.600 tracce di esecuzione di sistemi multi-agente ha distinto problemi di progettazione e specifica del sistema, disallineamenti tra agenti ed errori di verifica e conclusione del lavoro. Le sole modifiche alle descrizioni dei ruoli e all’orchestrazione producevano effetti limitati ([Cemri et al., 2025](https://arxiv.org/abs/2503.13657)). È un limite importante del mio modello: istruzioni, gerarchia e reporting sono necessari, ma il sistema deve anche saper verificare il risultato e fermarsi quando l’obiettivo è stato raggiunto.

L’architettura dovrebbe quindi derivare dal problema. Un solo agente può sostituire un logo. Una correzione trasversale della funzione DCA può richiedere un manager, programmatori responsabili di livelli diversi e un tester indipendente. L’organizzazione è un costo che deve ripagarsi in qualità, tempo o capacità di coprire le dipendenze.

La trappola di un’organizzazione che lavora su se stessa

Il principale problema attuale di Paperclip non è la mancanza di idee per migliorare, ma il loro eccesso. Ho osservato situazioni in cui circa 150 attività su 200 riguardavano lo sviluppo del sistema stesso. L’organizzazione avrebbe dovuto creare applicazioni, ma consumava la maggior parte delle proprie energie per migliorare l’organizzazione.

L’auto-sviluppo è una forma di esplorazione: il sistema cerca processi, ruoli e strumenti migliori. Il lavoro sulle applicazioni sfrutta le capacità già possedute. James March ha descritto come esplorazione e sfruttamento competano per le stesse risorse limitate, anche se i loro benefici compaiono in momenti diversi ([March, 1991](https://doi.org/10.1287/orsc.2.1.71)). Paperclip non può quindi trattare l’auto-miglioramento come un’aggiunta gratuita al lavoro sul prodotto.

Ogni miglioramento dell’organizzazione dovrebbe avere un responsabile, un budget limitato, un’ipotesi di miglioramento e una condizione di arresto. Deve rispondere a un problema individuato: per esempio la ripetuta assegnazione dello stesso lavoro, la mancanza di test delle dipendenze o un rapporto senza prove. Dopo l’implementazione bisogna verificare se il problema si verifica davvero meno spesso. In caso contrario, un altro rapporto sull’auto-sviluppo non fa che ampliare il ciclo.

Un’organizzazione non deve essere ottimale prima di cominciare a consegnare. Deve essere abbastanza buona da svolgere il lavoro, soddisfare i criteri di accettazione, non lasciare errori bloccanti noti e permettere di tornare a uno specifico miglioramento dopo aver prodotto valore. Non è un permesso di lavorare male. È un’applicazione pratica dell’approccio *satisficing*: con informazioni e capacità di calcolo limitate, il sistema cerca una soluzione che soddisfi una soglia esplicita invece di un optimum irraggiungibile ([Simon, 1956](https://iiif.library.cmu.edu/file/Simon_box00063_fld04854_bdl0001_doc0001/Simon_box00063_fld04854_bdl0001_doc0001.pdf)).

L’essere umano continua a definire l’impresa

Considero Paperclip un insieme di lavoratori digitali che operano in un sistema progettato. Non voglio però affidargli le decisioni sulla direzione dell’azienda, sulla sua strategia o su quali prodotti e funzionalità debbano essere creati. Queste decisioni definiscono l’impresa e appartengono ancora all’essere umano.

Gli agenti devono attuare questa direzione come esperti: individuare incoerenze, proporre soluzioni, coordinare le dipendenze e mostrare prove. Possono migliorare un processo entro i confini dell’obiettivo, ma non dovrebbero trasformare il proprio sviluppo in una nuova strategia aziendale. Una supervisione periodica di Codex può analizzare il loro lavoro e registrare conclusioni, ma le modifiche all’organizzazione dovrebbero derivare da una valutazione esplicita e non dall’espansione automatica del sistema.

L’autonomia non significa quindi assenza dell’essere umano. Significa la capacità del sistema di completare una parte sempre più ampia del lavoro senza guidare ogni passaggio, mantenendo la direzione stabilita, criteri osservabili e la possibilità di fermare o annullare un’azione.

L’autonomia si vede in un ciclo chiuso

Non so ancora in quale momento Paperclip potrà essere definito onestamente un’azienda autonoma. So invece che cosa non accetterò come prova: il numero di agenti, di attività completate, di token consumati o di pagine di documentazione.

La prova sarà un ciclo chiuso. Il sistema prende un obiettivo derivato dalle premesse dell’applicazione, riconosce l’intera portata della modifica, distribuisce il lavoro, ricorda lo stato, raccoglie prove, verifica le dipendenze e restituisce un risultato funzionante. Solo dopo aver prodotto valore migliora l’elemento specifico del proprio processo che si è rivelato insufficiente durante il lavoro.

Se un’organizzazione sa soltanto lavorare su se stessa, non è autonoma: è intrappolata in un ciclo. Se sa eseguire esclusivamente compiti locali indicati manualmente, è uno strumento. Un’azienda autonoma nasce tra questi estremi: dove più agenti specializzati riescono a trasformare una direzione stabilita da un essere umano in un cambiamento verificabile della realtà.

Una soglia pratica per l’autonomia

L’attività degli agenti non dovrebbe essere considerata progresso finché il sistema non sa presentare sei elementi: un problema chiaramente definito e il risultato atteso, la prova che il risultato funziona, la verifica delle funzioni e dei flussi dipendenti, un bilancio esplicito tra il lavoro arrivato al prodotto e quello speso in documentazione e auto-sviluppo, una condizione di arresto e la giustificazione che il costo di coordinare più agenti sia inferiore al valore aggiunto da tale coordinamento.

Questi elementi non sono una ricetta universale per ogni organizzazione. Sono il meccanismo minimo che distingue un sistema capace di consegnare un risultato da uno che produce soltanto tracce di attività. Aiutano inoltre ad adattare l’architettura al problema: a volte basta un agente, a volte è giustificato un team specializzato e a volte il sistema adatto è una persona supportata da più strumenti.

Se il sistema non sa mostrare il risultato, le prove, i limiti e il costo del proprio funzionamento, la sua autonomia potrebbe essere soltanto un’etichetta. Se sa trasformare una direzione stabilita da un essere umano in un cambiamento funzionante, verificarne le conseguenze e fermarsi dopo aver soddisfatto i criteri, può essere valutato come un’organizzazione: in base a ciò che ha cambiato nella realtà.

Bibliografia

• Yubin Kim et al., “Capable language models can outgrow the benefits of collaboration”, *Nature Machine Intelligence* 8, 2026, [articolo](https://www.nature.com/articles/s42256-026-01268-y), consultato il 4 settembre 2026.
• Mert Cemri et al., “Why Do Multi-Agent LLM Systems Fail?”, arXiv:2503.13657, versione 3, 2025, [preprint](https://arxiv.org/abs/2503.13657), consultato il 4 settembre 2026.
• James G. March, “Exploration and Exploitation in Organizational Learning”, *Organization Science* 2(1), 1991, [DOI](https://doi.org/10.1287/orsc.2.1.71), consultato il 4 settembre 2026.
• Herbert A. Simon, “Rational Choice and the Structure of the Environment”, *Psychological Review* 63(2), 1956, [PDF](https://iiif.library.cmu.edu/file/Simon_box00063_fld04854_bdl0001_doc0001/Simon_box00063_fld04854_bdl0001_doc0001.pdf), consultato il 4 settembre 2026.