Framework Eliza nel 2026: come funziona e se conviene costruirci

Il 4 agosto 2026 il fondatore di Eliza Labs, Shaw Walters, ha affidato a X una frase che suonava come un epitaffio: il token era «morto, completamente», e la fondazione dietro il progetto stava chiudendo i battenti. Due settimane dopo quel messaggio, il repository del framework Eliza riceveva ancora commit quasi ogni giorno, superava le 19 mila stelle su GitHub e veniva forkato da team di infrastruttura di primo piano come Nethermind e Automata Network. Nel frattempo una società quotata annunciava un prodotto commerciale costruito proprio sopra quel codice.

È la contraddizione che definisce Eliza nel 2026: il token che ne portava il nome vale ormai una manciata di decimillesimi di euro, mentre il software non è mai stato così attivo. Per questo la domanda che conta oggi non è più che cosa sia successo al token, una vicenda ormai chiusa che abbiamo ricostruito in dettaglio altrove. La domanda è tecnica: come funziona davvero il framework, perché è diventato lo stack di riferimento per gli agenti AI on-chain e se convenga ancora costruirci sopra ora che l’incentivo speculativo che lo aveva reso celebre è sparito. Questa guida prova a rispondere, con un occhio a ciò che cambia per chi sviluppa o fa impresa in Italia.

Che cos’è il framework Eliza (e cosa non è)

Eliza è un framework open source scritto in TypeScript per costruire agenti AI autonomi: software che percepisce un contesto, ragiona con un modello linguistico, mantiene una memoria persistente e agisce, anche firmando transazioni on-chain con un proprio wallet. Il repository ufficiale, github.com/elizaOS/eliza, è distribuito con licenza MIT e si descrive come «il tuo sistema operativo agentico». La differenza tra un agente di questo tipo e un normale bot di trading è la catena decisionale: non esegue una regola scritta a mano, ma interpreta il contesto e sceglie come agire.

Distinguere il framework dal token è il primo passo per capire la storia. Il progetto nasce nell’ottobre 2024 come ai16z, una parodia del fondo di venture capital a16z lanciata su Solana; il clamore intorno al token porta la capitalizzazione, al culmine di inizio 2025, nell’ordine dei miliardi di dollari. Poi arrivano il rebrand in elizaOS, la causa collettiva, la migrazione del token e, il 4 agosto 2026, la dichiarazione di morte e la chiusura della fondazione. Oggi ELIZAOS scambia intorno a 0,00016 euro, con una capitalizzazione di poco superiore a 1,2 milioni di euro, secondo CoinGecko: più del 99% sotto quel culmine.

Il framework, però, è un artefatto diverso dal token. È codice sotto licenza permissiva: chiunque può scaricarlo, eseguirlo, modificarlo e distribuirlo, con o senza il token. Questa è la ragione per cui può sopravvivere alla sua morte finanziaria, e il resto di questa guida spiega che cosa quel codice fa esattamente.

Il runtime: il cuore che tiene insieme l’agente

Al centro di ogni agente Eliza c’è il runtime, l’orchestratore che collega tutti i pezzi. Non è il modello linguistico, ed è una distinzione importante: il modello (GPT, Claude o un modello locale) è solo uno dei componenti che il runtime coordina. Il runtime gestisce il ciclo di vita dell’agente, il flusso dei messaggi, l’accesso alla memoria, il caricamento dei plugin e la registrazione di tutte le capacità disponibili.

Il funzionamento segue un ciclo ricorrente. Arriva un messaggio (da Discord, da Telegram, da X o da una API); il runtime recupera dalla memoria le informazioni rilevanti; raccoglie lo stato corrente attraverso i Providers; compone un contesto e lo passa al modello; il modello sceglie una o più Actions da eseguire; il runtime le esegue; infine gli Evaluators analizzano l’interazione e aggiornano la memoria. Questo ciclo, ripetuto migliaia di volte, è ciò che trasforma un modello linguistico privo di stato in un agente che sembra avere continuità e intenzione.

La documentazione ufficiale sintetizza la filosofia in una riga: «parti da un file di personaggio, arriva a milioni di interazioni». Il runtime è la macchina che rende possibile quella scala, tenendo insieme componenti che altrimenti sarebbero scollegati.

Vale la pena notare che nel 2026 Eliza non è più soltanto una libreria. Il repository principale raccoglie un intero stack: il runtime, un’applicazione con interfaccia grafica, una CLI a riga di comando, i servizi cloud per il deployment e i plugin di prima parte. È il segno di un’ambizione iscritta nel nome stesso del progetto, quel sistema operativo agentico che punta a diventare l’ambiente standard in cui gli agenti nascono, girano e vengono distribuiti.

Il character file: l’identità dell’agente in un file

Se il runtime è il motore, il character file è la carta d’identità dell’agente. È un file (di solito in formato JSON o TypeScript) che dichiara chi è l’agente e come si comporta: il nome, una biografia, i tratti di personalità e di stile, un corpo di conoscenza di base, i plugin da caricare e il provider di modello da usare.

La scelta progettuale è deliberata: la personalità e le competenze di un agente sono dati, non codice. Cambiare il tono di un agente, aggiungergli una nuova fonte di conoscenza o dargli un nuovo canale non richiede di riscrivere il runtime, ma di modificare il file di personaggio o aggiungere un plugin. Questo abbassa moltissimo la barriera d’ingresso: un team può clonare il repository, scrivere un character file e avere un agente funzionante in poche ore anziché in settimane.

È anche il motivo per cui gli agenti Eliza più noti, dai bot di trading agli account social autonomi, condividono la stessa ossatura tecnica pur avendo personalità diversissime. Sotto la maschera del personaggio girano lo stesso runtime e gli stessi quattro primitivi.

I quattro primitivi: Actions, Providers, Evaluators, Services

Tutto ciò che un agente Eliza sa fare si riduce a quattro tipi di componenti, i cosiddetti primitivi. Capirli è la chiave per capire il framework, perché ogni plugin non è altro che un pacchetto che ne registra uno o più.

• Actions: le capacità operative. Un’Action è qualcosa che l’agente può fare, come inviare un token, pubblicare un post, chiamare una API esterna o eseguire uno swap. È il modello a decidere quale attivare, ma è lo sviluppatore a definirne il perimetro.
• Providers: iniettano contesto e stato nel prompt prima che il modello decida. Un Provider può fornire il saldo del wallet, l’ora corrente, i prezzi di mercato o i fatti pertinenti recuperati dalla memoria. Sono gli occhi e le orecchie dell’agente.
• Evaluators: entrano in gioco dopo la risposta. Analizzano l’interazione appena conclusa per estrarne conoscenza, per esempio individuando i fatti da salvare in memoria o valutando se un obiettivo è stato raggiunto. Sono la capacità di riflessione dell’agente.
• Services: connessioni e processi di lunga durata verso il mondo esterno, come il client che tiene aperta la connessione a Discord o a un nodo blockchain.

Questa architettura a quattro primitivi è ciò che rende Eliza estensibile in modo ordinato: qualsiasi nuova capacità, per quanto complessa, si incarna in una di queste quattro forme, e questo mantiene il codice prevedibile anche quando l’agente cresce.

Il sistema a plugin: perché tutto passa da un’unica interfaccia

La forza di Eliza non è nei quattro primitivi in sé, ma nel modo in cui vengono impacchettati. Tutto passa da un’unica interfaccia, il Plugin. Un plugin può registrare Actions, Providers, Evaluators e Services, ma anche adattatori di database, provider di modello, rotte HTTP e gestori di eventi. È l’unità di distribuzione del framework.

La documentazione ufficiale parla di oltre 90 plugin, dai connettori social (Discord, Telegram, X, Farcaster) alle integrazioni con blockchain e servizi esterni. I plugin si installano da npm e si attivano elencandoli nel character file. Il risultato è che costruire un agente somiglia più a comporre moduli che a scrivere codice da zero: serve un agente che pubblica su X e fa trading su Solana? Si combinano il plugin per X e quello per Solana, si scrive una personalità e si parte.

Questa modularità è anche una delle ragioni per cui il framework è sopravvissuto al token. I plugin sono mantenuti da attori diversi, spesso indipendenti da Eliza Labs, e formano un ecosistema che non dipende dalla salute finanziaria di un singolo asset speculativo.

Dal punto di vista pratico, lo sviluppo passa dalla CLI del progetto: si genera lo scheletro di un plugin, si implementano gli handler dei primitivi e si registra il tutto nell’interfaccia Plugin, che il runtime carica all’avvio. Un plugin ben scritto è autosufficiente e riutilizzabile tra agenti diversi, ed è questa componibilità a spiegare perché registri paralleli come quelli di Nethermind e Automata abbiano senso: chi costruisce su Eliza attinge a un catalogo comune invece di reinventare ogni volta gli stessi connettori.

Memoria e RAG: come un agente ricorda

Un modello linguistico, di per sé, non ricorda nulla tra una richiesta e l’altra. La memoria di un agente Eliza è quindi un sistema costruito attorno al modello, non dentro di esso. Il framework archivia le interazioni in un database vettoriale e, a ogni ciclo, recupera i frammenti più pertinenti per reinserirli nel contesto: è il meccanismo noto come retrieval-augmented generation, o RAG.

La memoria è organizzata per contesto, per stanza e per entità, così che un agente possa mantenere conversazioni separate con interlocutori diversi senza confonderle. Sono gli Evaluators, come visto, a decidere che cosa vale la pena ricordare, estraendo i fatti dalle interazioni e archiviandoli per il futuro. Questa memoria persistente è ciò che dà agli agenti Eliza la loro apparente continuità nel tempo.

Lo stesso meccanismo, però, è anche la loro superficie di attacco più pericolosa. Se un aggressore riesce a inquinare la memoria, non compromette una singola risposta: inquina tutte le decisioni future dell’agente. Torneremo su questo punto, perché è il vero collo di bottiglia del framework.

Worlds, Rooms ed Entities: il modello di messaggistica

Per gestire agenti che vivono su più piattaforme contemporaneamente, Eliza usa un modello di messaggistica a tre livelli. I Worlds sono gli spazi più ampi (un server, un workspace); le Rooms sono i canali o le conversazioni al loro interno (un canale Discord, un messaggio diretto); le Entities sono i partecipanti, siano essi utenti umani o altri agenti.

Questa astrazione permette a un unico agente di comparire su Discord, Telegram e X mantenendo un’identità coerente ma contesti separati. I connettori verso ciascuna piattaforma sono, ancora una volta, plugin: aggiungere un canale significa aggiungere un plugin, non riscrivere la logica dell’agente. Nel corso del 2026 il progetto ha spinto verso un’architettura più orientata ai canali, segno di un framework ancora in rapida evoluzione e di scelte di design che possono cambiare da una versione all’altra.

Modelli: dal cloud al locale

Eliza è agnostico rispetto al modello. Il provider di modello è un componente sostituibile: si può usare un’API commerciale (OpenAI, Anthropic) oppure un modello eseguito in locale attraverso runtime come Ollama o llama.cpp. La scelta si dichiara nel character file, e passare da un fornitore all’altro non tocca il resto dell’architettura.

Questa flessibilità non è solo comodità. Eseguire il modello in locale significa che i dati sensibili e le chiavi non transitano dai server di terzi, un punto su cui insiste anche Vitalik Buterin. In un post dell’aprile 2026 dedicato agli LLM sicuri, il cofondatore di Ethereum riassume la sua ricetta in poche parole: tutta l’inferenza in locale, tutti i file ospitati in locale, tutto isolato in sandbox. Non a caso il progetto ha lavorato a modelli locali dedicati, pensati per far girare un agente senza dipendere da un fornitore esterno.

Per chi costruisce agenti che gestiscono denaro, la questione dei modelli si intreccia con quella, più ampia, della fiducia nell’inferenza: come si verifica che un modello abbia calcolato davvero ciò che dice di aver calcolato? È un fronte di ricerca a sé, che passa per le prove a conoscenza zero (zk-ML) e per le prove di frode ottimistiche (opML), due approcci che HOGE Wire ha analizzato altrove e che diventeranno rilevanti man mano che agli agenti si affideranno somme più consistenti.

La sicurezza è il vero collo di bottiglia

Se c’è un motivo per cui un’azienda dovrebbe pensarci due volte prima di affidare fondi a un agente Eliza, è la sicurezza. Il problema non è specifico di Eliza, ma il framework, essendo il più diffuso, è diventato il banco di prova preferito dei ricercatori.

Il lavoro più citato è uno studio di un gruppo di ricercatori di Princeton (Atharv Singh Patlan, Peiyao Sheng, S. Ashwin Hebbar, Prateek Mittal e Pramod Viswanath), intitolato Real AI Agents with Fake Memories, che usa proprio ElizaOS come framework rappresentativo. Gli autori distinguono due minacce. La prima è la prompt injection, già nota: un’istruzione malevola nascosta in un input che l’agente scambia per un comando legittimo. La seconda, più insidiosa, è la memory injection: l’aggressore non attacca il singolo messaggio, ma corrompe la memoria persistente dell’agente, piantando comandi che sembreranno interazioni passate autentiche e influenzeranno ogni decisione futura.

Il risultato dimostrato è pesante: trasferimenti di asset non autorizzati e violazioni di protocollo. Il loro benchmark, CrAIBench, copre oltre 150 compiti blockchain realistici e più di 500 casi di attacco, e la conclusione è netta: i modelli sono molto più vulnerabili alla memory injection che alla prompt injection. La radice del problema è che un LLM non distingue in modo affidabile tra istruzione e dato, perché tutto arriva come testo nel contesto. È la stessa debolezza che, nella primavera del 2026, ha permesso di svuotare agenti collegati a wallet nascondendo comandi in messaggi apparentemente innocui su X.

Le difese esistono (limiti di spesa, conferme umane, isolamento dei permessi), ma riducono l’autonomia che rende gli agenti attraenti. Buterin propone una regola pratica per gli strumenti che collegano un LLM a un wallet: un tetto alle transazioni autonome nell’ordine di 100 dollari al giorno, oltre il quale serve la conferma di un essere umano, così che uomo e modello facciano da doppio fattore l’uno per l’altro (news.bitcoin.com). Chi valuta di costruire su Eliza deve mettere in conto che questa parte del lavoro ricade interamente sulle proprie spalle.

In concreto, chi mette in produzione un agente Eliza adotta quasi sempre alcuni accorgimenti ricorrenti: restringere le Actions disponibili a una lista chiusa e verificata, tenere il wallet operativo separato dai fondi principali e con un tetto di spesa, imporre una conferma umana sulle operazioni oltre una certa soglia e trattare con diffidenza tutto ciò che finisce in memoria, perché è proprio lì che si annidano gli attacchi più insidiosi. Sono mitigazioni, non soluzioni: finché il modello non distingue in modo strutturale l’istruzione dal dato, il rischio di fondo resta.

Chi ci costruisce davvero: Nethermind, Automata, Secure Blockchain

La prova più solida che il framework valga più del suo token defunto non è nei numeri di GitHub, ma in chi lo usa. Diversi team di infrastruttura che non hanno alcun interesse nel token ELIZAOS mantengono la propria porzione dell’ecosistema Eliza.

Nethermind, il team dietro uno dei principali client di esecuzione di Ethereum, mantiene un proprio fork del registro dei plugin. Automata Network, che si occupa di attestazioni verificabili per Web3 e AI, gestisce un secondo registro e contribuisce con plugin per l’attestazione TEE tramite lo standard DCAP di Intel: un modo per provare crittograficamente che un agente sta girando dentro un ambiente sicuro e non manomesso. È l’approccio hardware al problema della fiducia negli agenti, complementare alle prove crittografiche viste sopra.

Sul fronte commerciale, Secure Blockchain Development Corp, società quotata sul mercato canadese TSXV, ha siglato con la Eliza Foundation un accordo di sviluppo per Agentic SME, un prodotto white-label che permette a piccole e medie imprese di automatizzare vendite, amministrazione, contabilità e assistenza clienti con agenti costruiti sopra elizaOS, con lancio previsto per la seconda metà di agosto 2026 (accessnewswire). È il tipo di adozione, poco appariscente e orientata al business, che sopravvive a prescindere dalla speculazione sul token.

Il filo che lega questi tre esempi è che nessuno di loro dipende dal prezzo di ELIZAOS. Un client Ethereum, un protocollo di attestazione hardware e una software house quotata scelgono Eliza per ragioni tecniche e di prodotto, non per esposizione a un token. È esattamente il tipo di adozione che un progetto open source dovrebbe desiderare, e che pochi framework nati come parodia di una meme-coin riescono a costruire.

Eliza contro gli altri framework

Chi valuta Eliza oggi lo fa confrontandolo con alternative che affrontano lo stesso problema con filosofie diverse. La tabella seguente mette a fuoco le scelte ingegneristiche, non le quotazioni.

In sintesi: Virtuals Protocol punta tutto sulla tokenizzazione, con ogni agente dotato del proprio token, un modello opposto a quello scelto oggi da Eliza; Olas è orientato ai servizi autonomi decentralizzati con un registro on-chain; LangChain e CrewAI vengono dal mondo Python e dell’orchestrazione LLM generica, non sono crypto-native e non hanno alcun token. Il punto di forza di Eliza resta l’integrazione nativa tra personalità dell’agente, memoria, wallet e connettori social, il tutto sotto una licenza permissiva che non lega a nessun fornitore.

L’economia di un framework senza token

Qui sta la vera incognita. Un progetto open source con oltre 19 mila stelle ha comunque bisogno di qualcuno che lo mantenga, corregga i bug, risponda alle segnalazioni di sicurezza e faccia evolvere l’architettura. Finché c’era un token da miliardi, la manutenzione si finanziava quasi da sola. Ora quel motore economico è spento.

Walters ha messo le cose in chiaro. «Ricomincio da capo, visto che l’IP è mia, e non lascerò mai più che un token si avvicini a Eliza», ha dichiarato dopo la transazione con lo studio Burwick Law, aggiungendo che continuerà a costruire e puntando ora su robotica e partner hardware (Decrypt). In pratica, il framework si regge su tre gambe: lo sviluppo diretto di Walters e del suo team, i contributi della comunità volontaria e, soprattutto, gli adottanti commerciali come Secure Blockchain, che hanno un interesse concreto a tenerlo in salute perché ci costruiscono sopra prodotti veri.

È un modello diverso da quello di reti AI che finanziano la propria manutenzione con emissioni e incentivi on-chain, come Bittensor. La domanda aperta, per chi valuta di adottare Eliza, è se questa combinazione di sviluppo commerciale e volontario reggerà nel tempo con la stessa velocità di rilascio che ha avuto finché c’era il token a pagare il conto. Per dare un’idea di quanto il token sia ormai marginale, ecco dove si colloca ELIZAOS nel settore degli AI agent.

Conversione indicativa dai valori in dollari al cambio EUR/USD di circa 1,17; dati CoinGecko al 20 agosto 2026, con il settore AI agent nel suo complesso intorno ai 2,8 miliardi di dollari. Il contrasto è la fotografia del progetto: la categoria vale miliardi, l’ex token del framework più usato ne vale poco più di uno.

Cosa significa per un builder italiano: Consob, MiCA e responsabilità

Per chi sviluppa in Italia, la buona notizia è che il framework in sé non è oggetto di vigilanza. Eliza è software con licenza MIT: scaricarlo e usarlo non è un’attività regolamentata, così come non lo è scrivere in Python. Consob e Banca d’Italia, sotto MiCA e il decreto italiano di attuazione (il D.lgs. 129/2024), vigilano sui servizi in cripto-attività e sugli emittenti, non sul codice.

I problemi nascono da ciò che l’agente fa. Se un agente Eliza offre a terzi un servizio in cripto-attività (custodia, scambio, esecuzione di ordini), scatta l’obbligo di autorizzazione come CASP. Qui pesa una scadenza recente: il periodo transitorio di MiCA in Italia si è chiuso il 1 luglio 2026, e a oggi Consob, in coordinamento con Banca d’Italia, ha autorizzato appena nove soggetti (otto CASP, tra cui Young Platform, Conio e CheckSig, più la Banca Sella), come indica la stessa comunicazione dell’autorità. Chi opera senza titolo deve cessare l’attività. Se invece l’agente fornisce consulenza o gestione di portafoglio, si entra nel perimetro della MiFID II, con Consob come autorità, e valgono i principi ESMA su governance, trasparenza e supervisione umana per l’AI nei servizi di investimento. Su tutto pesa il quadro MiCA, oggi in via di revisione.

Resta il nodo della responsabilità. Un agente non ha personalità giuridica, non ha un codice fiscale e non può essere convenuto in giudizio: la responsabilità ricade sull’essere umano o sull’azienda che lo ha messo in funzione. Se l’agente gestisce pagamenti, si aggiungono gli obblighi antiriciclaggio e la Travel Rule del GAFI. Non è un dettaglio teorico: la causa collettiva che ha ucciso il token è stata intentata contro persone e società, non contro l’agente, un promemoria di dove finisce la responsabilità quando qualcosa va storto.

Conviene costruire su Eliza nel 2026?

Messi insieme i pezzi, la risposta dipende da chi la pone. A favore di Eliza giocano la maturità del codice, l’ampiezza dell’ecosistema di plugin, l’integrazione nativa con wallet e social, la licenza MIT che non lega a nessun fornitore e un’adozione commerciale reale che ne sostiene la manutenzione. Per un prototipo di agente crypto-native, resta probabilmente il punto di partenza più veloce oggi disponibile.

Contro Eliza pesano invece l’incertezza sulla governance dopo la chiusura della fondazione, un ritmo di rilascio così rapido da produrre modifiche che rompono la compatibilità tra una versione e l’altra, e soprattutto un onere di sicurezza che ricade interamente su chi costruisce: nessun framework di agenti, oggi, risolve la memory injection al posto tuo. Chi ha bisogno soltanto di orchestrare chiamate a un LLM in un contesto aziendale, senza wallet e senza operazioni on-chain, troverà probabilmente più adatti strumenti come LangChain o CrewAI.

La lezione più duratura della vicenda Eliza è forse proprio questa separazione tra il valore di un token e la qualità di un software. Il token è morto per ragioni che con l’ingegneria avevano poco a che fare; il codice vive perché risolve un problema reale per chi lo usa. Nel 2026 la scelta di costruire su Eliza è, per la prima volta, una decisione puramente tecnica. Ed è probabilmente la posizione più sana in cui un framework possa trovarsi.

Domande frequenti

Che cos’è il framework Eliza (elizaOS)?

Eliza è un framework open source in TypeScript con licenza MIT per costruire agenti AI autonomi, capaci di ragionare con un modello linguistico, mantenere una memoria persistente e agire, anche firmando transazioni on-chain con un proprio wallet. È distinto dal token ELIZAOS, oggi privo di valore, e continua a essere sviluppato in modo indipendente.

Il token ELIZAOS è morto: il framework funziona ancora?

Sì. Il 4 agosto 2026 il fondatore ha dichiarato morto il token e avviato la chiusura della fondazione, ma il codice è sotto licenza MIT e continua a ricevere aggiornamenti quasi quotidiani su GitHub, dove supera le 19 mila stelle. Team come Nethermind e Automata Network ne mantengono forkati i registri dei plugin.

Su quale linguaggio e con quale licenza è costruito Eliza?

Il framework è scritto in TypeScript ed è distribuito con licenza MIT, permissiva, che consente di usarlo, modificarlo e ridistribuirlo anche a fini commerciali senza alcun legame con un token.

Quanto è sicuro un AI agent costruito con Eliza?

La sicurezza è il punto debole di tutti gli agenti AI, non solo di Eliza. Ricercatori di Princeton hanno mostrato, usando proprio ElizaOS, che attacchi di memory injection possono corrompere la memoria dell’agente e provocare trasferimenti di fondi non autorizzati. Difese come limiti di spesa, conferme umane ed esecuzione locale del modello riducono il rischio ma anche l’autonomia.

Serve una licenza Consob per lanciare un agente Eliza in Italia?

Usare il framework non è un’attività regolamentata. Serve un’autorizzazione se l’agente offre a terzi servizi in cripto-attività (autorizzazione CASP da Consob e Banca d’Italia sotto MiCA) o se fornisce consulenza o gestione di portafoglio (perimetro MiFID II). La responsabilità ricade sempre sulla persona o sull’azienda che gestisce l’agente, perché l’agente non ha personalità giuridica.

Marcus Okafor è senior editor di HOGE Wire e segue AI, agenti autonomi e infrastrutture crypto.