1. Cos'è Metnos

Metnos è un'architettura self-hosted per un agente governato. Il core non definisce un dominio applicativo: pianifica, applica policy, ricorda, sintetizza, isola e registra. È il set di executor ammessi a definire cosa può fare davvero una specifica istanza. Gli executor sono piccoli programmi firmati, generati o importati soltanto dentro un vocabolario chiuso e orchestrati da un planner LLM local-first. I modelli frontier sono consulti opzionali, non la sede del sistema.

Il nome viene da mētis (l'intelligenza astuta) + noûs (la mente). Vive su una macchina sotto il tuo controllo fisico e legale. L'istanza di riferimento si usa da Telegram e dal browser (porta 8770), e il suo catalogo corrente copre file, posta, foto, calendari, web, GitHub e operazioni sull'host. Sono usi di quel catalogo, non limiti di Metnos. Cambiando gli executor ammessi e le skill/backend attive cambia il dominio operativo, senza cambiare l'architettura che lo governa.

La carta d'identità

2. Le tre scommesse

Tutto il progetto sta in tre scommesse architetturali. Sono scelte di campo, non ottimizzazioni: ciascuna rovescia un'abitudine diffusa dei framework agentici.

Il confronto, senza sconti

3. I concetti chiave, in sette carte

Sette parole reggono tutto il documento. Definirle adesso vi risparmia mezz'ora di confusione fra trenta righe; ognuna ha il suo contratto implementativo nell'atlante dei componenti.

L'anatomia di un nome

Il vocabolario chiuso è l'idea più fertile del progetto: rende i nomi componibili (il pianificatore può prevedere come si chiama una capacità che non ha mai visto), filtrabili (il prefilter ragiona su verbo e oggetto) e sintetizzabili (synt non può nominare nulla fuori dalla grammatica).

4. L'architettura a strati

Metnos è una cipolla: l'esterno parla col mondo, l'interno esegue. Ogni strato si fida solo di quello più interno e i privilegi calano scendendo verso il centro. Una richiesta — venga da un utente o da un task schedulato — li attraversa tutti, nell'ordine.

• Canali — un canale è un adattatore: converte un'interfaccia esterna (Telegram, browser) in messaggi e risposte. Aggiungerne uno non tocca il nucleo (cap. 11).
• Runtime del turno — il guscio che misura e orchestra: telemetria per sotto-fase (intent_ms, prefilter_ms, vaglio_ms, exec_ms), cap di sicurezza, log.
• Motore Mētis — pianifica una volta, esegue deterministicamente, recupera con criterio, e quando non c'è via d'uscita lo dice (cap. 5).
• Guardie — nessun subprocess a mano libera, mai: ogni effetto passa da policy, vaglio e sandbox (cap. 12).
• Executor e backend — chi agisce e contro cosa: la separazione skill↔backend tiene il fornitore fuori dalla testa del pianificatore; il placement decide poi se l'executor resta sul server o va a un device registrato (cap. 3 e 6).
• Tessuti — ciò che resta fra un turno e l'altro: memoria associativa, scorciatoie apprese, cronologia per l'undo, audit.

5. Anatomia di un turno multitool

Questo è il capitolo da leggere se ne leggete uno solo. Seguiamo una richiesta vera — «cerca le mail spam e mettile nel cestino» — dall'ingresso alla risposta: quattro strumenti concatenati, una sola chiamata al modello, ogni passaggio misurato e annotato.

5.1 La cascata, passo per passo

La regola di fondo: il modello è l'ultima risorsa, non la prima. Prima si tenta la memoria (zero LLM, millisecondi); se la richiesta è nuova, il modello viene interrogato una volta sola e gli si chiede l'intero piano; l'esecuzione che segue è pura meccanica deterministica.

1. Scorciatoie letterali. Una tabella chiusa riconosce le frasi notissime («che ora è») in microsecondi. Qui: nessun match.
2. Intent. Una chiamata al tier fast (ragionamento spento, ~0,4 s) estrae verbo canonico, oggetto e parole chiave. Le richieste composte diventano una lista ordinata di clausole, ognuna col suo pool.
3. Memoria dei piani. Fastpath (scorciatoie che hai approvato col bottone ★) e Autopath (piani imparati da soli) rispondono senza modello se riconoscono la richiesta. Qui: miss, è la prima volta.
4. Prefilter. Il catalogo si riduce al pool pertinente per la clausola: match su verbo+oggetto, bonus per qualifier, e — per rompere i pareggi fra fratelli — il bonus di affinity curata (cap +3). Tutto deterministico: stessa query, stesso pool, stesso ordine.
5. Proposer Mētis. UNA chiamata al tier wise produce l'intero piano: steps, collegamenti, messaggio finale. Genera fino a N candidati (adattivo, con early-stop), ognuno fisicamente vincolato dalla grammatica GBNF del pool; un rango teleologico sceglie il migliore.
6. Validator. Typecheck del piano prima di eseguire: tool esistenti, args ben formati, riferimenti reali. Un errore banale costa una riproposta, non un'esecuzione sbagliata.
7. Esecuzione. Meccanica pura: per ogni step il runtime risolve i segnaposti, passa dal vaglio, invoca in sandbox, accumula l'osservazione. Cap: 12 step per turno, stesso executor max 3 volte di fila.
8. Chiusura. Il messaggio finale è un template riempito dai risultati veri. Se il turno riesce, Autopath lo registra: la prossima volta si salta direttamente al punto 3.

5.2 Il piano: cosa propone davvero il modello

Il Proposer non produce prosa: produce un oggetto strutturato — steps, slot da riempire (fillers), messaggio finale. Questo è il piano reale della nostra richiesta:

{
  "steps": [
    {"tool": "find_messages",
     "args": {"folder": "INBOX", "query": "is:unread"}},
    {"tool": "classify_entries",
     "args": {"from_step": 1, "dimension": "spam"}},
    {"tool": "filter_entries",
     "args": {"from_step": 2, "where_field": "spam", "where_value": "spam"}},
    {"tool": "move_messages",
     "args": {"from_step": 3, "dst_folder": "${FILLER:cestino_folder}"}}
  ],
  "fillers": {
    "cestino_folder": {
      "prompt": "Come si chiama la cartella cestino per questo account?",
      "default": "Trash",
      "tier": "fast"
    }
  },
  "final_message": "Spostate ${step4.ok_count} mail nel cestino."
}

Da notare: il modello non conosce il nome della cartella cestino dell'account — e non lo inventa. Dichiara uno slot (${FILLER:cestino_folder}) che il runtime riempirà al momento giusto con una micro-chiamata economica (con cache) o col default.

5.3 Il data piping: come i passi si parlano

6. Executor: vettoriali per costruzione

Ogni executor accetta una lista e ritorna una lista — anche quando la lista ha zero o un elemento. Non esiste nessun *_batch: la versione batch è l'executor. È la decisione che rende i piani corti e i risultati componibili.

Dal contratto discendono tre convenzioni che vedrete ovunque:

• entries vs results — chi arricchisce o legge una lista ritorna entries (lo schema dei record si conserva, la pipeline può continuare); chi trasforma (move, write, delete) ritorna results (lo schema cambia: esiti, non record).
• Robustezza al confine col linguaggio naturale — 0 come placeholder vale «nessun limite»; i confronti sono case-insensitive di default; sui domini testuali aperti i valori con */? sono glob, sui domini chiusi (id, slug, scope) il match è esatto e stretto. Così le inclinazioni dell'LLM non diventano fallimenti silenziosi.
• Onestà dei conteggi — ok_count conta gli elementi realmente processati. Mai dichiarare un esito che non corrisponde alla realtà.

Il manifest: il prompt del tool

Ogni executor porta con sé un manifest TOML. Non è documentazione di cortesia: è ciò che il pianificatore legge quando decide se e come usare lo strumento — scritto su misura per un LLM medio locale, non per un modello frontier. Frasi corte, esempi letterali, default in chiaro; la descrizione segue quattro capitoli prescrittivi:

Lo stesso manifest dichiara anche dove l'executor puo' girare. I campi platforms e [placement] impediscono di mandare a Windows un tool scritto solo per Linux, o di eseguire su un PC un executor non auditato per il device. Quando la chat nomina un PC appaiato, il runtime usa queste dichiarazioni per decidere se eseguire sul server o sul dispositivo; se il bersaglio non e' raggiungibile, l'esito e' onesto, non un fallback silenzioso.

[description]
it = "SCOPO: cerca file per pattern in directory.
      PATTERN: find_files(base_path=\"/\", patterns=[\"*.jpg\"]).
      NON: list_dirs+filter_entries; get_files (lookup ID).
      OUT: entries=[{path,name,type,mime,kind,size,mtime}]."

Una sola politica di esecuzione

Ogni chiamata a un executor, locale o remota, attraversa lo stesso motore di esecuzione. In un punto solo il runtime applica metriche, retropressione, limiti per risorsa e un tetto derivato dall'hardware. Il comportamento predefinito resta intenzionalmente seriale e il pool trasversale e' spento: adottare l'infrastruttura non cambia l'ordine, gli input, gli output o le capacita' degli executor esistenti.

[execution]
effect = "unknown"
parallelism_class = 0
resource_class = "default"
concurrency_key = "none"
equivalence_gate = "unverified"

La classe misura soltanto un budget: non concede autorita' e non significa sola lettura. Un futuro executor che crea o modifica oggetti puo' essere concorrente, ma deve dichiarare una chiave d'isolamento, fornire l'identita' della risorsa e superare prove di equivalenza, collisione, idempotenza e postcondizione. Se manca una di queste evidenze, il loader lo riporta alla classe 0.

Anche i tre percorsi che generano executor — proposta Synt, sintesi reattiva e generazione da skill — consumano un unico contratto centrale. Il modello locale puo' progettare un'implementazione ricca, ma non puo' riscrivere identita', ciclo di vita, I/O o politica iniziale. Se parallelizza elementi indipendenti, il numero di worker arriva dal motore e i risultati devono tornare nell'ordine di ingresso.

Autorità remota: dichiarata una volta, consumata tre volte

Il nome di un provider dentro un argomento è un dato, non un permesso. Per un executor conforme, l'accesso remoto esiste solo quando il manifest dichiara una capability provider:access effettiva. Una condizione when chiusa può attivarla soltanto per il backend selezionato. Condizioni invalide o non corrispondenti non concedono nulla.

Esecuzione sul server o su un PC registrato

La forma normale resta semplice: il piano sceglie un executor, il runtime lo passa attraverso policy e vaglio, poi lo invoca nella sandbox del server. Gli executor remoti aggiungono una sola deviazione controllata: per alcuni executor dichiarati portabili, il punto di esecuzione puo' essere un PC registrato nella stessa rete o overlay.

Non e' un nuovo canale e non e' un backend qualunque. Il canale resta Telegram o web; il backend resta file, posta, calendario o altro servizio. Il remote executor e' il luogo in cui gira il piccolo programma firmato. Metnos mantiene sul server la scelta dell'executor, il controllo di policy, il registro dei device, la firma del payload, il timeout e l'audit.

La scelta non dipende dall'indirizzo IP del browser. In una UI web la macchina che apre la pagina puo' coincidere col server, con un altro PC della rete, o essere dietro un proxy; da Telegram non c'e' proprio un browser locale. Per questo Metnos usa il nome del device appaiato e lo ancora al linguaggio della richiesta: «sul portatile» e' un target, «il portatile» da solo non lo e'.

Il client remoto non riceve liberta' generale. Fa polling verso il server, non espone porte; verifica la firma del server prima di eseguire; scarica solo executor firmati e compatibili; scrive il result nello spool locale prima di consegnarlo. Se il server non risponde, ritenta la consegna senza rieseguire il lavoro gia' fatto.

Il client remoto e' contenuto per costruzione: su Windows il Job Object limita durata, memoria e albero dei processi; su Linux la sandbox usa bwrap quando presente. Su questa base i remote executor non sono piu' solo read-only: da C7 (ADR 0183) girano sul dispositivo anche i mutanti — scrittura, spostamento e cancellazione file — resi sicuri dalla policy che a lungo avevano richiesto: idempotenza, audit e reversibilita' device-aware (reverse pattern deterministici e backup blob accodati allo stesso dispositivo per l'annullamento; con il gap noto che il restore-da-blob non e' remotabile). Gli executor le cui dipendenze non sono risolvibili sul dispositivo restano server-only.

Il dettaglio operativo — pairing del PC, installazione dalla UI, heartbeat, coda firmata, sandbox per sistema operativo e limiti attuali — sta nel contratto executor remoti.

7. Synt: la fabbrica degli strumenti

Quando il pool non sa fare una cosa, il pianificatore non improvvisa codice nel mezzo del turno: passa la mano a synt, il processo che fa esistere ciò che manca. Prima prova a comporre executor esistenti; solo come eccezione documentata genera un executor nuovo — in cinque stadi, ognuno col suo contratto.

Due inneschi, una cascata

In entrambi i casi vale la stessa regola: synt propone, l'umano approva. Nessuna auto-modifica senza filtro; ogni proposta arriva con motivazione, ed è reversibile.

Il gate a 7 livelli

Lo stesso imbuto vale per il codice sintetizzato e per le skill importate da fuori: nessun pacchetto si esegue sulla fiducia.

8. Quattro tier, un routing deterministico

I tier sono ruoli astratti, non modelli inchiodati: fast / middle / wise sono incarichi che leghi a qualunque endpoint tu abbia, frontier è il cloud facoltativo. Più tier possono condividere un endpoint oppure essere separati: il planner vede sempre il ruolo.

Le tre serrature del determinismo

Un LLM a temperatura zero non basta a rendere il routing riproducibile: il server locale resta non-deterministico per via della decodifica speculativa col seed casuale. Metnos chiude la porta con tre serrature, una per ogni fonte di rumore:

9. La memoria che accelera

Metnos non addestra modelli: niente fine-tuning, niente RLHF. Tutto ciò che impara è dato ispezionabile — piani, tracce, scorciatoie — e ogni cosa imparata si può leggere, correggere, cancellare. L'effetto pratico: più lo usi, meno chiama il modello.

10. I sensi: la pipeline immagini

Per cercare nelle foto, Metnos non spedisce nulla a nessuno: tre estrattori nel processo trasformano ogni immagine in tre segnali — cosa si vede, chi c'è, dove e quando — fusi in un indice unificato interrogabile dal vocabolario normale.

La ricerca arriva dal canale come qualunque altra richiesta: il pianificatore compone find_images_indices con i criteri estratti dalla frase, e il canale mostra le anteprime inline. La costruzione dell'indice è un lavoro di fondo, incrementale e riavviabile, che si lancia con una frase («indicizza le foto in…»).

11. I canali: Telegram e web

Un canale è un adattatore: converte un'interfaccia esterna in messaggi e risposte, più una capacità opzionale — rendere bottoni per conferme e scelte. Due canali nascono con l'installazione; aggiungerne altri non tocca il nucleo.

Il Tutor: spiegare senza eseguire

Le domande esplicite su come usare Metnos vengono intercettate allo stesso confine HTTP/Telegram, prima del pianificatore e senza consumare un dialogo pendente. Un rilevatore prudente riconosce soltanto la classe di richiesta; la scheda pertinente non è scelta da sinonimi o frasi exact, ma da embedding BGE-M3 locali confrontati con vettori conservati nel catalogo SQLite firmato.

Dopo il recupero, il principal autenticato filtra il contenuto. Le procedure amministrative restano deterministiche; per le guide informative il modello locale formula la risposta usando soltanto la scheda recuperata e l'inventario ammesso dell'istanza. Non riceve strumenti e attraversa lo slot centrale llm in classe seriale: può spiegare, non agire. Catalogo non valido, match debole o contesto insufficiente producono un esito dichiarato, mai una capacità inventata.

12. Sicurezza e reversibilità

La sicurezza non è un modulo: è una catena di guardie indipendenti, e un'azione deve passarle tutte. E siccome anche la guardia migliore sbaglia, l'ultima difesa è poter tornare indietro: undo onesto, per costruzione.

13. Atlante dei componenti

L'architettura vista fin qui dice cosa promette il sistema. Questo atlante mostra quale componente possiede ogni promessa e dove vive il suo contratto esatto.

13.1 Dalla visione ai contratti dei componenti

L’architettura di Metnos ha due livelli di ingrandimento. Il livello alto descrive il sistema nel suo insieme: strati, organi, leggi e fini. È il percorso che avete appena seguito dal capitolo 1.

Il livello basso è l'insieme degli approfondimenti collegati qui sotto: un documento HTML per ogni componente, con il dettaglio sufficiente a scriverne il codice senza inventare nulla. Le scelte qui non sono opinioni — sono contratti: schema dei dati, firme delle funzioni, flag di sandbox, condizioni di errore. Quando il codice e il documento divergono, vince il documento e il codice si adegua, oppure il documento viene corretto subito (mai «dopo»).

La regola di vita è semplice: nessun componente viene implementato prima che il suo HTML esista, sia approvato e parli la stessa lingua del codice già in casa.

13.2 Quattro nomi, ora come contratti implementativi

Tutto Metnos gira intorno a quattro nomi. Definirli adesso vi risparmia mezz’ora di confusione fra trenta righe.

executor

Una capacità eseguibile: un piccolo programma che fa una cosa sola e bene (leggere file, mandare una mail, calcolare un hash, tradurre un OCR, scoprire URL nuovi su un sito). Ogni executor accetta liste in ingresso e produce liste in uscita; ha un manifest che lo descrive, una firma Ed25519 che lo autentica e un profilo di sandbox che lo confina. Gli appartenenza al prodotto, origine e trasporto restano assi distinti. Gli executor GitHub mantenuti da Metnos sono builtin di origine handcrafted, non importati; il catalogo generato è la fonte unica per la suddivisione del tree sorgente.

mnest

Il filo che collega due executor quando sono stati attivati insieme dal pianificatore. Non è un puntatore di codice, è una traccia: nasce dal contesto, si rinforza con la ripetizione, decade se non viene riusato.

mnestoma

Il grafo emergente di tutti i mnest. È la memoria associativa del sistema: vive su SQLite, viene curata da un processo notturno (ager) e fornisce al pianificatore l’intuizione di «quale executor di solito segue quale». La controparte inglese del termine è mnestome.

agent runtime

Il motore che orchestra il tutto: riceve la richiesta dell’utente, la spezza in passi, sceglie gli executor, li lancia in sandbox, raccoglie le osservazioni, decide il passo dopo. Implementa il loop ReAct con tool-use nativo (LLM locale, tier wise) e si appoggia agli altri componenti per le decisioni difficili (Vaglio per la sicurezza, Synt per le capacità mancanti, Telos per i fini).

13.3 La mappa dei componenti

I componenti documentati sono organizzati per ruolo. Lo schema sotto raggruppa i nodi principali per ruolo: il bordo nero spesso è il motore centrale, le forme verdi i «servizi» che il motore consulta, le forme azzurre i «tessuti» che memorizzano lo stato, le forme color bronzo gli organi periferici verso l’utente e verso l’ambiente. Le frecce indicano chi chiama chi.

Tre osservazioni utili per leggere lo schema.

1. Il telos sta sopra a tutto: non è un servizio che si chiama, è un’orientazione. Il runtime pesa le alternative anche in funzione dei fini dichiarati nell’omonimo file del workspace.
2. Il vaglio è sempre prima dell’esecuzione, mai dopo. Una volta che un executor è partito non si torna indietro in modo gratuito: l’undo esiste, ma costa storia e blob di backup.
3. Il pool di executor è aperto: il synt può comporne di nuovi mettendo in fila quelli esistenti, oppure (se non basta) generandone uno ex novo, con firma e installazione automatica.

13.4 Una seconda richiesta guidata

Per fissare la mappa, seguiamo una richiesta semplice dall’ingresso fino alla risposta: «sposta in ~/Archivio/2026 i PDF di fatture arrivati questa settimana».

1. Channel. Telegram riceve il messaggio dell’utente. Il daemon controlla che il mittente sia stato pairato con un livello d’autorizzazione sufficiente; in caso contrario il messaggio viene scartato senza eco. Pairing significa «canale + sender ID riconosciuto»: si ottiene rispondendo a un codice Ed25519 firmato con TTL.
2. Agent runtime — pianificazione. Il runtime estrae l’intent (verbo canonico: move; oggetto: files; criterio: PDF allegati a fatture in finestra «ultima settimana»), interroga il prefilter per ridurre il catalogo agli executor pertinenti e prepara il primo passo del loop ReAct.
3. Vaglio — guardia + giudice. Prima di lanciare l’executor il Vaglio controlla due cose: che il percorso non sia vietato (forbidden paths), che il comando shell non sia irrecuperabile (rm -rf e simili). Per le operazioni che cadono in zona grigia, il giudice rule-based assegna un punteggio e, se sopra soglia, chiede una conferma all’utente tramite carta a 3 righe (cosa/dove/perché).
4. Sandbox + executor. Il runtime invoca read_messages dentro bwrap con i flag derivati dal manifest. L’output torna come lista di entries; ogni entry è un dizionario con il path del PDF e i metadati.
5. Pipe. Il passo successivo è move_files; riceve la lista del passo precedente con from_step: N. La verità sui dati vive nello scratchpad: il pianificatore non vede l’intera lista, ne vede una vista sintetica che gli basta per decidere.
6. Mnest + mnestoma. La coppia read_messages → move_files rinforza una traccia esistente nel grafo. Se non esiste, viene creata. L’ager notturno farà manutenzione: decadimento, fusioni, scarti.
7. Risposta. Il runtime restituisce all’utente, via Telegram, il numero di file spostati e il primo motivo di scarto se qualcosa è stato escluso. La final_answer include il marker di troncamento se la lista di partenza era stata limitata da un cap.

13.5 Gli approfondimenti canonici

Sotto, i documenti sono raggruppati per ruolo. Tutti hanno la controparte inglese in /en/architecture/.

13.6 Vocabolario e primitive

Il vocabolario chiuso conta 26 azioni (read, write, move, delete, create, find, list, filter, sort, group, classify, get, set, send, describe, render, extract, compress, compute, compare, change, order, share, open, login, act) e 26 oggetti (files, dirs, packages, messages, events, contacts, places, processes, urls, numbers, images, signatures, texts, proposals, persons, tasks, inputs, approval, credentials, issues, pulls, calendars, entries, lists, skills, sites). I qualifier sono divisi in quattro famiglie: formato (codifica del dato), modalità (come agisce l’executor), criterio di sicurezza, provider (per indicare un backend diverso da quello predefinito, ad esempio _google_workspace). Tutto centralizzato in runtime/vocab.py.

Le liste di entries che il turno produce passo per passo si manipolano con nove consumer planner-visible. I cinque operatori strutturali o numerici sono filter_entries, filter_lists, sort_entries, group_entries e compute_entries. I quattro helper semantici in-process sono classify_entries, compare_entries, extract_entries e describe_entries. Il primo gruppo filtra una lista, combina due liste, ordina, unisce/deduplica o calcola un aggregato; il secondo classifica, confronta semanticamente, estrae record strutturati o sintetizza. L'elenco è verificato contro il registro del runtime e i manifest firmati. Esempio reale: la domanda «c’è un appuntamento HLT che si sovrappone a uno MNM nei prossimi tre mesi?» viene risolta in sei passi: read_events → due filter_entries (uno per HLT, uno per MNM) → filter_lists(op=overlap) → risposta finale.

L'inventario live verificato comprende 115 executor standard e firmati: 82 handcrafted nel tree principale, 16 builtin GitHub di origine handcrafted e 17 builtin runtime con trasporto in-process. Il Composer usa lo stesso contratto per tutti e non sceglie in base al trasporto. I verbi produttori ortogonali sono cinque (find per pattern, get per id/stato, read per blob da sorgente, list per container, filter per riduzione).

13.7 Convenzioni dei contratti

Ogni file di contratto di un componente segue lo stesso template della visione architetturale di questo manuale:

• palette navy / sage / bronze; CSS inline, niente dipendenze esterne;
• ogni elenco dichiarato esaustivo indica la fonte di verità ed è generato da essa oppure coperto da un test di uguaglianza elemento per elemento;
• title-page, indice numerato, capitoli con id stabili;
• almeno una figura SVG inline (mai PNG: i diagrammi devono restare ricercabili e leggibili in PDF stampato);
• una sezione Contratto (Protocol + condizioni di errore), una Implementazioni, una Test di conformità;
• sticky nav in alto con breadcrumb;
• le regole prescrittive ai LLM seguono il pattern DEVI / NON DEVI / OK / ERRORE, quattro righe massimo;
• nessun anglicismo gratuito quando esiste una resa italiana piana (no peer, trigger, plumbing, gate);
• nessun nome proprio di terzi: solo «Roberto» o generici (guest, ospite, familiare invitato);
• etichette di alternative come (a)/(b)/(c), mai con lettere greche.

14. I principi, in otto carte

Se di questo documento doveste ricordare solo otto frasi, sono queste. Tutto il resto — codice, prompt, convenzioni — discende da qui.

15. Cosa NON è Metnos

Metà del design sta nei no. Ogni tentazione di aggiungere un elemento di questa lista va respinta.

• Non è un framework di plug-in senza governo. Il core è indipendente dal dominio, ma ogni istanza concreta ha un set circoscritto di executor ammessi e policy esplicite. Un dominio nuovo si esprime tramite executor e skill governati, non lasciando che pacchetti arbitrari ereditino i privilegi dell'agente.
• Non esegue skill di terzi così come sono. I formati drop-in sono esecuzione di codice altrui con i tuoi privilegi. Qui ogni pacchetto passa il gate a 7 livelli, o non gira (cap. 7).
• Non addestra modelli. Niente fine-tuning, niente RLHF. La crescita è memoria ispezionabile + sintesi col filtro umano (cap. 7 e 9).
• Non è un cloud agent. Gira a casa; il frontier è un consulto esplicito, mai la sede. Nessuna apertura non scelta.
• Non è un IDE né un dev assistant. Non scrive codice in altri progetti per conto tuo; al massimo analizza con executor read-only.
• Non sostituisce la domotica. A un sistema domotico può chiedere; non lo duplica.
• Non è multi-canale a tutti i costi. Due canali fatti bene; gli altri quando servono davvero.

16. Dove andare dopo

Ora avete entrambi i livelli: il sistema dall'alto e la mappa dei contratti dei componenti. Usate l'atlante per il dettaglio implementativo, oppure proseguite con il tour, il glossario e i dialoghi di progetto.

Metnos — Manuale di architettura (luglio 2026).
mētis + noûs: l'intelligenza astuta al servizio della mente — su hardware tuo.
Documentazione bilingue IT+EN su metnos.com; codice su github.com/brunialti/metnos.