Executor che usano un modello

Un executor intelligente usa un modello per risolvere uno o più passaggi incerti, ma conserva il normale contratto di un executor. Il pianificatore gli affida un compito preciso e riceve il risultato previsto, senza dover conoscere il percorso interno.

Idea centrale. Il modello può proporre come procedere entro un insieme limitato di possibilità. Non ottiene per questo nuovi permessi e non decide da solo che cosa conta come successo.
Contratto stabileArgomenti, autorità e forma del risultato non cambiano quando interviene il modello.
Scelta circoscrittaIl modello propone soltanto valori o azioni che l'adattatore sa convalidare.
Esito verificatoLa postcondizione dell'executor, non una dichiarazione del modello, stabilisce se il tentativo è riuscito.

Il confine architetturale

Il manifest e il codice dell'executor definiscono lo scopo, gli argomenti, le capacità, il consenso, i limiti e la forma del risultato. Quando una parte del percorso richiede un modello, l'adattatore prepara un'osservazione limitata, controlla la proposta e decide quale operazione concreta eseguire. Il modello non invoca direttamente gli executor e non modifica il proprio contratto.

Nel manifest, intelligence = "agentic" dichiara questa modalità e permette al registro e all'interfaccia di rappresentarla correttamente. La dichiarazione viene convalidata, ma da sola non dimostra che l'implementazione sia sicura: limiti, validazione delle proposte e postcondizioni devono essere verificati nel codice e nei test.

Ciclo limitato di un executor intelligente Un contratto stabile delimita un ciclo interno, con controlli sulle proposte e sui risultati. PERMESSI FISSI: capacità · consenso · segreti · destinazioni Osservastato limitato Proponiuna proposta Convalidaregole definite Esegui e verificarisultato atteso ESITO: completato · non conclusivo · limite raggiunto Tentativi, tempo, cronologia e osservazioni hanno limiti definiti.
Il ciclo comune limita tentativi, tempo, cronologia e dimensione delle osservazioni. L'adattatore conserva il controllo dell'azione.

Che cosa offre oggi il runtime comune

Metnos fornisce un ciclo sincrono e uno asincrono. A ogni tentativo può aggiornare l'osservazione, chiedere una proposta, convalidarla, eseguirla e controllare la postcondizione. L'esito interno è uno fra completed, inconclusive ed exhausted. Esiste anche la variante «prima il metodo deterministico, poi il modello»: se il ripiego non produce un risultato valido, resta valido il risultato deterministico iniziale.

ResponsabilitàRuntime comuneAdattatore dell'executor
LimitiImpone massimi a tentativi, tempo, cronologia e osservazioniPuò scegliere limiti più stretti e deve limitare ogni singola operazione
PropostaLa richiede e ne gestisce il cicloDecide che cosa il modello può vedere e proporre
ValidazioneNon accetta una proposta respintaDefinisce le regole concrete di ammissione
SuccessoRestituisce l'esito del cicloDefinisce e verifica la postcondizione
AutoritàNon la ampliaOpera entro manifest, policy, consenso e sandbox
Il limite di tempo del ciclo non interrompe automaticamente un'azione già iniziata. Serve a impedire nuovi tentativi. L'adattatore deve assegnare un proprio timeout a ogni operazione, soprattutto quando questa può modificare dati.

Dove viene usato

Scelta controllata

Nella navigazione web il modello può scegliere l'identificatore di un controllo fra candidati preparati dal broker. Non produce selettori CSS o XPath.

Nella ricerca di immagini può riordinare identificatori noti quando i metadati non offrono un segnale lessicale sufficiente.

Ripiego controllato

L'OCR prova prima Tesseract. Soltanto se il testo è insufficiente può chiedere al modello visivo una trascrizione; un risultato debole non sostituisce quello iniziale.

L'estrazione strutturata e alcuni percorsi di consultazione usano lo stesso principio con contratti propri.

Il modello è utile quando lo scopo è ristretto, il percorso può variare e la conclusione è verificabile. Non è adatto a nascondere dentro un executor una ricerca aperta, una strategia fra domini o un compito senza un criterio netto di completamento: quelle decisioni appartengono al pianificatore.

I segnaposto sono ammessi soltanto negli esempi generativi. Le osservazioni del sito e i risultati conservano i dati effettivamente rilevati o ne dichiarano l’assenza; un segnaposto non dimostra che una voce sia stata trovata.

Accedere a un sito

Metnos cerca prima un modulo di accesso. Se non lo trova, segue gli ingressi all’area personale e i menu pertinenti. Usa i segnali della pagina; quando non bastano, il modello locale sceglie fra i comandi effettivamente osservati. Non inventa collegamenti né contiene percorsi dedicati a singoli siti.

Una preferenza fra i segnali vale solo se distingue un comando. Alcune pagine usano la parola dell’accesso come verbo generico, ad esempio «Accedi a» seguito da molte sezioni diverse: quella parola non indica l’ingresso e non nasconde il solo comando che l’insieme dei segnali designa senza ambiguità, come «Area clienti».

La ricerca esplora fino a quattro passaggi per percorso, con un limite complessivo di 32 azioni. In un vicolo cieco torna a una diramazione già verificata e prova un’alternativa. Se durante il ritorno la pagina è cambiata, abbandona quel ramo e torna all’ingresso iniziale per una nuova lettura, conservando i comandi già provati e i limiti. Questa ripresa è disponibile soltanto prima dell’uso delle credenziali e non ripete il ramo abbandonato. Un comando ambiguo resta un motivo di arresto. Un pannello temporaneo che copre la pagina, anche se disegnato dentro un iframe, si chiude soltanto da un’uscita sicura che non naviga e non invia dati. Una pausa per il consenso non azzera i tentativi.

Dopo un clic attende anche la comparsa ritardata del modulo o della nuova scheda, entro il tempo della ricerca. Un ingresso già provato non viene scambiato per una nuova alternativa. Le nuove schede passano dagli stessi controlli sul sito autorizzato.

Trovato il modulo, il componente che gestisce il browser inserisce le credenziali senza affidarle al modello. Controlla il sito autorizzato e il contenuto dei campi prima dell’invio. Un modulo ambiguo o un valore diverso da quello previsto impedisce l’invio. Nei moduli a due passaggi distingue l’indirizzo email dalla password; un collegamento di accesso fuori dal modulo non basta a scambiare una newsletter per una pagina di login.

Dopo l’invio osserva la pagina per un intervallo limitato. Un segnale di accesso comparso entro quell’intervallo completa la propria verifica di stabilità, al massimo per le letture che questa richiede; un segnale successivo, interrotto o non osservabile resta non verificato. Se il modulo invia via script e la sua richiesta non ha ancora risposto, l’osservazione si estende una sola volta di un altro intervallo. Una pagina che sta già caricando il documento successivo, come nei rimbalzi dell’accesso unico, non è ancora un esito: l’osservazione e la raccolta attendono quel documento.

Salvataggio, elenco, uso e cancellazione delle credenziali condividono un unico deposito cifrato. L’elenco mostra soltanto metadati. I valori non compaiono nei risultati o nei registri e cambiare la cartella dei dati dell’istanza non seleziona un deposito diverso.

Raccogliere dati da più pagine

Una richiesta come «raccogli tutte le fatture del 2026» richiede di distinguere gli oggetti cercati, i filtri e i campi da estrarre. Trovare un primo elenco non conclude il lavoro: Metnos cerca anche pagine successive, archivi, altri periodi e dettagli necessari. I comandi visibili vengono esaminati a gruppi, così una pagina molto lunga non nasconde quelli successivi.

La ricerca esplora fino a otto livelli. Le espansioni dello stesso elenco, come la pagina successiva, restano allo stesso livello, come i pulsanti che cambiano la pagina sul posto (un menu, l’elenco completo); in quello stato si esplora solo ciò che il cambiamento ha rivelato. Un dettaglio completa una voce già trovata. Avanzamenti, scorrimenti e ritorni condividono 256 azioni e dieci minuti di lavoro attivo. Le attese per l’utente non consumano questo tempo e non azzerano i tentativi. Ogni decisione del modello locale dispone di 20 secondi, compresi nel tempo complessivo.

Quando torna su una pagina, Metnos ritrova i comandi già verificati senza ripetere clic inutili. Pulsanti uguali vengono distinti tramite il testo visibile della propria riga. Due righe indistinguibili restano ambigue; testo nascosto e valori modificabili non vengono usati per distinguerle. Un comando non riconoscibile con certezza non viene scelto per posizione.

Dopo il clic su un collegamento verso un’altra pagina, Metnos attende che la navigazione si completi. Se invece la pagina risponde sul posto, chiedendo soltanto dati senza caricare un nuovo documento, e poi resta ferma, l’attesa termina subito; senza questa prova vale l’attesa normale.

Uno strato senza testo che copre tutta la finestra, mentre nessun comando visibile è raggiungibile, viene trattato come caricamento in corso: Metnos attende che sparisca, entro il limite consueto, prima di leggere la pagina o di chiudere una finestra sottostante. Finestre, pannelli e messaggi scritti che offrono qualcosa da premere non sono considerati veli.

Controlli di caricamento: un errore, un timeout o un risultato non valido del controllo di caricamento non dimostra che la pagina sia pronta. Metnos ripete l’osservazione entro la stessa scadenza, che comprende anche il tempo dei controlli. Una pagina osservata subito come stabile non richiede pause aggiuntive.

Allo stesso modo Metnos attende i dati che la pagina sta ancora scaricando, per esempio un elenco di fatture che compare dopo l’apertura. Se una richiesta resta aperta oltre il limite, come un collegamento permanente, la pagina viene letta così com’è.

Dopo ogni clic Metnos legge la pagina quando ha smesso di cambiare: alcuni collegamenti cambiano indirizzo e disegnano la nuova pagina dopo il clic. Se una lettura fallisce perché la pagina cambia proprio in quel momento, la ripete una volta, invece di interrompere la raccolta.

Il dettaglio di una voce aperto su un’altra pagina serve a completare quella voce: Metnos lo legge, lo conserva e torna indietro, senza esplorare da lì altre sezioni. Per una raccolta completa si apre prima l’elenco intero (per esempio «tutte le bollette»), poi i dettagli.

Prima di cliccare, Metnos controlla ancora che il comando sia quello osservato, nella stessa pagina e nello stesso contesto. Se è cambiato, un percorso già visitato può essere preparato di nuovo una sola volta, rispettando consensi e limiti. Questo recupero non ripete un clic già inviato né una preparazione che ha già chiuso finestre o gestito consensi.

Il controllo finale osserva il comando senza riscrivere gli identificatori nella pagina. Appena viene invocato il clic, l’approvazione è consumata: un errore o un timeout non dimostrano l’assenza di effetti e non autorizzano a ripeterlo. Una nuova lettura può chiarire lo stato, senza reinviare il comando.

Una navigazione osservata può collegare una riga al suo dettaglio. Soltanto se il legame è univoco Metnos può unire i dati delle due viste, privilegiando il dettaglio e conservando i campi presenti solo nell’elenco. Date o importi uguali non dimostrano che due voci siano la stessa. Viste ambigue o troncate restano separate e le osservazioni originali sono conservate.

La stessa voce letta in pagine diverse, per esempio in un riepilogo e nell’archivio, diventa una sola riga soltanto se le due righe mostrano lo stesso identificativo: un codice di lettere e cifre che, in ciascuna pagina, compare in una sola riga. Un codice ripetuto su tutte le righe non identifica nulla; date e importi scritti con separatori non contano. Le righe si uniscono se i campi comuni concordi sono più di quelli discordi: un elenco e il dettaglio possono indicare date diverse per la stessa fattura, mentre una nota di credito che la cita differisce quasi in tutto. Resta la riga più completa, senza mescolare valori, e il foglio dichiara le righe unite nelle Note e in chat. Ogni lettura di una pagina conta come fonte distinta, anche quando la stessa pagina viene riletta. Righe di fonti diverse con almeno due campi uguali e nessun identificativo in comune, o con un identificativo comune ma più campi discordi che concordi, restano separate e vengono segnalate come possibili doppioni.

Documenti scaricati e identità delle fatture

Quando l'azione approvata include il salvataggio, i documenti vengono conservati nella cartella indicata, entro i limiti dichiarati, e restituiti come file leggibili nei passi successivi. Un errore o una risposta persa non autorizzano un secondo invio al sito. Le letture HTML e PDF conservano l'esito di ciascun indirizzo, compresi gli errori; un PDF senza testo segnala la necessità del riconoscimento ottico senza dichiararlo già eseguito.

Due fatture con codici differenti restano separate anche quando hanno lo stesso numero di fornitura. I separatori nei codici conservano i gruppi osservati: INV-20-005 e INV-200-05 sono distinti. Le copie equivalenti si uniscono soltanto nel proprio gruppo, senza usare una riga priva del codice per collegare fatture differenti. Queste modifiche sono verificate localmente; il collaudo del flusso completo è ancora richiesto.

Quando interviene un modello cloud

Se è configurato, il modello cloud del livello Frontier sceglie i percorsi da esplorare e riconosce i dati visibili durante la raccolta. Per riconoscerli riceve anche il testo osservato della pagina, entro il limite di lettura; la scelta separata del percorso riceve i nomi dei comandi con il titolo della sezione. Queste osservazioni possono contenere dati personali. I valori dei campi di accesso restano esclusi. Login, pianificazione, estrazione delle righe e altre operazioni mantengono i rispettivi modelli configurati. La risposta conta le richieste cloud e il passo mostra un simbolo $ rosso; una richiesta già inviata rimane conteggiata anche se scade il tempo disponibile.

Senza Frontier configurato decide il modello locale. Se Frontier è configurato ma la decisione fallisce o scade, la raccolta resta incompleta: non passa automaticamente a un altro modello. L’amministratore può disattivare entrambe le decisioni cloud con METNOS_SITES_FRONTIER_ROUTES=0.

Filtri, date e fogli

Collaudo del flusso reale ancora aperto. Le locuzioni di raccolta, l’osservazione dei pannelli cookie e le sfide robot testuali descritte qui richiedono ancora collaudo e accettazione del flusso reale.

«Tutte», «elenco completo» e «lista completa» mantengono il significato di raccolta completa anche quando il piano abbrevia la richiesta, soltanto se affermate per l’oggetto richiesto. Negazioni e divieti non attivano quella raccolta; l’aggettivo «completo» da solo non ne definisce l’estensione. Riconoscere la richiesta non certifica che tutte le voci siano state trovate. Periodo, categoria e altri vincoli devono riferirsi senza ambiguità alla stessa azione e valere insieme per ogni voce. I filtri si applicano ai dati raccolti: la data di una pagina intermedia non basta a escludere un percorso. Un riepilogo o una fattura diversa non dimostrano che una voce rispetti i requisiti.

Le date conservano la precisione della fonte: «08/2026» indica un mese, «luglio–agosto 2026» un intervallo e «15/09/2026» un giorno. Sono riconosciuti anche i nomi dei mesi inglesi. L’anno deve essere presente nella fonte; nelle date numeriche l’ordine resta giorno/mese, indipendentemente dalla lingua dell’interfaccia. Una data illeggibile viene dichiarata, con il numero di righe escluse e il campo interessato, anche nel risultato del foglio.

Il foglio riusa il campo estratto quando l’intestazione differisce solo per maiuscole o spazi esterni. Cerca prima il nome esatto, poi una corrispondenza univoca con queste differenze e infine una corrispondenza univoca senza differenze di punteggiatura e accenti. Non risolve un’ambiguità scegliendo il primo campo. Emissione e scadenza restano date distinte.

Il lessico comune riconosce anche le equivalenze fra numero identificativo, importo e stato nelle etichette italiane e nelle chiavi inglesi. Il numero identificativo resta distinto dal conteggio. Queste corrispondenze non dipendono dall’ordine dei campi e non richiedono una chiamata al modello; se più campi competono, serve un collegamento esplicito alla chiave.

Le intestazioni del foglio sono etichette, separate dalle chiavi estratte. Con uno schema già dichiarato non aggiungono campi; un collegamento esplicito tra intestazione e chiave può richiedere un nuovo campo. In assenza di schema, le intestazioni possono definirlo. Un filtro temporale già dichiarato con campo e periodo non riceve un secondo filtro automatico privo di campo.

Il censimento dei campi comprende tutte le righe. Un campo univoco presente ma vuoto può produrre una colonna vuota; una collisione resta ambigua anche se compare nelle ultime righe.

I valori forniti come dati non diventano formule. Nei file XLSX il nuovo testo viene salvato come testo, conservando le formule già presenti quando si aggiungono righe. Nei CSV e nelle scritture Google Sheets i testi attivi ricevono un apostrofo iniziale di protezione: nel CSV è parte del dato e può essere visibile. Le ricevute indicano il numero di celle così protette. Sul dispositivo serve il pacchetto aggiornato: un vecchio pacchetto non acquisisce questa protezione senza aggiornamento.

Per un errore durante un’azione del browser, la diagnostica interna distingue preparazione, invio del comando, operazioni successive, pulizia e registrazione. Conserva il tipo dell’eccezione e indizi da un insieme chiuso, senza riportare messaggi, selettori o dati della pagina. Gli indizi possono derivare anche da testo citato: non certificano la causa e non cambiano esiti, tentativi o limiti.

Al termine della procedura di login, anche prima dell’uso delle credenziali, l’audit conserva l’esito, il motivo e la classe interna, la fase raggiunta e il numero di azioni di ricerca. Un eventuale rifiuto della navigazione lascia soltanto contatori e confronti da un insieme chiuso, senza dati della pagina, destinazioni o segreti. Questa traccia serve alla diagnosi e non introduce nuovi tentativi né certifica la causa di un errore.

Correzioni candidate del recupero, 15 ottobre 2026

Dopo un accesso verificato, il candidato conserva come punto di ritorno l’indirizzo effettivamente raggiunto, invece della pagina pubblica di apertura. L’unico recupero già previsto non reinvia credenziali o moduli. Richiede la stessa pagina, l’indirizzo esatto e l’origine autorizzata; un cambio o una richiesta di intervento pendente fermano il recupero. Tornare all’indirizzo non costituisce una nuova verifica dell’autenticazione.

Nella raccolta, dopo una navigazione già eseguita, un cambio del documento durante il controllo può consentire una sola nuova lettura sulla stessa pagina e origine, entro quattro secondi complessivi e il tempo residuo del chiamante. Il risultato della lettura precedente viene scartato anche se era favorevole. Nessun clic viene ripetuto; una sfida o un consenso pendente restano bloccanti.

I nuovi registri distinguono il motivo del recupero e l’esito della scelta locale fra comandi osservati: conservano contatori, durata e categorie chiuse, senza testo della pagina, indirizzi, valori dei campi o risposta del modello. La completezza dichiarata riguarda soltanto la finestra consegnata alla scelta, non l’inventario del sito. La diagnostica non cambia decisioni o tentativi.

La qualifica isolata di questi delta resta distinta dalla consegna e dal collaudo sul sito. Non dimostra che il primo comando non trovato sia risolto, che siano state raccolte tutte le fatture o che esista un risolutore CAPTCHA automatico generale o un nuovo supervisore.

La raccolta completa è ancora in collaudo. Le prove isolate IT/EN dei filtri sono superate; completezza e assenza di duplicati devono ancora essere confermate sul sito reale. Raggiungere un limite di tempo, azioni, profondità o lettura produce un risultato parziale, senza inventare il numero totale degli oggetti.

Se un ostacolo interrompe la ricerca, i dati già osservati possono essere consegnati anche in un foglio. Se il totale atteso non è noto, l’avviso dice che la completezza non è verificata e indica il limite osservato; la verifica delle righe scritte non dimostra che siano state raccolte tutte le fatture. Un login fallito, un rifiuto senza dati o un consenso pendente fermano invece la sequenza. Un comando ambiguo non giustifica l’aumento dei limiti.

Il servizio consente fino a otto sessioni browser contemporanee, anche dello stesso utente. «Chiudi le sessioni web» termina le proprie sessioni; non cambia le preferenze del browser né cancella dati del sito.

CAPTCHA, codici e ripresa

I confini del sito e le richieste di consenso restano validi durante tutta la navigazione. I cookie seguono una procedura separata che rifiuta le opzioni facoltative e ricontrolla eventuali nuovi avvisi prima dell’invio. Dopo il rifiuto attende brevemente la chiusura del pannello, osservandolo senza ripetere il clic o richiedere una nuova decisione al modello. I codici OTP vengono chiesti all’utente, salvo automatismi autorizzati esplicitamente; non sono trattati come CAPTCHA.

Metnos osserva il testo pubblico statico e non modificabile del pannello, anche dentro un modulo o in elementi senza un riquadro proprio (display:contents). Include il nome accessibile del solo pannello e il testo alternativo delle immagini visibili al suo interno. Restano esclusi contenuti nascosti o estranei, valori dei campi, testo modificabile e codice attivo, con gli stessi limiti e oscuramenti. Questi indizi permettono di distinguere anche un avviso promozionale: classificarlo come altro non autorizza a premere Chiudi.

Il rifiuto dei cookie richiede un significato esplicito nell’etichetta del controllo e una coppia di identificatori osservata nello stesso pannello. Una semplice chiusura o un menu di navigazione non costituiscono un rifiuto. Anche le decisioni conservate vengono ricontrollate; se le evidenze non bastano, Metnos sospende l’azione. Le espressioni di rifiuto provengono dal lessico nativo aggiornabile, senza regole specifiche per ciascun portale.

Un campo chiamato «codice» o «token» non basta a richiedere un OTP. Metnos cerca un campo visibile e modificabile, identificato come codice monouso oppure accompagnato da indicazioni di verifica nello stesso modulo o gruppo di campi. Riconosce codici numerici e alfanumerici, anche suddivisi in caselle da un carattere. Se più campi non permettono una scelta univoca, non inserisce il codice. I campi sensibili restano oscurati e l’invio rispetta i confini del sito autorizzato.

Metnos riconosce anche una richiesta testuale esplicita di verificare che l’utente sia umano nel proprio modulo di accesso. Legge la prosa completa, conservando FAQ, citazioni e negazioni intorno al messaggio, anche in presenza di collegamenti, pulsanti o campi vicini. Citazioni illustrative, FAQ e richieste negate non attivano la verifica. I campi delle credenziali visibili possono essere temporaneamente disabilitati: questo non elimina la sfida e non permette di compilarli o inviarli. La richiesta testuale passa al controllo manuale anche se il widget non è ancora visibile.

Per i CAPTCHA Cloudflare supportati, Metnos prova una sola volta la libreria locale playwright-captcha, nella stessa sessione e per non più di dieci secondi. Il tentativo rientra nei limiti del login, viene ricontrollato sulla pagina e non usa servizi a pagamento. Se la verifica resta aperta o non è supportata, come reCAPTCHA, Metnos chiede il tuo intervento.

Non è attivo un risolutore CAPTCHA automatico generale: il percorso comune offre rilevamento e intervento umano. Il tentativo locale Cloudflare resta separato dal supervisore proposto e può fallire. Il rilevamento o caricamento di una sfida non autorizza un clic automatico sulla checkbox. Il supervisore single/swarm e la gestione CAPTCHA generale tramite spin agent appartengono a fasi successive.

Il pannello mostra la pagina della sessione già aperta, con i campi sensibili oscurati. Puoi cliccare, scorrere, aggiornare l’immagine e premere Riprendi. Il broker conserva il passaggio manuale nella stessa sessione e continua la richiesta originale soltanto dopo un esito verificato con una nuova osservazione del sito. Un clic o una risposta del modello non provano il superamento; un’osservazione non disponibile non chiude la verifica. Se le credenziali erano già state inviate, controlla quel tentativo senza inviarle di nuovo. Il pannello scade dopo dieci minuti; annullarlo chiude la sessione. Verifiche che richiedono tastiera o audio non sono supportate da questo pannello.

La ripresa ha un nuovo identificativo collegato al turno sospeso e conserva utente, conversazione, risultati e allegati. Dopo l’invio del modulo, la pagina mostra l’attesa e recupera l’esito anche dopo una ricarica o una risposta persa, senza inviare nuovamente i valori. Se non può confermare il risultato, lo dichiara e non ripete automaticamente l’operazione.

Se non riesce

Dalla release 122: quando un comando web risulta coperto, il browser gestito conserva da solo una copia statica della pagina e le misure dell'ostacolo. Non serve eseguire script nella console. La copia esclude campi riservati e codice attivo; rimane locale, protetta come gli screenshot. Non viene acquisita durante consensi o verifiche di accesso in attesa e non certifica il flusso sul sito.

Se nessuna proposta viene ammessa, il ciclo è inconclusive. Se sono terminati i tentativi o il tempo disponibile, è exhausted. L'adattatore traduce poi questo esito nel contratto pubblico del proprio executor: può mantenere il risultato deterministico, restituire un errore tipizzato o chiedere l'intervento dell'utente. Il ciclo comune non inventa un risultato e non promette da solo una ripresa persistente.

Trasporto e intelligenza sono indipendenti. Un executor locale o remoto può essere diretto oppure intelligente. Il trasporto stabilisce come raggiungerlo; manifest, policy e codice stabiliscono che cosa può fare.