Il runtime accompagna una richiesta dall'ingresso alla risposta. Mantiene il contesto dell'utente, sceglie le capacità ammesse, costruisce o riusa un piano, applica i controlli e coordina gli executor. È il direttore d'orchestra di un turno, non un executor universale.
Un turno comincia quando Metnos riceve una richiesta e termina quando restituisce una risposta, chiede un'informazione indispensabile oppure affida un lavoro lungo a LRE. Il runtime associa subito la richiesta a:
Queste informazioni delimitano tutto ciò che segue. La cronologia di una conversazione non viene mescolata con quella di un altro utente; un dispositivo associato a un proprietario non diventa una risorsa comune; una credenziale viene cercata soltanto entro il mandato autorizzato per quel turno.
Consideriamo la richiesta: «Leggi i tre preventivi nella cartella Acquisti, confronta i prezzi e crea una tabella riepilogativa».
Il modello linguistico aiuta nei punti in cui serve capire o comporre linguaggio. I controlli di schema, identità, autorizzazione, collocazione e firma restano invece deterministici. Proporre un piano non equivale ad avere il potere di eseguirlo.
Il runtime prova i percorsi dal più semplice al più generale:
| Percorso | Quando serve | Che cosa viene ricontrollato |
|---|---|---|
| Regola deterministica | Per operazioni dal significato chiuso, come annullare l'ultimo turno o riprendere un dialogo noto. | Identità, stato corrente e contratto specifico. |
| Fast path | Per riusare un piano riuscito sulla stessa richiesta. | Firme del catalogo, argomenti variabili e condizioni operative. |
| Autopath | Per riusare un piano generalizzato e confermato su una richiesta affine. | Somiglianza, assenza di valori personali incorporati, catalogo e validazione completa. |
| Nuova proposta | Quando non esiste un percorso precedente affidabile. | Intero piano, passo per passo. |
Fast path e autopath sono cache di piani, non scorciatoie intorno ai controlli. Conservano le firme delle capacità rilevanti. Se il mondo operativo cambia, il riuso non è più valido e Metnos torna alla pianificazione ordinaria.
I modelli sono scelti per funzione attraverso livelli configurabili. Il runtime chiede, per esempio, un modello adatto alla pianificazione o alla sintesi; non dipende dal nome commerciale di un modello. La configurazione effettiva è visibile in Sistema › Modelli.
Un piano è una lista finita di passi tipizzati. Ogni passo nomina un executor presente nel catalogo, fornisce argomenti conformi al suo schema e può dipendere da risultati precedenti. Non contiene codice libero da eseguire.
{
"steps": [
{"tool": "find_files", "args": {"base_path": "~/Acquisti", "pattern": "*.pdf"}},
{"tool": "read_files", "args": {"from_step": 1}},
{"tool": "extract_entries", "args": {"from_step": 2, "fields": ["fornitore", "prezzo"]}},
{"tool": "create_files_spreadsheet", "args": {"from_step": 3, "path": "~/Acquisti/riepilogo.xlsx"}}
]
}L'esempio mostra la forma, non promette che ogni installazione possieda esattamente quegli executor. Il catalogo generato è la fonte per le capacità installate.
Il validatore rifiuta un executor sconosciuto, un argomento fuori schema, un riferimento a un passo futuro o una combinazione incoerente. Le guardie comuni possono anche inserire un produttore indispensabile, riallineare dipendenze note o chiedere una nuova proposta quando manca un'azione esplicitamente richiesta. Non aggiungono capacità estranee al catalogo.
I risultati non vengono copiati a mano nella richiesta del passo successivo. Il piano usa due riferimenti principali:
from_step: N passa la raccolta prodotta dal passo N;{{stepN.campo}} passa un singolo valore del risultato.Prima dell'invocazione, il runtime risolve questi riferimenti e ricontrolla lo schema finale. Se un produttore non restituisce dati, il consumer non riceve per errore il risultato di un vecchio passo. Se una raccolta è molto grande, può essere conservata nello scratchpad mentre il pianificatore ne vede soltanto una proiezione utile e dichiaratamente troncata.
I dati conservano anche la loro provenienza. Sapere che un valore arriva dal passo 2 non basta a trasformarlo in un percorso locale, in un destinatario o in un'autorizzazione: il consumer deve dichiarare che cosa accetta e il runtime deve poterlo verificare.
Ogni passo attraversa lo stesso punto di invocazione, indipendentemente dal fatto che il piano sia nuovo, riusato, programmato o destinato a un dispositivo remoto. Qui il runtime applica i controlli comuni e registra l'esito reale.
Se serve una conferma, l'esecuzione si ferma prima dell'effetto. La proposta deve rendere riconoscibili azione, scopo, destinazione e conseguenze rilevanti. La risposta viene legata all'utente e al turno che l'ha generata, così una conferma vecchia o appartenente a un'altra conversazione non può riprendere il piano.
Le credenziali seguono un percorso separato. Il pianificatore può indicare il tipo di accesso necessario, ma il runtime risolve il segreto da un archivio cifrato e da un mandato circoscritto soltanto al momento dell'esecuzione. Il valore non entra nel piano, nei messaggi del modello o nei registri ordinari.
Non tutte le richieste possono concludersi in un'unica risposta HTTP o Telegram.
Una ripresa non ricomincia alla cieca. Il runtime ricontrolla proprietario, scadenza, stato del dialogo, catalogo e condizioni operative prima di proseguire.
Un executor può riuscire, non produrre alcun elemento, produrre un risultato parziale oppure fallire. Questi casi non sono equivalenti. Il runtime conserva la distinzione e la usa per decidere se proseguire, tentare un recupero limitato o terminare.
Il recupero non ripete ciecamente un'azione che potrebbe avere già modificato lo stato. Prima classifica l'errore e considera gli effetti registrati. Se non esiste una ripresa sicura, la risposta dichiara il limite. Quando solo una parte del piano fallisce, ciò che è riuscito rimane visibile senza trasformare il risultato complessivo in un falso successo.
La traccia del turno comprende il percorso scelto, i passi, i controlli, i tempi, gli esiti e l'eventuale ricevuta di annullamento. Non deve contenere segreti. Amministratori e utenti vedono soltanto le informazioni compatibili con il proprio ruolo e la propria identità.
In una frase. Il runtime non stabilisce che cosa Metnos può fare: lo stabiliscono gli executor ammessi. Il runtime fa sì che quelle capacità vengano scelte, controllate, eseguite e raccontate nello stesso modo, qualunque sia il percorso che ha prodotto il piano.