Il runtime coordina un turno di Metnos. Interpreta la richiesta, seleziona le capacità ammesse, costruisce o riusa un piano, ne controlla forma e permessi, quindi affida ogni passo all'executor competente. Il modello linguistico può proporre il piano e comporre una spiegazione; non ottiene per questo accesso diretto a file, posta, browser, dispositivi o credenziali.
All'apertura del turno il runtime associa la richiesta a quattro coordinate: utente proprietario, attore tecnico, canale e conversazione. Preferenze, lingua, credenziali, dispositivi, dialoghi sospesi e cronologia vengono risolti entro questo contesto. Un turno di un utente non autorizza l'accesso alle risorse di un altro.
| Componente | Responsabilità |
|---|---|
| Runtime | Orchestra il turno, conserva il contesto e applica l'ordine dei controlli. |
| Motore degli intenti e proponente | Interpretano la frase e propongono un framework; il loro risultato è probabilistico. |
| Catalogo | Espone soltanto executor ammessi, con schema, policy, piattaforme e disponibilità correnti. |
| Validatore e guardie | Controllano struttura, tipi, riferimenti, ordine, destinazione e condizioni di sicurezza. |
| Executor | Esegue una capacità circoscritta e restituisce un risultato strutturato. |
| Canale | Rende risposta, allegati e richieste di conferma nella forma adatta a Web o Telegram. |
Il runtime non è una shell generale. La superficie operativa coincide con le capacità presenti nel catalogo attivo e ammesse dalle regole. Per conoscere la disponibilità effettiva dell'istanza si può chiedere al Tutor oppure aprire, nella chat web, Impostazioni › Sistema › Servizi.
Chiedi a Metnos con una richiesta come quella di questo esempio: «Cerca sul web le linee guida europee più recenti sul passaporto digitale dei prodotti, leggi le tre fonti più autorevoli e crea un documento di sintesi nella cartella Rapporti.»
La stessa frase si può inviare da Telegram. Se una regolazione è disponibile soltanto nella chat web, Metnos deve indicare esplicitamente quel canale e il percorso di navigazione, non limitarsi a citare il nome tecnico della pagina.
Non ogni richiesta richiede una nuova proposta del modello. Il runtime prova in ordine percorsi con responsabilità diverse:
Le foto allegate e le continuazioni di un dialogo portano stato specifico del turno e quindi non usano come se nulla fosse un piano cache generico. La destinazione remota viene risolta prima dell'instradamento: se il dispositivo nominato è ambiguo o irraggiungibile, il turno si ferma o propone un differimento esplicito.
I nomi fast, middle, wise,
creative e frontier indicano ruoli configurabili, non prodotti fissi:
fast serve compiti brevi come estrazione dell'intento, filler e
alcune sintesi;middle svolge trasformazioni e giudizi intermedi deterministici;wise propone framework e affronta le composizioni più complesse;creative formula proposte e testi divergenti con una policy distinta;frontier è facoltativo e viene usato soltanto da percorsi che lo
richiedono esplicitamente.La lingua viene risolta per utente e propagata all'intero turno. Prompt, messaggi del runtime, moduli di conferma e risposta finale devono usare quella lingua. Il testo di un prompt non deve imporre incidentalmente una lingua diversa: ogni famiglia di prompt ha una variante localizzata e, per una nuova lingua, una risorsa mancante deve essere rilevata in compilazione o produrre un ripiego esplicito, non un miscuglio silenzioso.
Il catalogo unisce executor distribuiti con manifest firmato, capacità interne e operazioni aggiunte da skill ammesse. Prima della proposta, l'instradamento crea un insieme più piccolo usando intenti, oggetti canonici, fornitori nominati, relazioni fra produttori e consumatori e stato di disponibilità. Se il segnale è insufficiente, il sistema può lasciare al proponente un catalogo più ampio.
Un piano L0 o L1 non è valido per sempre. Alla registrazione conserva due firme: quella degli executor usati e quella delle famiglie di candidati pertinenti. A ogni riuso il runtime le confronta con il catalogo corrente. Un executor modificato o rimosso, una nuova alternativa rilevante o un cambio dell'epoca di instradamento rende il piano un miss e forza una nuova decisione.
Il riuso riguarda il framework operativo, non una scheda personale inserita nel pianificatore. Preferenze chiuse e contesto dell'utente vengono applicati nei punti previsti dal runtime e nella generazione finale; non contaminano una chiave cache condivisa con prosa biografica.
Il proponente restituisce un Framework: una lista finita di passi,
eventuali filler e un terminale. Ogni passo indica un nome presente nel catalogo e
argomenti conformi allo schema dell'executor. Il framework non contiene codice
arbitrario da eseguire.
{
"steps": [
{"tool": "find_urls", "args": {"query": "..."}},
{"tool": "read_urls_html", "args": {"from_step": 1}},
{"tool": "create_files_doc", "args": {"from_step": 2, "path": "Rapporti/..."}},
{"tool": "final_answer", "args": {}}
]
}Prima dell'esecuzione il validatore controlla executor, tipi, campi obbligatori,
alternative requires_one_of, riferimenti a passi precedenti e
placeholder. Le guardie strutturali riallineano l'ordine e possono richiedere una
nuova proposta se manca un'azione esplicitamente richiesta. L'executor condiviso
risolve poi gli argomenti e applica la stessa sequenza a piani freschi e piani
riusati.
I dati non vengono copiati nel prompt come testo libero quando esiste un riferimento strutturale:
from_step: N passa la raccolta prodotta dal passo N al consumer;${stepN.field} passa un singolo campo;${RUNTIME:key} inserisce un valore controllato dal runtime, come
l'identificatore del turno;${FILLER:name} risolve un breve valore mancante entro lo schema
dichiarato.Una destinazione esplicita scritta dall'utente prevale su un riferimento generico a un passo precedente. Il runtime conserva inoltre l'autorità dei dati: un percorso prodotto su un dispositivo remoto non diventa un percorso locale soltanto perché un filtro intermedio è stato calcolato sul server.
Un turno può fermarsi con ask o needs_inputs quando manca
una scelta, una credenziale, una posizione o un consenso. Il dialogo persistito
contiene il proprietario, il canale, la conversazione e il callback ammesso. Alla
risposta, il runtime ricostruisce i passi già completati come stato
done e pianifica soltanto il seguito; non riesegue automaticamente le
mutazioni precedenti.
Le osservazioni necessarie ai passi successivi restano nello stato strutturato del turno. Il sottosistema scratchpad offre inoltre una lettura controllata dei risultati persistiti o voluminosi. Un allegato caricato entra come input virtuale consumabile, non come azione già eseguita.
La sicurezza non dipende dalla buona volontà del proponente. Il catalogo limita ciò che può essere nominato; schema e sandbox limitano gli argomenti e l'ambiente; la policy classifica l'azione; il Vaglio applica guardia e giudizio; la richiesta di consenso sospende la sequenza prima della mutazione quando necessario.
L'approvazione è legata a utente, turno, azione, argomenti e destinazione. Il testo è localizzato e il canale usa il proprio controllo nativo: modulo nella chat web, pulsanti o scelta compatibile in Telegram. Frequenza, formulazione della richiesta e silenzio non creano da soli un permesso persistente.
Il TurnLog registra identificatori del turno e della conversazione,
utente, canale, lingua, intenti, origine del piano, passi, tempi, esiti, effetti
contabili, destinazione reale e stato finale. Credenziali riconosciute vengono
oscurate prima della persistenza; gli allegati sono esposti al client tramite URL
firmati o trasferimento del canale, non come percorsi grezzi.
La traccia consente di ricostruire quali executor siano stati invocati e quali controlli abbiano deciso. Non trasforma però una spiegazione generata dal modello in prova: per verificare un fatto servono l'osservazione strutturata e, quando applicabile, la sorgente originaria. La pagina osservabilità descrive viste, metriche e limiti di retention.
Lo scheduler builtin esegue lavori di manutenzione registrati e alimenta i cicli di osservazione e proposta previsti dal prodotto. Le attività create dall'utente sono invece richieste persistenti con proprietario, pianificazione, comando, canale di consegna e cronologia degli esiti. Al momento dello scatto il corpo viene eseguito come un nuovo turno dello stesso utente: non eredita privilegi da un altro canale o da un altro account.
Chiedi a Metnos con una richiesta come quella di questo esempio: «Ogni lunedì alle 8 cerca le mail non lette dell'account lavoro e mandami un riepilogo su Telegram.» Se la ricorrenza è riconosciuta in modo univoco, Metnos registra l'attività; altrimenti chiede i dati mancanti invece di eseguire subito il corpo della richiesta.
Gli errori strutturali sono classificati come strumento errato, argomenti errati, input mancante o fuori ambito. Quando non ci sono effetti già prodotti, il recupero può proporre una sola alternativa e la sottopone alla stessa finalizzazione del piano originale. Un errore operativo, come rete assente, rate limit o servizio non disponibile, non viene mascherato cambiando arbitrariamente executor.
Se l'executor restituisce opzioni strutturate che l'utente può decidere, il runtime le trasforma in un modulo. Se il recupero non è sicuro, la risposta dichiara il limite e conserva gli eventuali risultati parziali. Non deve affermare che una scrittura, un invio o una cancellazione siano riusciti quando i contatori degli effetti dicono il contrario.
| Parte | Garanzia corretta |
|---|---|
| Catalogo, firme e cache validity | Controlli deterministici rispetto allo stato osservato. |
| Validatore, guardie, passaggio dei dati ed esecuzione | Regole di codice ripetibili; gli esiti esterni possono cambiare. |
| Riuso valido della cache | Riprende lo stesso framework, dopo averlo sottoposto ai controlli correnti. |
| Intent e nuova proposta | Uscita probabilistica del modello, circoscritta da vocabolario, insieme dei candidati, grammatica quando abilitata e validazione successiva. |
| Sintesi finale | Può variare nella forma; deve restare fondata sugli esiti registrati. |
Metnos rende quindi governabili i confini fra proposta ed esecuzione. Non promette che una nuova pianificazione linguistica sia identica a ogni invocazione, né che un servizio esterno restituisca sempre gli stessi dati.
Riferimenti nel codice:
runtime/agent_runtime.py: contesto del turno, canali, dialoghi e bridge verso il motore;runtime/engine/dispatch.py: cascata L0/L1, proponente, validatore, guardie, recupero e terminatore;runtime/engine/types.py e runtime/engine/executor.py: framework, riferimenti e semantica di esecuzione;runtime/engine/cache_validity.py: firme dei piani cache;runtime/recurring_tasks.py e runtime/scheduler_v2/: attività utente e lavori builtin;runtime/turn_events.py: persistenza e lettura delle tracce.