Gli si parla dal browser o da Telegram, in linguaggio naturale. Legge mail, file, foto, calendario e web; agisce — sposta, scrive, invia, programma — e si ferma a chiedere prima di ogni cosa che non si può rifare. Non c'è un cloud di Metnos, non c'è un «registrati»: i dati e la logica restano in casa.
Quello che succede a ogni richiesta, in un disegno:
Le quattro proprietà che lo distinguono da un agente generico:
Di agenti self-hosted ce ne sono già — quelli da terminale (OpenClaw e simili) e l'ecosistema delle «skill» importabili. Metnos fa scelte opposte su quattro assi, e le fa per una ragione precisa: un planner locale non è un modello di frontiera, e va messo nelle condizioni di non sbagliare.
| Framework agentico tipico | Metnos | |
|---|---|---|
| Strumenti | Scritti a mano, importati o generati al volo in forma libera — poi eseguiti così come sono, coi privilegi dell'assistente. | Sintetizzati anche a runtime, ma da un vocabolario chiuso e verificato: firmati, testati alla nascita, invecchiati, ammessi solo dopo un cancello a 7 strati. |
| Instradamento | Il modello sceglie uno strumento a ogni turno: chiedete due volte, ottenete due piani. | Deterministico per costruzione: seme fisso, pareggi rotti da affinità curate. Stessa richiesta, stesso piano, a ogni run. |
| Output | Forma libera, per strumento. | Uniforme: liste in ingresso, liste in uscita, componibili fra passi senza colla. |
| Undo | Raro, o nella migliore delle ipotesi «si spera». | Di prima classe: catalogo chiuso di pattern di reverse, move = COPY-poi-DELETE, ok_count onesto. |
| Lingua | Inglese, stringhe cablate nel codice. | i18n per costruzione: ogni stringa e prompt è dato per-lingua. IT+EN validate; altre lingue a incastro, non ancora testate. |
| Sicurezza | Ci si fida dell'autore del pacchetto. | Non ci si fida del pacchetto: è il pacchetto a dover passare i controlli. |
I formati di skill in voga sono comodi e pericolosi in pari misura: importate un pacchetto e l'assistente ne esegue il codice coi propri privilegi. Per un assistente che tocca file, mail e shell di casa vostra, è esecuzione remota di codice per disegno: basta un pacchetto malevolo o sciatto. Metnos sceglie la sicurezza per costruzione: vocabolario chiuso (non potete nominare uno strumento che la grammatica non ammette), cancello di ammissione a 7 strati per ogni executor nuovo o importato (firma → sovrapposizione di affinità → invecchiamento → sandbox → test di fumo → verifica LLM → audit append-only), consenso esplicito prima di ogni azione distruttiva. Lo slogan: il pacchetto non si fida, il pacchetto si guadagna il posto. L'ecosistema pubblico delle skill non viene ignorato: viene tradotto dentro questo modello, mai eseguito crudo.
La maggior parte degli agenti tratta l'LLM come un oracolo da rilanciare a ogni turno. Metnos fa la scommessa opposta: un planner locale su vocabolario chiuso si può rendere riproducibile — il seme di generazione è fissato, e quando due strumenti fratelli pareggiano decide un segnale di affinità curato, non il caso. Risultato misurabile: il banco di prova interno ripete ogni richiesta cinque volte e pretende lo stesso piano, cinque su cinque. E si compone: una forma di richiesta risolta una volta viene rigiocata da Praxis senza alcuna chiamata LLM — latenza più bassa, costo zero, esito identico. La flessibilità (il modello di frontiera) resta disponibile, ma è la riserva, non il motore.
Onestà dovuta: come compagno di chi scrive codice — dentro un repository, in tempo reale — un agente da terminale maturo resta superiore, con un ecosistema di estensioni che Metnos non ha né insegue. Metnos è un'altra cosa: un assistente di casa per posta, foto, calendario, archivio, web e manutenzione del proprio server. I due convivono benissimo.
Il modo più rapido per capire è guardare. Ogni scena qui sotto è una richiesta vera fatta all'istanza di riferimento; l'intestazione indica quando è stata verificata dal vivo. Dove c'è un limite, è scritto accanto al merito.
Dammi il riassunto delle mail importanti di oggi.
Ok, rispondi tu all'avvocato: digli che invio il documento entro giovedì.
Una mail in uscita verso un destinatario esterno non parte mai in silenzio, a nessun livello di autonomia. Metnos compone la bozza e su Telegram arriva questa bolla con due bottoni:
Toccate Approva: il daemon verifica che il token sia ancora pendente, non scaduto, e che chi decide sia lo stesso mittente accoppiato che ha chiesto. Poi: «Spedita alle 11:34. Riga di audit #1247.»
Le tre righe della carta non sono un vezzo: sono cosa, su che cosa, quanto è rifacibile — il minimo per decidere a colpo d'occhio. Alla terza occorrenza identica la carta scende a due righe, poi a una. Vedi approval_ux.
Ordina tutti i file immagine in ~/images creando sottocartelle per anno, premettendo al nome data e luogo di scatto. Se il luogo non c'è, metti «unknown».
Non esiste uno strumento «ordina foto»: il planner ne compone quattro della
libreria, collegando l'uscita di ognuno all'ingresso del successivo. I dati non
transitano dal modello: passano per riferimento (from_step).
find_files(base_path="~/images", patterns=["*.jpg","*.png","*.heic"], recursive=true)
→ 98 entries (con size e mtime già inclusi)filter_entries(from_step=1, kind="image")
→ 98 entries · filtro in memoria, conferma il tipo dichiarato dal MIMEget_files(from_step=2, fields=["dates","place"])
→ 98 entries arricchite: EXIF → data; GPS → luogo via reverse-geocode (cache locale); senza GPS → "unknown"move_files(from_step=3, dst_template="~/images/{anno}/{data}_{luogo}_{nome}")
→ 98 spostati, 0 errori · ogni coppia sorgente→destinazione registrata nel registro di undoQuattro executor che non si conoscono fra loro, scelti e collegati dal planner. Run reale del 28/04/2026, 98 foto.
Il giorno dopo, cambio di idea:
Annulla l'ultima operazione.
Il portale della scuola richiede login. Il riassunto deve arrivare sul Telegram della figlia, accoppiata come ospite. Tre messaggi di preparazione, poi va da solo.
Aggiungi credenziali per portale-scuola.example: utente roberto.b, password ●●●●●●●.
Metnos riconosce un valore che somiglia a una password e apre una carta dedicata:
propone di cifrare il dato in una cassaforte locale e di cancellare il valore in
chiaro dal log del turno (<REDACTED:cred>). Approvato, prova un
login di test.
Ogni mattina alle 7 cerca le novità sul portale (compiti, voti, circolari), leggi anche i PDF allegati, e manda il riassunto delle 5 più rilevanti alla figlia su Telegram.
Domenica mattina, cinque frasi in fila — foglio su Drive, bollette dalle mail, riepilogo in un Doc, condivisione, ricorrenza:
Crea uno spreadsheet «Budget 2026-05» su Drive con colonne Data, Categoria, Importo, Note, Pagato. — Popolalo con le mail degli ultimi 30 giorni che contengono «fattura». — Fammi un riassunto per categoria in un Google Doc. — Condividi tutto con il familiare. — Aggiornami ogni mattina alle 8.
Comprimi /tmp/cfg.json in gzip.
Il planner ispeziona il catalogo: nessun executor adatto, e nessuna catena di esistenti chiude il vuoto. Parte la sintesi — cinque stadi piccoli invece di un prompt mostro, ogni stadio vede solo la fetta di contesto che gli serve:
cfg.json.gz creato.
È così che il catalogo è arrivato a 77 executor: una capacità alla volta, motivata da una richiesta vera, mai in anticipo. Il meccanismo completo è nel capitolo 7.
Decine di migliaia di foto su un disco di rete. La prima volta Metnos propone di indicizzarle: l'indicizzazione gira in background e avvisa su Telegram a lavoro finito. Da quel momento:
Trova le foto in montagna.
Le foto della figlia al mare?
Il supporto del progetto stesso è gestito così — niente servizio dedicato, niente codice ad hoc: due richieste in linguaggio naturale, registrate come task ricorrenti, che il planner trasforma nelle solite catene di executor.
Ogni 30 minuti: trova le issue nuove del repo, scarta quelle già nel db locale, cerca per ciascuna le issue simili già risolte, classificala e analizzala col tier frontier, salva la bozza di risposta con stato «prepared», e avvisami.
Dopo la mia approvazione: leggi dal db le issue «approved» non ancora pubblicate, pubblica la risposta come commento su GitHub, segnale «posted».
Metnos gira su una macchina Linux vostra. L'istanza di riferimento è un piccolo sistema a memoria unificata (96 GB) che serve un modello locale ~35B a circa 80 token/s; ma i livelli LLM sono ruoli astratti, non modelli fissati — un endpoint su CPU, un modello che già servite o il solo ripiego di frontiera sono percorsi di prima classe. Telefoni e laptop sono clienti: la mente, la memoria e l'audit vivono su una macchina sola.
Il browser: una chat servita dal server stesso (porta 8770), con
le anteprime delle foto, la galleria, e i cruscotti di amministrazione (proposte del
synt, executor, run, turni). Telegram: lo stesso cervello in tasca,
con le carte di conferma come bottoni in linea. Per chi automatizza, l'API HTTP
(/agent/turn, anche in streaming) è la stessa porta che usa la chat.
La chat web mostra anche i badge di feedback ✓/✗ per ogni risposta: il gradimento alimenta la cura del catalogo.
Telegram è una superficie pubblica: chiunque conosca il nome del bot può
scrivergli. Metnos lega ogni coppia (canale, mittente) a un livello di
autonomia con un codice firmato monouso: /pair PAIR.<codice>
(Ed25519, scade in pochi minuti) per gli accoppiamenti decisi dall'host;
/start <token> per gli ospiti creati dall'interfaccia di
amministrazione. Niente account centrale, niente password: una rubrica
per-canale-per-mittente che solo l'host modifica.
Vedi pairing.
Ogni messaggio visibile, ogni descrizione di strumento e ogni prompt LLM vive come
dato per-lingua: italiano e inglese sono validati, una lingua nuova si
aggiunge per traduzione dei pacchetti, senza toccare codice
(prompts_cli add-language <codice> prepara la struttura; la
traduzione si rivede e si promuove a mano). Onestà: oltre IT e EN, oggi, è terreno
non testato. Vedi multilang.
È il pezzo di esperienza più importante del progetto. Ogni azione che cambia lo stato del mondo — inviare, scrivere fuori dal perimetro concesso, eseguire shell — passa per quattro componenti reali, in quest'ordine. Il punto non è chiedere sempre: è chiedere bene, e sempre meno.
| Fase | Cosa fa |
|---|---|
| 1 · Planner | Prepara il passo (executor + argomenti) in memoria. Niente è ancora eseguito. |
| 2 · Vaglio | Prima la guardia binaria: percorsi vietati (~/.ssh, /etc…) e pattern di shell quasi irrecuperabili (rm -rf /, mkfs, fork bomb) sono negati a prescindere, a ogni livello di autonomia. Poi il giudice graduato: un punteggio di allineamento ai vostri telos (i fini scritti in TELOS.md). |
| 3 · Policy | Classe di capability × livello di autonomia × concessioni persistenti → uno fra allow_silent, approval_required, deny. |
| 4 · Carta | Tre righe (cosa · su che cosa · quanto è rifacibile) + due bottoni. Token opaco monouso, TTL 600 s, verifica che chi decide sia chi ha chiesto. Solo dopo l'approvazione l'executor parte — dentro una sandbox bubblewrap col profilo dichiarato nel suo manifest firmato. |
Sempre meno fastidio, mai meno controllo. La carta si modula sulla
ricorrenza: piena le prime volte, poi due righe, poi una. E alla prima approvazione di
una tipologia potete concedere un territorio («tutte le scritture dentro
~/Documenti/fatture/») — da quel momento, lì, Metnos smette di chiedere;
la concessione è revocabile quando volete. Vedi
approval_ux.
E quando ha agito, può tornare indietro. L'undo non è un LLM che «ci prova»: è un catalogo chiuso di pattern di reverse dichiarati nel manifest di ogni executor mutante (scambia sorgente/destinazione, cancella i creati, ripristina il backup del blob, cancella per id). Conteggi onesti: se dice che ha annullato tre cose, erano tre.
SOUL.md, sei principi operativi): il synt propone solo executor,
mai modifiche a se stesso, al vaglio o al runtime — e ogni proposta passa dal vostro sì.
Quattro depositi distinti, con durate e regole di scrittura diverse — tabelle SQLite e file di testo che potete aprire, non un vettore opaco da qualche parte.
| Deposito | Orizzonte | Cosa contiene | Regola |
|---|---|---|---|
| Scratchpad | il turno | Le osservazioni dei passi intermedi. | si svuota a fine turno |
| Storico turni | giorni | «Cosa ti ho chiesto martedì scorso?» | un file per turno, alimenta i cruscotti |
| Memorie su di voi | per sempre | «Il compleanno della mamma è il 23/4.» | mai scritte di nascosto: propone, voi approvate |
| Mnestoma | su di sé | Quali strumenti hanno collaborato, con che esito; e i tentativi rimasti a metà. | il substrato che il synt legge per proporre |
Memoria del mondo (le prime tre righe) e memoria di sé (il mnestoma), tenute separate per disegno. Il quarto deposito è il più insolito: il mnestoma registra anche i vuoti — le richieste che nessuno strumento ha saputo chiudere — perché sono il motore della crescita.
Il dettaglio che conta: Metnos non promuove mai un fatto a memoria permanente da solo. Propone («ho notato che parli spesso del nuovo dentista: lo salvo come contatto abituale?»), voi decidete. E un tentativo fallito non viene dimenticato: resta come proto-mnest — un'aspirazione registrata, con abbastanza contesto per riconoscere la stessa forma la prossima volta. Vedi mnestoma e scratchpad.
Un executor è un piccolo file Python che fa una cosa sola, con un manifest che ne dichiara argomenti, capability e profilo sandbox. Una volta firmato è un artefatto stabile: non impara, non cambia. L'intelligenza di crescita sta altrove — nel sintetizzatore.
| Stadio | Cosa produce |
|---|---|
| 1 · Nome | dal vocabolario chiuso — tier middle |
| 2 · Firma | schema args, capability, pattern di reverse |
| 3 · Test | 4–6 prove di nascita: felice, vuoto, invalido |
| 4 · Descrizione | il «prompt dello strumento» + parole di affinità |
| 5 · Codice | tier wise, locale — def invoke(args) → liste |
All'uscita, il cancello di ammissione (7 strati): firma → sovrapposizione di affinità → invecchiamento → sandbox → test di fumo → verifica LLM descrizione-vs-codice → audit append-only · poi conferma umana e firma Ed25519.
Cinque prompt piccoli e focalizzati invece di uno monolitico: in convergenza ha prodotto 4 executor corretti su 4, contro il 32% del prompt unico. Solo lo stadio 1 vede il vocabolario chiuso; solo il 5 scrive codice.
La sintesi reattiva (capita in mezzo a un turno, scena 6) è il primo gradino di una cascata per costo crescente: prima componi gli esistenti, poi genera il mancante; di notte le passate introvertive propongono fusioni (due strumenti con tracce sovrapposte), generalizzazioni (tre specializzati collassano in uno parametrico) e specializzazioni (un caso caldo si stacca). Tutto passa dal vostro sì. Due installazioni, in due case, dopo sei mesi avranno cataloghi diversi — ognuno plasmato dall'uso reale. Vedi synt e lifecycle.
Tutto ciò che lega Metnos a un servizio esterno è una skill:
un gruppo di capacità dormiente finché non configurata, attivabile e
disattivabile a piacere (system · photos · mail ·
web · geo · calendar · github ·
google-workspace · frontier). Abilitare una skill senza i
prerequisiti è innocuo: resta visibile e inerte finché il suo servizio o la sua
credenziale non compaiono. Si gestiscono da riga di comando o chiedendolo in chat
(«quali skill ho?», «disattiva il web»).
Il backend è l'altro asse: come un'azione raggiunge un
servizio concreto. Il provider si sceglie da configurazione, deterministicamente —
il planner non vede mai «Google»: vede create_events, e il resolver
instrada. Aggiungere un secondo provider (es. GitLab accanto a GitHub) è
+1 file di backend, zero executor nuovi: niente strumenti fotocopia per
provider, niente bias di scelta nel modello locale. Vedi
skills_backends.
system è la skill che rende Metnos un assistente del computer,
non solo un chatbot: shell, sudo, pacchetti, mount di rete. Ogni azione
privilegiata richiede un giudizio del vaglio, e la skill si può spegnere del tutto —
Metnos resta fuori dal sistema finché non la riaccendete voi.
Metnos non è multi-tenant in senso SaaS: è una casa sola. Dentro quella casa c'è un host — il proprietario del server, custode della chiave di firma — e zero o più ospiti, ognuno col suo livello.
| Livello | Per chi | Cosa può |
|---|---|---|
| ReadOnly | Un ospite, un canale delicato | Solo executor di lettura; ogni scrittura viene rifiutata con garbo prima ancora di arrivare al planner. |
| Supervised | L'uso quotidiano | Tutto il turno; le azioni delicate alzano la carta di conferma sul canale stesso. |
| Full | L'host | Il perimetro più ampio che la policy ammette. I percorsi vietati restano vietati anche qui. |
La scena 4 mostra il modello al lavoro: l'host configura, l'ospite riceve, le righe di audit restano separate per accoppiamento. Ogni canale ha la sua porta, la sua chiave, la sua storia.
Un solo server, ma non un solo filesystem: tante cose su cui vorreste agire (i file del laptop, un'applicazione aperta, uno schermo) vivono altrove. La direzione tracciata è tenere gateway, policy e memoria sul server e lasciar girare alcuni executor su dispositivi registrati — un client sottile con identità Ed25519 propria, ammesso con un codice firmato monouso, revocabile dal server in un gesto.
~/.ssh, /etc, ~/.gnupg e simili: lista cablata nel codice, non in un file di configurazionerm -rf /, mkfs, fork bomb), a qualunque autonomiaRegola trasversale: nessun fallimento silenzioso. Cap raggiunto → lo dice (quanti usati, quanti disponibili) e chiede se allargare. Esito parziale → contato come parziale. Mai un «fatto» che non corrisponde alla realtà.
Vetrina funzionante, non prodotto rifinito. Metnos è il sistema con cui l'autore vive ogni giorno, costruito per una persona su una macchina — e condiviso perché chi ama homelab e architetture di agenti possa leggerlo, farlo girare, costruirci sopra.
| Pezzo | Stato a giugno 2026 |
|---|---|
| Uso quotidiano | Sì: l'istanza di riferimento è in servizio attivo (mail, foto, scheduler, manutenzione del proprio repo). 77 executor firmati, 2 660 test automatici, 21 documenti canonici bilingui allineati al codice. |
| Installer | Incluso. Il percorso managed (consigliato) replica un ambiente completo da un checkout pulito — modello, servizi di contorno, dati i18n, executor firmati — profila l'hardware per scegliere un modello adatto e chiude con un turno reale, non un ping. Il percorso custom (dichiarate il vostro LLM) esiste ed è sconsigliato a voce alta. |
| Repo pubblico | Un sotto-insieme deterministico dell'istanza viva — la fetta essenziale per l'esercizio. Può restare indietro fra una pubblicazione e l'altra: è previsto, non trascuratezza. |
| Maturità | pre-1.0: API e default cambiano senza strati di compatibilità quando emerge un disegno migliore. Capacità esistenti ma poco esercitate fuori dall'istanza di riferimento (l'i18n non-italiana su tutte). Se qualcosa si rompe: issue, e un filo di pazienza. |
Il requisito vero è l'hardware: una macchina che regga un LLM locale capace. I livelli sono ruoli astratti — un endpoint su CPU o un modello già in servizio vanno bene; un modello più debole significa pianificazione più debole, non un'installazione rotta. Nessuna GPU è richiesta per principio.
$ git clone https://github.com/brunialti/metnos.git && cd metnos $ bash install/bootstrap.sh --check # solo verifica: non scrive nulla $ bash install/bootstrap.sh # interattivo, sei fasi, idempotente
E il supporto è parte dell'esperimento: le issue del repo vengono triagiate da un'istanza di Metnos (scena 8) — bozze preparate dal sistema, pubblicate solo dopo approvazione umana. Se l'assistente non sa aiutarvi a far girare l'assistente, quello è un bug che vogliamo vedere.
Se portate via una cosa sola: Metnos è un assistente personale self-hosted con tre impegni peculiari — chiede prima di agire (un valutatore ispezionabile, non una sensazione), si costruisce gli strumenti dentro regole verificabili (vocabolario chiuso, firma, test di nascita, cancello a 7 strati), è riproducibile come il software (routing deterministico, conteggi onesti, undo per costruzione). Se questa combinazione vi incuriosisce, siete il pubblico giusto.
TELOS.md come tendenze morbide. Il giudice
misura le azioni proposte contro di essi.