Agenti AI su un vero desktop remoto — l'Agent Runtime, in sviluppo.
L'Agent Runtime è in sviluppo: non esiste ancora un SDK per agenti. Ciò che esiste già è il motivo per cui vale la pena costruirlo: la pipeline nativa di input e cattura dello schermo di Remio funziona già oggi per una persona seduta davanti a un vero Mac, PC o computer Linux. Questa pagina è il progetto onesto di ciò che verrà dopo, e dei paletti che ci impegniamo a rispettare prima che qualsiasi parte venga rilasciata.
Perché gli agenti hanno bisogno di uno schermo reale.
Una sandbox del browser va bene per un agente che compila solo moduli web. Nel momento in cui il lavoro passa alle app native, la sandbox non basta più. Un vero desktop è il runtime più pulito per un agente: ciò che usa una persona, può usarlo anche un agente.
Un agente che vive solo in un browser headless non può aprire Final Cut, non può trascinare un file video dal Finder in uno strumento creativo, non può firmare un PDF in Anteprima, non può eseguire un installer .dmg o .exe, non può concedere a un'altra app il permesso di registrare lo schermo, non può scegliere un file con il selettore di file di sistema e non può sopravvivere a una finestra di dialogo inattesa del sistema operativo. Sono i momenti in cui vive la maggior parte dei flussi di lavoro reali, e dove l'agente nel browser headless fallisce in silenzio.
I container virtualizzati (il modello del "computer per agenti" dei grandi laboratori) colmano alcune di queste lacune, ma ne portano di proprie. L'immagine è di solito un desktop Linux minimale con una manciata di app preinstallate; tutto ciò che sta fuori da quel perimetro è irraggiungibile. Il container non ha continuità con il lavoro reale dell'utente: le sue app installate, i suoi account connessi, i suoi file salvati, i permessi concessi. Ogni esecuzione dell'agente parte da una macchina vuota che non è la macchina dell'utente.
Il progetto di Remio prende l'altra strada. Un agente connesso tramite il runtime che stiamo costruendo avrebbe il vero desktop dell'utente — il Mac, il PC o il computer Linux su cui lavora davvero — attraverso la stessa sessione di desktop remoto che una persona usa già oggi. Ci sarebbero tutte le app installate dall'utente. Ci sarebbero tutti gli account a cui l'utente è connesso. Ci sarebbero tutti i file. L'agente non sarebbe un inquilino di un ambiente sintetico, ma un ospite sulla vera postazione di lavoro dell'utente, per tutto il tempo in cui l'utente lo lascia entrare e non un attimo di più.
La pipeline che userebbe un agente: già in funzione, per le persone.
Ogni clic, pressione di tasto e scorrimento che un utente Remio invia oggi arriva sull'host attraverso il sottosistema di input nativo del sistema operativo: lo stesso identico evento che genererebbero un mouse o una tastiera fisici. Quella pipeline non è ipotetica: è ciò che fa funzionare Remio per una persona adesso, su un vero Mac, PC o computer Linux. Ed è anche, non a caso, esattamente la base su cui si innesterebbe un agent runtime: nessuna API separata rivolta agli agenti, nessuna pressione di tasto sintetica iniettata nella coda eventi di una finestra, nessuno strato di accessibilità al posto di un vero clic.
L'impegno di progetto: se verrà rilasciato, l'input di un agente sarebbe indistinguibile da quello di una persona sull'host, perché userebbe la stessa identica pipeline, non una parallela costruita solo per gli agenti.
Questo conta più di quanto sembri, ed è il motivo per cui pensiamo che l'architettura di Remio sia davvero un buon punto di partenza per un agent runtime, e non solo uno comodo. Le piattaforme per agenti che simulano l'input a livello applicativo — pressioni di tasto sintetiche nella coda eventi di una finestra, o API di accessibilità che pilotano direttamente gli elementi dell'interfaccia — incontrano limiti continuamente: i campi protetti rifiutano l'input, le scorciatoie native non funzionano, il trascinamento tra app non va, la gestione del focus si confonde. Passare dalla pipeline di input a livello di sistema operativo aggira già tutto questo, per le sessioni umane attive oggi. Estenderla alle sessioni degli agenti è un lavoro di progettazione che dobbiamo ancora fare, ma la base che svolge la parte difficile è già in uso.
Per progetto, il confine dei privilegi resterebbe invariato. I permessi di Accessibilità e Monitoraggio input dell'host, concessi una volta da una persona all'app Remio Host, controllano già ogni evento di input inviato da una sessione umana. L'impegno di progetto è che una sessione di agente sarebbe controllata da quella stessa identica concessione: nessun permesso separato che un agente possa detenere da solo, nessuna porta più ampia di quella che la persona ha già aperto per l'app.
L'accesso allo schermo e il progetto di come lo userebbe un agente.
La pipeline di cattura dello schermo di Remio trasmette già oggi una vista in diretta dell'host a un client umano: fotogrammi completi, codificati in hardware, in tempo reale. Un agent runtime avrebbe bisogno di qualche altra forma degli stessi dati: una cattura statica su richiesta, una regione più piccola, una lettura strutturata di ciò che è sullo schermo. Nessuna di queste forme aggiuntive esiste ancora nel codice rilasciato.
Ciò che esiste oggi è lo stream in diretta: lo schermo dell'host, catturato in continuazione, codificato in hardware e consegnato sullo stesso canale cifrato che un client umano usa già. Un agent runtime riutilizzerebbe quella stessa pipeline per le proprie catture statiche — un singolo fotogramma su richiesta, o solo la regione in cui un modello sa già di dover guardare — invece di mettere in piedi un secondo percorso di cattura separato. Questo riutilizzo è una scelta di progetto che abbiamo fatto, non un'affermazione su ciò che esiste oggi.
Per gli agenti che ragionano meglio sul testo che sui pixel, il progetto abbozza una modalità trascrizione: il testo a schermo restituito con i riquadri di delimitazione, generato con l'OCR della piattaforma (framework Vision su macOS, API OCR di Windows su Windows) anziché con un modello di visione nel ciclo. Nulla di questo è stato costruito. È in elenco perché permetterebbe a un agente di trasformare una corrispondenza di testo in un clic preciso senza mai inviare un fotogramma al proprio modello: un vero guadagno di efficienza, se lo costruiamo bene.
Per l'accesso strutturato alla massima fedeltà, il progetto abbozza anche una lettura dell'albero di accessibilità del sistema operativo per la finestra in primo piano: lo stesso albero che percorre uno screen reader, una gerarchia etichettata di pulsanti, campi di testo, menu e ruoli. Neanche questo esiste ancora. E in ogni versione che stiamo abbozzando vale la stessa regola della pipeline di input: una sessione di agente vedrebbe esattamente ciò che il permesso di registrazione dello schermo dell'host consente già a una sessione umana di vedere, non di più. Se quel permesso è disattivato per un display, un agente non riceverebbe nulla da quel display, proprio come un client umano oggi.
I paletti che ci impegniamo a rispettare prima di scrivere il codice dell'agente.
Non sono funzioni da costruire più avanti sperando di farle bene. Sono i vincoli che l'intero progetto dell'Agent Runtime deve soddisfare prima che qualsiasi parte venga rilasciata: decisi ora, quando non c'è ancora codice intorno a cui progettare.
Ogni sessione Remio — di una persona o di un agente — inizierebbe allo stesso modo: una persona che inquadra il codice QR, o digita in Remio il Device ID e il PIN, mostrati sullo schermo dell'host. Non c'è nessun progetto allo studio in cui un agente crei da solo la propria sessione, detenga un token che può rinnovare in silenzio o prolunghi l'accesso oltre il momento in cui la persona che lo ha abbinato decide di chiuderlo. Per la sessione successiva dell'agente la persona dovrebbe abbinare di nuovo: un nuovo momento con la persona nel ciclo, ogni volta, per progetto.
Mentre una sessione di agente è attiva, sia l'host sia il client mostrerebbero un indicatore persistente e inequivocabile, e un comando Interrompi che termina subito la sessione, raggiungibile da chiunque sia seduto alla tastiera dell'host, non solo da chi l'ha avviata. Ogni azione compiuta dall'agente verrebbe scritta in un registro di controllo che la persona può rivedere. Nulla di questo esiste oggi nel codice rilasciato: è l'asticella che il progetto deve superare.
Il confine dei permessi segue la stessa logica delle sezioni su input e schermo qui sopra: una sessione di agente erediterebbe esattamente i permessi a livello di sistema operativo dell'host che una sessione umana già rispetta — Registrazione schermo, Accessibilità — niente di più ampio. Non otterrebbe una concessione elevata propria e non avrebbe modo di allargare il perimetro che la persona ha già impostato per l'app Remio. Se una funzione che stiamo progettando non entra in quel confine, non viene rilasciata.
Ancora nessun SDK: ecco la forma verso cui stiamo progettando.
Remio non ha pubblicato un SDK per agenti, una superficie API né una specifica di connessione per gli agenti. Abbiamo invece un breve elenco di capacità primitive a cui il progetto continua a tornare — input, accesso allo schermo, letture strutturate dell'interfaccia — e l'impegno che ciò che verrà rilasciato sarà indipendente dal modello fin dal primo giorno.
La forma a cui arriviamo di continuo è volutamente piccola: un paio di primitive per l'input (un clic, un tasto), un paio per la vista (un fotogramma statico, una regione), una per una lettura strutturata dell'interfaccia. Questo è lo schizzo, non una specifica: nulla è stato rilasciato e l'interfaccia esatta è ancora aperta. Ciò a cui ci impegniamo ora è la forma, non la sintassi.
L'indipendenza dal modello è un requisito di progetto, non un'aspirazione a cui arriveremo più avanti. Ciò che verrà rilasciato funzionerebbe allo stesso modo sia che il modello che pianifica il flusso di lavoro sia Claude, GPT, Gemini o qualcosa che esegui tu stesso. Non stiamo costruendo tutto intorno al formato di tool calling di un solo fornitore, perché nel momento in cui leghiamo il runtime all'interfaccia di un solo modello, abbiamo fatto il tipo sbagliato di promessa.
Il runtime del desktop e il runtime dell'agente sono due cose diverse, e intendiamo mantenerle tali. Remio sarebbe ciò che porta le azioni di un agente su un vero desktop; il modello, il ciclo di pianificazione e il luogo in cui gira resterebbero interamente a chi costruisce l'agente. Non abbiamo intenzione di ospitare i modelli, misurarne l'uso o controllarne l'accesso.
Per cosa questo progetto non è pensato.
Un runtime su un vero desktop sarebbe la forma giusta per alcuni flussi di lavoro con agenti e quella sbagliata per altri. Ecco il taglio breve e onesto, ancora prima che qualsiasi parte venga rilasciata.
Remio non è pensato per un agente che ha bisogno solo di un browser web — estrarre dati dalle pagine, compilare moduli, leggere dashboard. Un'intera sessione di desktop remoto è più di quanto serva a una scheda del browser, e Remio non cerca di competere in quella categoria.
Remio non è pensato per un agente che ha bisogno di decine di ambienti usa e getta — uno per attività, stato nuovo ogni volta, esecuzione in parallelo. Remio è costruito intorno a una sessione persistente abbinata da una persona, che è la forma opposta: poca concorrenza, molta continuità, contesto reale dell'utente.
Se costruiremo l'Agent Runtime come descrive questa pagina, sarebbe la risposta giusta quando l'agente ha bisogno di un vero desktop del sistema operativo con app native, il software effettivamente installato dall'utente, i suoi veri account e file, e un confine di sessione con la persona nel ciclo. Agenti di accessibilità che pilotano un desktop per un utente con disabilità. QA assistito dall'AI su vere app del sistema operativo. Flussi agentici che devono usare uno specifico strumento nativo che l'utente possiede già. Qualsiasi attività in cui "usa la mia macchina vera, con tutto ciò che c'è sopra, mentre io supervisiono" è l'impostazione naturale. Per questi casi, una volta rilasciato, Remio sarebbe il runtime.
Domande frequenti sull'Agent Runtime che stiamo progettando.
Cinque domande che questo progetto tende a sollevare, con risposte oneste qui sotto, comprese quelle in cui la risposta onesta è "non ancora".
Posso usare Claude, GPT o un altro agente AI per controllare il mio computer tramite Remio oggi?
Un agente potrebbe avviare da solo una sessione Remio, senza una persona?
Come farebbe l'host a sapere che è connesso un agente e non una persona?
Un agente potrebbe vedere o raggiungere più di quanto già possa una sessione umana?
Quali modelli AI funzionerebbero con l'Agent Runtime di Remio?
Reale oggi: un desktop veloce e privato per te. In arrivo: lo stesso desktop per i tuoi agenti AI.
Installa Remio per il modo più veloce e privato di raggiungere il tuo Mac, PC o computer Linux: input nativo, accesso nativo allo schermo, cifratura end-to-end, nessun account richiesto. L'Agent Runtime descritto in questa pagina non è stato rilasciato e non promettiamo una data, ma la stessa architettura è esattamente il motivo per cui pensiamo che valga la pena costruirlo.