Un termine compare in questo glossario quando è usato in più documenti del progetto e non è immediatamente ovvio. Il criterio è pragmatico: se un lettore senza contesto può inciampare sul nome, c'è una voce qui. Le definizioni sono brevi. I link portano alla fonte canonica — il documento dove il concetto è definito nella forma completa.
Proposta di azione generata spontaneamente da myclaw (dalla reflection, dall'indexer, da un neurone), in contrasto con una PlannedAction che discende da una richiesta esplicita dell'utente. Contiene il piano, l'impatto stimato, la reversibilità, una razionale testuale. Viene valutata dal Vaglio contro i telos; se supera la soglia, arriva all'utente nell'inbox proposte.
Canonico: Prospettive estese §2D · telos §4
Il "cuore pensante" di myclaw: il ciclo ReAct (thought → action → observation) che, per ogni richiesta, costruisce il prompt, invoca il modello linguistico, valida le chiamate a tool, registra tutto nella ExecutionTrace. Non conosce i canali né la domotica: riceve testo, restituisce testo, usa tool.
Canonico: agent_runtime.html
La tendenza a trattare un sistema tecnico come se avesse intenzioni, emozioni o coscienza. Il progetto usa termini evocativi (neurone, sinapsi, memoria, personalità) per brevità espositiva, ma mantiene in più punti un framing linguistico esplicito per evitare che si scivoli nell'illusione: myclaw non "sente", non "vuole", non "pensa". Esegue loop, chiama tool, registra trace. La scelta del nome Vaglio (invece di "Arbitro" o "Super-io") rientra in questa stessa cautela.
Framing canonico: constitution (sezione linguistica)
Oggetto che rappresenta una richiesta di approvazione all'utente, prima che myclaw esegua un'azione con effetto sul mondo (invio mail, scrittura file, spesa). Ha una macchina a stati (pending → granted/denied/timeout), un timeout che dipende dal canale, un'audit trail. Il Gateway è l'unico autorizzato a costruirne una.
Canonico: approval_ux.html · gateway §4.1
Un agente specializzato in casa per ingresso vocale e controllo domotica (wake-word, STT, TTS, MQTT verso la centralina domotica). myclaw non assorbe queste funzioni: le lascia a un assistente dedicato già presente o da costruire. Nel disegno esteso (Prospettive estese §2B) myclaw e l'assistente domotico si parleranno tramite un canale inter-agente dedicato, con divisione del lavoro netta: l'assistente domotico ha calendari, voce e domotica; myclaw ha ricerca documentale e memoria strutturata. Nei nostri doc trattiamo il pattern in astratto; nell'ambiente dell'autore esiste un progetto concreto che ricopre questo ruolo, parallelo a myclaw.
Presentazione canonica: Architettura Intro §5
Registro append-only JSONL in workspace/.audit/. Ogni trace,
ogni approvazione, ogni modifica al workspace, ogni modifica costituzionale
lascia una riga. È la Legge 3 (tracciabilità) resa operativa: una firma che
sopravvive a reboot, crash, aggiornamenti.
Canonico: observability §3
Tre livelli di libertà con cui myclaw opera, impostati per sender+canale: read_only (legge, non scrive, non spende), supervised (chiede conferma per ogni azione con effetto), full (agisce e riferisce, chiede conferma solo per cose irreversibili o costose). Default: supervised. Il livello si cambia esplicitamente.
Canonico: Architettura Intro §6 · policy §2
Il "costo di disturbare" l'utente: un contatore che cresce ogni volta che myclaw pubblica una proposta, decresce nel tempo. Se il budget è esaurito, una nuova proposta — anche se ben allineata ai telos — viene rinviata al riassunto serale o rigettata. Evita l'assedio di notifiche.
Canonico: telos §5
Protocol Python che astrae come myclaw riceve input e invia output. CLI, Telegram, voce (via un assistente domotico sibling), futuro AgentChannel per dialogo inter-agente. Ogni canale ha capability (bottoni inline? streaming? markdown?) che myclaw interroga prima di produrre output.
Canonico: channel.html
Tre gradi di "non-allineamento" di un'azione rispetto alla Costituzione e ai telos, che il progetto distingue in modo rigoroso perché solo uno dei tre blocca.
Canonico: vaglio §3 · Dialogo — Giornata IV
Le quattro regole che myclaw rispetta in modo non negoziabile. In ordine
di precedenza: Legge 0 (perimetro fisico ed economico —
cosa può toccare, quanto può spendere); Legge 1
(non-nocività — non fare danno a persone, dati, processi);
Legge 2 (obbedienza informata — eseguire solo istruzioni
che hanno passato la 0 e la 1); Legge 3 (tracciabilità —
lasciare traccia auditabile di tutto). Scritte in SOUL.md,
firmate, versionate. La Costituzione non giudica, verifica: se un
articolo è violato, blocca; altrimenti tace. Vedi
telos per il suo complemento positivo.
Canonico: constitution.html
Oggetto immutabile che raccoglie tutto ciò che è successo durante una richiesta: step di ragionamento, tool call, risultati, costi, timing, esito finale. Non è un log accessorio: è la fonte primaria di verità. Audit, replay, eval, fitness dei neuroni, memoria episodic: tutti consumano ExecutionTrace. Append-only durante, immutabile dopo la chiusura.
Canonico: agent_runtime §5 (schema e ciclo di vita) · types.html
Il punto di ingresso unico di myclaw: espone HTTP interno, accoglie i canali (CLI, Telegram, …), gestisce le sessioni, costruisce le ApprovalRequest, orchestra il Runtime. Processo systemd unico. Nessun canale comunica mai direttamente col runtime: passa sempre da qui.
Canonico: gateway.html
Seconda fase del Vaglio. LLM indipendente dal
proponente che stima il fit di un'azione rispetto ai telos.
Produce un punteggio graduato, non binario.
Canonico: vaglio §5
Prima fase del Vaglio. Verifica deterministica che l'azione non contraddica un articolo della Costituzione. Output binario: blocca o lascia passare. Non un LLM: regole eseguibili.
Canonico: vaglio §4
Termine greco (ὕβρις), nel mito la tracotanza di chi supera la misura che gli spetta, provocando la punizione degli dei. Nel progetto è la metafora che inquadra il rischio di un agente che sa e agisce: trasformare l'utilità in arroganza, superare i propri limiti, finire per contendere con le Leggi che il creatore ha posto. Il Vaglio è la struttura che risponde a questo rischio. Introdotto nel prologo del Dialogo — Giornata I.
L'idea che myclaw non debba conoscere solo il sender (es.
telegram:@roberto) ma l'identità umana stabile dietro
sender multipli (voce, CLI, Telegram). È una questione trasversale alle
famiglie proattive e al multi-agente. La microprogettazione
identity.html è pianificata, non ancora scritta.
Visione: Prospettive estese §3
Parola greca che significa fama, rinomanza, memoria duratura di ciò che si è fatto. Nell'Iliade è ciò che un eroe lascia di sé. È l'etimologia del nome Mykleos, la figura dialogata del progetto: un'entità costruita per fare cose e perché di quelle cose resti traccia.
Il dominio di casa dell'autore, sotto il quale sono pubblicati i
documenti del progetto (mykleos.knowcastle.com). Non è un
componente: è il luogo.
Vedi Costituzione.
Large Language Model. Nel progetto non è un fornitore specifico: myclaw usa LLM ma non li contiene. L'accesso passa sempre per l'interfaccia LLM che rende il sistema provider-agnostic. Un tema ricorrente del design è sapere in che casi dell'LLM fidarsi: per questo esiste il Vaglio, che risolve il self-enhancement bias.
Un principio architetturale vincolante di myclaw: l'uso di qualsiasi modello linguistico passa sempre per un'interfaccia logica, mai per il client di un fornitore specifico. La stessa idea vale per servizi AI affini (STT, TTS, embedding, speaker ID). La motivazione è tripla.
Il contratto è definito con typing.Protocol: ogni servizio
ha un'interfaccia (LLMProvider, STTProvider,
TTSProvider, …), un registry, e implementazioni
intercambiabili via configurazione.
Nell'ambiente dell'autore, questo pattern è realizzato da suprastructure, un package sibling che fornisce l'interfaccia e i backend già pronti. In un ambiente diverso, l'interfaccia potrebbe essere realizzata da qualunque altro adapter o framework (LangChain, LiteLLM, un modulo custom): il contratto resta. myclaw dipende dall'interfaccia, non dall'implementazione.
Canonico: Architettura Intro §5 · agent_runtime §6
Tre-più-uno livelli che prendono il vocabolario da CoALA (Cognitive Architectures for Language Agents).
Canonico: memory.html
Il nome che myclaw riceve dentro il Dialogo sui fini e i limiti. Dal greco κλέος, "fama, memoria di ciò che si è fatto". Non è un componente diverso da myclaw: è la sua personificazione letteraria, scelta per rendere vivo al lettore l'oggetto del dialogo — un'entità, non un acronimo. myclaw resta il nome tecnico del progetto, Mykleos vive nel dialogo.
Il progetto stesso: un assistente personale che vive in casa, riceve
input da più canali (CLI, Telegram, voce), agisce al posto dell'utente
chiedendo permesso quando serve. Vive in /opt/myclaw/. Nome
tecnico (vs Mykleos, nome in-dialogo).
Ingresso: Quick tour · Architettura — Introduzione
Un tool auto-sintetizzato da myclaw quando i tool esistenti non bastano. Il termine è metaforico (attenzione a non prenderlo come "pensiero"): un neurone è codice Python con firma HMAC, test di nascita, journal di co-attivazioni. Compete per fitness: se dà risultati scadenti su scenari ripetuti, decade e viene eventualmente rimosso.
Canonico: neuron.html · Neuroni, Sinapsi e Memoria v1
Progetto open-source su GitHub (openclaw/openclaw), scritto in TypeScript su Node 24+. Ispirazione principale di myclaw per il pattern gateway-first, multi-canale, sandbox plug-in. myclaw non ne è un clone: riusa alcune idee in un linguaggio (Python) coerente col resto dello stack di casa (suprastructure come implementazione dell'interfaccia LLM, sibling agents preesistenti).
Confronto dettagliato: Architettura Intro §2
Il riconoscimento di un nuovo sender su un canale multi-utente (tipicamente Telegram): l'utente riceve un codice firmato out-of-band, lo presenta a myclaw, il legame sender↔identità viene registrato. Revoca possibile in ogni momento.
Canonico: pairing.html
Un'azione che myclaw sta per eseguire su richiesta esplicita dell'utente (reattivo). Contiene tool, argomenti, effect_class, sender, trace_id. Passa per la Policy e per la fase Guardia del Vaglio; il giudice teleologico non la valuta (il Telos non giudica richieste esplicite). Distinto da ActionProposal, che nasce spontaneamente.
Canonico: types §4.1
L'arbitro operativo delle azioni reattive: verifica forbidden paths, never-list per sender, rate limit, budget, green zone per autonomy, e (check 0) la Guardia costituzionale. Emette un verdetto: allow, deny, approve_required.
Canonico: policy.html
Il processo ricorrente (quotidiano) con cui myclaw rilegge le proprie
ExecutionTrace recenti e propone
aggiornamenti: fatti da ricordare (FactProposal) e — versione
estesa — azioni da compiere (ActionProposal).
Le proposte richiedono approvazione umana.
Canonico: memory §6
Il contenitore in cui gira ogni tool con effetti sul filesystem o sul
sistema. Profili bubblewrap (bwrap) che definiscono cosa il tool può
leggere, scrivere, eseguire. Forbidden paths espliciti: un tool non vede
nemmeno .audit/.
Canonico: sandbox.html
La tendenza documentata di un LLM a valutare positivamente i propri output o stili familiari (Zheng et al. 2023). È la ragione strutturale per cui il Vaglio esiste: se l'LLM che valuta è lo stesso (o riceve il contesto) di quello che ha proposto, tifa per sé. La soluzione: contesto separato, prompt separato, idealmente provider separato.
Canonico: vaglio §6 · Dialogo — Giornata III
Altri agenti specializzati che possono vivere nello stesso ambiente di myclaw e condividere con esso la stessa astrazione LLM (vedi interfaccia LLM). Un agente domotico è un esempio; altri possono essere bot specializzati su domini ristretti (industriali, didattici, medicali). myclaw è pensato per convivere, non per essere unico: lo scambio avviene via canale inter-agente (Prospettive estese §2B).
Un collegamento dichiarato o osservato fra neuroni: "quando si attiva A, tende ad attivarsi anche B". Viene rinforzato dall'uso, indebolito dal disuso (decadimento à la Ebbinghaus). Il grafo delle sinapsi è un rollup derivato dai journal dei singoli neuroni.
Canonico: synapse.html
Nell'ambiente dell'autore di myclaw, suprastructure è il
package sibling che realizza concretamente l'interfaccia
LLM e le altre astrazioni di servizio AI (STT, TTS, embedding, speaker
ID, model registry). Vive in /opt/suprastructure/. Ogni
servizio è un'interfaccia typing.Protocol con backend
intercambiabili via YAML (Claude, OpenAI, llama.cpp, Piper, faster-whisper,
…). Cambiare backend = una riga. Nessun consumer se ne accorge. È
condiviso con l'assistente domotico e
altri sibling agents.
In un ambiente diverso il ruolo di suprastructure può essere ricoperto da qualunque altro adapter: il contratto è l'interfaccia, non questa implementazione particolare. myclaw è stato disegnato in modo che i suoi documenti e il suo codice non dipendano da suprastructure ma dal pattern che suprastructure incarna.
Canonico: Architettura Intro §5
La pipeline che produce un nuovo neurone quando un fallimento ripetuto lo giustifica: spec da fallimento → bozza → analisi statica → test → approvazione umana → firma. Sette stadi, retry max 3.
Canonico: synthesizer.html
Un "fine ultimo" (τέλος, greco): qualcosa verso cui si tende, non un
obiettivo da raggiungere. L'utente scrive 3-7 telos in
TELOS.md (sesto file del workspace); ogni proposta proattiva
di myclaw viene valutata contro questi, da un LLM indipendente nel
Vaglio. I telos sono positivi (vs
le Leggi che sono negative), orientati
all'utilità (vs la sicurezza delle Leggi), scritti dall'utente
(vs le Leggi co-scritte con myclaw). La Costituzione non giudica,
la teleologia sì.
Canonico: telos.html · Dialogo sui fini e i limiti
Una funzione che myclaw può chiamare durante il suo loop di ragionamento:
fs_read, fs_write, shell_exec,
web_fetch, …. Protocol Python con schema validato,
contratto di errore, rate limit. I neuroni sono tool auto-sintetizzati; i
tool base sono quelli che myclaw trova al primo avvio.
Canonico: tool.html
Abbreviazione informale di ExecutionTrace.
Un punteggio che si accumula per-neurone (o per-coppia neurone/effect
class) basato sugli esiti storici: gap_pre − gap_post. Il TrustStore è
aggregato offline (niente apprendimento online) e letto a runtime dalla
Policy per modulare la soglia di approvazione
(trust-gating). Un neurone affidabile su azioni a basso rischio può
vedere approve_required promosso a allow.
Canonico: rl_offline.html
Un marker che avvolge qualsiasi contenuto proveniente da fuori myclaw
(output di web_fetch, testo di mail, allegati). Il prompt istruisce l'LLM
a trattare quanto è dentro <untrusted>…</untrusted>
come dato, non come istruzione. Mitigazione principale
contro il prompt injection indiretto. Usato coerentemente ovunque.
Canonico: agent_runtime §3 · constitution
Il componente di valutazione indipendente. In italiano vagliare significa separare col setaccio: un gesto meccanico, non antropomorfico. Due fasi: Guardia costituzionale (binaria, deterministica: blocco o silenzio) e Giudice teleologico (gradiente, LLM indipendente). La frase-cardine del design: "La Costituzione non giudica, la teleologia sì". Il Vaglio è la struttura che la rende operativa.
Canonico: vaglio.html · Dialogo — Giornate III-IV
La "casa" di myclaw sul disco: /opt/myclaw/workspace/.
Contiene cinque file markdown di personalità (IDENTITY, USER, MEMORY,
AGENTS, SOUL) più TELOS.md, più la cartella di audit
e gli indici di memoria episodic/semantic.
Canonico: workspace.html
Progetto open-source in Rust (zeroclaw-labs/zeroclaw). Ispirazione di myclaw per i livelli di autonomia, la sandbox a strati, il pattern trait-based. Scartato come base direttamente riusabile perché riscrive da zero il layer LLM/STT/TTS che in casa è già fornito da suprastructure.
Confronto dettagliato: Architettura Intro §2