Metnos è un agent governor installabile su un computer locale. Riceve una richiesta, decide quali capacità possono soddisfarla, ne controlla l'uso e registra ciò che accade. Non possiede in partenza una posta, un browser o un file system: sono gli executor ammessi dall'installazione a stabilire che cosa può fare davvero.
L'installazione di riferimento può funzionare come assistente personale o domestico. Non è però questa la definizione di Metnos. Sostituendo il catalogo degli executor con un altro catalogo governato, lo stesso nucleo può servire la manutenzione del software, la ricerca o un diverso dominio operativo circoscritto.
Il nucleo pianifica, giudica, ricorda e registra. Gli executor agiscono. Questa separazione evita che un modello linguistico ottenga automaticamente i privilegi del computer che lo ospita. Il modello può proporre «leggi questi file, confrontali e crea un rapporto»; soltanto executor dichiarati e ammessi possono eseguire quei passi.
| Parte | Compito | Non può fare da sola |
|---|---|---|
| Canale | Riceve la richiesta e riconosce utente, conversazione e lingua. | Concedere capacità o aggirare i controlli. |
| Runtime | Coordina il turno, costruisce o riusa un piano e conserva il contesto. | Eseguire liberamente comandi estranei al catalogo. |
| Policy e Vaglio | Verificano autorità, rischio, destinazione e necessità di una conferma. | Trasformare una conferma in un permesso illimitato. |
| Executor | Esegue un'azione circoscritta secondo un contratto firmato. | Ampliare il proprio mandato durante l'esecuzione. |
| Registri e memoria | Conservano esiti, ricevute e relazioni utili fra operazioni. | Inventare un successo o concedere autorità. |
Immaginiamo questa frase: «Trova i rapporti in PDF ricevuti questa settimana, riassumili e salva la sintesi nella cartella Progetti».
Se l'utente chiede come funziona Metnos, il Tutor cerca la risposta nelle fonti pubbliche ammesse e può consultare alcune osservazioni correnti in sola lettura. Non avvia un executor operativo. Se la stessa frase contiene anche un'azione separabile, il Tutor spiega la parte informativa e chiede prima di passare la parte operativa al motore normale.
Metnos non chiama sempre un modello da zero. Prova anzitutto i percorsi più semplici e già verificati:
Un piano riusato non è una scorciatoia permanente. Prima di eseguirlo, Metnos ricontrolla il catalogo, gli schemi e il contesto operativo. Se un executor è cambiato, è comparsa un'alternativa rilevante o una dipendenza non è più disponibile, il piano viene scartato e ricostruito.
I dati passano fra i passi con riferimenti strutturati. Le raccolte possono essere conservate nello scratchpad del turno, così il pianificatore vede quanto gli serve senza ricevere interi archivi di posta o file. Credenziali e altri valori sensibili vengono risolti dal runtime soltanto al momento dell'esecuzione: non sono affidati al modello.
Un'azione è ammessa solo quando tutti i confini applicabili concordano. Non esiste un unico interruttore «sicuro/non sicuro».
La conferma non crea da sola un nuovo potere: autorizza una proposta già compatibile con identità, policy e contratto. Allo stesso modo, la presenza di un executor nel catalogo non significa che ogni utente possa usarlo ovunque.
Il contratto distingue tre casi. Un'azione può essere annullabile quando produce una ricevuta sufficiente a ripristinare lo stato precedente; può essere non annullabile quando modifica dati senza una procedura inversa affidabile; oppure l'annullamento può essere non applicabile, perché una lettura o un calcolo puro non lascia niente da ripristinare. Il catalogo degli executor mostra la classificazione derivata dai manifest.
Per impostazione normale, gli executor vengono eseguiti sul computer che ospita il server Metnos. Un utente può anche associare un altro computer, per esempio un portatile Windows. Il runtime sceglie quel dispositivo solo quando il piano lo richiede, l'executor è compatibile e l'utente possiede l'autorità necessaria.
Il client del dispositivo non decide che cosa fare. Riceve un'invocazione autorizzata, applica il contratto e la sandbox disponibili su quel sistema, registra l'esito e restituisce una ricevuta al server. Se il dispositivo non è raggiungibile, Metnos non finge di aver eseguito l'azione: può fermarsi oppure, nei casi predisposti, proporre di differirla.
Il trasporto non cambia il significato dell'executor. La stessa capacità deve avere gli stessi argomenti, gli stessi risultati e la stessa autorità sia in locale sia su un dispositivo remoto.
Metnos conserva tipi di stato diversi, ciascuno con uno scopo preciso:
| Stato | A che cosa serve | Durata |
|---|---|---|
| Conversazione | Mantiene continuità fra messaggi e dispositivi dello stesso utente. | Finché la conversazione rimane disponibile. |
| Scratchpad | Conserva risultati voluminosi durante un singolo turno. | Temporanea e legata al turno. |
| Registro del turno | Documenta piano, controlli, esiti ed errori osservati. | Secondo le regole dell'istanza. |
| Mnest e mnestoma | Registrano relazioni utili fra executor e ne consolidano l'esperienza operativa. | Persistente, con manutenzione e decadimento. |
| LRE | Gestisce lavori lunghi come unità persistenti, limitate e riprendibili. | Fino al completamento o alla chiusura. |
Nessuna di queste memorie concede capacità. Ricordare che due executor hanno funzionato bene insieme non autorizza il secondo a leggere dati che il primo non poteva consegnargli.
Una capacità nuova entra nel sistema come executor, non come istruzione libera nel prompt. Deve avere un nome nel vocabolario ammesso, uno schema, effetti e risorse dichiarati, test, firma e regole di collocazione. Soltanto dopo l'ammissione compare nel catalogo utilizzabile dal pianificatore.
Synt può comporre capacità esistenti o preparare un nuovo executor quando serve davvero. Le skill importate seguono lo stesso confine: il loro contenuto viene tradotto in capacità Metnos, controllato e ammesso; il codice di terzi non eredita automaticamente i privilegi dell'istanza.
I nomi degli executor combinano un'azione e un oggetto scelti da un vocabolario chiuso. Oggi comprende 28 azioni e 27 oggetti. In questo modo «leggere file» e «leggere messaggi» condividono lo stesso verbo senza diventare la stessa capacità.
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,install,run.
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,preferences.
Quando un piano deve lavorare su una raccolta già ottenuta, usa operatori comuni anziché creare una variante per ogni dominio. Quelli strutturali sono filter_entries,filter_lists,sort_entries,group_entries,compute_entries; quelli semantici sono classify_entries,compare_entries,extract_entries,describe_entries.
| Se vuoi capire… | Continua da qui |
|---|---|
| come il runtime trasforma una frase in un piano | Runtime delle richieste |
| quali azioni esistono oggi | Catalogo degli executor |
| che cosa si può fare nei diversi ambiti operativi | Reference dei domini |
| dove trovare funzioni e impostazioni nella chat web | Guida all'interfaccia |
| come funzionano i computer associati | Executor remoti e associazione dei dispositivi |
| come arrivano le richieste | Canali di conversazione e chat web e API HTTP |
| come vengono applicati permessi e limiti | Policy e autorità, conferma e sandbox |
| come Metnos spiega se stesso senza agire | Tutor |
| come osservare l'installazione | Sezione Sistema |
Questa guida descrive il comportamento implementato. Per inventari che cambiano nel tempo, come l'elenco degli executor, rimanda alle pagine generate dai contratti correnti invece di copiare conteggi destinati a diventare obsoleti.