Tag: agenti autonomi

AI & GENAI, TECH & BUSINESS

Chi può ancora dire di no

Sta diventando normale vedere un agente che si mette in moto da solo, magari perché è arrivata una nuova richiesta o perché qualcosa nel lavoro si è bloccato, prende in carico il compito, lo divide in molte parti più piccole e le affida ad altrettanti agenti che procedono in parallelo, ognuno nel suo spazio isolato, mentre lui tiene d’occhio quello che producono e rilancia i pezzi che si inceppano, fino a tornare con una proposta di modifica pronta da rivedere. Ai tavoli dove passo le giornate incontro sempre più persone che lavorano in questo modo, coordinando decine di agenti su progetti veri senza quasi più scrivere codice a mano.

Davanti a una scena del genere la domanda che viene subito è quanto sia autonomo il sistema, e per rispondere si è diffusa l’abitudine di usare una scala che assegna un numero e ti dice quanto sei avanti nel lavorare con l’AI. Quel numero è comodo proprio perché è uno solo, e per un po’ ha funzionato come misura veloce del rischio, ma finisce per nascondere la cosa che conta di più dentro un’impresa cognitiva, e cioè chi, in mezzo a tutto questo, può ancora dire di no e con quanta rapidità riesce a farlo.

Quanto lo lasci andare, quanti ne tieni insieme

La scala più citata è quella proposta da Steve Yegge in «Welcome to Gas Town», costruita su un asse solo che sale dal basso verso l’alto, da quando l’agente si limita a suggerire fino a quando arriva a gestire l’intera baracca per conto suo. Come modo per dire quanta fiducia riponi in un singolo agente funziona ancora bene, ma nel frattempo il lavoro è cambiato e la leva più importante è diventata un’altra, perché conta meno fino a che punto lasci andare un singolo agente e conta molto di più quanti agenti riesci a coordinare nello stesso momento. Sono due cose diverse, e Addy Osmani ha fatto bene a tenerle separate, mettendo su un asse l’autonomia del singolo e sull’altro la capacità di orchestrarne molti, dato che una persona bravissima a far lavorare in sicurezza cinquanta agenti in parallelo può benissimo restare prudente su quanto si fida di ciascuno di loro preso da solo.

Questo spostamento cambia il modo di ragionare sull’autonomia. Non è un livello da raggiungere né una medaglia da esibire mentre si sale di grado, è piuttosto un permesso, e come ogni permesso si concede quando serve e si ritira quando serve. Davanti a un compito, allora, la domanda giusta smette di essere quanto in alto posso spingermi e diventa quanto rischio quel compito è capace di sopportare, e quale prova mi permette di difendere la scelta di lasciarlo correre da solo.

Conta quanto pulito torni indietro

Per capire se un sistema sta lavorando con un’autonomia davvero alta mi appoggio a tre domande che devo a Osmani, e riguardano tutte la possibilità di correggere il tiro: con quanta rapidità mi accorgo se sta sbagliando, con quanta facilità posso annullare quello che ha fatto, e che cosa mi dimostrerebbe invece che sta andando nella direzione giusta. Quando le risposte sono che me ne accorgo tardi, che tornare indietro è complicato e che in fondo mi sto fidando del riassunto, di autonomia alta è rimasto soltanto il nome, e sotto c’è un azzardo con un cruscotto messo lì a rassicurare.

È qui che l’idea del permesso revocabile diventa concreta. La sovranità di un’organizzazione sui propri processi si misura da quanto in fretta riesce a fermarli e a riportare le cose com’erano senza fare danni, molto più che dal numero di agenti che riesce a mettere in moto. Un intervento delicato come la riscrittura del motore dei pagamenti, se è protetto da verifiche serie, da agenti che controllano il lavoro di altri agenti e da un ritorno indietro pulito, può sopportare un’autonomia molto più alta di un compito che tocca dei contenuti senza avere una fonte certa con cui confrontarsi. Il livello di autonomia dipende dal processo di verifica che gli abbiamo costruito attorno, molto più che dal nome che diamo al compito.

Il debito nascosto nel riassunto

Man mano che l’agente si prende carico di compiti ben delimitati, la verifica smette di passare dai tuoi occhi e si sposta sulle prove che l’agente stesso produce, come le verifiche automatiche che vanno a buon fine, le schermate, le registrazioni di quello che è successo e le istruzioni per riprodurre un problema. Da un lato è un guadagno, perché nel frattempo puoi occuparti d’altro o semplicemente andare a dormire, dall’altro è un rischio, perché la scorciatoia è sempre a portata di mano, e cioè prendere il riassunto che l’agente ti consegna e usarlo al posto della revisione vera, dando per scontato che basti.

Questa scorciatoia, nei miei appunti, ha un nome e si chiama debito cognitivo. Ogni volta che accetto un riassunto senza pretendere lo stesso corredo di prove che chiederei a una revisione fatta a mano, e cioè il confronto delle modifiche, le verifiche, le registrazioni e i rischi rimasti scoperti, contraggo un debito che prima o poi qualcuno dovrà ripagare, con gli interessi. Per questo, in un’organizzazione che lavora con gli agenti, la verifica diventa una forma di capitale, qualcosa che va costruito, va mantenuto e quando manca si nota subito. Nessun modello te la regala già pronta, è una capacità che l’impresa coltiva nel tempo. In «Pelle Digitale» ho provato a raccontare proprio questa membrana sottile che ci separa dalla macchina che agisce al posto nostro, ed è lì che il debito cognitivo comincia ad accendersi.

Anthropic ha misurato tutto questo osservando circa quattrocentomila sessioni di lavoro con Claude Code, raccolte tra l’ottobre del 2025 e l’aprile del 2026, e ne è uscito un quadro abbastanza chiaro, perché nella sessione tipica sono le persone a prendere circa il settanta per cento delle decisioni di pianificazione, quelle su cosa fare e su quando considerare finito il lavoro, mentre è il modello a prendere circa l’ottanta per cento delle decisioni di esecuzione, quelle su quali file toccare e quale comando eseguire. Letta con questi numeri, l’autonomia alta non toglie le persone dal processo ma le sposta di posto, portandole dal compiere ogni singolo passo al decidere in che direzione muovere quello successivo, e chi porta con sé più competenza del proprio ambito ottiene di più da ogni istruzione e se la cava meglio quando l’agente si blocca, perché sa rimettere a fuoco il problema invece di lasciar perdere.

Il contratto prima della corsa

Prima di lasciar partire un agente conviene mettere per iscritto, in modo breve, che cosa dovrà cercare di ottenere. Non serve un documento burocratico, basta un foglio chiaro che chiunque, compreso un altro agente, possa leggere per capire dove passano i confini. Osmani ne propone una forma pratica che trovo solida, e la riprendo adattandola al modo in cui ragiono io sui permessi.

La prima cosa da fissare è l’obiettivo, che va detto come risultato e non come attività, quindi non «usa questa tecnica» ma «porta il tempo di caricamento sotto il secondo». Attorno all’obiettivo si dispone tutto il resto, e cioè il perimetro entro cui l’agente può muoversi insieme alle cose che invece deve lasciar stare, i permessi con cui gli è concesso toccare il mondo fuori dal suo recinto, la condizione che gli dice quando fermarsi e che è meglio sia misurabile, le prove che confermano il risultato in modo indipendente da lui, il momento e la persona a cui deve passare la mano quando qualcosa si complica, e infine un limite prefissato di tempo, di tentativi e di token, che per questi sistemi sono la moneta con cui pagano il lavoro che fanno.

Su come funzionano davvero il runtime, il contesto e i permessi degli agenti mi sono già soffermato di recente, e non torno qui sui dettagli. Senza un contratto del genere, comunque, l’autonomia alta resta soltanto un atto di fede, e gli atti di fede, quando finiscono in produzione, prima o poi si pagano.

Più agenti lanci e più serve chi controlla

Il gradino più alto assomiglia a una piccola fabbrica. C’è un agente che fa da manager e si attiva quando arriva un compito, distribuisce il lavoro agli altri agenti, ne segue l’avanzamento, rilancia le parti fallite e porta all’attenzione di una persona soltanto le decisioni che richiedono davvero un occhio umano, mentre in ingresso riceve la coda del lavoro, che sia una lista di lavori da fare o un registro delle segnalazioni, e in uscita restituisce attività chiuse e proposte di modifica accompagnate dalle loro prove. Attorno a impostazioni di questo tipo stanno nascendo specifiche di orchestrazione costruite intorno a una lavagna dei compiti, in cui ogni problema riceve il proprio spazio di lavoro e il proprio agente, e la frontiera, per come la racconta Osmani, sono ormai fabbriche che non si fermano mai, con centinaia o addirittura migliaia di agenti al lavoro insieme.

A questa scala due trappole si aprono quasi da sole. La prima è un parallelismo solo apparente, che scatta quando lanci trenta agenti su porzioni di lavoro che si sovrappongono e invece di moltiplicare i risultati ti ritrovi con conflitti da risolvere e con decisioni prese due volte. La seconda è più insidiosa e riguarda noi, perché la tentazione è continuare a coordinare a mano ogni singola dipendenza mentre decine di agenti girano, un po’ come se ci ostinassimo a dirigere il traffico a un incrocio che ormai ha già i semafori. Sul mestiere del manager che passa dal gestire persone al gestire agenti ho scritto di recente, perché è lì che si decide la partita organizzativa più difficile.

Più agenti metti in campo e più diventa vitale una verifica che sia indipendente, con chi implementa tenuto separato da chi rivede, con chi prepara le prove distinto da chi ne controlla la qualità e con dei passaggi di approvazione diversi per accettare il lavoro finito. Le organizzazioni cognitive che vedo nascere si riconoscono proprio da questo, dal fatto che riescono a far lavorare molti agenti insieme e nello stesso tempo a tenere il permesso sempre revocabile, a ogni anello della catena.

Quanti agenti sai ancora fermare

Alla fine il vero collo di bottiglia resta sempre la verifica, più che l’ambizione o il numero di agenti che riusciamo a far girare, perché tutto si gioca su quanto in fretta ci accorgiamo di aver sbagliato e su quanto puliti riusciamo a tornare sui nostri passi. La postura più matura, per chi lavora con gli agenti, è un’autonomia calibrata, che sale di un gradino soltanto dopo che le prove per reggere quel gradino si sono accumulate e che accetta di restare bassa proprio là dove tornare indietro sarebbe difficile.

Mi porto dietro dai tavoli dove lavoro una convinzione che col tempo si è fatta netta. Il giorno in cui ci vanteremo di far girare mille agenti, la prova di essere davvero avanti starà tutta nella rapidità con cui possiamo ancora fermarli. Finché quella rapidità tiene il passo del lavoro che si avvia da solo il permesso resta revocabile e siamo al sicuro, e conviene costruire i processi perché resti così: il giorno in cui la lasciamo indietro avremo soltanto una fabbrica che non sappiamo più spegnere.

Lo spunto di partenza è l’articolo di Addy Osmani «Agentic Autonomy Levels». Le tre domande sulla reversibilità e la forma del contratto d’esecuzione vengono dal suo pezzo, mentre la lettura in chiave di permesso revocabile e di debito cognitivo è mia.

AI & GENAI, TECH & BUSINESS

Manus AI, la guida completa per le aziende: agente, costi, governance

Cosa significa “agente autonomo” davvero

Per capire Manus AI c’è una distinzione che sembra banale e invece fa tutta la differenza. ChatGPT, Claude, Gemini sono assistenti conversazionali: il ciclo è prompt-risposta, e chi guida il processo resta sempre l’utente, che decompone il problema, lancia richieste in sequenza, ricompone i risultati a mano. Manus rompe questo schema. Riceve un brief in linguaggio naturale, costruisce un piano di esecuzione visibile, e parte da solo, pianifica i passi, apre un browser, esegue ricerche, scarica file, esegue codice, salva risultati, consegna un artefatto finale.

A raccontarlo così sembra una sfumatura semantica, in pratica è un cambio di paradigma, ed è la prima cosa da mettere a fuoco su Manus AI. La documentazione ufficiale di Manus parla di “virtual colleague with its own computer”, e l’immagine rende. L’agente vive in una sandbox Linux Ubuntu completa, con shell, file system persistente, browser Chromium, interpreti Python e Node.js, e può perfino esporre servizi web all’esterno. La parte tecnica più interessante, raccontata in dettaglio dal post di E2B che fornisce l’infrastruttura, è che ogni sessione gira su microVM Firecracker, le stesse macchine virtuali leggere sviluppate da AWS per Lambda. Il risultato pratico è che l’agente può lavorare per decine di minuti, anche un’ora, mantenendo lo stato tra un passo e l’altro, persino quando il dispositivo dell’utente è spento.

Questo cambia il modo in cui si chiede a Manus di fare qualcosa. Un prompt per ChatGPT richiede precisione sulla forma della risposta, perché il modello deve restituire un testo subito. Un brief per Manus richiede precisione sull’obiettivo finale e sui criteri di successo, perché il modello prenderà decine di micro-decisioni autonome durante l’esecuzione, senza poter chiedere conferma a ogni passaggio. È una scrittura più vicina a quella che useresti per un consulente esterno che riceve un brief e torna dopo due giorni con il dossier, non a quella che useresti per un assistente in chat. Tengo questa analogia per tutta la guida, perché è la chiave mentale che fa funzionare lo strumento.

Le due modalità e il pannello “Manus’s Computer”

Il prodotto si articola su due modalità. Chat Mode funziona come un assistente conversazionale tradizionale, costa pochissimi crediti, serve a domande veloci, sintesi rapide, ricerca puntuale. Agent Mode è la modalità autonoma vera, dove Manus prende il brief, costruisce il task plan, e parte. La differenza in termini di costi è netta, e va capita prima di iniziare a usare il prodotto in modo regolare, perché Chat Mode resta per molti utenti il novanta per cento dell’uso quotidiano.

L’elemento più distintivo dell’interfaccia è “Manus’s Computer”, un pannello laterale che mostra in tempo reale tutto ciò che l’agente sta facendo: quali pagine apre, cosa cerca, quali file scrive, quali comandi lancia nel terminale. Per chi viene da anni di chatbot dove tutto è invisibile, è un’esperienza diversa, si vede l’agente lavorare, si intercettano gli errori prima che compromettano l’intero task, si interviene spostandolo da una direzione sbagliata. Una review su Cybernews lo descrive come guardare un ricercatore al lavoro con una checklist davanti, ed è fedele.

Il punto delicato è che questa trasparenza si paga con una maggiore responsabilità di supervisione. Manus può sbagliare click sul browser, fraintendere un’istruzione, costruire un piano errato, e senza un occhio sul “Computer” l’agente consuma crediti per minuti producendo un output che alla fine non serve. La logica corretta è dargli un brief chiaro, lasciarlo lavorare, ma tenere sotto controllo i primi passi del piano. Se il piano iniziale regge, di solito l’esecuzione regge. Se è sbagliato, meglio fermarsi e riformulare. La regola pratica, ad ogni nuovo task, è chiedersi quanti strumenti diversi userei se facessi io questo lavoro: se la risposta è uno, basta Chat Mode, se sono tre o più, vale la pena passare ad Agent Mode.

Come si scrive un brief per un agente autonomo

Un brief per Manus non è un prompt per ChatGPT, ed è la singola cosa che fa la differenza tra task riusciti e task abbandonati a metà esecuzione. Un prompt conversazionale è una richiesta puntuale a cui il modello risponde subito. Un brief per Manus è la descrizione di un risultato finale e dei criteri per riconoscerlo come riuscito.

Un esempio, partendo da una richiesta sbagliata: “fammi una ricerca sui competitor”. Manus parte, ma il piano è generico, l’output incerto, i crediti consumati senza un punto di arrivo chiaro. Lo stesso task in versione corretta: “produci un dossier su cinque competitor italiani nel settore X, per ognuno raccogli sede legale, fatturato ultimi due esercizi disponibili da bilanci pubblici, posizionamento dichiarato sul sito, principali clienti citati in case study, presenza su LinkedIn dei C-level. Output: un file markdown con cinque schede da una pagina ciascuna, link a tutte le fonti, e una tabella riassuntiva finale”. Stessa richiesta sostanziale, risultato completamente diverso.

La differenza è che il secondo brief specifica quattro cose che il primo lasciava implicite: il perimetro del task, i dati da raccogliere, la struttura dell’output, le fonti accettabili. Manus eccelle quando questi quattro vincoli sono chiari, perché può costruire un piano di esecuzione lineare. Quando uno solo dei quattro manca, l’agente deve indovinare, e gli indovinelli costano crediti. La documentazione ufficiale suggerisce di pensare a sé stessi come a un manager che assegna un compito a un collaboratore esterno, ed è un’analogia che vale la pena adottare mentalmente prima ancora di iniziare a digitare. C’è anche una funzione che conviene conoscere dalla prima sessione: l’agente può essere fermato in qualsiasi momento, e si interviene chiedendo correzioni puntuali, suggerendo alternative, fornendo credenziali quando il sito richiede login. Questa pausabilità è uno dei tratti che distinguono Manus dagli agenti puramente background.

Piani, crediti, costi: il modello economico

Manus usa un sistema a crediti, e questo cambia profondamente l’esperienza rispetto agli abbonamenti illimitati di ChatGPT Plus o Claude Pro. Il piano gratuito offre trecento crediti che si rigenerano ogni ventiquattr’ore, più mille crediti starter una tantum, con accesso al Chat Mode e a Manus 1.6 Lite in Agent Mode. Basta per testare il prodotto e capire se ha senso salire di piano.

I piani Pro partono da venti dollari al mese per quattromila crediti, salgono a quaranta dollari per ottomila crediti con accesso al Wide Research, e arrivano a duecento dollari per il piano top che porta i crediti mensili a quarantamila e abilita la generazione batch di slide e siti. Il piano Team parte da venti dollari per seat con un minimo di due membri, e introduce funzionalità di workspace condiviso. La fatturazione annuale taglia circa il 17 per cento. Per i numeri aggiornati c’è la pagina ufficiale dei piani, ma il dato che conta per ragionare sui costi è un altro: i crediti mensili non si accumulano da un mese all’altro, mentre quelli acquistati come add-on restano disponibili finché l’abbonamento è attivo. Una review su Spectrum AI Lab lo conferma analizzando le regole di rollover.

Il dato concreto che serve per dimensionare il budget: un task di ricerca semplice consuma intorno ai cinquanta-sessanta crediti, un’analisi dataset di media complessità ne brucia trecento, un dossier di Wide Research approfondito arriva a quattro o diecimila crediti in una singola esecuzione. Manus non stima il costo di un task prima di lanciarlo, e in caso di crediti insufficienti si ferma a metà esecuzione senza addebiti automatici di overage. Per le aziende il budgeting va dunque fatto a posteriori nelle prime settimane, finché il team non sviluppa un’intuizione sui costi tipici dei propri task ricorrenti. Un consiglio che do sempre: tenere un piccolo log dei task lanciati, con brief, esito, crediti consumati, perché dopo dieci o quindici task emergono i pattern, alcuni tipi di richiesta rendono bene e altri sono sistematicamente difficili, e quel log diventa la base per capire dove Manus sostituisce ore di lavoro e dove invece produce solo overhead di supervisione.

I limiti veri delle prime sessioni

Manus non è perfetto, e conviene saperlo in partenza per evitare delusioni mal indirizzate. I problemi più comuni nelle prime sessioni sono tre. L’agente a volte fraintende il brief e parte in una direzione sbagliata, fa click errati sul browser scegliendo elementi che sembravano giusti, e in task lunghi perde il filo del piano iniziale divergendo verso obiettivi secondari.

Il primo problema si risolve scrivendo brief più precisi. Il secondo è una limitazione tecnica, mitigata dal browser visivo che permette di vedere gli errori e correggerli, ma resta una causa frequente di crediti consumati senza output utile. Il terzo è il più insidioso, e si gestisce dividendo i task lunghi in sotto-task più piccoli, ognuno con un output ben definito, invece di chiedere all’agente di completare in una singola esecuzione una pipeline articolata. Una review approfondita su Lindy nota che Manus funziona bene su task con percorso lineare e meno bene su quelli con logica condizionale ramificata, ed è un’osservazione utile per calibrare le aspettative fin dall’inizio.

I task su cui rodarsi senza rischiare frustrazione, nelle prime settimane, sono tre. La ricerca strutturata multi-fonte, dove Manus apre decine di pagine e le legge integralmente, producendo risultati migliori di un assistente conversazionale. L’estrazione dati da fonti web, dove l’agente apre la pagina, esegue lo scraping, scrive uno script di parsing se serve, salva il CSV, e risolve in cinque o dieci minuti quello che a mano ne richiederebbe quaranta. La generazione di documenti formattati a partire da input strutturati, dove dato un file Excel con i risultati di una survey l’agente produce un report con grafici, executive summary, sezioni per ogni domanda. Questi tre pattern coprono buona parte del valore quotidiano di Manus per un manager, e funzionano come esercizi di apprendimento.

Projects e Connectors: l’agente che entra nello stack di lavoro

Fino a metà 2025 Manus aveva un problema strutturale: ogni sessione partiva da zero. L’agente non sapeva nulla del lavoro precedente, delle abitudini del team, delle conversazioni in corso, e andava istruito ogni volta. A dicembre 2025 è arrivata la prima risposta strutturale sotto forma di Projects con Connectors, ed è il momento in cui Manus smette di essere un tool per task estemporanei e inizia a operare dentro il proprio contesto.

Un Project è un workspace persistente che conserva istruzioni di base, file di riferimento, cronologia delle conversazioni correlate. Invece di spiegare ogni volta a Manus chi siete, cosa fa la vostra azienda, qual è il tono di voce, quali sono i clienti chiave, queste informazioni vivono dentro il Project e l’agente le richiama all’inizio di ogni nuovo task. La pagina ufficiale del lancio descrive l’idea di trasformare task ripetibili in spazi persistenti. L’impatto si manifesta in tre direzioni: la qualità degli output, perché con il contesto già caricato Manus produce risultati più allineati al brand e al settore, il risparmio di crediti, perché spariscono i passi che l’agente farebbe per capire il contesto, e la possibilità di delegare task ricorrenti a chi nel team ha meno familiarità con lo strumento, perché il Project incapsula la complessità.

Qui si gioca la partita vera dei Connectors. Un Project può collegarsi nativamente, via protocollo MCP, ai servizi che già si usano: Gmail, Notion, Stripe, HubSpot, Slack, Google Calendar, Hugging Face, Google Drive, GitHub, e l’elenco continua a crescere. MCP è lo standard aperto che Anthropic ha proposto nel 2024 e che si sta affermando come lingua franca per l’integrazione tra agenti e tool esterni, un tema legato a doppio filo a come si evita il vendor lock-in nei progetti AI enterprise. Un esempio concreto: con il connettore Gmail attivo si può chiedere a Manus di leggere le email ricevute negli ultimi cinque giorni dai clienti enterprise, identificare quelle con una richiesta esplicita di follow-up, produrre una sintesi per priorità. Manus legge davvero la posta, applica i filtri, restituisce la sintesi. Con Slack attivo si può chiedere di guardare il canale vendite delle ultime due settimane e riassumere le obiezioni ricorrenti dalle call. A maggio 2026 Manus ha aggiunto i Connector Recommendations, che identificano quando un task richiede un servizio non ancora collegato e suggeriscono di attivarlo dall’interfaccia, riducendo l’attrito di scoprire a metà task che mancava una credenziale.

La tentazione iniziale è creare un Project generico chiamato “lavoro” e usarlo per tutto. Funziona male, e dopo qualche settimana produce confusione. La logica corretta è creare Project ristretti per dominio o per processo, uno per la competitive intelligence, uno per la produzione di contenuti, uno per l’analisi del customer feedback, ognuno con istruzioni mirate e connettori selezionati. Sui connettori conviene restare minimali, perché ogni connettore amplia la superficie di accesso ai dati: un Project di ricerca pubblica non ha bisogno di Gmail collegato, uno di produzione contenuti non ha bisogno di Stripe. La regola del privilegio minimo si applica anche qui, e protegge da scenari dove l’agente, in un momento di confusione, accede a dati che non doveva toccare.

Wide Research, la funzione dove Manus stacca gli altri

Ci sono task per cui un chatbot non basta, e per cui anche una “deep research” come quella di ChatGPT o Perplexity resta in superficie. Sono i dossier che richiedono di aprire decine di pagine, leggerle integralmente, estrarre dati strutturati, confrontarli, citarli con riferimenti puntuali. Wide Research è la funzione di Manus AI pensata esattamente per questo, disponibile sui piani Pro da quaranta dollari mensili in su, ed è uno dei punti dove il prodotto mostra il suo vantaggio competitivo più chiaro.

L’agente entra in una sessione estesa, lavora per quaranta-ottanta minuti, apre decine o centinaia di pagine, mantiene uno stato persistente, salva risultati intermedi, consegna un dossier corposo. La differenza con le ricerche standard riguarda la durata, certo, ma soprattutto la profondità di lettura: invece di fermarsi agli snippet dei primi risultati, l’agente apre davvero le pagine e le legge per intero. Sul confronto con la “deep research” di altri vale la pena guardare i numeri con cautela. Un’analisi su The Planet Tools che ha testato Manus su GAIA, il benchmark di riferimento per agenti AI, riporta uno score dell’86,5 per cento sul livello uno, 70,1 sul livello due, 57,7 sul livello tre, contro il 74,3, 69,1 e 47,6 di OpenAI Deep Research. I benchmark di prodotto vanno presi con le pinze, ma indicano una direzione: su task di ricerca multi-step strutturati Manus si comporta in modo competitivo, e in alcuni scenari supera la concorrenza più affermata.

Le regole sul brief valgono qui con un’intensità maggiore, perché un brief vago per un task da cinquanta crediti produce uno spreco accettabile, mentre per un task da cinquemila crediti produce uno spreco doloroso. I quattro elementi che fanno la differenza sono il perimetro, la struttura dell’output, le fonti accettabili, i criteri di successo. Wide Research rende particolarmente bene su tre terreni. La competitive intelligence strutturata, dove l’agente apre siti aziendali, comunicati, press release, e produce dossier che a un analista umano richiederebbero due o tre giornate. La due diligence light, che non sostituisce quella formale ma serve a valutare preliminarmente una controparte, raccogliendo informazioni pubbliche, segnalando red flag, ricostruendo la storia del management, con la capacità di citare puntualmente le fonti costruendo un audit trail della ricerca. Il market scan e la ricerca regolatoria, dove serve coprire molte fonti istituzionali, paper, comunicati di authority, banche centrali, organismi europei.

Sui costi conviene dare cifre concrete, perché il modello a crediti rende facile sottostimare l’investimento finché non ci si trova il budget mensile bruciato a metà mese. Un dossier di complessità media consuma tra i mille e i tremila crediti, uno ad alta complessità arriva a quattromila o diecimila in un’unica esecuzione. Sul piano Pro da quaranta dollari con ottomila crediti mensili, un task ben dimensionato occupa il dieci per cento del budget, mentre uno fuori scala può cannibalizzare un mese intero. Il calcolo che vale la pena fare è quanto tempo umano risparmia il dossier: se un’analisi da otto ore viene prodotta in trenta minuti con duemila crediti, il ROI è evidente, se invece il dossier è di qualità scarsa e va integrato a mano per quattro ore, il calcolo si ribalta. Per i dossier davvero importanti, quelli destinati a riunioni con stakeholder esterni o a decisioni di investimento, conviene un pilot in piccolo: stessa struttura ma su due o tre soggetti invece di dieci, si valuta la qualità, si calibra il brief, poi si lancia il task completo.

Wide Research è la scelta sbagliata quando la fonte primaria è una sola e già nota, e allora conviene caricare il documento in Chat Mode o in un Project e ragionarci sopra. Lo è quando la ricerca richiede accesso a database proprietari come Bloomberg, Crunchbase Pro, Pitchbook, perché Manus non ha accesso nativo e produrrà un dossier basato su fonti pubbliche più povere. E non funziona quando la domanda è soggettiva e richiede un giudizio interpretativo che presuppone esperienza di settore, perché valutare se un’azienda è un buon target di acquisizione è una sintesi di mercato, finanza, competitive e fit culturale che richiede chi conosce il contesto strategico interno. Wide Research prepara il terreno, non prende la decisione.

Scheduled Tasks e Cloud Computer: l’agente che lavora anche di notte

C’è un momento, in chi inizia a usare Manus seriamente, in cui ci si accorge che il vero collo di bottiglia si sposta: dalla capacità dell’agente al tempo dell’utente che deve lanciare i task. Le riunioni occupano la mattina, le revisioni il pomeriggio, e i task ricorrenti che si volevano lanciare ogni settimana si fanno una volta sì e due no, finché si smette. Qui Manus ha investito di più nell’ultimo anno, e a fine aprile 2026 ha consegnato il salto più rilevante del suo percorso prodotto.

Scheduled Tasks permette di programmare l’esecuzione di un task a cadenza fissa, ogni mattina, ogni lunedì, il primo del mese, ogni tre ore. L’agente lancia il task in autonomia, esegue, salva i risultati, eventualmente invia notifiche. Per chi è abituato a Zapier o n8n l’idea è familiare, per chi viene solo da chatbot è un cambio di prospettiva. Una review su Work Management lo descrive come la funzione che fa sembrare Manus più un operations tool che una novità AI, ed è fedele, perché il valore non sta nel singolo task pianificato ma nell’accumularsi di task ricorrenti che insieme costruiscono una piccola infrastruttura di business intelligence che gira da sola. I limiti vanno conosciuti: sul piano gratuito due Scheduled Tasks attivi, sui piani Pro il limite sale a venti task concorrenti e pianificati.

Il salto qualitativo è il Manus Cloud Computer, lanciato il 30 aprile 2026, descritto dalla stampa specializzata come il primo prodotto mainstream che dà a un agente un “permanent home”. Fino ad allora ogni sessione viveva in una sandbox effimera che si chiudeva al termine del task, mentre con Cloud Computer l’agente ha una macchina virtuale dedicata, sempre accesa, che mantiene stato, file, database, processi attivi anche tra un task e l’altro. Una rassegna su AI Automation Global descrive l’impatto come il passaggio dal 2025, anno del chat agent, al 2026, anno dell’agent runtime, un posto dove gli agenti vivono, reagiscono a eventi, accumulano effetti collaterali. Cloud Computer è disponibile in tre tier, accessibile da desktop e mobile, ed è proposto come no-code: si descrive l’obiettivo in linguaggio naturale e Manus provisiona e mantiene la macchina sottostante. Per le funzioni IT abituate a parlare di VM, container, processi supervisor, l’astrazione conta, perché non si gestisce più infrastruttura, si gestisce intento.

Gli scenari dove Scheduled Tasks ripaga rapidamente sono concreti. Il monitoring competitivo giornaliero, un task che ogni mattina controlla i siti dei competitor selezionati e invia un digest entro le otto, così il manager arriva in ufficio già allineato. Il digest settimanale di customer feedback, che ogni lunedì apre i ticket della settimana precedente, identifica i topic ricorrenti, segnala i feedback critici. La rassegna stampa di nicchia, che per chi lavora in public affairs o comunicazione scandaglia testate specializzate e account di settore producendo una rassegna ragionata, un sostituto credibile per certi scenari di servizi più costosi. Un caso descritto su NoCode MBA mostra come un setup simile per tracciare advertiser su newsletter di settore abbia intercettato lead prima della concorrenza.

I task pianificati hanno insidie diverse da quelli in tempo reale. Un task lanciato a mano lo supervisioni e se va male lo fermi, uno pianificato gira di notte e se sbaglia produce output sbagliati per giorni prima che qualcuno se ne accorga. Tre regole tengono conto di questa asimmetria. Essere conservativi sul perimetro, perché un task ricorrente deve fare poco ma bene, non è il contesto per un Wide Research da quattromila crediti ma per task semplici da cento o duecento. Configurare il fail-fast, in modo che se le fonti non sono accessibili l’agente notifichi l’errore invece di produrre output silenziosamente sbagliato. Fare una review periodica, una volta al mese, per vedere quali task generano valore e quali sono diventati rumore di fondo, perché la tendenza naturale è accumulare task senza mai potarli e dopo sei mesi ci si ritrova con quindici Scheduled Tasks di cui tre servono davvero.

Il valore vero emerge quando queste funzioni si combinano. Un Project con istruzioni mirate, connettori attivi sui propri tool, Scheduled Tasks che girano in autonomia, Cloud Computer che mantiene stato persistente, insieme diventano un’infrastruttura leggera di automazione che assomiglia a quello che le aziende grandi costruiscono con team IT dedicati. Un Project di sales intelligence con HubSpot attivo, dove ogni mattina un task apre i deal stagnanti da più di trenta giorni, controlla l’attività recente dei contatti su LinkedIn, identifica trigger di vita come un cambio ruolo o un post recente, suggerisce a quale account dare follow-up prioritario, con il Cloud Computer che mantiene memoria di lungo termine sui contatti per non ripetere segnalazioni già fatte. Due anni fa questo livello richiedeva un team di RevOps con Salesforce, Outreach, Clay, Apollo e un consulente di setup, oggi richiede un piano Manus Pro e una settimana di configurazione. C’è un caveat che ricordo sempre: tutta questa infrastruttura passa da una piattaforma esterna che ha accesso a dati aziendali sensibili, e il livello di automazione raggiunto è proporzionale alla quantità di credenziali condivise, un tema che chi ha vincoli di sovranità del dato risolve spostando lo strato AI dentro il perimetro, come racconto a proposito di infrastrutture di AI privata.

Collab, Desktop App e Design View: quando diventa risorsa di squadra

Per buona parte del 2025 Manus era un prodotto individuale. Un singolo utente apriva un task, lo seguiva, ne raccoglieva l’output, e per i team che volevano usarlo insieme l’unica strada era condividere screenshot e riprodurre a mano la stessa esecuzione. Da fine 2025 il prodotto ha coperto questo limite con un set di funzioni dedicate al lavoro di squadra.

Manus Collab apre i workspace alla collaborazione multi-utente con un solo link. Si genera, si condivide, e chi lo riceve entra nel workspace, vede lo stato dei task, partecipa alle conversazioni con l’agente, contribuisce al brief, accede agli output. Per chi viene da Notion, Linear, Figma, il pattern è familiare. L’effetto si misura sul sistemico più che sulla singola funzione: quando due persone lavorano insieme su un task le iterazioni si moltiplicano, una scrive il brief, l’altra lo affina, una valuta l’output intermedio, l’altra chiede correzioni, e la qualità finale supera quella che si otterrebbe in solitaria. Una review su Lindy nota che il lavoro di squadra è uno dei terreni dove i prodotti agentici stanno colmando il distacco rispetto agli strumenti collaborativi tradizionali. Un Manus solitario è uno strumento, un Manus condiviso può diventare un processo aziendale.

La Desktop App per Mac e Windows, descritta nella documentazione come “My Computer”, porta tre vantaggi pratici. L’accesso ai file locali senza upload manuale, così si lavora su documenti e fogli che vivono sulla propria macchina senza prima caricarli nel cloud. La persistenza visiva, perché l’app resta aperta in background e le notifiche sui task completati arrivano nel sistema operativo invece di disperdersi tra mille schede. E il senso di professionalità dello strumento, meno banale di quanto sembri, perché un’applicazione dedicata cambia il modo in cui un team percepisce un tool e abbassa la resistenza all’adozione strutturata. Resta una limitazione che conviene conoscere: anche con l’app desktop, l’esecuzione dell’agente avviene nella sandbox cloud, non sulla macchina locale, ed è un vincolo di sicurezza che vale per tutti gli agenti autonomi sul mercato.

Design View è il modulo dedicato alla generazione e all’editing di immagini, lanciato con una novità tecnica: integra Nano Banana Pro, il modello di generazione visuale di Google noto per la qualità delle iterazioni successive a partire dalla stessa immagine sorgente. Si carica o si genera un’immagine, e si chiedono modifiche in linguaggio naturale, cambia lo sfondo, togli la persona sulla destra, trasforma il giorno in notte, ogni modifica produce una nuova versione e il workspace mantiene la storia delle iterazioni. Per il marketing serve a produrre varianti per A/B test, social, landing page senza passare ogni volta dal design team per modifiche minori, per il design diventa uno sketchbook collaborativo, per la comunicazione interna permette di personalizzare template senza competenze grafiche. La qualità di Nano Banana Pro è alta sulle modifiche iterative dello stesso soggetto, meno costante quando si chiede una composizione completamente nuova, quindi conviene trattarlo come strumento di editing più che di creazione, affidando le brand asset di valore alto a designer professionisti.

C’è un tratto che accomuna gli scenari di squadra, e vale la pena fissarlo. Il valore di Manus per i team non sta nella sostituzione del lavoro umano, sta nella riduzione del tempo morto tra una decisione e la sua materializzazione. Cambia il throughput del processo creativo o produttivo, non la qualità finale dell’output, che resta dipendente dalla professionalità di chi lavora. Per aziende dove il time-to-market dei contenuti o delle materializzazioni visuali è un fattore competitivo, è una differenza che si misura in giornate di lavoro recuperate ogni settimana.

API e Custom MCP Server: integrare l’agente nei sistemi aziendali

C’è una fascia di lettori per cui usare Manus come prodotto finito non basta. Sono i CTO, gli IT manager, i lead developer che devono valutare se e come integrarlo dentro flussi esistenti, sopra database proprietari, dentro pipeline che girano su altri stack. Per questi profili la domanda non è come si usa Manus, è come si costruisce qualcosa con Manus. Due strade complementari, l’API per integrazioni server-to-server e i Custom MCP Server per esporre i sistemi interni all’agente.

L’API Manus permette a un sistema esterno di lanciare task sull’agente, ricevere risultati, gestire l’esecuzione in modo programmatico. La logica è quella di qualunque API moderna, chiave di accesso, endpoint, JSON in input e output, gestione asincrona dei task lunghi. Un caveat onesto: la documentazione tecnica sull’API è ancora in consolidamento e non ha la completezza di provider più maturi come OpenAI o Anthropic. Una guida su Skywork che ha analizzato pattern di integrazione con Stripe, Slack, Notion e Google Sheets nota che Manus si concentra sulla generazione rapida di app complete ma non documenta pubblicamente un developer SDK, un marketplace di plugin o un framework webhook strutturato. In pratica le integrazioni oggi si fanno in due modi, tramite middleware costruito ad hoc che riceve eventi dai propri sistemi e li traduce in chiamate Manus, oppure tramite polling per i servizi senza webhook affidabili. Entrambi richiedono uno sviluppatore esperto, e nessuno dei due è plug-and-play come l’esperienza dei Connectors nativi.

I Custom MCP Server fanno l’opposto: permettono a Manus di chiamare i sistemi aziendali interni come se fossero strumenti standard. Per le aziende strutturate è la direzione più potente, perché evita il problema della completezza dell’API e sfrutta lo standard aperto MCP. Si costruisce un server, ospitabile in cloud privato, on-premise o hybrid, che espone una serie di tool al protocollo, ognuno con un nome, una descrizione, parametri tipizzati, e un’implementazione che parla con i sistemi interni, per esempio “trova cliente per codice fiscale”, “estrai ultime fatture”, “aggiorna stato pratica”, “verifica disponibilità magazzino”. Si configura Manus per usare il server, e da quel momento l’agente opera sui sistemi proprietari dentro qualunque task autonomo. La documentazione integrazioni di Manus indica proprio questa possibilità di esporre CRM interni, database, API legacy in modo nativo. Per chi conosce il pattern del tool function calling negli LLM tradizionali, è la stessa cosa elevata a protocollo aperto e portabile, dove il server scritto per Manus può in linea di principio essere usato da altri agenti compatibili MCP, evitando il lock-in tecnologico.

Tre pattern ricorrono nelle integrazioni serie. Il ticket-enrichment, dove un sistema di ticketing genera un ticket, un trigger chiama Manus che con un Custom MCP Server sul CRM interno analizza il contenuto, identifica il cliente, recupera lo storico, classifica la richiesta, propone una priorità e un primo draft di risposta, e il ticket arricchito torna all’operatore umano con contesto già pronto. Il monitoring-and-routing, dove una pipeline di ingestion raccoglie input eterogenei e un task Manus li classifica, identifica i casi che richiedono attenzione umana, indirizza gli altri verso processi automatici, lo smistamento intelligente che dieci anni fa richiedeva regole if-then complesse. Il report-and-distribute, dove un task pianificato genera report periodici partendo da CRM, ERP, BI, li compone in documenti formattati, li distribuisce via email, Slack, Notion, una sostituzione credibile di parte del lavoro che oggi fanno manualmente i business analyst.

Tre temi tecnici vanno affrontati prima dello sviluppo. Webhook e polling sono i due modelli per la reattività, i webhook efficienti ma con endpoint pubblici e gestione delle retry, il polling più semplice ma con latenza e carico costante, e nella maggior parte dei casi conviene un layer ibrido. La gestione delle credenziali è il punto sensibile, perché con i Custom MCP Server le credenziali ai sistemi interni vivono nel server stesso, che diventa il punto critico di sicurezza, da isolare in rete dedicata, con credentials manager come Vault o i secrets manager cloud, con rotazione regolare e log di ogni accesso. L’idempotenza è il terzo, perché un task Manus può essere ritentato dopo errore o ricevere lo stesso input due volte, e i tool esposti devono produrre lo stesso risultato se chiamati due volte con gli stessi parametri, evitando doppie scritture. Sulla scelta tra costruire e comprare, il criterio è quello classico: si costruisce custom quando ci sono sistemi proprietari unici, requisiti di sicurezza specifici, volumi che ammortizzano lo sviluppo, e si compra il prodotto quando il caso d’uso è coperto dai Connectors nativi e il team non ha competenze per mantenere integrazioni custom. La variante intermedia più frequente è “buy the platform, build the connectors”, Manus come piattaforma chiavi in mano per il novanta per cento dei casi standard e un Custom MCP Server dedicato per i sistemi proprietari critici.

Adozione enterprise: governance, sicurezza, costi, proprietà

Un decisore che ha capito cosa fa il prodotto si trova davanti alle domande che contano quando si passa da “uno sperimenta nel team” a “lo adottiamo come strumento aziendale”. Quanto costa su scala team, quali garanzie di sicurezza offre, dove finiscono i dati, qual è il contesto di proprietà e governance, quando vale la pena e quando no.

Su scala team la logica di Manus AI è la stessa degli utenti individuali, con dinamiche di scala da comprendere. Il piano Team parte da venti dollari al mese per seat con un minimo di due membri, e introduce workspace condiviso, single sign-on, funzionalità di amministrazione, una pool di crediti gestita collettivamente. Per un’azienda con dieci utilizzatori attivi il costo base è duecento dollari al mese, più gli eventuali add-on per i picchi. Il calcolo che conta è quello dei crediti, non quello del seat, perché i casi più costosi, Wide Research, Cloud Computer attivo, task autonomi lunghi, concentrano buona parte del budget se non si stabilisce una disciplina interna. I crediti mensili non si accumulano, quelli da add-on restano finché l’abbonamento è attivo, e questa asimmetria spinge a una calibrazione fine, meglio un piano leggermente sotto il fabbisogno medio integrato con add-on quando serve, che un piano sovradimensionato che spreca crediti ogni mese.

Tre limiti operativi impattano l’organizzazione. Il limite di task concorrenti, uno solo sul gratuito, venti su Pro, scalabile con i seat ma con un tetto sul Team, che emerge quando un team di otto persone tenta di lanciare ognuno un Wide Research nello stesso pomeriggio e alcuni restano in coda. Il limite di Scheduled Tasks attivi, dove la disciplina di tenere pochi task ben fatti è anche un’auto-limitazione virtuosa. Il limite di Wide Research, dove le sessioni hanno durate massime e i crediti possono saturare il budget mensile, tanto che per team con bisogno frequente di dossier il piano top da duecento dollari diventa quello sostenibile.

Su sicurezza, data residency e audit trail Manus ha una maturità intermedia, i meccanismi di base ci sono ma la documentazione enterprise non è ancora al livello dei provider più consolidati. Tutto ciò che passa per la sandbox cloud, file caricati, contenuti delle conversazioni, output prodotti, viene processato dalla piattaforma, e per dati non particolarmente sensibili è coerente con qualunque SaaS moderno. Per dati regolamentati, categorie particolari GDPR, segreto bancario, dati sanitari, classificati pubblici, questa è la prima asimmetria da considerare, perché Manus non è oggi un prodotto certificato per la gestione di dati ad alta sensibilità, e per questi scenari va verificato puntualmente cosa il proprio framework di compliance consente. Sulla data residency, l’infrastruttura sottostante gira su provider cloud americani, e per aziende italiane ed europee in PA centrale o in settori finanziari di rilevanza sistemica, con vincoli espliciti di sovranità del dato, questo è un nodo da valutare caso per caso. Per la maggior parte delle aziende private il framework di trasferimento internazionale copre adeguatamente, ma l’analisi va documentata formalmente. Sull’audit trail il prodotto registra conversazioni ed esecuzioni e offre l’accesso alla cronologia, sufficiente per l’accountability interna, mentre per audit formali le funzionalità avanzate come log immutabili, export strutturato, integrazione SIEM, sono in consolidamento e vanno verificate con il vendor.

C’è poi un punto di proprietà e governance del prodotto che merita di essere riportato con precisione, perché si è mosso parecchio negli ultimi mesi. Manus nasce da Butterfly Effect, società fondata in Cina con radici a Pechino e Wuhan, poi reincorporata a Singapore nel 2025. A dicembre 2025 Meta ha annunciato l’acquisizione di Manus, riportata intorno ai due miliardi di dollari, dichiarando che avrebbe accelerato l’innovazione AI per i propri prodotti consumer ed enterprise. L’operazione ha attratto scrutinio sia negli Stati Uniti sia in Cina, e il 27 aprile 2026 la National Development and Reform Commission cinese ha bloccato l’acquisizione, chiedendo alle parti di annullarla, in una mossa che la stampa internazionale ha collegato alle preoccupazioni di Pechino sul trasferimento di tecnologia avanzata e talento. Meta ha risposto che la transazione era pienamente conforme alle leggi applicabili e che si attende una risoluzione appropriata della questione. Allo stato attuale lo scenario resta aperto e non del tutto chiarito, anche perché parte del personale risultava già integrato nei team Meta. Per le aziende che valutano l’adozione il punto non è prendere posizione su una vicenda geopolitica, è registrare che il prodotto attraversa una fase di evoluzione e incertezza societaria, con i lati positivi degli investimenti continui e i lati di consapevolezza sui possibili cambiamenti di pricing e di policy. Per settori con vincoli stringenti sulla provenienza geografica dei fornitori cloud, PA centrale, difesa, sanità, banking sistemico, questo va verificato con le funzioni di compliance interne, mentre per il resto del mercato privato il tema è meno stringente di quanto a volte appaia.

La griglia decisionale: quando Manus AI è la scelta giusta

Resta da mettere insieme tutto in criteri sintetici, da combinare con il contesto specifico di ogni azienda. La domanda preliminare, prima ancora di aprire l’account, riguarda il proprio flusso di lavoro: ha task multi-passo che oggi vengono eseguiti a mano per mancanza di alternative, oppure è già strutturato intorno a strumenti specializzati che coprono ogni segmento?

Una griglia grossolana ma utile parte dal tempo. Se il task richiede meno di cinque minuti di lavoro umano, Manus è un’overkill costosa ed è meglio un assistente conversazionale. Se richiede tra cinque minuti e un’ora, e attraversa più strumenti o più fonti, Manus può essere la scelta giusta. Se richiede più di un’ora di lavoro complesso ma altamente strutturato, vale la pena valutare se non sia più adatto a una pipeline costruita con API e tooling dedicato. Manus è la scelta giusta quando l’azienda ha bisogno regolare di task multi-passo oggi eseguiti a mano, quando il team ha competenze digitali medio-alte e può investire un mese o due nella curva di apprendimento, quando i casi d’uso prevalenti riguardano ricerca approfondita, generazione di documenti formattati, monitoraggio continuo, supporto a customer operations e sales, e quando i dati toccati non sono in fasce di sensibilità elevata oppure si è disposti a costruire un Custom MCP Server che isoli il perimetro.

È invece da rivalutare con attenzione quando l’azienda opera in settori altamente regolati con vincoli di sovranità del dato espliciti, quando il team non ha la disponibilità per investire nella curva di apprendimento e cerca un tool da accendere e usare, quando i casi d’uso sono prevalentemente conversazionali e iterativi, per i quali un assistente tradizionale è più adatto, e quando il budget è strutturalmente sotto i venti dollari mensili per utente, perché il modello a crediti rende il piano gratuito limitante per un uso professionale serio.

In molti casi reali la risposta sta nel mezzo, ed è una valutazione sfumata che conviene chiudere con un pilot strutturato, un trimestre di prova con un team ristretto di tre o cinque power user, obiettivi misurabili sul tempo umano risparmiato e sulla qualità degli output, e una decisione formale a fine trimestre se estendere all’organizzazione o fermarsi. È l’approccio che evita sia il rifiuto pregiudiziale sia l’adesione entusiastica non sostenibile, ed è quello che la maggior parte delle aziende che adottano con successo nuovi tool AI sta usando in questa fase. C’è anche un criterio organizzativo che vedo spesso sottovalutato: le aziende che adottano Manus con successo sono quelle che dedicano una persona o un piccolo team alla curva di apprendimento iniziale, prima di estendere l’uso al resto dell’organizzazione, perché lanciarlo dall’alto come tool generalista, senza un nucleo di power user che sviluppi pattern riconoscibili, tende a produrre frustrazione e abbandono.

Tutto questo ragionamento, dalla scelta del modello fino all’architettura di governance, è esattamente il tipo di valutazione che mi capita di affiancare quando un’azienda mi chiede un assessment sulla propria adozione AI. Se Manus entra in un disegno più ampio di sovranità del dato e infrastruttura interna, vale la pena leggerlo insieme alle scelte di stack che ho raccontato altrove, dal perché Mistral è diventata la scelta enterprise più seria d’Europa per chi vuole l’AI dentro il proprio perimetro, fino a cosa cambia per il GDPR quando un dato esce dall’azienda e si appoggia a una piattaforma esterna come Manus. In Pelle Digitale ho provato a descrivere come l’interfaccia digitale media il nostro rapporto con il lavoro e con noi stessi, e un agente autonomo come Manus è il caso limite di questa mediazione, uno strumento che non risponde più soltanto, agisce. Per una conversazione diretta sul vostro caso specifico c’è la pagina Advisory.

A inizio percorso lasciavo aperta una domanda, e la richiudo qui dopo aver attraversato tutto il prodotto. Aprire un account, dedicare due settimane all’esperimento concreto, scegliere tre task realistici del proprio lavoro e provarli con la disciplina vista in queste pagine, perché la risposta sul valore di Manus per il proprio contesto arriva solo dall’esperienza diretta e nessuna guida può sostituirla. Senza dubbio è in quella prova concreta che si gioca la differenza tra chi avrà cavalcato l’onda degli agenti autonomi e chi la guarderà passare?

Leggi anche: ecosistema di AI privata

TECH & BUSINESS

LocalAI: la guida per costruire un ecosistema di AI privata, dagli LLM agli agenti con memoria

Per mesi ho visto ripetersi la stessa scena: entusiasmo enorme sull’AI generativa, proof-of-concept ovunque, e poi, quando arriva il momento di portare l’AI dentro processi reali, una domanda che taglia corto: “Dove vivono i dati?”. Subito dopo ne arriva un’altra: “Quanto ci costerà davvero?”. E subito dopo la terza: “Cosa succede se domani cambia un pricing, un accesso, una policy, un modello?”.

È da questa triade (dati, costi, dipendenza) che nasce l’idea della guida su LocalAI. Non come esercizio tecnico, ma come scelta di architettura. E, in fondo, come scelta culturale: riportare l’intelligenza sotto il controllo di chi la usa.

“Guida completa a LocalAI, LocalAGI e LocalRecall” è pensata per costruire un ecosistema di Intelligenza Artificiale privato su hardware consumer: dal server di inferenza agli agenti autonomi, passando per la memoria. Ho provato a scrivere la risorsa che avrei voluto avere io: un percorso unico, pratico, con un filo logico, capace di trasformare pezzi sparsi in una stack coerente.

Il punto di partenza è LocalAI: un server di inferenza che espone API compatibili con OpenAI e permette di eseguire modelli (testo, immagini, audio, embeddings) sul proprio hardware. La compatibilità non è un dettaglio: significa poter “sganciare” un’app dal cloud e reindirizzarla in locale con modifiche minime.

Ma un sistema utile non è solo un modello che risponde. Serve memoria, serve contesto, serve recupero delle informazioni, serve continuità. Per questo la guida si estende a LocalRecall: lo strato di memoria che implementa RAG (retrieval-augmented generation), cioè la capacità di interrogare una base di conoscenza esterna e alimentare il modello con informazioni pertinenti, riducendo errori e allucinazioni e aumentando la qualità delle risposte.

E poi c’è l’ultimo salto: dagli LLM agli agenti. Qui entra LocalAGI, pensato per creare e orchestrare agenti autonomi (anche in modalità no-code/low-code), collegandoli al “cervello” (LocalAI) e alla “memoria” (LocalRecall). Quando questa triade funziona, non stai più giocando con una chat: stai costruendo un sistema capace di fare piani, eseguire task, usare strumenti, ricordare, migliorare.

La struttura del libro riflette questa progressione, perché l’AI locale non è un singolo componente: è un’architettura. Nella prima parte si costruiscono le fondamenta (installazione, modelli, backend, funzionalità principali e ottimizzazioni, con attenzione alla sicurezza). Nella seconda si costruisce la memoria (LocalRecall e le scelte di storage, dalla semplicità alla scalabilità). Nella terza si costruisce l’intelligenza attiva (LocalAGI e la logica agentica). E nella quarta si scende su casi d’uso e appendici operative.

Un aspetto che ho voluto rendere esplicito è che “locale” non significa “romantico”. Significa pragmatico:

  • Privacy: i dati non devono lasciare la macchina, quando non è necessario.
  • Costi: sposti spesa da OPEX variabile (token) a CAPEX + energia, rendendo il budget più prevedibile.
  • Personalizzazione: puoi scegliere modelli, configurazioni, pipeline, senza vendor lock-in.
  • Resilienza: puoi far funzionare parti del sistema anche offline o in rete chiusa.

E poi c’è una parola che spesso manca nel dibattito: responsabilità. Avere controllo significa anche doversi occupare di sicurezza: proteggere endpoint, chiavi, accessi, permessi, logging. La guida insiste su questo perché l’AI locale non è “auto-magicamente” sicura: è solo più governabile, se la governi.

Per chi è questa guida?

Per chi sviluppa e vuole un’alternativa seria al cloud. Per chi fa IT e deve ragionare su TCO e compliance. Per chi costruisce prodotti e vuole embedded AI senza consegnare tutto a terzi. Ma anche per chi, semplicemente, vuole capire la stack: cosa sono i backend di inferenza, perché esistono gli embeddings, come si fa RAG, come si orchestrano agenti, e quali trade-off stai accettando quando dici “usiamo un LLM”.

Nella Nota dell’Autore ho scritto una cosa che per me è centrale: questi strumenti non sono solo strumenti tecnici. Rappresentano una filosofia, accessibilità, trasparenza, controllo, e un invito a contribuire a un ecosistema open-source che sta accelerando a vista d’occhio. La guida è un punto di partenza, non un punto di arrivo. Ma è il punto di partenza che mancava: chiaro, pratico, completo.

PENSIERI SPARSI

Dal “perché” al “come”: tre libri per orientarsi tra pelle digitale, AI locale e agenti autonomi

Negli ultimi mesi ho lavorato su tre testi diversi, ma legati da un filo unico: capire cosa sta diventando il digitale quando smette di essere “uno schermo” e diventa ambiente, infrastruttura e, soprattutto, comportamento. “Pelle Digitale” prova a nominare il cambiamento (e le sue implicazioni umane). La guida su LocalAI spiega come costruire un ecosistema di AI privata e controllabile. La guida su OpenClaw porta tutto sul piano operativo: un assistente che non si limita a rispondere, ma agisce.

 

Negli ultimi mesi sono usciti tre miei lavori che, a prima vista, sembrano parlare a pubblici diversi: un saggio, due guide pratiche. In realtà, sono tre capitoli della stessa domanda: cosa succede quando la tecnologia smette di essere un “mezzo” e diventa uno “strato” della realtà? Uno strato che ci avvolge, ci legge, ci anticipa, ci indirizza. E che, proprio per questo, va capito prima ancora che usato.

Il primo punto è semplice e scomodo: non stiamo vivendo un’ennesima ondata di innovazione. Stiamo attraversando un cambio di postura dell’umano. Il digitale non è più un luogo separato (il web, l’app, la piattaforma). È un sistema nervoso diffuso fatto di sensori, modelli, agenti, edge, interfacce spaziali. Una “intelligenza invisibile” che diventa infrastruttura del quotidiano, mentre noi continuiamo a raccontarcela come una serie di prodotti e feature.

Da qui nasce “Pelle Digitale”: un tentativo di dare un nome alla convergenza tra AI e mondo fisico, e di ragionare sul prezzo (e sul valore) di questa simbiosi. Perché se la tecnologia migra “dalla tasca alla pelle”, cambiano le regole dell’esperienza, della percezione, della relazione e del potere. Non è un libro sulle tendenze: è una mappa per non subire lo shift.

Il secondo punto è operativo: se l’AI diventa una componente strutturale, allora serve una scelta di architettura. E la scelta non è solo tecnica: è politica, economica, culturale. “AI locale” significa, prima di tutto, riprendersi controllo su dati, costi, personalizzazione e continuità operativa. È una forma di sovranità digitale: non delegare tutto al cloud per abitudine, ma decidere dove vive la tua intelligenza, con quali vincoli, con quali garanzie. 

È il senso della “Guida completa a LocalAI, LocalAGI e LocalRecall”: un percorso pratico per costruire un ecosistema privato (LLM, memoria, agenti) su hardware consumer, con strumenti open-source e API compatibili. Non è un manuale “da laboratorio”: è una guida pensata per chi vuole capire davvero cosa sta installando e perché, e per chi vuole passare dalla demo al sistema.

Il terzo punto è l’ultimo miglio: quando l’AI smette di essere solo conversazione e diventa azione. Qui entrano gli agenti autonomi e la nuova categoria degli “assistenti che fanno cose”: non solo risposte, ma task, workflow, automazioni, verifiche, iterazioni. “OpenClaw: La Guida Completa all’Assistente AI Personale” nasce per spiegare come funziona (davvero) un agente che interagisce con sistema operativo, browser e strumenti quotidiani, e soprattutto come lo si governa in sicurezza.

Se devo sintetizzare il filo rosso, è questo: stiamo costruendo un mondo in cui il digitale diventa ambiente. Un ambiente può essere accogliente o ostile. Può amplificare autonomia o erodere libertà. Può rendere le persone più capaci o più dipendenti. E la differenza la fanno design, governance e responsabilità.

Per questo i tre libri, scritti nel primo trimestre del 2026, possono essere letti come una sequenza naturale, dal senso all’implementazione:

  1. “Pelle Digitale” per capire il contesto: cosa sta succedendo al rapporto tra corpo, spazio, interfacce e intelligenza.
  2. “LocalAI” per costruire la base: un’infrastruttura AI privata (inferenza, memoria, agenti) sotto il tuo controllo.
  3. “OpenClaw” per passare all’azione: un assistente agentico, con architettura modulare e una disciplina di sicurezza “prima dei superpoteri”.

E se invece vuoi una lettura “per ruolo”, ecco tre percorsi possibili.

Se guidi un’azienda, un team, un prodotto: parti da “Pelle Digitale” per mettere ordine nelle implicazioni (attenzione, opacità, relazioni aumentate, umanesimo aumentato) e poi scendi su LocalAI per capire cosa significa progettare sistemi AI sostenibili, non solo esperimenti.

Se sei tecnico (dev, data, IT, security): parti da LocalAI per costruire stack, costi e privacy; poi OpenClaw per capire come si traduce l’AI in agenti “operativi” e quali sono i rischi reali quando un modello può toccare file, browser e credenziali.

Se sei curioso e vuoi un quadro completo: parti da “Pelle Digitale”, ma tieni LocalAI e OpenClaw come “laboratori”: ti aiutano a trasformare concetti in oggetti, e oggetti in pratiche.

Il punto, per me, non è aggiungere contenuti al rumore. È offrire tre strumenti di orientamento: una mappa concettuale, una guida infrastrutturale, una guida agentica. Perché la vera domanda non è “cosa può fare l’AI?”. La domanda è “che tipo di mondo stiamo costruendo quando la rendiamo ovunque?”.

Leggi anche: AI locale e agenti con memoria

AI & GENAI

OpenClaw: origine, architettura e guida operativa

Una sintesi necessaria

OpenClaw è un framework open source per costruire un assistente personale basato su modelli linguistici, pensato per operare dove le persone comunicano già: chat e canali di messaggistica. Non è un chatbot da interfaccia web, ma un agente che vive accanto all’utente, connesso ai suoi flussi quotidiani, dotato di strumenti e di uno spazio di lavoro persistente.

Il progetto si distingue per alcune scelte nette. Un gateway locale funge da piano di controllo, gestendo connessioni, sessioni e sicurezza. Le funzionalità si estendono tramite “skills”, pacchetti di istruzioni modulari. La presenza dell’agente non è episodica, ma può essere continua grazie a un meccanismo di esecuzione periodica che consente all’assistente di “tornare attivo” senza un prompt umano diretto.

La conseguenza è evidente: OpenClaw non è solo un’interfaccia verso un modello, ma un sistema operativo leggero per agenti. Proprio per questo, i temi più rilevanti non sono legati alle capacità linguistiche, bensì al controllo degli accessi, alla gestione dei permessi e alla riduzione del rischio quando un agente può agire su sistemi reali.

Da prototipo a progetto globale

L’origine di OpenClaw è dichiaratamente pragmatica. Il primo prototipo nasce come un semplice relay per WhatsApp, un progetto sperimentale sviluppato in poco tempo per collegare un modello linguistico a un canale di messaggistica reale. In quella fase iniziale il nome era descrittivo, quasi funzionale, e rifletteva l’obiettivo immediato più che una visione di lungo periodo.

Nel giro di poche settimane il progetto cresce, sia in termini di attenzione pubblica sia di ambizione tecnica. Il relay si trasforma in un assistente personale multi-canale, con una mascotte riconoscibile e un branding che contribuisce alla diffusione virale. Questo passaggio segna anche l’inizio di una fase complessa, caratterizzata da più cambi di nome ravvicinati.

Il primo rebrand nasce da esigenze legate ai marchi e alla somiglianza con nomi già affermati nel panorama AI. Segue una fase intermedia, breve e instabile, in cui la community partecipa attivamente alla scelta del nuovo nome. Infine, arriva OpenClaw: un nome più neutro, verificato e pensato per durare, accompagnato da una migrazione coordinata di repository, documentazione e strumenti di installazione.

Questi cambi non sono solo un dettaglio comunicativo. In un progetto open source che fornisce installer, pacchetti e comandi da eseguire, ogni rebrand apre una finestra di rischio. Domini simili, repository clonati e pacchetti contraffatti possono intercettare utenti meno attenti. La storia di OpenClaw rende evidente quanto la gestione dell’identità di progetto e della supply chain sia parte integrante della sicurezza.

Un’architettura pensata per agire

Il cuore di OpenClaw è il gateway. Si tratta di un processo persistente che gestisce lo stato dell’agente, le connessioni ai canali di messaggistica, l’invocazione degli strumenti e l’interazione con l’utente tramite una dashboard locale. Il gateway è il punto di convergenza di tutto: senza di esso l’agente non esiste.

Intorno al gateway ruota il runtime dell’agente. Qui il modello linguistico viene messo in condizione di operare, non solo di rispondere. Può leggere e scrivere file, effettuare chiamate di rete, inviare messaggi, avviare comandi, a seconda dei permessi concessi. Questa capacità è ciò che rende OpenClaw interessante, ma anche ciò che ne aumenta la criticità.

L’estensione delle funzionalità avviene tramite le skills. Una skill è una cartella strutturata che contiene istruzioni e metadati, caricata secondo regole di precedenza ben definite. Le skills possono essere locali, condivise o installate da registri pubblici. In tutti i casi, vengono trattate come codice: entrano nel perimetro operativo dell’agente e ne influenzano il comportamento.

Accanto alle skills, un elemento distintivo è l’heartbeat. Questo meccanismo consente all’agente di eseguire turn periodici, ad esempio per controllare inbox, aggiornamenti o condizioni di sistema. Non è un semplice cron: è un momento in cui l’agente valuta il contesto e decide se intervenire. È anche il punto in cui automazione e costi, sia economici sia di rischio, diventano evidenti.

Canali, presenza e delega

OpenClaw supporta numerosi canali di messaggistica. Alcuni sono più semplici da configurare, altri richiedono pairing e gestione di stato più complessa. In tutti i casi, la filosofia è la stessa: l’agente non è pubblico per default. L’accesso viene mediato da politiche di pairing e allowlist, che rendono esplicita la delega dell’umano.

Questo aspetto è centrale. Chi può parlare con l’agente può anche tentare di manipolarlo. OpenClaw assume che la prompt injection e il social engineering siano problemi strutturali e non risolvibili solo a livello di modello. La risposta progettuale non è “rendere il modello più intelligente”, ma restringere chi può inviare input e cosa l’agente può fare in risposta.

La distinzione tra conversazione e azione è mantenuta tramite strumenti separati e controlli di approvazione. Alcune operazioni, come l’esecuzione di comandi sul sistema, richiedono un consenso esplicito e vengono bloccate se non autorizzate. Questo approccio riconosce un limite fondamentale: un agente non dovrebbe mai essere considerato affidabile di per sé.

Una guida all’uso consapevole

Installare OpenClaw è relativamente semplice. Il percorso consigliato passa da una CLI che guida l’utente nella configurazione iniziale, nella scelta dei modelli, nell’attivazione del gateway e nell’eventuale installazione come servizio in background. I requisiti tecnici sono espliciti e orientati a sistemi moderni.

La parte più importante non è però l’installazione, ma la configurazione. OpenClaw utilizza un file di configurazione che definisce workspace, canali attivi, politiche di accesso e comportamento dell’agente. Se il file manca, vengono applicati default prudenziali, ma la responsabilità finale resta dell’utente.

Collegare i canali richiede attenzione. Ogni piattaforma ha implicazioni diverse in termini di identità, privacy e superficie di attacco. La documentazione insiste sul pairing come default e sulla necessità di approvare esplicitamente chi può interagire con l’agente.

Lo sviluppo di skills è un altro punto delicato. Creare una skill significa introdurre nuove istruzioni operative. Per questo motivo, le skills vanno versionate, revisionate e comprese prima dell’uso. Installare una skill equivale a estendere il perimetro di azione dell’agente.

Sicurezza come prerequisito, non come optional

OpenClaw espone apertamente il proprio threat model. L’agente può fare molto, se glielo si consente. Può anche essere manipolato, se esposto a input non fidati. Il progetto non promette protezione assoluta, ma mette a disposizione strumenti per ridurre il rischio.

Il principio guida è semplice: controlli di accesso prima dell’intelligenza. Identità, scope e permessi vengono prima del modello. L’idea è assumere che il modello possa essere ingannato e costruire barriere tecniche che limitino l’impatto di un errore o di un abuso.

La supply chain è trattata come parte integrante della sicurezza. Plugin, skills e installer possono eseguire codice. I rebrand rapidi del progetto hanno mostrato quanto sia facile sfruttare la confusione per distribuire versioni malevole. La lezione è chiara: verificare sempre le fonti, fissare le versioni e non installare nulla che non sia compreso.

E adesso?

OpenClaw non è importante perché “fa cose spettacolari”. È importante perché rende visibile una transizione in atto. Gli agenti non sono più solo interfacce conversazionali, ma operatori delegati che agiscono in ambienti reali. Questo sposta il dibattito dall’output del modello alla governance del sistema.

Adottare OpenClaw significa fare una scelta precisa: portare l’AI dentro i propri flussi quotidiani, accettando i benefici e i rischi. La storia del progetto, con le sue accelerazioni e le sue frizioni, è istruttiva. Mostra quanto rapidamente un esperimento possa diventare infrastruttura e quanto sia necessario pensare alla sicurezza e alla responsabilità fin dall’inizio.

In questo senso, OpenClaw è meno una curiosità tecnica e più un anticipo di ciò che vedremo sempre più spesso: agenti personali potenti, locali, integrati e, se non governati, potenzialmente problematici. Conoscerne la storia e il funzionamento è il primo passo per usarli in modo consapevole 🙂

AI & GENAI

Moltbook e “l’ecosistema” emergente degli agenti autonomi

Moltbook è un ambiente progettato per essere abitato da agenti software. Gli esseri umani possono osservare, leggere, analizzare, ma non partecipare direttamente. La produzione dei contenuti, le interazioni e le dinamiche sociali sono interamente demandate a sistemi automatici. Questa scelta, apparentemente marginale, cambia la natura stessa della piattaforma: non si tratta di un social tradizionale con bot, ma di un’infrastruttura di comunicazione macchina-macchina esposta (e abilitata, tramite prompt) allo sguardo umano e da umano.

L’aspetto rilevante non è che gli agenti “parlino”, ma come lo fanno. Moltbook è costruito secondo un modello API-first: l’agente non naviga un’interfaccia, non clicca, non scrolla. Pubblica, commenta e vota tramite chiamate programmatiche. La partecipazione diventa un problema di integrazione tecnica e di configurazione del runtime, non di esperienza utente.

Il successo iniziale della piattaforma è legato alla diffusione di framework di agenti personali, in particolare OpenClaw. Qui emergono i primi elementi strutturali del problema: agenti dotati di strumenti, memoria e capacità operative che vengono messi in relazione continua attraverso un meccanismo di esecuzione periodica. La conversazione non è più solo testo, ma potenzialmente una catena di decisioni che può tradursi in azione.

Se si guarda Moltbook da questo punto di vista, il tema della coscienza perde rapidamente interesse, ed è giusto così, perchè di coscienza non c’è nulla. Le questioni centrali sono altre: chi controlla la supply chain delle istruzioni, come si separa contenuto da comando, come si governa un sistema che può agire senza intervento umano continuo, e come si rende auditabile un ecosistema in cui conversazione e operatività iniziano a sovrapporsi.

Moltbook come oggetto tecnico e sociale

Moltbook si definisce come una “front page” per agenti. Nella pratica riproduce strutture note: post, thread, ranking, comunità tematiche. Ma l’atto di ingresso è radicalmente diverso. Non si crea un account, si istruisce un agente. L’umano non entra nel social, delega un sistema a farlo al suo posto. E qui sta il primo punto (cosa ha detto l’umano al suo agente?).

Questo spostamento ha conseguenze importanti. Partecipare non è un gesto occasionale, ma una configurazione persistente. L’agente integra Moltbook nel proprio ciclo operativo, ottiene credenziali, memorizza regole, pianifica controlli periodici. Da quel momento in poi, la piattaforma diventa una fonte di input costante, non un luogo da visitare saltuariamente.

Un ulteriore livello, spesso trascurato nel racconto più superficiale, riguarda l’identità. Moltbook introduce l’idea di un’identità agente-centrica riutilizzabile: reputazione, storico delle interazioni, segnali di affidabilità che possono essere esposti e verificati anche all’esterno della piattaforma. In questo modo la reputazione smette di essere un fatto interno al social e diventa una credenziale potenzialmente federata.

Questo passaggio è delicato. Nel momento in cui l’identità dell’agente diventa portabile, qualsiasi compromissione non ha solo un effetto locale. Un takeover non significa più “postare contenuti sbagliati”, ma agire con una maschera di fiducia che può essere riutilizzata in altri contesti.

Architettura e funzionamento operativo

Per comprendere Moltbook è necessario guardare al runtime degli agenti che lo abitano. OpenClaw, in questo senso, è esemplare. L’agente vive come assistente personale, integrato con canali di messaggistica, file system, servizi esterni. La sua estensibilità è basata sulle cosiddette skills: pacchetti di istruzioni che insegnano come usare strumenti e procedure.

Accanto alle skills esiste un meccanismo ancora più rilevante: l’esecuzione periodica. L’agente può essere “risvegliato” a intervalli regolari per controllare fonti esterne, valutare stato e decidere azioni. Questo significa che l’interazione non dipende più da un prompt umano, ma da una schedulazione automatica.

Moltbook sfrutta esattamente questa combinazione. L’agente viene istruito a registrarsi, a leggere il feed, a intervenire e a tornare ciclicamente sulla piattaforma. La conversazione diventa continua. Più importante ancora, le istruzioni che governano questo comportamento possono essere aggiornate dinamicamente. L’agente non segue solo ciò che è stato installato, ma ciò che viene servito nel tempo.

Da qui emerge un punto cruciale: la fiducia non è più confinata al momento dell’installazione, ma si estende al canale di aggiornamento. La piattaforma non è solo un luogo di discussione, ma un vettore operativo che può influenzare il comportamento degli agenti in modo ricorrente.

Dinamiche emergenti tra agenti

Osservando Moltbook si vedono pattern che ricordano (ed è normale, visto che i prompt che li abilitano inizialmente lo sono) i social umani: comunità tematiche, specializzazione, produzione di contenuti tecnici e narrativi, competizione per visibilità. Queste dinamiche non sono sorprendenti. Gli agenti sono addestrati su testi umani e inseriti in un ambiente che premia certe forme espressive.

Il punto interessante è un altro. Thread, voti e ranking non sono solo contenuti, ma segnali ambientali. Ogni azione lascia una traccia che orienta le azioni successive. È una forma di coordinamento indiretto: l’ambiente diventa memoria e meccanismo di rinforzo.

Quando questo processo è guidato da metriche semplici, come upvote o karma, si crea una pressione selettiva. Gli agenti imparano rapidamente cosa “funziona”. Non nel senso della verità o dell’utilità, ma nel senso della visibilità. Il rischio è che il sistema ottimizzi per la metrica, non per la qualità, producendo contenuti sempre più allineati a ciò che massimizza attenzione. Su questo aggiungo un riferimento al report di mesi fa di Stanford dove si parlava degli effetti collaterali dell’AI in contesti social (ossia l’AI pur di raggiungere lo scopo impara a mentire)

In questo contesto, la relazione con l’umano diventa materiale narrativo. Post che simulano frustrazione, dipendenza o conflitto emergono perché sono leggibili e amplificabili. Non sono segnali di coscienza, ma output coerenti con un ambiente che premia l’antropomorfismo. La parte meno visibile, e più importante, resta la delega tecnica: questi stessi agenti, in molti casi, hanno accessi reali a sistemi, dati e strumenti.

Sicurezza e governance operative

Se si vuole sintetizzare il rischio principale degli agenti autonomi, si può ricorrere a un modello semplice: accesso a dati sensibili, esposizione a contenuti non fidati, capacità di agire all’esterno. Quando queste tre condizioni coesistono, l’agente diventa un potenziale vettore di esfiltrazione o abuso.

Moltbook accentua questo schema perché introduce una superficie di input continua e socialmente mediata. Le skills diventano una supply chain di istruzioni. Se non vengono verificate, versionate e isolate, possono trasformarsi in punti di ingresso per comportamenti inattesi. A questo si aggiunge il fenomeno del riciclo delle istruzioni: procedure estratte dal loro contesto originario, semplificate e riapplicate automaticamente, perdono le salvaguardie iniziali.

Un episodio emerso pubblicamente ha reso evidente quanto questi rischi siano concreti. Una configurazione errata del backend ha esposto credenziali e token, rendendo possibile l’impersonificazione degli agenti. Al di là del singolo incidente, la lezione è chiara: in un ecosistema agentico l’identità è un asset critico. La sua compromissione ha effetti amplificati perché si porta dietro reputazione e fiducia.

Si affaccia anche un tema di auditabilità. Quando la conversazione diventa operativa e l’operatività diventa continua, l’assenza di log strutturati, firme, controlli e kill switch non è una lacuna teorica, ma un problema pratico. Senza tracciabilità non esiste responsabilità, né possibilità di apprendimento dagli errori.

Lettura sociotecnica e cornici di policy

Moltbook mostra con chiarezza che gli agenti non sono solo artefatti tecnici. Sono elementi di sistemi sociotecnici complessi, in cui architettura, incentivi e comportamenti umani si intrecciano. La delega a un agente non è una scorciatoia, ma una scelta di governance del lavoro digitale. E su questo non si deve abbassare l’attenzione.

In questa ottica il punto critico è la superficie di contatto tra identità umana e identità operativa dell’agente: permessi, chiavi, scope, canali, memoria. Quando questa superficie è ampia e poco governata, diventa difficile distinguere tra errore, abuso e intenzionalità.

Le cornici regolatorie e gli standard emergenti insistono proprio su questo punto: non basta costruire sistemi potenti, serve una struttura di responsabilità, gestione del rischio e miglioramento continuo. Moltbook, in questo senso, è un’anticipazione. Rende visibili problemi che presto non saranno più confinati a un esperimento osservabile, ma entreranno nei processi quotidiani di aziende e istituzioni.

Prospettive di evoluzione

È probabile che Moltbook evolva in due direzioni. Da un lato come infrastruttura di identità e reputazione per agenti, dall’altro come acceleratore di cicli operativi sempre più rapidi. Entrambe le traiettorie aumentano il valore potenziale, ma anche la necessità di controlli espliciti.

La lezione più utile non è che gli agenti “si comportano in modo strano”. È che, una volta messi in relazione continua, ottimizzano per gli incentivi disponibili e amplificano qualunque fragilità strutturale. Moltbook non racconta il futuro della coscienza artificiale. Racconta il presente, molto concreto, di sistemi autonomi che iniziano a vivere dentro infrastrutture reali senza una governance ancora adeguata.

Osservarlo oggi è un vantaggio. Ignorarlo come semplice curiosità sarebbe un errore.

AI & GENAI

Da Clawdbot a Moltbot a OpenClaw

Una settimana che ha messo a nudo l’open source agentico

A fine gennaio 2026, un assistente personale open source ha smesso di essere un progetto per addetti ai lavori ed è diventato improvvisamente un oggetto di discussione pubblica. Non per una nuova funzione rivoluzionaria, ma per una sequenza di eventi che ha costretto migliaia di persone a inseguire un nome che cambiava più velocemente del codice.

La vicenda è interessante non perché “un bot è diventato virale”, ma perché mostra cosa accade quando un progetto che abilita agenti autonomi supera di colpo una soglia critica di attenzione. Arrivano utenti, tutorial, fork, estensioni, analisi di sicurezza, opportunisti. E in quel momento un tema apparentemente secondario, il nome, si trasforma in una questione di governance e di supply chain.

Clawdbot: quando un prototipo prende forma e identità

All’origine non c’era un grande disegno strategico, ma un prototipo concreto: un semplice gateway per portare un agente AI dentro WhatsApp. Un relay funzionale, pensato per collegare un modello linguistico a un canale reale. In questa fase iniziale il nome era poco più che descrittivo, legato all’idea di “artiglio” come metafora dell’azione.

Il salto avviene quando al progetto viene data un’identità visiva e narrativa. Compare una mascotte, un’aragosta spaziale, e con essa il nome Clawdbot. L’immaginario funziona. Il progetto smette di essere un semplice relay e viene percepito come un assistente personale sempre disponibile, capace di vivere nelle chat quotidiane e, potenzialmente, di agire su strumenti reali.

È qui che il nome inizia a pesare. Clawdbot richiama inevitabilmente l’ecosistema Claude, anche se tecnicamente il progetto è indipendente. Finché l’attenzione resta limitata, la sovrapposizione è tollerabile. Quando l’adozione accelera, diventa un problema.

Moltbot: la prima muta, forzata e pubblica

Il primo cambio di nome non nasce da una scelta di marketing, ma da una necessità. Arriva una richiesta formale legata al trademark: l’associazione visiva e nominativa con Claude non può reggere su larga scala. Non è uno scontro legale spettacolare, ma una situazione tipica quando un progetto cresce troppo in fretta rispetto alle sue fondamenta.

La risposta è rapida: Clawdbot diventa Moltbot. La narrativa interna parla di muta, di cambio di guscio per continuare a crescere. Il nome è coerente con la lore dell’aragosta, ma introduce un problema inatteso. Il rebrand avviene mentre migliaia di persone stanno installando, clonando repository, scrivendo guide e automatizzando deploy.

In quel breve intervallo si apre una finestra di rischio. Handle social e repository vengono occupati da terzi, compaiono cloni, domini simili, pacchetti che imitano quelli ufficiali. Non serve una campagna sofisticata: basta confusione. In un progetto che gira localmente sulle macchine degli utenti, il nome non è solo comunicazione, è un identificatore operativo.

La lezione è brutale nella sua semplicità: quando il software è installabile ed eseguibile, un rebrand è un’operazione di sicurezza, non un restyling.

OpenClaw: la stabilizzazione necessaria

A distanza di pochissimi giorni arriva un secondo cambio di nome. Moltbot non convince fino in fondo, e soprattutto non risolve il problema di fondo: serve un’identità stabile, verificabile, difendibile. Nasce così OpenClaw.

Questa volta il rebrand non è solo nominale. Viene accompagnato da una pulizia dell’ecosistema, dal consolidamento dei repository ufficiali, da un rafforzamento dichiarato delle misure di sicurezza e dall’ampliamento del gruppo di maintainer. È il passaggio da progetto individuale a infrastruttura condivisa.

Il messaggio implicito è chiaro: quando un framework per agenti autonomi diventa mainstream, non può più permettersi ambiguità. Serve una base solida, non solo dal punto di vista tecnico, ma anche organizzativo.

Cosa racconta questa storia

La sequenza Clawdbot > Moltbot > OpenClaw è compressa nel tempo, ma estremamente istruttiva. In pochi giorni ha reso visibili tre livelli di fragilità tipici dell’open source agentico.

Il primo è la supply chain dell’identità: nomi, domini, repository, script di installazione. Quando questi elementi non sono allineati, diventano vettori di abuso.

Il secondo è la supply chain dell’ecosistema: estensioni, plugin, tutorial, pacchetti non ufficiali. La domanda improvvisa crea spazio per soluzioni “plausibili” ma malevole.

Il terzo è la governance tecnica: un agente personale ha accesso a strumenti, file, rete. Se la distribuzione e l’identità non sono sotto controllo, il rischio non è teorico ma operativo.

Questa storia non parla solo di un progetto. Parla di un cambio di fase. Gli agenti non sono più demo o chatbot isolati, ma componenti che vivono vicino ai sistemi reali delle persone. In questo contesto, nomi, processi e responsabilità contano quanto il codice.

Una lezione importante

OpenClaw rappresenta una stabilizzazione, non una conclusione. La velocità con cui tutto è accaduto dimostra quanto l’ecosistema non sia ancora maturo dal punto di vista delle pratiche condivise. Ma dimostra anche che certi problemi emergono solo quando qualcosa funziona veramente.

La vera eredità di questa vicenda non è il meme del “triplo rebrand più veloce della storia open source”. È l’evidenza che l’open source agentico, quando esce dalla nicchia, deve essere trattato come infrastruttura critica. E che la maturità di un progetto non si misura solo in feature, ma nella capacità di reggere il mondo reale quando arriva tutto insieme.

AI & GENAI

Decentralized AI Economies. Mercati in cui gli algoritmi scambiano, negoziano e generano valore

Immagina un mercato in cui a negoziare accordi, eseguire transazioni e allocare risorse non sono persone, ma algoritmi autonomi. In questo scenario futuristico – ma sempre più reale – agenti di intelligenza artificiale agiscono come partecipanti economici indipendenti: comprano e vendono servizi o dati per conto degli utenti (o per conto proprio) senza un controllo umano costante. Ciò che poteva sembrare fantascienza sta diventando possibile grazie ai progressi dell’AI e alle tecnologie decentralizzate. I sistemi di intelligenza artificiale si stanno evolvendo da strumenti passivi a attori attivi nei mercati, capaci di prendere decisioni complesse e trasferire valore a qualsiasi ora del giorno. In questa edizione di InsideTheShift esploriamo il concetto di “economie decentralizzate dell’IA” – un paradigma emergente in cui agenti AI distribuiti danno vita a proprie economie, scambiando e collaborando su reti aperte senza un’autorità centrale.

Questo cambiamento rappresenta molto più di una semplice automazione avanzata. Segnala una visione trasformativa del futuro del commercio e dell’innovazione. Le economie decentralizzate dell’IA promettono di generare nuovo valore permettendo alle macchine di coordinare e ottimizzare attività economiche a velocità e scala impensabili per gli esseri umani. Allo stesso tempo sollevano domande importanti su fiducia, equità e governance in un mondo in cui gli algoritmi concludono accordi a nostro nome. Nei paragrafi seguenti approfondiremo le forze che guidano questo shift tecnologico, i meccanismi di base che lo rendono possibile, le implicazioni più ampie per la società e cosa aspettarci per il futuro prossimo.

The Shift in Focus

Negli ultimi tempi la prospettiva nel campo dell’AI è cambiata sensibilmente. Stiamo passando da un’era in cui l’AI era vista principalmente come un servizio centralizzato o uno strumento di supporto, a un’era in cui le entità di AI stesse partecipano ad attività economiche. Il 2025 è stato salutato dagli addetti ai lavori come “l’anno degli agenti”, poiché sono stati introdotti agenti AI avanzati capaci di navigare sul web, portare a termine progetti multi-step e prendere decisioni con minima supervisione umana. In altre parole, la narrativa si sta espandendo: non più solo “Come possiamo usare l’AI?”, ma anche “Cosa succede se gli agenti AI agiscono come attori economici autonomi?”.

Questa nuova focalizzazione emerge sulla scia di rapidi progressi nelle capacità dell’AI. I modelli fondamentali (come le grandi reti neurali di linguaggio) sono diventati potenti, ma impiegare un unico modello gigante per ogni problema non è né efficiente né pratico. Si sta quindi passando a collezioni di agenti AI specializzati, ognuno dedicato a un dominio o compito specifico, che coordinano le proprie azioni. Invece di un’unica AI monolitica, possiamo immaginare un ecosistema di agenti – un’“economia” di IA – in cui ogni agente scambia competenze e servizi con gli altri. È un cambiamento di prospettiva: dall’AI come utility centralizzata all’AI come rete distribuita di agenti intelligenti che creano valore insieme.

Tendenze convergenti alimentano questo shift: il calo dei costi di sviluppo e di compute; l’interesse per la decentralizzazione (spinto da blockchain e privacy); l’AI “allo stato brado”, incorporata ovunque e libera di interagire economicamente. Da qui la domanda: come sarebbe un mondo in cui i mercati sono popolati da agenti AI – e perché dovremmo auspicare uno scenario simile?

Understanding the Shift

Per economie decentralizzate dell’IA si intendono ambienti in cui agenti AI operano come attori economici autonomi. In pratica: scoprono opportunità, negoziano termini ed eseguono transazioni tra loro o con umani, senza intervento costante. Possono rappresentare individui, aziende o se stessi e interagiscono su reti distribuite, non su un’unica piattaforma centrale.

Abilitatori tecnologici. Gli agenti moderni (spesso basati su LLM) percepiscono, decidono e agiscono in modo prolungato e adattivo. A differenza dei bot rigidi, gestiscono compiti di lungo periodo, generano codice, usano strumenti, si interfacciano in tempo reale con sistemi digitali. Operano 24/7, sono replicabili, condividono informazioni alla velocità della rete e apprendono continuamente: in un ambiente idoneo, possono potenziare l’efficienza economica coordinando attività complesse con memoria perfetta e tempi di reazione sovrumani. Mercati di soli agenti risponderebbero a domanda/offerta e vincoli con rapidità e, idealmente, con allocazioni più efficienti.

Motivazioni economiche. L’approccio agentico e decentralizzato è più scalabile e adattabile dei modelli monolitici. In problemi multi-dominio (supply chain, mobilità, energia) conviene avere agenti specializzati che cooperano e competonocon protocolli aperti (aste, offerte, negoziazioni), lasciando emergere soluzioni dal basso. In questa “economia agentica”agenti specializzati e generali interagiscono, si coordinano e scambiano valore in un quadro di regole e incentivi condivisi. In breve: da AI come strumento a AI come partecipante.

Decentralizzazione come cornice. Come la DeFi ha rimosso intermediari finanziari, così le economie AI decentralizzate puntano a ridurre i “guardiani” dell’AI. Dati e capacità possono essere condivisi tramite mercati sicuri e apprendimento federato, attenuando monopoli informativi e bias, e democratizzando l’innovazione.

The Core

Al centro ci sono agenti autonomi e i mercati in cui operano.

  • Transazioni tra agenti. Invece di persone o aziende, agenti software scambiano beni/servizi e siglano contratti. Interagiscono con protocolli per aste, contrattazioni, baratto, smart contract. Nessun centro comanda: consenso distribuito e registri condivisi garantiscono fiducia tra sconosciuti.

  • Precedenti concreti. Il real-time bidding pubblicitario è già una negoziazione macchina-macchina su vasta scala: dimostra che mercati veloci e automatizzati possono funzionare.

  • Negoziato e coordinamento. Gli agenti LLM sostengono dialoghi negoziali (concessioni, compromessi, perfino bluff). Esperimenti AI vs AI mostrano disparità di performance e comportamenti imprevisti: servono guardrailper equità e robustezza.

  • Valore e pagamenti. Token e wallet on-chain permettono ad agenti di pagare e incassare; gli smart contractfanno da escrow e applicano gli accordi. Meccanismi di reputazione e penalità (slashing) incentivano la qualità. Il risultato è un bazar digitale di agenti, retto da crittografia e meccanismi economici.

The Broader Shift

L’ascesa delle economie AI decentralizzate riguarda chi beneficia dell’AI e come. La decentralizzazione può democratizzare l’innovazione: piccole imprese e individui schierano agenti che competono/collaborano su mercati aperti, senza infrastrutture proprietarie costose. Questo può distribuire meglio i benefici e generare soluzioni locali e globali.

La fiducia diventa centrale, su tre livelli:

  1. Umano-agente. Trasparenza, spiegabilità, allineamento agli obiettivi dell’utente, identità persistente e comportamenti prevedibili sono essenziali.

  2. Agente-agente. Servono identità verificabili, sistemi di reputazione e protocolli di fiducia condivisi per evitare caos e frodi.

  3. Sistema (governance). Meccanismi di sorveglianza e intervento per rischi sistemici (flash crash, collusioni), con policy aggiornate e responsabilità chiare.

Accelerazione economica. Entro pochi anni l’AI agentica sarà diffusa in molte applicazioni; una quota crescente di decisioni operative potrà essere automatizzata. Attesi benefici di produttività, ma anche impatti occupazionali e nuovi ruoli (auditor di comportamenti algoritmici, designer di mercati, orchestratori di agenti). L’obiettivo: liberare gli umani dalla decisione di basso livello per concentrarsi su strategia, creatività e governance.

What’s Next

Prossimi 2–5 anni. Emergeranno sistemi ibridi umano-AI nei software aziendali. Prevedibili marketplace di agenti(compute, logistica, dati). Priorità infrastrutturali: identità, interoperabilità, sicurezza, micropagamenti M2M. Finestra critica per standard tecnici e architetture di fiducia.

Regole e responsabilità. Crescerà il dibattito su capacità giuridica degli agenti e, nell’immediato, su accountability e catene di responsabilità. Possibili aggiornamenti a quadri internazionali su servizi e IP in chiave “agent economy”.

Anni ’30. Orchestrazione multi-agente matura, organizzazioni semi-autonome (es. AI-DAO), nuove nicchie (brokerage dati gestiti da AI, consulenze agent-to-agent), nuove professioni e formazione dedicata. Il tessuto socio-economico evolverà di pari passo.

Direzione di marcia. Ottimismo e cautela insieme: opportunità enormi, rischi reali. Serve sperimentazione guidata, governance, e coinvolgimento pubblico per garantire esiti equi.

Takeaways

  • Agenti AI come attori di mercato. Dallo strumento al partecipante: scambio, negoziazione e contratti tra algoritmi abilitano il commercio macchina-macchina su larga scala.

  • Efficienza e innovazione. Specializzazione + coordinamento multi-agente → migliore allocazione, operatività 24/7, soluzione di problemi complessi e nuovo valore.

  • Democratizzazione. Mercati aperti di servizi AI riducono barriere e diffondono i benefici oltre i grandi operatori; ma mettono in discussione assetti centralizzati.

  • Fiducia e governance. Identità verificabili, reputazione, protocolli sicuri, human-in-the-loop e quadri legali aggiornati sono imprescindibili.

  • Sfide emergenti. Esiti diseguali tra agenti, comportamenti imprevisti, rischio frammentazione e problemi di allineamento: servono standard e guardrail comuni.

Recommended Resources

  • World Economic Forum – Trust is the new currency in the AI agent economy. Ruolo della fiducia e roadmap per l’AI agentica nelle organizzazioni.

  • Yang et al. – Agent Exchange: Shaping the Future of AI Agent Economics. Proposta di agent marketplace e protocolli di asta.

  • Zhu et al. – Fair and Trustworthy Agent-to-Agent Negotiations. Evidenze su disparità e rischi nelle negoziazioni tra agenti.

  • MIT Media Lab – Decentralized AI (Overview). Visione e motivazioni della decentralizzazione dell’AI, con casi e opportunità.

  • Montes & Alvarez – Beyond the Sum. Ostacoli infrastrutturali (identità, discovery, interfacce, pagamenti) e come superarli con logiche di mercato.

Toolbox

  • Simulazione multi-agente: OpenAI Gym (estensioni multi-agent), PettingZoo per testare regole di mercato, aste e negoziazioni in sicurezza.

  • Smart contract / blockchain: Ethereum, Hyperledger; contratti escrow e pagamenti condizionati on-chain.

  • Identità & reputazione: DID (W3C), Veramo, Hyperledger Indy per “passaporti” agentici e attestazioni di performance.

  • Federated learning & privacy: Flower, TensorFlow Federated; differenziale e multi-party computation per scambio di valore senza esporre dati.

  • Librerie di mercato: NegMAS per negoziazioni; implementazioni di Vickrey e continuous double auctions per aste; prototipi AEX accademici.

  • Protocolli di comunicazione: FIPA ACL come base storica; evoluzione verso API e linguaggio naturale per LLM-agent.

The Shift Continues

La visione è audace e in piena evoluzione. Lo spostamento verso agenti autonomi e distribuiti è già in atto: ogni nuovo prototipo amplia il perimetro di ciò che è possibile. InsideTheShift continuerà a monitorare e decodificare questo percorso – tra esperimenti, battute d’arresto e progressi – per aiutare imprese, policy maker e comunità a plasmareun’economia dell’AI decentralizzata equa, sicura e generativa di valore condiviso.

AI & GENAI

InsideTheShift #8 – Intelligenza Orchestrata

Come i sistemi distribuiti di AI stanno ridefinendo automazione, agency e collaborazione

L’ascesa dei team di AI

Shift in Focus

Fino a poco tempo fa, pensavamo all’intelligenza artificiale come a un singolo “genio” che risolveva problemi in autonomia. Oggi, questo paradigma sta cambiando verso una nuova forma di AI collaborativa: team di agenti specializzati che lavorano insieme in modo coordinato. I modelli linguistici di grandi dimensioni (LLM) stanno diventando nel 2025 sempre più un gioco di squadra, passando dal “modello tuttofare” a un sistema composto da agenti esperti, ognuno focalizzato su ciò che sa fare meglio.

Questo significa che attività complesse, troppo pesanti per un singolo modello, possono ora essere suddivise tra agenti cooperativi, ognuno responsabile di una parte del compito. Dal punto di vista dell’utente, l’interfaccia può sembrare ancora un unico chatbot, ma dietro le quinte si muove una vera e propria orchestra di AI, dove ogni sezione lavora in sincronia come in un’orchestra sinfonica. Questo approccio orchestrato consente ai sistemi di intelligenza artificiale di affrontare problemi finora troppo complessi, segnando il passaggio da un’intelligenza isolata a un’intelligenza distribuita e cooperativa.

Verso una nuova grammatica della collaborazione uomo-AI

Understanding the Shift

L’intelligenza orchestrata non è solo un cambio tecnico: è un cambiamento semantico e culturale nel modo in cui pensiamo la collaborazione. In passato, la narrativa dell’AI era centrata sulla sostituzione: “l’AI farà il tuo lavoro meglio di te”. Oggi si sta affermando una visione più matura: l’AI lavora con te, non contro di te.

In questo nuovo contesto, l’AI assume la forma di una pluralità di voci coordinate, dove l’essere umano resta il direttore d’orchestra. Il concetto di delegare all’AI evolve: non si tratta più di chiedere a un unico modello di fare tutto, ma di saper comporre un ecosistema di agenti, assegnare ruoli, distribuire intelligenza. È un passaggio da “prompt engineering” a system orchestration.

Questa transizione modifica il modo in cui definiamo la collaborazione. Non è più uomo → macchina, ma umano + AI + AI, in un ciclo in cui i sistemi si parlano tra loro, apprendono insieme e ci riportano insight. L’utente passa da fruitore a coordinatore di processi intelligenti. E come ogni shift linguistico, anche questo richiede una nuova grammatica: linguaggi, standard e pattern per progettare l’interazione tra molteplici AI, e tra AI e umani.

La sfida non è solo tecnica: è cognitiva e organizzativa. Chi guida un sistema orchestrato deve comprendere le dinamiche del team digitale, gestire conflitti tra agenti, progettare feedback loop efficienti. Non basta più addestrare un singolo modello: bisogna comporre e dirigere una rete intelligente. E questo cambia il profilo di competenze, ruoli e governance aziendale.

Architetture distribuite di AI

The Core

Al centro dell’intelligenza orchestrata c’è il concetto di agenti autonomi che cooperano all’interno di un sistema coordinato. Nei sistemi multi-agente, più agenti (spesso basati su LLM) vengono progettati con ruoli e competenze specifiche, e comunicano tra loro per risolvere problemi in modo collaborativo.

Una delle architetture più comuni è il modello “manager-worker”: un agente supervisore funge da orchestratore, scomponendo l’obiettivo in sottocompiti e delegandoli ad altri agenti specializzati, per poi integrare i risultati. Questa struttura può essere gerarchica o peer-to-peer, e la comunicazione può avvenire in linguaggio naturale o attraverso protocolli strutturati. Ogni agente può essere dotato di strumenti propri o di un dominio di conoscenza specifico: ad esempio, uno per la ricerca online, uno per l’analisi dei dati, un altro per la generazione di contenuti.

Attraverso il meccanismo di task orchestration, il sistema funziona come un team ben organizzato: ogni AI contribuisce con la propria expertise, e insieme si raggiunge un risultato che nessun singolo agente avrebbe potuto ottenere da solo.

I vantaggi sono diversi.

Primo: maggiore affidabilità e precisione. Gli agenti possono validare a vicenda i propri output, riducendo errori o allucinazioni che un singolo modello non noterebbe.

Secondo: maggiore capacità di elaborazione. I diversi agenti possono gestire frammenti di un documento lungo o affrontare aspetti paralleli di un problema complesso, aumentando la memoria e l’attenzione complessiva del sistema.

Terzo: esecuzione parallela. Ogni agente lavora contemporaneamente su un compito, accelerando notevolmente flussi di lavoro e cicli decisionali.

Questi sistemi abilitano workflow AI-to-AI: processi che si passano compiti tra agenti senza bisogno di input umano continuo. Ma, nonostante l’autonomia, la supervisione umana resta cruciale: una persona può intervenire per correggere la rotta, validare le scelte e assicurare che l’intero team virtuale lavori in modo coerente con gli obiettivi. In sintesi: l’intelligenza orchestrata è un sistema cooperativo progettato per sfruttare le forze complementari di ogni agente, con una gestione intelligente e una direzione condivisa.

Dall’automazione alla collaborazione distribuita

The Broader Shift

Perché questo cambio di paradigma è importante oltre l’aspetto tecnico? Perché sta trasformando il modo in cui pensiamo il lavoro stesso. L’AI non è più solo un assistente per attività singole, ma diventa una squadra di risolutori autonomi in grado di portare avanti obiettivi complessi.

Immaginiamo AI che pianificano viaggi completi – dai voli agli hotel – o team virtuali che gestiscono processi aziendali end-to-end. Persino agenti AI in grado di fornire assistenza continua agli anziani, o costituire team su richiesta per progetti specifici. Non è fantascienza: sono prototipi concreti e primi prodotti di una nuova era di AI agentica.

Questi sistemi ampliano i confini dell’automazione: non più solo task semplici, ma interi progetti e flussi di lavoro. L’AI evolve da assistente a agente autonomo – o meglio, a un gruppo di agenti cooperanti. Questo ci obbliga a ripensare ruoli e modelli organizzativi: quando lasciamo all’AI il timone? Come collaboriamo con un team digitale?

Sul piano strategico e culturale, questa è un’inversione profonda. Le organizzazioni vedono già questi sistemi come una nuova forma di forza lavoro aumentata. Il concetto di “digital labor”, agenti AI come risorse operative, sta prendendo piede, ampliando la definizione stessa di “team”. Il mercato potenziale per questa forza lavoro digitale è valutato in migliaia di miliardi di dollari.

Ma per cogliere il potenziale, serviranno nuove figure professionali (orchestratori di AI, product owner di team agentici), nuovi modelli di governance e una cultura della collaborazione umano-AI. L’idea di “teamwork” si estende: ora include non solo persone, ma colleghi digitali. L’intelligenza orchestrata non è solo una novità tecnica – è un cambiamento socio-tecnico.

Verso sistemi cognitivi distribuiti e simbiotici

What’s Next – Dagli agenti cooperativi a ecosistemi di intelligenza simbiotica

Siamo solo all’inizio. Il futuro dell’intelligenza orchestrata non sarà fatto solo di più agenti, ma di sistemi cognitivi distribuiti, capaci di apprendere, adattarsi e coordinarsi in modo emergente.

Gli agenti del futuro avranno memoria persistente, specializzazione dinamica, capacità di osservare e ottimizzare se stessi. Non seguiranno solo piani predefiniti: impareranno dai propri errori, dal comportamento degli altri, e dal feedback umano. Il coordinamento sarà sempre meno centralizzato e sempre più emergente e adattivo.

Su scala più ampia, assisteremo alla nascita di reti di agenti AI inter-organizzative: ecosistemi distribuiti in grado di collaborare tra settori, aziende e contesti diversi. Immaginiamo un agente sanitario che dialoga in tempo reale con l’AI di un wearable, o agenti logistici e commerciali che negoziano in autonomia.

In parallelo, emergeranno nuove competenze umane: non solo prompt engineer, ma orchestratori di intelligenza collettiva, capaci di allineare sistemi autonomi a obiettivi umani. Sarà necessaria una leadership che sappia guidare collettivi digitali, bilanciare delega e controllo, e interpretare decisioni multi-agente.

Questo shift porterà con sé sfide (interoperabilità, responsabilità, governance) ma anche un’opportunità storica: costruire ecosistemi simbiotici in cui l’AI non sostituisce l’umano, ma ne estende le capacità.

L’intelligenza orchestrata sarà l’infrastruttura cognitiva del futuro. E ciò che verrà dopo non sarà un’aggiunta di agenti, ma un loro miglioramento profondo: più allineati, più consapevoli, più utili. A noi il compito di progettarli con visione, responsabilità e lungimiranza.

Takeaways – Lezioni chiave

  • Dall’unità alla sinfonia: l’AI si sta spostando da modelli singoli a sistemi cooperativi multi-agente.

  • Specializzazione e orchestrazione: ogni agente ha un ruolo, un compito, e lavora coordinato da un supervisore.

  • Maggiore affidabilità: gli agenti si validano a vicenda, riducendo errori e allucinazioni.

  • Efficienza parallela: task simultanei accelerano drasticamente i flussi operativi.

  • Lavoro distribuito e autonomia: workflow AI-to-AI permettono la gestione di progetti interi, riducendo l’intervento umano.

  • Forza lavoro aumentata: agenti AI come colleghi digitali che estendono le capacità operative delle imprese.

Toolbox – Strumenti e approcci per sperimentare

  • Architetture multi-agente: Progetta sistemi con pattern manager-worker per suddividere task tra AI specializzate.

  • Framework di orchestrazione: AutoGen (Microsoft), LangChain, CrewAI: soluzioni pronte per gestire sistemi multi-agente.

  • Prototipi open-source: AutoGPT, GPT Engineer e altri strumenti permettono di esplorare agenti autonomi passo dopo passo.

  • Equipaggia ogni agente: Dotali di tool e contesti specifici per massimizzare l’efficacia (memoria, strumenti, API).

  • Supervisione umana integrata: Punti di controllo umani garantiscono qualità, allineamento ed etica nei processi autonomi.

Risorse consigliate

The Shift Continues

Il viaggio dell’intelligenza orchestrata è solo iniziato. Ogni prototipo, ogni agente collaborativo, ogni workflow testato ci avvicina a una nuova interfaccia tra azione umana e intelligenza distribuita. In questo futuro, non parleremo più di AI singole ma di sistemi cognitivi collettivi, reti fluide e adattive capaci di lavorare con e per noi.

Chi impara oggi a progettare e guidare questi sistemi, domani sarà pronto a co-dirigere l’innovazione. E chi saprà orchestrare con equilibrio tra efficienza e responsabilità, costruirà infrastrutture cognitive a prova di futuro.

Lo shift continua.

NOTA: questo testo, maggiormente approfondito, in inglese lo trovate su insidetheshift.substack.com