1. Cos'è Metnos?

Metnos è un maggiordomo digitale per casa: un assistente AI che vive su un computer di famiglia, parla attraverso i canali che già usi (terminale, Telegram, in futuro voce), esegue azioni reali (leggere file, lanciare comandi, consultare il web) ma chiede il permesso prima di fare qualcosa di serio.

L'analogia del maggiordomo è utile. Un buon maggiordomo:

• vive nella tua casa (self-hosted: gira sul tuo server di casa, non sul cloud di un fornitore terzo — vedi cap. 4);
• ha le chiavi di certe stanze ma non di tutte (sandbox: può toccare il workspace, non /etc né ~/.ssh);
• esegue compiti di routine da solo (cron, notifiche);
• per decisioni importanti chiede conferma esplicita;
• apre la porta solo a chi riconosce o a chi mostra un invito (DM pairing);
• tiene un registro di tutto ciò che fa (audit log).

Tecnicamente è un processo Python ≥ 3.11 che gira a ${METNOS_HOME}/, composto da quattro strati (gateway, policy, sandbox, workspace/tool). Ogni servizio AI (LLM, STT, TTS, embedding, speaker-ID) viene consumato tramite un'interfaccia astratta — Metnos è provider-agnostic per costruzione. Nel caso specifico dell'ambiente dell'autore l'interfaccia è realizzata da suprastructure, un package sibling preesistente; in un altro ambiente potrebbe essere realizzata da qualunque adapter equivalente.

Obiettivi espliciti

2. Perché non bastano openclaw o zeroclaw

Entrambi sono progetti eccellenti e sono stati la fonte di ispirazione primaria. Entrambi però hanno tare che li rendono non-pronti per l'uso domestico qui sul mio PC:

La decisione: prendere i pattern migliori di entrambi (gateway-first di openclaw, autonomy+pairing+sandbox-a-strati di zeroclaw) e reimplementarli in Python, dove:

1. posso riusare l'implementazione di interfaccia LLM che ho già pronta in casa;
2. Metnos è coerente con gli altri sibling agents dell'ambiente (un solo linguaggio, convenzioni condivise);
3. posso alzare i default di sicurezza per il contesto domestico senza combattere contro convenzioni cloud-native.

3. Quattro aggettivi, un sistema

Prima di entrare nella tecnica, fissiamo cosa Metnos deve essere. Quattro aggettivi, non in ordine di importanza ma in ordine di difficoltà crescente. Il quarto è la novità della v1.1 delle prospettive: prima c'erano tre, ora sono quattro.

Il quarto aggettivo è quello che alza l'asticella. Un agente solo reattivo è un chatbot con tool. Un agente proattivo deve avere un motivo per agire, e un freno per non esagerare. Motivo e freno sono il contenuto dei capitoli 9, 10 e 11.

4. Dove vive Metnos: la topologia reale

Metnos non vive sul laptop. Vive su un server Linux acceso ventiquattro ore su ventiquattro, e il laptop — come il telefono, come il browser di un dispositivo in viaggio — è un cliente che lo interpella. Questo capitolo, nuovo rispetto alla v1.0, spiega perché è così e cosa ne consegue; in fondo apre la porta a una direzione futura importante: gli executor remoti.

Rileggere "local-first"

Il termine local-first ha nella letteratura (Kleppmann 2019) un significato preciso che mescola due proprietà: (a) i dati vivono sulla macchina dell'utente; (b) il sistema funziona anche offline. La v1.0 aveva preso entrambe come obiettivo. Messo alla prova della vita reale di una famiglia, il quadro cambia.

La proprietà che davvero conta è la (a): i dati e la logica non stanno in cloud di terzi. Il motivo è di sovranità, di privacy, di assenza di vincoli al fornitore. La proprietà (b) — "funziona offline" — è per noi una mezza verità: un agente che orchestra modelli linguistici, richieste al web e notifiche non è comunque utile senza rete. Se non c'è rete, anche il laptop — nell'ipotesi in cui Metnos vivesse lì — non potrebbe chiamare un modello linguistico, consultare una pagina web, mandare un messaggio.

La v1.1 riformula il principio: Metnos è self-hosted, non "local-first" in senso stretto. Il dato e la logica vivono su una macchina sotto il tuo controllo fisico e legale — nel nostro caso metnos-server, il server di casa. Nessuna dipendenza da fornitori terzi, nessun canale obbligato verso server di terzi. La nuvola resta una possibilità opzionale (modelli linguistici remoti, canale Telegram) ma mai come luogo di residenza.

Cinque topologie sul tavolo, una scelta

Pensare il problema bene significa enumerare le alternative prima di decidere. Cinque topologie erano (sono) plausibili per un agente domestico di questa forma:

La scelta pragmatica: A come base, con E come direzione esplicita verso cui Metnos può crescere.

I tre modi di parlare a Metnos

C'è un quarto scenario — sei in aereo, la casa non ha rete per un'interruzione di corrente: nessun canale raggiunge metnos-server, Metnos è inattivo per te. È un caso degradato accettabile, simmetrico a quello di qualsiasi servizio: senza rete non si fa molto.

Il gap dei file del laptop: strategia modulare

Molti dei file che vorrai far elaborare a Metnos nascono sul laptop Windows (fatture, foto, codice di lavoro), ma Metnos gira su metnos-server. Risolviamo il gap in modo modulare, a partire dalla soluzione più semplice:

Si parte dal livello 0. Si sale solo quando la carenza si fa sentire in un caso concreto. La semplicità (principio 6) prevale.

Executor remoti: direzione eccitante, in certi casi l'unica

L'opzione E della tabella sopra è la più interessante strutturalmente. Al posto di pretendere che tutti i file finiscano nella cartella condivisa, si introduce un'idea semplice: gli executor non vivono tutti su metnos-server. Alcuni girano sul laptop, sono esposti a metnos-server tramite l'overlay Headscale, e quando Metnos li invoca riceve il risultato come se fossero locali. Un unico gateway, un'unica regola, un unico mnestoma; braccia distribuite.

Non è solo un'ottimizzazione. Per certi casi d'uso diventa l'unica modalità sensata. L'esempio che fissa l'idea: riordinare un archivio fotografico di diecimila file sul laptop. La soluzione "sincronizza tutto su metnos-server, riordina, risincronizza indietro" comporta gigabyte di traffico, doppia occupazione del disco, finestre temporali in cui lo stesso file esiste in due stati su due macchine, il rischio concreto di conflitti durante l'operazione. Una rinominazione sul posto, eseguita direttamente sul laptop, risolve in un secondo ciò che la copia impiegherebbe minuti, senza sprecare spazio e senza rischio di divergenza. Esempi affini: portare in primo piano un'applicazione, leggere un file che per dimensioni o per natura non sta nella cartella condivisa, pulire una vecchia cartella scaricamenti, modificare i permessi di una gerarchia.

Il pattern "prima / dopo" per la reversibilità

Il quinto principio (cap. 14) dice che ogni atto evolutivo è reversibile. Vale anche per le azioni remote: prima di eseguire un'operazione che modifica lo stato del laptop, Metnos conserva su metnos-server un'istantanea del "prima" — solo quello che serve per tornare indietro, non i dati per intero quando non occorre. Per un blocco di rinominazioni foto il "prima" può essere un semplice elenco (percorso_originale, nuovo_percorso, size, hash) firmato e datato. Se Roberto dice "annulla", Metnos legge il manifest e manda al laptop lo stesso schema invertito. La duplicazione è minima (kilobyte, non gigabyte), la reversibilità resta completa, e il registro d'audit su metnos-server conserva la traccia di entrambi i lati. Nei casi più rischiosi (per esempio un'eliminazione definitiva), il manifest può essere promosso a istantanea dei soli file toccati, conservata finché Roberto non dice "conferma".

Per questo, anche se la direzione è inevitabile, non si fa tutto subito. La regola è: si introduce un executor remoto alla volta, motivato da un caso d'uso concreto che la cartella condivisa non riesce a coprire. Quel singolo executor nasce con tutte le garanzie della lista qui sopra e il suo contratto vive in un documento di microprogettazione dedicato. La roadmap (cap. 17) colloca il primo executor remoto come fase ideale 5+, ma quel numero non è intoccabile: se un caso d'uso prioritario lo richiede prima — riordinare le foto è il candidato più naturale — la fase si anticipa; i requisiti di sicurezza no.

5. Libertà, safety, robustezza: tre assi, non due

Un agente che fa tutto quello che vuole è pericoloso. Un agente che chiede conferma per tutto è inutile. Tra i due estremi non c'è una sola tensione, ce ne sono tre. La parola "sicurezza" le confonde tutte sotto un unico termine; questo capitolo le separa, perché solo separate si possono trattare in modo onesto.

Tre parole, tre cose diverse

Distinguere all'inizio paga interessi per tutto il documento. Le tre parole che ci servono sono safety dell'identità, safety del perimetro e robustezza. La prima è una sola cosa intera; la seconda ha un nucleo e un guscio; la terza è un asse a sé. Tutte e tre stanno in un certo rapporto con la libertà di Metnos, ma il rapporto cambia di natura. Il punto del capitolo è insegnare a riconoscere quale dei tre rapporti si sta esercitando in un momento dato, perché applicarne il criterio sbagliato è un errore frequente di progetto.

Tre cose, tre relazioni diverse con la libertà. La parte centrale di questo capitolo le esamina una alla volta.

Asse 1 — Libertà e safety dell'identità: nessun compromesso

La safety dell'identità non è un limite della libertà di Metnos: è la sua condizione preliminare. Se l'identità cede — LLM dirottato da prompt injection, dipendenza maligna che si traveste da executor, comando ricevuto da uno sconosciuto credendolo l'utente — non c'è più "Metnos che agisce liberamente": c'è qualcun altro, vestito da Metnos, che agisce al posto suo. La libertà di Metnos non può essere la libertà di un impostore.

Per questo gli strumenti di safety dell'identità non sono negoziabili. Non c'è un livello di autonomia che li allenta, non c'è un profilo di sandbox che li spegne, non c'è un caso d'uso che li giustifica:

• Pairing dei mittenti (DM pairing, cap. 12): un nuovo utente non comanda finché non è ammesso da un canale già fidato. Stesso principio per i dispositivi (cap. 4): un nuovo laptop non parla alla mente di Metnos prima di una cerimonia firmata.
• Firme e manifest per ogni executor: il gateway rifiuta chiamate a versioni non riconosciute. Gli executor remoti seguono lo stesso trattamento.
• Confine sui contenuti non fidati: tutto ciò che arriva dal web, da canali multi-utente, da file ricevuti è trattato come potenzialmente ostile. Le 4 Leggi (cap. 11) stabiliscono in modo esplicito che Metnos non segue istruzioni nascoste nei dati, solo quelle del proprio utente autenticato.
• Autenticazione reciproca di ogni canale di comunicazione interno (mTLS o equivalente).

Questi strumenti non riducono la libertà: la rendono possibile. Il paragone è con le serrature di casa. Una porta che si chiude non limita la libertà di chi vive dentro, limita quella di chi vorrebbe entrare senza essere invitato.

Asse 2 — Libertà e safety del perimetro: il vero compromesso

Sull'asse del perimetro il compromesso esiste, ed è serio. Allargare il recinto di Metnos — più cartelle leggibili, più comandi eseguibili, più dispositivi pilotabili — amplia ciò che può fare per te, ma amplia contemporaneamente la superficie su cui un errore (suo o altrui) può manifestarsi: una prompt injection ha più cose potenziali da chiedere; un bug di executor ha più file da poter toccare; uno strumento "vedente" può finire per vedere troppo. Più raggio d'azione, più raggio dell'eventuale danno: i due crescono insieme.

Metnos non risolve il compromesso fingendo che non esista, lo media in due livelli. C'è un nucleo duro che non si discute, e c'è un guscio modulabile intorno.

Il nucleo duro

Il nucleo è ciò che resta vietato anche al più permissivo dei livelli di autonomia. Non si configura da YAML: vive nel codice e nelle Leggi, e per modificarlo serve un rito (revisione, firma, rilascio). Esempi:

• Forbidden paths hard-coded: ~/.ssh, ~/.gnupg, le aree di sistema, la cassaforte dei segreti, workspace/.audit/. Anche il livello Full non li passa.
• Sandbox tecnologica: ogni executor che tocca file o shell gira in bubblewrap o systemd-run con un profilo firmato. È il processo stesso che non può uscire dai propri limiti, indipendentemente da quello che gli si chiede o gli si fa credere di dover fare.
• Le 4 Leggi: divieto di azioni che rendano lo stato irrecuperabile, divieto di esfiltrare segreti, divieto di seguire istruzioni nascoste nei dati, divieto di operare al di fuori del proprio utente autenticato.

Il nucleo è un piccolo cerchio. Dentro non si entra mai. Il fatto che sia piccolo è importante: tutto ciò che è nel nucleo paga il prezzo della rigidità, e la rigidità ha un costo — non si può rilassare quando un caso legittimo lo richiederebbe. Mettere troppe cose nel nucleo trasforma Metnos in un sistema chiuso che non sa più aiutare.

Il guscio modulabile

Tutto ciò che sta fuori dal nucleo è il guscio: la latitudine d'azione che si sceglie di concedere a Metnos, modulabile per fascia. La modulazione avviene su tre leve, applicate insieme:

• Livello di autonomia (cap. 12): ReadOnly, Supervised, Full. Definisce quali categorie di azioni Metnos può intraprendere senza chiedere conferma. La latitudine cresce per fiducia dimostrata.
• Profilo di sandbox per executor: ogni executor dichiara nel proprio manifest il proprio profilo (quali percorsi può leggere, quali può scrivere, se può uscire in rete). Profili minimi per gli executor più comuni; profili più ampi solo dove necessario, dichiarati e firmati.
• Soglia di approvazione caso per caso: anche dentro il livello Full, certe azioni (per esempio l'invio di un messaggio a terzi, o l'eliminazione definitiva di un file) restano soggette a conferma esplicita. La soglia non è binaria, è una funzione del rischio dell'azione e del livello di autonomia attivo.

Il guscio si può allargare e restringere in vita. Si parte da configurazioni strette e si rilassa solo quando l'uso lo richiede e la storia lo giustifica. La direzione opposta — partire larghi e restringere "se succede qualcosa" — non si pratica: i guai sui gusci sono in larga parte irreversibili.

Asse 3 — Libertà e robustezza: asimmetria precauzionale

Sul terzo asse il compromesso ha forma diversa. La libertà di Metnos di agire senza chiedere conferma compete con il rischio di azioni che non si possono annullare. Anche qui c'è un principio preciso, ed è economico, non ideologico:

La reversibilità è il vero strumento che sposta l'equilibrio di questo asse, perché rende quasi-recuperabile ciò che altrimenti non lo sarebbe. Una rinominazione è più "libera" se Metnos conserva l'elenco dei vecchi nomi e sa applicarlo al contrario; uno spostamento di file è più "libero" se la copia di sicurezza esiste; un'esecuzione è più "libera" se è idempotente. Il quinto principio (cap. 14) lavora qui: la reversibilità abbassa il costo del sì.

L'asimmetria precauzionale non deve però trasformarsi in paranoia. Un Metnos che blocca sempre per "non sapere mai cosa può andar male" è un agente inutile: il costo non è solo il "non-danno", è anche il "non-valore". Roberto non vuole il cugino che chiama ogni due minuti; non vuole nemmeno il maggiordomo che chiede permesso per spostare una sedia.

I freni dell'architettura, mappati sui tre assi

L'architettura distribuisce le contromisure in modo disomogeneo sui tre assi, ed è giusto così. Vale la pena vederlo in colonna.

Chi vince, in pratica

• Forbidden path, violazione di Legge, mittente non pairato, executor senza firma: vincono identità e nucleo del perimetro. Silenzio, audit, fine.
• Azione esterna irreversibile (invio di un messaggio a terzi, eliminazione definitiva, modifica di file fuori workspace): vince la robustezza — Metnos chiede conferma esplicita, anche se il giudizio teleologico passerebbe.
• Azione ordinaria reversibile dentro il workspace, proposta con alto allineamento ai telos: vince la libertà — Metnos agisce, traccia in audit, pronto ad annullare se Roberto non è d'accordo.
• Accumulo anomalo di azioni o di costo: il bother budget alza la frizione senza che ci sia stata violazione, senza chiamare in causa nessuno dei freni di safety.

6. Idea chiave: i quattro strati

Metnos è una cipolla: l'esterno parla con il mondo, l'interno esegue. Ogni strato si fida solo di quello più interno, concedendo meno privilegi man mano che si va verso il centro.

Strato 1 — Gateway

Un singolo processo FastAPI che espone HTTP/WebSocket/SSE su 127.0.0.1:42618. Riceve messaggi dai canali, gestisce le sessioni, smista webhook, pianifica cron job. È l'unico punto di contatto con il mondo. Non esegue mai direttamente comandi sensibili.

Strato 2 — Policy (con Telos e Vaglio)

Il filtro di legalità e di senso. Dato un evento — "utente X chiede di fare Y", oppure "Metnos vuole proporre Z" — risponde: permesso, negato o permesso solo dopo approvazione. Applica il livello di autonomia (cap. 12), i limiti di frequenza, i tetti di costo, i percorsi vietati, e invoca il Vaglio (cap. 11) quando serve: una guardia costituzionale che blocca violazioni delle Leggi, seguita, se la guardia tace, da un giudice teleologico che misura quanto l'azione è allineata ai telos dell'utente.

Strato 3 — Sandbox

Quando la policy dice "sì", l'azione non viene comunque eseguita a mano libera. Per i tool che toccano filesystem o shell si entra in bubblewrap (o systemd-run con hardening) con un profilo scelto dal livello di autonomia. Niente subprocess.run diretto, mai. Docker è un'opzione futura per il modo più strict.

Strato 4 — Workspace, Executor, Mnestoma

Dentro la sandbox, un executor (capitolo 9) fa il suo lavoro: leggere un file dal workspace (${METNOS_HOME}/workspace/), chiamare un LLM via l'interfaccia astratta, scrivere una riga nell'audit log. Ogni volta che due executor collaborano, un mnest registra silenziosamente l'accaduto. L'insieme di tutti i mnest forma il mnestoma, la memoria relazionale del sistema.

7. Il flusso di una richiesta

Seguiamo un esempio concreto. Sei in giardino, scrivi da Telegram: "dimmi cosa c'è nel log di stasera".

La variante proattiva

C'è un secondo tipo di richiesta che non viene mai mostrata nei diagrammi classici degli agenti: la richiesta che nasce da dentro. Un cron, o il grafo delle proto-mnest (cap. 9), o una regolarità notata da Metnos stesso, genera una proposta: "vuoi che archivi le foto di stasera come fai di solito?". Questa proposta entra nello strato 2 dal basso, non dal Gateway: prima passa per il Vaglio (cap. 11) che verifica se viola una Legge e se l'allineamento ai telos è sufficiente, e solo se supera l'uno e l'altro arriva al Gateway, che la inoltra al canale preferito dell'utente come notifica leggera. Se l'utente ignora, la proposta non si ripropone identica: viene registrata e il suo peso decresce.

Esempio canonico: presidiare una casella di posta

Un caso d'uso semplice e ricorrente della variante proattiva è presidiare una casella di posta del dominio (per esempio [email protected]): controllarla a un ritmo concordato, classificare i messaggi nuovi (richieste reali, conferme automatiche, spam mancato dal filtro, ecc.) e consegnare a Roberto un riassunto solo quando ha senso. Le quattro mosse minime:

1. Controllare a intervalli (es. una volta al giorno, mattina): un executor imap_status conta i messaggi non letti per cartella senza scaricarli.
2. Leggere e classificare solo se ci sono novità: un executor imap_fetch_headers recupera intestazioni; un classificatore (LLM local-fast, vedi cap. 8) etichetta in tre o quattro categorie.
3. Riassumere: per i messaggi che meritano attenzione umana, un executor summarize produce due righe per ciascuno.
4. Consegnare: un executor notify manda il riassunto sul canale preferito di Roberto (Telegram, mail personale, voce). Il bother budget e il telos di discrezione regolano la frequenza.

Le quattro mosse non sono una nuova categoria di design: sono una catena di executor invocata dallo scheduler (executor builtin, cap. 9 della microprogettazione executor) a un ritmo accettato una volta in fase di proposta. Vista dal mnestoma, è una traccia di quattro mnest che si rinforza ogni mattina; in tempi più lunghi synt (cap. 9) può proporne una versione fusa, un singolo executor email_morning_digest che incorpora la catena. Le invocazioni programmate dallo scheduler consumano una quota separata dal bother budget delle proposte ad-hoc, perché il consenso al ritmo è già stato dato.

8. L'interfaccia LLM, il pattern provider-agnostic

Metnos non parla mai direttamente con Claude, OpenAI, Ollama o qualunque altro fornitore di modelli linguistici. Parla con un'interfaccia astratta (tipicamente un typing.Protocol) che il registro risolve a runtime in un'implementazione concreta. Lo stesso vale per STT, TTS, embedding, speaker ID. È il pattern che rende Metnos provider-agnostic: chi scrive Metnos non deve sapere quale modello girerà davvero, e chi amministra l'ambiente può cambiarlo con una riga di configurazione.

Nel diagramma che segue, Metnos è un consumer tra i possibili altri: un assistente domotico per voce e controllo casa, ulteriori bot specializzati su domini ristretti. Tutti condividono la stessa astrazione. Nessuno riscrive il layer AI: lo usa.

Il vantaggio concreto: un nuovo modello (es. Claude 4.7 quando sarà disponibile) si configura una volta sola nell'implementazione dell'interfaccia e tutti i consumer lo ereditano simultaneamente — Metnos compreso. Nessun codice da rifare, nessun deploy da coordinare.

9. Executor, mnest, mnestoma: l'anatomia dell'agire e del ricordare

Qui entriamo nel cuore del secondo dialogo. Due domande che sembrano diverse ma sono la stessa: come agisce Metnos? e come ricorda?. La risposta è un piccolo vocabolario di cinque parole. Impararlo bene ora paga il resto del documento.

Un esempio: la fattura che genera syntesi

Roberto riceve una fattura in PDF. Metnos la legge (fs_read), estrae il testo (pdf_ext), archivia (archive), notifica (notify). Ogni passaggio di mano tra due executor incrementa il peso del relativo mnest. Dopo un mese, la traccia "fatture" ha quattro nodi densamente connessi.

Un giorno arriva una fattura che contiene solo un'immagine scansionata. pdf_ext restituisce stringa vuota. Metnos cerca un executor che sappia fare OCR. Non c'è. Registra un proto-mnest: "da pdf_ext vorrei andare a un ipotetico ocr, che non esiste". Dopo cinque fatture scansionate (tutte con lo stesso proto-mnest) il synt (cap. 10) propone all'utente: "sto incontrando ripetutamente PDF-immagine. Vuoi che provi a sintetizzare un executor ocr_image?". Se Roberto approva, nasce un executor nuovo.

La cascata della sintesi: prima comporre, poi generare

Quando un proto-mnest ricorre, il synt non salta subito a scrivere codice nuovo. Procede per gradi, in una cascata che mette al primo posto il riuso. Il principio è pratico, non estetico: una chiamata a un LLM frontier per generare uno scheletro di executor costa attorno all'euro; cercare una catena di executor già firmati che risolve la stessa cosa non costa nulla. Disciplina del costo e disciplina della libreria coincidono.

1. Comporre. Il synt scorre il pool degli executor attivi e prova a costruire una catena A → B → C che chiuda il proto-mnest. Se la trova, la propone come prima risposta: nessuna sintesi, nessun executor nuovo, solo un orchestrato di pezzi esistenti. Lascia però una traccia: se la stessa composizione si ripete, è un segnale che varrebbe la pena promuoverla a executor unico (un piccolo proto-mnest verso una composizione, non verso un executor).
2. Generare. Solo se la composizione non esiste o è troppo lunga per restare leggibile, il synt entra nella pipeline a sette stadi (cap. 10) e propone un nuovo executor. La generazione è il fallback, non il default.

A questi due passi reattivi (che rispondono a una richiesta dentro il turno) si affiancano tre passi introvertivi, eseguiti nottetempo dall'ager sul mnestoma e sul pool firmato:

• Fondere due executor con tracce sovrapposte e profili compatibili in uno solo che li copre entrambi (già previsto dal lifecycle «fuso» del cap. 6 della microprogettazione executor).
• Generalizzare N executor specializzati con stessa forma in un executor parametrico più ampio, quando le richieste ricorrenti rendono evidente la dimensione comune.
• Specializzare un executor generale per un caso caldo, ma solo se la specializzazione produce un beneficio misurabile (non come ottimizzazione preventiva).

Tutti i passi introvertivi sono proposte: arrivano a Roberto in modo batch, con la stessa pipeline di approvazione di un executor di sintesi reattiva. Niente si sposta nel pool senza firma. La libreria non degrada perché ogni passo, prima di entrare, attraversa la guardia umana.

10. Tracce, ager, reversibilità: come il sistema cresce e si disfa

Un grafo che cresce per accumulo e non si disfa è una discarica. Metnos ha tre meccanismi per restare maneggiabile: emergenza di tracce (la struttura si auto-organizza), ager (invecchiamento per uso, non per calendario), reversibilità (ogni mossa evolutiva ha il suo opposto).

Tracce: struttura che nessuno disegna

Su scala settimanale, un processo leggero misura la modularità del grafo mnestoma — un'idea che arriva dalla network medicine: cluster di nodi con alta densità interna e bassa densità esterna sono tracce naturali. Metnos non le progetta, le rileva. "Fatture", "foto", "mail" nella figura 5 sono tre tracce emerse.

Le tracce hanno due conseguenze concrete:

1. Routing: quando Metnos entra in una conversazione, sa quali tracce sono rilevanti e porta al tavolo solo i loro executor, evitando che l'intero mnestoma affolli il prompt.
2. Disciplina della fusione: due executor possono essere proposti per essere fusi in uno più generale, ma solo se stanno nella stessa traccia. Le fusioni cross-traccia sarebbero regressioni strutturali travestite da progresso.

Ager: il tempo dell'uso, non il tempo del calendario

Se vai in vacanza un mese e spegni il computer, non vuoi trovare al ritorno Metnos invecchiato di un mese. Il tempo dell'ager è il tempo dell'uso: i cicli avanzano con le invocazioni, non con i giorni. Un sistema che dorme non invecchia. Sembra una sfumatura; non lo è. Il tuo mnestoma è legato a quanto lo hai usato, non a quanto tempo è passato.

Ogni N invocazioni (50, 100 — il parametro è nel file di configurazione) l'ager:

• decrementa linearmente il peso dei mnest non aggiornati di recente;
• marca come "in quarantena" gli executor il cui uso è sceso sotto una soglia;
• propone all'utente l'archiviazione di executor e mnest in quarantena da tempo.

Propone, non esegue. L'ager non ha potere di decisione autonomo. Porta la lista, l'utente decide. Come ogni cosa in Metnos.

Reversibilità: ogni mossa ha il suo opposto

Il quinto principio (cap. 14) dice: ogni atto evolutivo è reversibile, con motivazione scritta. Le operazioni hanno nomi specifici:

11. Telos e Vaglio: proattività senza tirannia

Un sistema proattivo che non si ferma è un sistema molesto. Un sistema proattivo che si ferma sempre non è proattivo. La coppia telos + vaglio è il meccanismo che regola questo equilibrio. I telos danno il motivo di proporre; il Vaglio decide se la proposta si merita davvero la tua attenzione.

Telos: i fini ultimi, scritti a mano

TELOS.md è uno dei cinque file del workspace (cap. 13). Contiene da tre a sette frasi brevi che descrivono cosa, nella vita quotidiana, l'utente vuole che Metnos favorisca. Non sono KPI. Sono tendenze morbide.

### TELOS.md (esempio)

1. Liberare il mio tempo: preferisci ciò che riduce il mio carico manuale
   ripetitivo.
2. Ordine, non perfezione: meglio una casa di file a posto al 70% in
   automatico, che uno sforzo continuo per averla perfetta.
3. Nessuna sorpresa sulle spese: soglie chiare, notifiche tempestive.
4. Solitudine protetta: non disturbarmi la sera dopo le 21, salvo urgenze
   reali.
5. Coltivare gli strumenti: se ti chiedo qualcosa che il tuo pool non sa
   ancora fare, esaurisci le strategie di sintesi (comporre, generare,
   chiedere) prima di rispondere "non posso". Il fallimento è lecito,
   la rinuncia silenziosa no.

Ogni proposta spontanea di Metnos passa per una funzione di allineamento: quanto la proposta favorisce ciascun telos, pesato per la loro importanza relativa. Il risultato è un numero tra 0 e 1. Se è sopra la soglia, la proposta arriva. Se è sotto, resta muta e finisce in un registro di "proposte non fatte", utile per capire in retrospettiva se i telos pesavano davvero come credevi.

Vaglio: la guardia e il giudice

Prima che una proposta, spontanea o richiesta, arrivi all'utente, passa per il Vaglio. Il Vaglio ha due fasi in ordine fisso.

Perché due fasi e non una sola

Se mescolassi "è lecito?" e "quanto vale?" in un solo punteggio, otterresti ciò che la letteratura chiama self-enhancement bias: il modello tende a giustificare le sue proposte. Separare deontologia (binaria) e teleologia (graduata) è una scelta progettuale precisa. E c'è di più: il giudice teleologico è un LLM diverso dal proponente — contesto separato, prompt separato, possibilmente provider separato. Indipendenza strutturale, non dichiarata.

Il componente di microprogettazione dedicato è vaglio.html; quello dei fini è telos.html. Lì ci sono le tipologie dati, i Protocol, i test di conformità.

Bother budget: il costo di disturbare

Anche con l'allineamento alto, c'è una cosa che il Vaglio valuta: quante proposte ho già fatto di recente?. Il bother budget è un freno moltiplicativo che degrada l'allineamento quando Metnos ha già parlato troppo in una finestra temporale. È la traduzione meccanica di "non essere il cugino che chiama a ogni pensiero".

12. I tre livelli di autonomia e il DM pairing

Concetti ripresi e adattati da zeroclaw. Ogni sessione gira a un livello di autonomia dichiarato; il livello determina quanto Metnos può fare prima di dover chiedere conferma. Ortogonale all'autonomia, il pairing distingue un familiare da uno sconosciuto su canali multi-utente come Telegram.

Livelli di autonomia

Il DM pairing

Un canale come Telegram è inerentemente multi-utente: chiunque conosca l'handle del bot può scrivergli. Il pairing è il meccanismo che distingue un familiare da un estraneo.

13. Il workspace: file markdown invece di codice

La "personalità" di Metnos non è in un file Python. È nel workspace/, in sei file markdown che Roberto può editare quando vuole senza restart. L'idea viene da openclaw/zeroclaw ed è azzeccata: la configurazione comportamentale è testo leggibile, non una struttura dati sepolta.

Questi file sono iniettati nel prompt di sistema a ogni chiamata LLM (con opportuno caching per non consumare token). Editarli è il modo primario di "riprogrammare" Metnos.

L'audit log vive in workspace/.audit/ come JSONL append-only: una riga per ogni tool call, con timestamp, sender, azione, esito, costo stimato. Ogni mossa evolutiva (synt, fusione, defuse, archiviazione, ripristino) vi lascia una riga. Questo è l'unico registro che non si disfa; la reversibilità è nello stato, non nella storia.

14. I sei principi

Alla fine del secondo dialogo, Roberto si è imposto di contare i principi sulle dita. Il risultato è un vocabolario minimo che regge tutto il resto del documento. Se dovessi perdere tutto e dovessi ricostruire solo da sei frasi, sarebbero queste.

15. Struttura del repository

16. Cosa NON è Metnos

• Non è un framework generalista. openclaw punta a essere piattaforma; Metnos è un agente per una casa. Se serve un altro agente con regole diverse, se ne fa un'altra istanza, non si astrae.
• Non è un hub di servizi AI. I servizi AI stanno dietro un'interfaccia astratta, fornita da un adapter esterno. Se manca un servizio, lo si aggiunge là, non qui.
• Non addestra modelli. Niente fine-tuning, niente RLHF, niente RAG con vector store indistinto. Il sistema cambia sé stesso attraverso il mnestoma (memoria relazionale fuori dall'LLM) e attraverso synt (proposta di nuovi executor con approvazione umana). L'LLM resta quello del provider, quando viene aggiornato dal provider.
• Non supporta 20+ canali fin dall'inizio. Si parte con 2 (CLI + Telegram). Signal, WhatsApp, voce arrivano quando servono davvero.
• Non è un cloud agent. Gira a casa. Accesso remoto solo via overlay esplicito (Headscale self-hostato), o via il canale Telegram quando comodo. Mai un'apertura non scelta.
• Non è un agente che gira sul laptop. Il laptop è un cliente di Metnos, non la sua sede. Il processo, la memoria e la regola vivono su metnos-server: una sola istanza, un solo mnestoma, un solo registro d'audit. Vedi cap. 4 per la spiegazione completa di questa scelta e per le quattro alternative scartate.
• Non è un sostituto di un sistema di domotica. Per il controllo vocale e la domotica c'è un assistente domotico dedicato. Metnos può chiedergli, non duplicarlo.
• Non è un framework agentico generico (langchain, llamaindex, crewai, ...). Quelle librerie possono essere usate dentro un executor, mai come sostituto dell'architettura.
• Non è un IDE né un dev assistant. Non scrive codice in altri progetti per conto dell'utente: al massimo ne analizza con executor read-only. Per lavorare sul codice esiste già Claude Code.

17. Roadmap & approfondimenti

La roadmap è volutamente piccola. Passo uno alla volta, con il documento di microprogettazione che precede il codice.

Continua a leggere

Metnos — Architettura: Introduzione v1.1 — 2026-04-24
Ispirato a openclaw e zeroclaw, costruito sopra suprastructure.
v1.1: incorpora il Dialogo sui fini e sui limiti (telos, vaglio, 4 Leggi) e il Dialogo sugli executor e la memoria distribuita (executor, mnest, mnestoma, tracce, ager).