1. L'idea in due righe

Prima di interpellare il pianificatore, Metnos prova a riconoscere la richiesta. Se l'ha già vista e sa già come risolverla, ne riusa il path già pronto — la sequenza di executor che la porta a termine — e risponde in mezzo secondo invece che in dieci. Niente modello linguistico da consultare: basta la memoria.

2. Perché serve un fast-path

Il pianificatore di Metnos è un modello linguistico locale, il tier wise, il più capace. Ragiona bene, ma per scegliere il primo passo di un turno ci mette una decina di secondi: per molte richieste è un'attesa fuori misura. «Che ora è?» non chiede un modello, chiede lo strumento get_now. E «scaricami questa pagina e descrivimela in due righe», se la chiediamo spesso, non chiede il pianificatore ma un path già noto: get_urls, poi describe_entries.

Resta da capire come riconoscere una richiesta nota — e quando una soltanto somigliante è abbastanza vicina da trattarla allo stesso modo. È il compito del fast-path introvertivo, su due livelli: colgono gradi diversi di somiglianza, ma arrivano allo stesso risultato, il path giusto eseguito senza ripensarci.

3. I due livelli

I due livelli si distinguono per quanto riconoscono del path. L0 ne riconosce tutto, argomenti compresi: la stessa richiesta di prima, con gli stessi valori concreti. L1 riconosce il solo path — lo scheletro della soluzione, spogliato degli argomenti — e per questo vale per un'intera famiglia di richieste affini.

L'ordine è fisso: prima si tenta L0; se non trova corrispondenza si passa a L1. Se mancano entrambi, la richiesta arriva al pianificatore (il motore), come sempre.

4. L0 — cache auto-prodotta (fastpath.py)

Il primo livello vive in runtime/engine/fastpath.py e custodisce, in un database SQLite (fastpaths.sqlite), i piani già eseguiti. Le voci nascono da sole: ogni volta che un turno va a buon fine — un piano nuovo del motore, il riuso di un L1, una promozione dal coseno 0b — Metnos annota la query canonica, la sua impronta, l'embedding BGE-M3 (la forma numerica del testo, quella con cui se ne misura la vicinanza di significato), il piano per intero (lo scheletro, o framework) e l'intent, cioè il verbo e l'oggetto della richiesta. Nessuna approvazione: le catene sono fatte di executor già vagliati e provati.

Due modi di trovare la corrispondenza

La ricerca avviene in due fasi:

• 0a — confronto per impronta. La query, ridotta a forma normale, diventa un'impronta (un hash deterministico) e si cerca una corrispondenza esatta. Meno di 5 ms, senza modello né embedding. È l'unica via concessa ai piani legati a una singola richiesta: quelli con argomenti letterali presi dalla domanda — un nome proprio usato come chiave di ricerca, poniamo — che, riusati su una richiesta somigliante ma diversa, restituirebbero il dato sbagliato.
• 0b — coseno semantico. Se l'impronta non trova nulla, la query diventa il suo vettore BGE-M3 e si confronta, per coseno, con le voci sopra la soglia configurata. Così cadono sotto la stessa risposta le varianti di una richiesta («che ora è?» e «dimmi l'ora»). Il coseno vale solo per i piani generali, quelli non legati a una singola richiesta: così gli argomenti di una domanda non finiscono per sbaglio su un'altra vicina di significato ma distinta.

Valvole di sicurezza

• Riscontro negativo: un «✗» dell'utente cancella il fastpath di quella query — che rinasce, se la richiesta torna e va a buon fine (vince sempre l'ultima parola).
• Amministrazione: i fastpath si cancellano a mano dalla console /admin/praxis.
• Strumenti non memorizzabili: undo_last_turn e get_inputs non generano fastpath, perché il loro significato dipende dal turno in corso.
• Date assolute: un piano con date ISO esplicite (per esempio since_iso="2026-06-11") non si registra: rieseguirlo un altro giorno aprirebbe una finestra temporale ormai congelata. Le date relative (time_window="today") invece sì, perché a ogni riesecuzione si ricalcolano da capo.

5. L1 — autopath promossi dal riscontro (autopath.py)

Il secondo livello vive in runtime/engine/autopath.py e ragiona in modo diverso: non ripete la stessa query, ma generalizza a un gruppo di intent affini, quello che l'utente ha approvato con un riscontro positivo.

A ogni «✓» dell'utente, Metnos annota lo scheletro del turno, la sua impronta e il gruppo di significato a cui appartiene. Bastano poche conferme — configurabili, di base una sola — sullo stesso scheletro e gruppo perché il piano diventi un autopath riusabile: la volta dopo, un intent dello stesso gruppo lo rimette in moto senza disturbare il pianificatore.

Anti-autopath e confronto campione/sfidante

• Anti-autopath: dopo un riscontro negativo ripetuto (tre fallimenti o più), Metnos registra un anti-autopath che mette quel piano al bando, per quel gruppo, per trenta giorni. Vale la stessa simmetria: un riscontro positivo revoca il bando.
• Campione e sfidante: se più piani si contendono lo stesso gruppo, vince quello con più conferme e meno fallimenti, secondo un punteggio complessivo.

6. Invecchiamento, morte e eredità

I fastpath L0 invecchiano e muoiono per regole fisse, senza che nessun modello ci metta mano. Ogni notte il processo task_state_reaper applica tre regole d'invecchiamento e quattro condizioni di morte.

Invecchiamento

Morte (solo con catalogo completo)

Eredità dei punti

Quando un fastpath muore perché un executor lo ha superato (le condizioni C2), i suoi conteggi d'uso (n_uses) passano all'executor erede, lungo lo stesso meccanismo d'invecchiamento degli executor. La domanda già raccolta non si butta via.

7. L'estrattore di argomenti

Riconoscere la richiesta è metà del lavoro. L'altra metà è ricavarne i valori concreti: quali path, quali URL, quale data, quale soglia. Se ne occupa un estrattore a regole (args_extractor.py), anch'esso senza modello:

• Regole chiuse. Espressioni regolari per i tipi noti: URL (https://...), path (~/... o /..., con la scorciatoia «home» che diventa ~/), email, numeri, estensioni di file («file PDF» → *.pdf), date (oggi, ieri, domani, dopodomani — in italiano e in inglese — tradotte in formato ISO) e finestre temporali («questa settimana», «ultime 24 ore», «last 7 days»).
• Argomenti che dipendono dalla richiesta. Alcuni valori — l'account di posta, la finestra temporale — cambiano con la domanda: all'esecuzione (e alla registrazione) si ricalcolano sulla query attuale, non si ereditano dal piano in memoria.

8. Configurazione

Il fast-path si regola con variabili d'ambiente METNOS_*. Per i valori che devono restare nel tempo c'è un file TOML (~/.config/metnos/runtime.toml); il valore scritto nel modulo è l'ultima rete, quando tutto il resto tace.

Livello 0 (fastpath)

Livello 1 (autopath)

Promozione a executor

9. Promozione a executor sintetico

Quando più fastpath L0 ricorrenti condividono la stessa struttura di piano (l'impronta dello scheletro) e lo stesso intent, ogni notte il processo task_fastpath_promotion li soppesa come candidati a diventare un executor sintetico a tutti gli effetti. A pesare è il gruppo, mai la singola istanza: servono almeno tre fastpath distinti, quindici utilizzi in tutto e trenta giorni di età. E si promuovono solo gli schemi a più passi: quelli a passo singolo un executor ce l'hanno già, e lì il fastpath serve a saltare l'LLM, non a comporre il piano.

Due modalità di promozione

• Modalità 1 (predefinita, attiva). Il candidato diventa una proposta che attende l'approvazione di una persona: compare in /admin/changes, la vista unificata delle modifiche (ADR 0158). Con il sì, un marcatore synt_pending/ avvia la sintesi completa — i cinque stadi, i test, la firma, l'installazione.
• Modalità 2 (opzionale, spenta). Oltre una soglia ben più alta, Metnos sintetizza l'executor da sé, senza che nessuno approvi. La sicurezza regge lo stesso: la sintesi passa comunque per vaglio, test e firma, come ogni executor. Un solo tentativo a notte, e non uno di più.

Da dove viene un executor

Al momento della promozione, Metnos annota in una tabella (promotions) da quali fastpath è nato il nuovo executor: ne registra gli identificatori e le impronte. Serve a chiudere il cerchio. Quando l'executor entra nel catalogo, i fastpath che lo hanno generato non servono più e vengono ritirati (è la condizione di morte «C2 provenienza» del cap. 6). Grazie a quell'annotazione il ritiro è esatto: Metnos sa con certezza quali fastpath togliere, perché il legame fra ciascun fastpath e il suo erede è scritto, non indovinato dal nome.

© 2026 Roberto Brunialti · documentazione Metnos