1. In una riga: un solo modello, chiamato una volta sola

Quando arriva una richiesta, Metnos non chiama più il pianificatore cinque o sei volte di seguito. Per prima cosa prova le scorciatoie che già conosce; se non bastano, chiede al modello linguistico locale di proporre l’intero piano in una sola chiamata; poi lo esegue in modo deterministico, e se qualcosa va storto tenta un recupero mirato o spiega onestamente cosa manca. Quattro strati, un solo modello, mai il cloud.

2. L’idea: proporre tutto in un colpo, e ricordare

Il motore attuale parte da due intuizioni semplici.

Prima intuizione: una sola proposta. Invece di interrogare il modello a ogni passo, lo si interroga una volta sola e gli si chiede l’intero piano in un colpo: la lista completa degli step, con i collegamenti fra loro e il messaggio finale. Il modello vede tutto il problema in una volta, costruisce coerenza interna (sa che lo step 4 ha bisogno dell’output dello step 3) e produce un piano molto più stabile. L’esecuzione che segue è pura meccanica deterministica: niente più dadi.

Seconda intuizione: ricordare ciò che funziona. Quando un piano arriva in fondo bene, il sistema lo conserva, indicizzato per «significato» della richiesta. La volta dopo che arriva una richiesta dello stesso tipo, il piano è già pronto: parte in pochi millisecondi, senza disturbare il modello. Il sistema diventa il proprio pianificatore — impara a non chiedere più.

Queste due intuizioni si traducono in quattro strati, provati in cascata. La distinzione che conta è fra ciò che ricorda e ciò che ragiona: i primi due strati (L0 e L1) sono memoria con stato — un archivio che cresce con l’uso e risponde senza disturbare il modello quando riconosce la richiesta. Gli altri due (L2 e L3) sono senza stato: non ricordano nulla da un turno all’altro, ma ricontrollano il piano e, se serve, lo costruiscono daccapo. Il terzo è un controllo, il quarto è il motore vero e proprio che propone, esegue, recupera e — se non c’è via d’uscita — ammette onestamente il limite.

4. I quattro strati del motore

Ogni turno attraversa gli strati dall’alto verso il basso. Appena uno strato risolve, il turno termina: gli strati sotto non vengono nemmeno toccati. I primi due (L0 e L1) sono i due strati con stato, la memoria che impara: sono velocissimi e non usano il modello linguistico. Gli altri due (L2 e L3) sono senza stato — non conservano nulla fra un turno e l’altro — e solo il quarto, solo quando serve, chiama davvero il modello.

5. La cascata che attraversa un turno

Ecco il cammino completo, dal messaggio dell’utente alla risposta finale. Si legge dall’alto verso il basso: ogni livello si tenta solo se quello sopra non ha già risolto.

 UTENTE: "cerca le mail spam e mettile in cestino"
 |
 v
 +-------------------+
 | fast_path (pre) | regex su pattern banalissimi ("che ora e'", "dove sono")
 | (zero LLM) | --> match? rispondi in ~50ms e termina
 +-------------------+
 | (no match)
 v
 +-------------------+
 | intent_extractor | LLM fast tier ~370ms
 | verbo + oggetto + | --> (verbo="move", oggetto="messages",
 | parole chiave | keywords=["spam","cestino"])
 +-------------------+
 |
 v
+--------------------------------------------------------------+
| MOTORE (engine/dispatch.run_turn) |
| |
| +----------------+ |
| | L0 Fastpath | hash (<5ms) + coseno BGE-M3 (<150ms) |
| | lookup | --> scorciatoia auto-appresa ? esegui |
| +----------------+ |
| | (miss) |
| v |
| +----------------+ |
| | L1 Autopath | match semantico + intent_hash |
| | lookup | --> autopath appreso ? esegui (no LLM) |
| +----------------+ |
| | (miss) |
| v |
| +----------------+ |
| | L3 Proposer | LLM wise 1-shot |
| | propose | --> piano JSON {steps, fillers, |
| | (Qwen 35B-A3B) | final_message} |
| +----------------+ |
| | |
| v |
| +----------------+ |
| | L2 Validator | typecheck piano; errore? --> riproponi |
| +----------------+ |
| | |
| v |
| +----------------+ |
| | Executor | per ogni step: |
| | (deterministico)| - resolve from_step + FILLER + RUNTIME |
| +----------------+ - invoke_executor + vaglio + accumula |
| | |
| v |
| +----------------+ |
| | render final | template "Trovate {N} mail, spostate" |
| +----------------+ |
+--------------------------------------------------------------+
 |
 v (ok? si' --> Autopath registra + risponde a utente)
 |
 | (errore? si' --> entra Recovery)
 v
 +-------------------+
 | Recovery | classifica errore: wrong_tool / wrong_args /
 | classify + retry | missing_input
 | | --> riproponi escludendo il tool fallito
 | | --> esegui di nuovo
 +-------------------+
 |
 v (ok? si' --> risposta)
 |
 | (out_of_scope o recovery fallita? --> Terminator)
 v
 +-------------------+
 | Terminator | spiega onestamente: causa + azione suggerita
 | honest dead-end | --> registra la lacuna in terminator_log.sqlite
 | | --> "Non posso risolvere: X. Per procedere: Y."
 +-------------------+
 |
 v
 UTENTE: messaggio finale (risposta o richiesta di azione)

6. Il piano: che cosa propone il motore

Il Proposer non produce testo libero: produce un oggetto strutturato che chiamiamo framework (il piano). Ha tre parti:

• steps — la lista ordinata dei tool da chiamare, con i loro argomenti;
• fillers — piccoli slot da riempire al volo (per esempio «qual è la cartella cestino di questo account?»);
• final_message — il modello del messaggio finale, con segnaposti che verranno riempiti dai risultati.

{
 "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 in cestino."
}

Dentro gli argomenti compaiono quattro tipi di segnaposto, che l’Executor risolve in modo deterministico al momento giusto:

7. Strato 0 — Fastpath: le scorciatoie auto-apprese

Il Fastpath è la corsia preferenziale. Ogni turno completato con successo dal piano pieno crea da solo la scorciatoia — le catene sono executor già vagliati e testati, nessuna approvazione —: da quel momento quella richiesta (e le sue varianti vicine) saltano tutto il resto e vengono servite direttamente. Le scorciatoie invecchiano da sole (mai riusate, stantie, tetto totale), muoiono quando un executor le rimpiazza o sparisce, e si rimuovono a mano dalla console admin.

Il riconoscimento avviene in due tempi. Prima un confronto esatto per impronta della frase (deterministico, sotto i 5 ms, senza alcun modello). Se non basta, un confronto per significato: la richiesta viene trasformata in un vettore con BGE-M3 e confrontata per coseno con le scorciatoie salvate (sotto i 150 ms). Una scorciatoia auto-appresa vince sempre, anche su un autopath appreso automaticamente.

8. Strato 1 — Autopath: gli autopath appresi dal feedback

L’Autopath è la memoria che cresce da sola, senza che nessuno scriva regole a mano. Conserva tre tabelle nel proprio archivio sqlite:

La ricerca procede in due tempi: prima per somiglianza semantica (la richiesta cade nel cluster di richieste affini già viste e si serve il piano «campione» di quel cluster), poi, se serve, per corrispondenza esatta dell’intento. Quando più piani competono per lo stesso cluster, vige un meccanismo campione/sfidante: lo sfidante deve dimostrarsi migliore prima di prendere il posto del campione.

9. Strato 2 — il controllo del piano

Prima di eseguire un piano appena proposto, il Validator lo passa al setaccio, in modo puramente deterministico e senza modello:

• i tool citati esistono davvero nel catalogo?
• gli argomenti hanno la forma giusta (niente segnaposti rimasti vuoti, niente campi obbligatori mancanti)?
• i riferimenti fra step (from_step, ${stepN.…}) puntano a step che esistono?

Se trova anche un solo errore, non avvia l’esecuzione: chiede al Proposer di riproporre il piano una volta, escludendo quello sbagliato. Così un refuso o un argomento storto vengono corretti a costo zero, senza sprecare una chiamata di recupero più pesante. È attivo per impostazione predefinita.

10. Strato 3 — Proposer, Executor, Recovery, Terminator

Proposer — la proposta in un colpo

Il Proposer è l’unico componente che parla davvero con il modello linguistico. Riceve la richiesta e l’intento estratto e produce, in una sola chiamata, il piano intero. Niente ragionamento passo-passo, niente tool-call iterativi: un solo oggetto strutturato.

Esistono varianti selezionabili (impostazione METNOS_ENGINE):

• simple — una proposta, diretta. La più veloce.
• metis (predefinita in esercizio) — genera due-tre piani alternativi e sceglie il migliore con un punteggio deterministico che preferisce le pipeline brevi, coerenti col verbo e con poche chiamate. Costa qualche frazione di secondo in più, ma copre meglio i casi ambigui. Tiene anche una piccola cache: in caso di riproposta, serve un’alternativa già pronta senza richiamare il modello.
• frontier — delega la proposta a un modello del cloud (opt-in), come ultima risorsa.

Executor — l’esecuzione senza dubbi

L’Executor è il componente più rigoroso: zero modello linguistico nel loop principale, solo Python deterministico. Per ogni step: risolve i riferimenti agli step precedenti (from_step), riempie gli slot ${FILLER:…} (una piccola chiamata fast con cache) e i valori di contesto ${RUNTIME:…}, valida gli argomenti, chiama l’executor del tool, passa il risultato al Vaglio (il giudice di sicurezza) e accumula. Alla fine compone il messaggio finale dal modello con i campi ${stepN.field}.

Recovery — il recupero mirato

Se uno step fallisce, entra la Recovery. Il suo primo lavoro è capire che tipo di errore è, leggendo la classe d’errore strutturata che l’executor restituisce (niente analisi del testo multilingua):

La Recovery tenta una sola alternativa, escludendo sia il piano fallito sia il tool che ha causato il problema. Niente loop infiniti: se l’alternativa non riesce, la parola passa al Terminator.

Terminator — il vicolo cieco onesto

Il Terminator è il pezzo più sottile del sistema. Non è un «gestore di errori»: è un riconoscimento onesto del limite. Quando arriva il suo turno, vuol dire che tutto il resto ha tentato e fallito. Il Terminator non finge un successo: spiega all’utente la causa e suggerisce un’azione concreta, e registra la lacuna in un archivio (terminator_log.sqlite) con un contatore di quante volte si è ripresentata.

I messaggi di causa e azione non sono stringhe fisse nel codice: passano dal dizionario multilingua, così l’utente li legge nella propria lingua. Il turno si chiude sempre con una risposta leggibile, mai con un silenzio o un errore grezzo.

11. Come impara e accelera

Sotto a ogni risposta in chat, l’utente vede dei piccoli pulsanti di riscontro:

• ✓ verde («risposta giusta»): il piano si avvicina di un passo alla promozione a autopath appreso.
• ✗ rosso («risposta sbagliata»): il piano si avvicina a essere messo fra gli anti-autopath ed escluso per un periodo.
• ↺ arancio («riprova»): esclusione transitoria, solo per il turno successivo.

Non è obbligatorio premere niente: se una pipeline arriva in fondo senza errori, l’Autopath la considera comunque un’osservazione positiva. Il feedback esplicito accelera e rifinisce, ma il sistema impara anche dal silenzio. Più lo si usa, più spesso le richieste vengono servite dalla memoria invece che dal modello — e quindi più in fretta.

12. Cosa cambia per l’utente

1. Le prime richieste sono più veloci

Anche al primo colpo, il motore non interroga il pianificatore passo-passo ma fa una sola proposta. La sensazione è quella di un sistema che «ci pensa un attimo» invece di «si blocca per un minuto».

2. Le richieste ripetute sono istantanee

Dopo qualche turno della stessa famiglia di richieste, l'autopath è appreso e i turni successivi partono dalla memoria. La risposta arriva in una frazione di secondo: è la differenza fra «assistente» e «reazione immediata».

3. I fallimenti diventano informativi

Quando qualcosa non si può fare, il Terminator dice esattamente cosa serve. Niente messaggi vaghi del tipo «errore generico», niente loop di tentativi inutili: una frase chiara, un suggerimento operativo e, se è il caso, un dialogo per risolvere la mancanza sul momento.

13. Perché funziona meglio dei framework LLM-in-loop

I framework per «workflow di agenti LLM» (LangGraph e affini) coprono in parte lo stesso problema: ridurre la varianza del modello nel loop dando struttura ai task. Ma hanno limiti che questo motore non ha:

L’analogia che chiarisce tutto

I framework LLM-in-loop tradizionali sono come artisti con tela bianca: ogni turno reinventano la composizione. Bella creatività, ma il rischio di sbagliare strumento è reale e ogni opera costa.

Il motore di Metnos è come un artigiano con quaderno di schizzi: il modello schizza il piano una volta (creatività concentrata e vincolata), e da quel momento l’artigiano riapre il quaderno alla pagina giusta. La creatività del modello c’è ancora, ma è limitata al momento dell’invenzione: l’esecuzione è riproduzione fedele dello schizzo. Così si evitano le allucinazioni in esecuzione, si guadagna velocità e si arriva a costo zero quando il quaderno è già ricco.

14. Numeri onesti

Su un campione di richieste reali (mail, file, web, posizione, ora, dialoghi multi-turno, scheduling, contatti), confrontando il pianificatore iterativo sul cloud con il motore locale a singola proposta:

Diverse volte più veloce, copertura equivalente, costo zero (il modello gira in locale su hardware a memoria unificata). E la latenza scende ancora man mano che la memoria si popola: le richieste ricorrenti partono dalla cache, sotto il secondo.

15. Domande aperte

• Validità degli autopath nel tempo. Quando il pool di executor cambia (uno nuovo sintetizzato, uno vecchio rimosso), gli autopath che li usavano vanno invalidati. Soluzione attuale: l’impronta del piano cambia col catalogo, quindi un autopath obsoleto semplicemente non viene più trovato.
• Autopath per-utente o condivise. Se due utenti dello stesso host condividono lo stesso intento («dammi l’agenda di domani»), conviene un autopath per-utente o globale? Scelta corrente: per-utente, per riservatezza. Da rivedere se emerge un collo di bottiglia.
• Autopath stagionali. La scadenza degli anti-autopath è empirica. Cammini molto rari potrebbero decadere mentre sarebbero ancora utili: possibile soluzione, una scadenza graduata sulla frequenza osservata.
• Quando salire al cloud. Se la proposta locale fallisce e la recovery non salva, esiste l’opzione di interpellare un modello frontier. Quando attivarla in automatico contro lasciarla come scelta dell’utente? L’interfaccia di escalation già copre il caso con un dialogo a più scelte.