Il design d'insieme di myclaw era abbastanza maturo per una revisione critica. L'ho sottoposto a quattro ottiche esperte (programmazione agentica, psicologia, UI, AI) e poi pesato ciascun punto emerso rispetto ai tre obiettivi dichiarati del prodotto. Questo documento consolida sia l'analisi sia il giudizio e chiude la fase 0 di progettazione.
Il metodo: generare critiche generose dalle quattro prospettive, poi applicare un filtro pragmatico "questa critica blocca utilità/intelligenza/autonomia? se sì la accetto, altrimenti la soppeso". Cinque verdetti possibili:
| Verdetto | Significato |
|---|---|
| bloccante | Senza questa modifica, almeno uno dei tre obiettivi non può essere raggiunto. Va fatta. |
| rinforzo | Non nuovo concept. Completa un pezzo del design esistente. Accettato. |
| rinvio | Utile, non bloccante. Si farà, con un gate esplicito per promuoverlo quando serve davvero. |
| tensione | Problema reale non risolvibile. Si gestisce, non si elimina. Accettazione esplicita del trade-off. |
| scartato | Valutato, costo supera il beneficio. Motivazione tracciata. |
Prima di giudicare serve definire. I quattro termini non sono interscambiabili.
Risolve un problema reale di Roberto al primo tentativo, senza intervento tecnico.
Misurato in: task completati / approvazioni chieste.
Capisce il contesto, sceglie lo strumento giusto, gestisce l'inatteso senza cadere in loop o risposte generiche.
Misurato in: success rate su casi non visti + qualità del "non lo so".
Agisce da solo nei casi prevedibili, chiede permesso solo quando serve.
Misurato in: azioni riuscite / approvazioni chieste.
Inizia azioni utili senza essere interpellato, quando il momento lo merita, senza disturbare.
Misurato in: proposte accettate / proposte emesse; silenzio appropriato.
Architettura a 4 strati pulita, protocol-based, audit log come feature. Ma
manca: la scelta del loop (ReAct? function calling? planner+executor?),
l'ownership dello stato in caso di crash, l'idempotenza dei tool, una
ExecutionTrace come oggetto first-class, la modalità dry-run,
e qualsiasi test strategy. Senza ExecutionTrace non ricucirai mai audit + replay
+ fitness darwiniana + eval — perché sono la stessa cosa vista da angolature diverse.
La memoria a tre livelli allinea con working/episodic/semantic. La selezione darwiniana ha fondamento in RL/ACT-R. Le 4 Leggi sono etica deontologica trasparente. Ma: "neurone" evoca intenzionalità (effetto ELIZA amplificato), l'approval fatigue svuota il significato dei gate, l'automation bias cresce con la fitness. Capability creep nelle aspettative: gli utenti proietteranno "diventa sempre più intelligente" e saranno delusi.
Documenti visivamente coerenti, progressive disclosure buona. Ma la superficie UX più delicata — il "vuoi che proceda?" in Telegram, in CLI, alla voce — non ha design. Status visibility durante il thinking è invisibile. Audit JSONL va benissimo per forensica e malissimo per "cosa ha fatto oggi il mio maggiordomo". Una dashboard admin minimale (anche sobria) cambia la quotidianità più di dieci feature nuove.
Consapevolezza esplicita dei limiti del self-judge LLM e del prompt injection indiretto. Vocabolario CoALA adottato. Ma: nessun modo di misurare se v0.2 è meglio di v0.1 (serve una mini eval, 15-20 scenari). Nessun cost model (ordine di grandezza: 1-3 €/giorno con Claude Sonnet su uso domestico). Model tiering ignorato: 60-80% di costo risparmiabile mettendo i gate su modello locale e le azioni serie su frontier. Il synthesis prompt per i neuroni — il pezzo che determina l'80% del success rate — non è specificato.
La tavola completa. Ogni riga è una critica specifica con il verdetto e la destinazione nel piano di lavoro.
| # | Critica | Prospettiva | Verdetto | Dove / quando |
|---|---|---|---|---|
| 1 | Reasoning loop non specificato | agentica + AI | bloccante | agent_runtime.html |
| 2 | Tool-call validation con schema + reject loop | AI | bloccante | agent_runtime.html |
| 3 | ExecutionTrace come oggetto first-class | agentica + AI | bloccante | agent_runtime.html |
| 4 | Status visibility in ogni canale | UI | bloccante | channel.html (req.) |
| 5 | Approval UX disegnata (batching, pause, revoca) | psicologia + UI | bloccante | approval_ux.html |
| 6 | Eval minimo (15-20 scenari YAML + harness) | AI | bloccante | eval.html |
| 7 | Model tiering + 5ª Legge operativa | AI + agentica | bloccante | policy.html + cost_tiering |
| 8 | Framing linguistico anti-antropomorfizzazione | psicologia | rinforzo | constitution.html |
| 9 | Prompt structure esplicita + caching rules | AI | rinforzo | agent_runtime.html |
| 10 | Admin web UI minimale (5 viste htmx) | UI | rinvio | fase 3-bis; gate: se JSONL non è mai aperto → promuove a fase 1 |
| 11 | Retrieval strategy memoria lunga | AI | rinvio | gate: >4k token lunga → RAG |
| 12 | MCP adoption | AI | rinvio | gate: 3+ tool esterni MCP |
| 13 | State persistence post-crash | agentica | rinvio | fase 1 accetta "sessione persa"; gate: >1×/settimana |
| 14 | Neuron versioning formale (semver) | agentica | rinvio | gate: >20 neuroni in library |
| 15 | Antropomorfizzazione → ELIZA | psicologia | tensione | mitigata da #8 + tool "cosa sai di me" |
| 16 | Automation bias con fitness alta | psicologia | tensione | mitigata da tutor mode in approval_ux.html |
| 17 | Costo dell'autonomia | psicologia + AI | tensione | Roberto deve sapere "Full mode 24h = X €" |
| 18 | Pairing SLA formale come meta-doc | UI | scartato | dettaglio di pairing.html |
| 19 | Mobile-first esplicito | UI | scartato | è testing, non design |
| 20 | Docs search | UI | scartato | trigger: >15 doc (ora 5) |
| 21 | Deadlock sinapsi come design dedicato | agentica | scartato | timeout globale copre il 95% |
| 22 | Multimodal day-1 | AI | scartato | già rimandato nel Survival Kit |
| 23 | Multi-utente famiglia day-1 | UI | scartato | prima release mono-principale; fase 3 |
| 24 | Cost model fine (TCO analysis) | AI | scartato | ordine di grandezza basta |
Totale: 7 bloccanti · 2 rinforzi · 5 rinvii · 3 tensioni · 7 scartati.
Queste sono le uniche modifiche non negoziabili. Tutte le altre sono al contorno.
| # | Cosa | Scelta di default + motivazione |
|---|---|---|
| 1 | Reasoning loop | ReAct + function calling nativo del provider per fase 1. Semplice, testato, compatibile con caching. Rivedere a fase 5 valutando CodeAct. |
| 2 | Tool-call validation | Ogni tool ha uno JSON Schema strict. Il dispatcher valida prima di eseguire. Errore di validazione → risposta "tool X esiste ma l'argomento Y è di tipo Z" reiniettata al LLM, max 2 tentativi, poi abbandono con messaggio utente. |
| 3 | ExecutionTrace first-class | Oggetto Python con: id, session_id, channel, messages[], tool_calls[],
cost_tokens, cost_usd, wall_time_ms, outcome. È la stessa struttura
usata da audit log, dry-run/replay, fitness darwiniana, eval. Una
sola fonte di verità su "cosa è successo". |
| 4 | Status visibility | Ogni canale ha il dovere di mostrare "penso...", typing indicator, e aggiornare al cambio di tool in esecuzione. Telegram: messaggio editabile; CLI: spinner con tool-name; voce: prompt di cortesia a fine di ogni secondo. |
| 5 | Approval UX | Batching: "approva azioni simili per 10 minuti".
Pausa lettura: il pulsante "ok" si abilita dopo 3 secondi.
Revoca: un comando /undo che ferma l'esecuzione in corso.
Tutor mode: ogni N approvazioni consecutive, un prompt
obbligatorio "controlla tu questa" rompe il flusso. |
| 6 | Eval minimo | 15-20 scenari YAML con input + oracolo (risposta attesa o criterio).
Harness che li gira via replay del reasoning loop. Report: success rate,
p95 latency, cost. Rigira ad ogni commit che tocca
agent_runtime/ o policy/. |
| 7 | Model tiering + budget | Due tier: local-fast (llama.cpp locale, < 500ms, gratis) per gate di policy + classification; frontier (Claude/Opus via supra) per ragionamento, sintesi, risposta utente. Budget: 2 €/giorno soft cap, 5 € hard cap. Notifica quando hai consumato 80%. |
Se elimini la metafora "maggiordomo", perdi calore e familiarità; se la lasci libera, scivoli nell'effetto ELIZA (utenti che attribuiscono coscienza e responsabilità morale al sistema). Scelta: teniamo la metafora, accettiamo la mitigazione al 70% via framing linguistico + tool "cosa sai di me" + tutor mode. Preferiamo caldo-con-monitoraggio a freddo-senza-ambiguità.
Più la fitness di un neurone è alta, più l'utente smette di controllare l'output. È il paradosso della selezione per qualità: amplifica la fiducia anche dove non dovrebbe. Mitigazione: tutor mode (forza review periodica anche su neuroni "affidabili"), separazione visiva tra "ho fatto X" e "ho fatto X perché l'ho già fatto 40 volte". Non risolve, limita.
Più l'utente vuole autonomia, più il sistema esplora, più spende.
Gestione: dichiarazione esplicita del costo prima di ogni
upgrade di autonomy (es. myclaw session --level full --for 24h
mostra "stima: 3.50 €"). Budget diventa parte del consenso.
Dei quattro aggettivi, utile e intelligente sono proprietà che l'agente può avere indipendentemente. Autonomo e proattivo no: emergono solo se le prime due sono tarate bene e si sovrappongono a meccanismi specifici — i gate di approvazione per l'autonomia, la funzione di allineamento ai telos per la proattività. Né un punto in più di utilità né un punto in più di intelligenza producono da soli autonomia o proattività.
Autonomia emerge dalla calibrazione del gap tra "fa da solo"
e "chiede permesso".
Proattività emerge dalla calibrazione del gap tra "propone" e
"tace", regolato dai telos.
Implicazione operativa:
agent_runtime.html, 10h
approval_ux.html, 10h eval.html. Tutto
il resto emerge da queste tre fondamenta.La proattività, come aggettivo strutturale, non sostituisce le sette critiche bloccanti — le rilegge. Nessuna di esse va scartata; alcune si rafforzano, altre si estendono, una richiede l'aggiunta di un requisito implicito. Inoltre compare una critica che non era nel set originario (l'inbox proposte come superficie UX).
| # | Bloccante originaria | Cosa cambia sotto la lente proattiva |
|---|---|---|
| 1 | Reasoning loop | Non cambia la scelta (ReAct + function calling), ma si aggiunge un requisito: il loop deve poter partire senza un turno utente che lo attiva. Trigger ammissibili: cron, evento interno (indexer), soglia su metriche (budget, attività sospetta). Documentato come modalità agent-initiated turn. |
| 2 | Tool-call validation | Invariato. Vale identico su turni proattivi. |
| 3 | ExecutionTrace first-class | Esteso: la trace deve registrare l'origine del turno (source: user | cron | indexer | policy | reflection). Senza questa distinzione l'audit non può rispondere a "chi ha deciso di partire, stavolta?" — domanda cruciale per la proattività. |
| 4 | Status visibility | Esteso: i turni proattivi (briefing serale, proposte inbox) devono essere riconoscibili come tali nel canale — iconografia diversa, tag "spontaneo" esplicito. Mai camuffare proattività da risposta-a-richiesta. |
| 5 | Approval UX | Rafforzato: la proattività moltiplica le superfici di approvazione. Oltre a batching e tutor mode, serve una superficie "inbox proposte" separata dagli approval bloccanti. L'utente deve poter rifiutare una classe di proposte ("meno di queste, grazie"), non solo la singola. |
| 6 | Eval minimo | Esteso: gli scenari di eval devono coprire la non-azione appropriata. "Mykleos decide di non proporre nulla oggi" è un output valido e va testato. Un eval harness che misura solo success rate su richieste esplicite è cieco ai silenzi giusti. |
| 7 | Model tiering + budget | Rafforzato drasticamente: la proattività consuma senza essere richiesta. Budget diventa un pre-requisito della proattività, non un optional. Proposta: il budget proattivo sia un capo separato dal budget reattivo (es. 30% / 70%), con hard cap indipendente. |
| 8 | (nuovo) Inbox proposte come superficie UX | Non era nel set originario. Diventa bloccante perché senza di essa il decadimento proattivo non ha dove accumularsi in modo non-invasivo. Si aggiunge al piano: proposal_ux.html (già previsto da Prospettive estese §5). |
Prima di questo giudizio, la fase 1 prevedeva 4 doc di microprogettazione classici:
gateway · channel · tool · sandbox.
Dopo questo giudizio, vanno prodotti prima tre doc trasversali, e solo dopo i quattro classici:
| Ordine | Doc | Coprono (critiche bloccanti) |
|---|---|---|
| 1 | agent_runtime.html | #1 reasoning loop · #2 tool validation · #3 ExecutionTrace · #9 prompt structure |
| 2 | approval_ux.html | #5 approval UX · mitigazione tensioni 1 e 2 |
| 3 | eval.html | #6 eval harness |
| 4 | gateway.html | (fase 1 classici) #4 status visibility in parte |
| 5 | channel.html | #4 status visibility completo |
| 6 | tool.html | pre-requisito per #2 |
| 7 | sandbox.html | — |
| 8+ | policy.html + cost_tiering (sotto-sezione) | #7 tiering · #17 costo autonomia |
myclaw — Prospettive & Giudizio v1.1 — 2026-04-22
Chiude la fase 0 di progettazione. Apre la fase 1 con un ordine nuovo.
v1.1: aggiunto il quarto aggettivo (proattivo) e la lente trasversale §7-bis.