← Indice documentazione Architettura › skill & backend

Metnos

skill ↔ backend — due assi ortogonali

Architettura del confine fra skill e backend
Pubblico: chi vuole capire dove finisce un provider e dove comincia una skill.

Indice

Due assi ortogonali
I tre tier di skill
Da un provider a molti
Lo spegni-accendi sta sul backend
Promozione: il meccanismo
Perché MCP resta al confine
Per andare più a fondo
E per te, in pratica?

1. Due assi ortogonali

In Metnos «skill» e «backend» rispondono a due domande diverse. Il backend dice COME si esegue un verbo_oggetto contro un servizio. La skill dice SE e QUALI capacità sono sbloccate, fidate e spedite. Confonderli porta a sdoppiare gli executor; tenerli separati è quel che permette di aggiungere un provider senza toccare il pianificatore.

	Backend / provider	Skill
Risponde a	COME eseguo `verbo_oggetto` contro un servizio	SE / QUALI capacità sono sbloccate, fidate, spedite
Asse	oggetto × provider	dipendenza esterna (credenziale / backend / hardware)
Visibilità	invisibile all'LLM, risolto da configurazione dal resolver dei backend	visibile all'utente (abilita / disabilita, dormienza, recinto, impacchettamento)

I due assi si toccano solo quando una skill ha un solo provider: in quel caso github, geo, mail sono di fatto il nome rivolto all'utente del backend di quel provider. Divergono appena la skill ha più backend (il calendario si serve su ICS locale, Google o CalDAV) o non ha alcun provider esterno (le foto, il nucleo). La mappa è molti-a-molti: un solo provider (Google Workspace) serve più skill — posta, calendario, drive, fogli, documenti.

Regola anti-duplicazione. La dipendenza esterna (credenziale, indirizzo di servizio, hardware) si dichiara una volta sola, al backend. La skill la aggrega — somma dei requisiti dei suoi backend — e non la ridichiara. La dormienza della skill è derivata dai suoi backend, non scritta a mano.

Figura 1 — I due assi. A sinistra l'esecuzione (planner → executor canonico → resolver → backend): invisibile all'LLM, risolta da configurazione. A destra le skill: accendono e spengono i backend, ma non cambiano il pool del pianificatore, che vede sempre find_issues.

2. I tre tier di skill

«Skill» ha finito per indicare tre cose diverse: una classificazione di executor già nel repository, dei pacchetti veri in repository, e codice di terzi importato. Il campo tier le unifica sotto un modello solo. Vive in skills_catalog.py (funzione skill_tier()) e nell'intestazione di SKILL.md.

Tier	Cos'è	Fiducia	Dove vive	Attivazione
1 — core	planner ed engine, file locali, cartelle, processi, tempo, scheduler locale, persone, credenziali, firme, proposte, gli helper dello scratchpad (filtra / ordina / raggruppa / calcola / descrivi / estrai)	massima	repository, firmato, multilingua	sempre attiva
2 — first_party	capacità spedite con Metnos allo stesso standard del nucleo, ma dormienti finché manca la dipendenza: github, foto, posta, web, geo, calendario, archivio dati generico (`sqldatabase`), frontier, Google Workspace	massima	repository (pacchetto versionato + executor firmati)	automatica, dormiente se non configurata
3 — imported	codice di terzi non auditato né vendorizzato (da agentskills.io e simili)	bassa	dati utente, con provenienza tracciata	facoltativa, recinto + rete a 7 strati

Cosa si spedisce al pubblico. Il rilascio porta con sé solo tier 1 e 2, dentro il repository firmato. Il tier 3 no: lo installa l'utente, e proprio a esso si applica la tesi-sicurezza del README («non fidarti del pacchetto»). La promozione tier 3→tier 2 richiede quattro sì congiunti: utile in generale, licenza compatibile, disponibilità a mantenerla (undo, i18n, ri-firma), e sostegno a una capacità già in catalogo.

3. Da un provider a molti

Domani potrebbe arrivare GitLab accanto a GitHub. La domanda è: come si aggiunge un secondo provider per le stesse issue? Due strade.

Opzione (a): sdoppiare l'executor — SCARTATA

Generare find_issues_github e find_issues_gitlab e lasciare che il pianificatore scelga. Funziona dove al centro c'è un modello frontier che disambigua leggendo la prosa. In Metnos il pianificatore è un modello locale, che davanti a due nomi quasi identici sviluppa un pregiudizio sul provider: sceglie sempre lo stesso, o sbaglia. Lo sdoppiamento rompe il routing.

Opzione (b): astrarre — SCELTA

Un executor canonico agnostico rispetto al provider: find_issues, read_issues, find_pulls. L'oggetto (issues, pulls) è l'astrazione stabile.
Un albero di backend per provider: runtime/backends/{issues,pulls}/{github,gitlab}.py.
Il resolver dei backend sceglie il provider dalla configurazione (mappa repository→provider, o per account), non dall'intento dell'utente.
Una skill per provider: skill github (PAT) e skill gitlab (token), con dormienza indipendente — perché la credenziale è il confine dove serve granularità («abilita gitlab» senza toccare github).
Il qualifier _github / _gitlab resta per il pin esplicito dell'utente («apri la issue su gitlab»); il default è agnostico.

Costo di un provider nuovo: +1 file backend, +1 skill (se introduce una credenziale nuova), 0 nuovi executor. È il percorso che calendario e file hanno già preso.

Il backend non si auto-concede autorità. La capability provider:access dichiara il binding della skill e può essere limitata con when al valore finale del selettore client. Solo il binding effettivo governa insieme rete, credenziali e pin al server; nome dell'executor e valore dell'argomento non sono fonti di permesso.

Un esempio già in casa: la skill sqldatabase. La forma astratta non è una promessa per il futuro: la skill sqldatabase la incarna oggi. Offre tre executor canonici — find_entries, write_entries, delete_entries — che leggono, scrivono ed eliminano record in archivi nominati (find_entries(store="spese", …)), senza che la query sappia mai dove i dati vivono davvero. Sotto, due backend intercambiabili sulla stessa base comune (SqlDatabaseBackend): uno persistente su SQLite, uno effimero in memoria; un domani PostgreSQL si aggiunge come sorella, senza toccare gli executor. Quale backend serva un dato archivio si decide in un registro, alla dichiarazione dello store, mai dalla richiesta dell’utente. La skill resta dormiente finché nessuno store è registrato.

Figura 2 — Mono→multi provider. A sinistra lo stato «cotto» (find_issues_github + find_issues_gitlab confondono il planner locale). A destra lo stato astratto: un solo find_issues, il resolver, due backend. La freccia è la promozione: refactoring con frontier una-tantum, poi vaglio umano. GitHub è attualmente nello stato «cotto».

Debito noto. Oggi GitHub è «cotto»: i sedici executor *_github (issue, PR, task, commenti e — da 25/6 — file del repo: find/read/list) portano il provider nel nome. Funziona finché il provider resta unico; appena ne arriva un secondo va astratto. Regola generale: un provider che plausibilmente avrà fratelli (github→gitlab/gitea, posta IMAP, calendario) va astratto da subito; uno che resterà unico può restare cotto.

4. Lo spegni-accendi sta sul backend

Nel modello a più provider la skill non accende e spegne l'executor: accende e spegne il backend. Questo cambia chi vede cosa.

L'executor find_issues è disponibile se almeno uno dei suoi backend è abilitato e configurato; diventa dormiente solo se sono spenti tutti (un AND su tutti i backend).
La skill è un backend (il confine è la credenziale): skill accesa → quel backend entra nel pool del resolver.
Il resolver sceglie fra i backend accesi e configurati; è onesto (§2.8) se chiedi un provider la cui skill è spenta.

Effetto desiderato: accendere o spegnere un provider non cambia il pool di strumenti del pianificatore — vede sempre find_issues — cambia solo il routing. Disabilitare uno dei due: l'altro continua a servire. Disabilitarli entrambi: l'executor diventa dormiente.

Oggi il filtro è per pattern sul nome dell'executor (skills_catalog): funziona solo finché il provider è unico. Il pezzo nuovo da costruire è una mappa skill→backend più la regola «executor dormiente = AND su tutti i suoi backend spenti». È il primo mattone: serve appena esiste il primo executor a più backend.

5. Promozione: il meccanismo

Fondere una skill mono-provider cotta (*_github) in find_issues + backend è un'operazione straordinaria. È ammesso un LLM frontier una-tantum SOLO per il refactoring; rilevamento e applicazione restano deterministici e con vaglio umano — firmare in automatico del codice generato da un frontier romperebbe la fiducia.

Fase	Chi	Cosa
QUANDO (trigger)	deterministico	all'arrivo del 2° provider — tipicamente l'import di una skill che mappa su un oggetto già coperto solo da executor provider-suffissati (`*_github`, riconosciuti dall'autorità di naming). Sovrapposizione di oggetto + provider diverso → «candidato a promozione». Nessun LLM per accorgersene.
DOVE (seam)	infrastruttura riusata	rilevamento nello strato di ammissione dell'importer; refactoring tramite l'escalation a un modello frontier in modo agentico; atterraggio nella pagina admin delle modifiche come modifica di tipo `promote_provider`, niente applicazione automatica; applicazione che scrive i file, ri-firma (§7.10), registra skill↔backend e filtro per-backend (§4).
COME (pipeline)	frontier solo in mezzo	rileva (det.) → il frontier genera {executor canonico + `backends/<obj>/{p1,p2}.py` + mappa skill→backend} → la modifica viene proposta → vaglio umano → applica + firma + verifica con i 7 strati di ammissione + smoke.

Bordi deterministici, centro creativo. Il frontier sta solo nel mezzo: produce la bozza del refactoring. I bordi — accorgersi che serve, e applicare firmando — sono codice deterministico e mani umane. Tre pezzi nuovi, indipendenti e incrementali: (1) un rilevatore di candidati alla promozione; (2) il prompt di promozione per l'escalation al modello frontier; (3) il filtro per-backend del §4 — che serve comunque, ed è il candidato da fare per primo.

6. Perché MCP resta al confine

MCP e il contratto executor risolvono problemi diversi. MCP permette a un client di scoprire e invocare strumenti esposti da un server, negoziando versione e capacità. Metnos deve invece stabilire che cosa significa una capacità per il pianificatore, quale autorità possiede e come si verifica il risultato.

Il contratto citato qui non è una convenzione implicita: è definito dal Metnos Executor Standard versionato. Un backend MCP deve rispettarlo come un backend locale o remoto.

Aspetto	MCP fornisce	Metnos deve conservare
identità	nome del tool entro un server	nome canonico `verbo_oggetto`, indipendente dal fornitore
contratto	schema JSON degli argomenti; schema del risultato facoltativo	forma vettoriale, semantica degli errori e postcondizione osservabile
autorità	connessione e autorizzazione verso il server	capacità, sandbox, mandato credenziale e consenso per l'azione
ciclo di vita	negoziazione, chiamata, annullamento e chiusura	limiti, audit, idempotenza, procedura inversa e recupero
catalogo	può segnalare tool aggiunti o modificati	ammissione esplicita e sospensione quando cambia lo schema

Vincolo di integrazione proposto, non funzione disponibile. Un broker MCP interno potrà essere un trasporto del resolver. Il pianificatore vedrà soltanto un executor canonico o non vedrà affatto la capacità. Un tool generico mcp_executor(server, tool, args) introdurrebbe un secondo linguaggio e aggirerebbe i controlli per singola azione, quindi non appartiene al contratto pubblico.

Un tool esterno potrà diventare il backend di un executor esistente, un executor proxy ristretto oppure restare in quarantena. La trasformazione in executor nativo sarà una promozione verificata e sottoposta a vaglio, non una riscrittura automatica di codice remoto.

7. Per andare più a fondo

Per capire…	Leggi
come si importa una skill di terzi e la si trasforma in executor firmati	skill importer
il recinto a strati in cui gli executor importati eseguono	sandbox
i controlli prima di ogni azione rischiosa	vaglio
cos'è un executor e com'è fatto	executor
l'altro asse di sostituibilità: come si sceglie e si cambia il modello (LLM, embedding, VLM) dietro le capacità, editando un TOML invece del codice	virtualizzazione dei modelli

8. E per te, in pratica?

E per te, in pratica? Dal tuo punto di vista, tutto questo cosa comporta? Non molto. Questa complessità vive sotto il cofano. La incontrerai soltanto quando userai funzioni che fanno la stessa cosa ma fornite da provider diversi — anzi, solo nel momento in cui aggiungerai il secondo provider per una stessa capacità: a quel punto basterà chiedere di «fondere» le due skill e Metnos creerà un nuovo backend. Sinceramente: quante volte ti capiterà, nell'uso quotidiano di uno strumento come Metnos? Quante volte userai contemporaneamente GitLab e GitHub?

Il lato positivo. Metnos nasce per restare il più possibile locale, senza costi aggiuntivi: il cervello che usi ogni giorno gira sulla tua macchina. Quella complessità di astrazione — fondere due skill in un backend — è l'unico momento in cui, e solo se serve, Metnos ricorre una tantum a un modello frontier (presumibilmente a pagamento) per generare il codice del nuovo backend. Un costo occasionale, esplicito e raro — non una dipendenza continua dal cloud. Per il resto, sei e resti locale.

Metnos — skill ↔ backend, due assi ortogonali