Prontos para agentes — este é o runtime que estamos projetando.

Um agente que vive só dentro de um navegador sem interface não consegue abrir o Final Cut, não consegue arrastar um arquivo de vídeo do Finder para uma ferramenta criativa, não consegue assinar um PDF no Preview, não consegue executar um instalador .dmg ou .exe, não consegue conceder a outro app a permissão de gravação de tela, não consegue escolher um arquivo no seletor de arquivos do sistema e não sobrevive a uma janela modal inesperada do SO. São esses os momentos em que a maioria dos fluxos de trabalho reais de fato acontece — e onde o agente de navegador sem interface falha em silêncio.

Contêineres virtualizados (o padrão de “computador do agente” dos grandes laboratórios) resolvem algumas dessas lacunas, mas trazem as suas. A imagem costuma ser um desktop Linux mínimo com meia dúzia de apps pré-instalados; tudo que estiver fora dessa pegada fica inacessível. O contêiner não tem nenhuma continuidade com o trabalho real do usuário — seus apps instalados, suas contas conectadas, seus arquivos salvos, suas permissões concedidas. Cada execução do agente começa numa máquina em branco que não é a máquina do usuário.

O projeto do Remio segue o outro caminho. Um agente conectado pelo runtime que estamos construindo receberia a área de trabalho real do usuário — o Mac, PC ou Linux de verdade em que ele trabalha — pela mesma sessão de área de trabalho remota que uma pessoa já usa hoje. Todos os apps instalados pelo usuário estariam lá. Todas as contas em que ele está conectado estariam lá. Todos os arquivos estariam lá. O agente não seria inquilino de um ambiente sintético; seria um convidado na estação de trabalho real do usuário, pelo tempo que o usuário deixar — e nem um instante a mais.

O que existe hoje é a transmissão ao vivo: a tela do host, capturada continuamente, codificada em hardware e entregue pelo mesmo canal criptografado que um cliente humano já usa. Um runtime de agente reutilizaria esse mesmo pipeline para as próprias capturas estáticas — um único quadro sob demanda, ou apenas a região que um modelo já sabe onde olhar — em vez de montar um segundo caminho de captura separado. Esse reaproveitamento é uma escolha de projeto que já fechamos, não uma afirmação sobre o que existe hoje.

Para agentes que raciocinam melhor sobre texto do que sobre pixels, o projeto esboça um modo de transcrição: o texto da tela devolvido com caixas delimitadoras, gerado pelo OCR da própria plataforma (framework Vision no macOS, API de OCR do Windows no Windows) em vez de um modelo de visão no meio do caminho. Nada disso foi construído. Está na lista porque permitiria a um agente transformar uma correspondência de texto em um clique preciso sem nunca enviar um quadro ao seu modelo — um ganho real de eficiência, se o construirmos bem.

Para o acesso estruturado de maior fidelidade, o projeto também esboça a leitura da árvore de acessibilidade do SO para a janela em foco — a mesma árvore que um leitor de tela percorre: uma hierarquia nomeada de botões, campos de texto, menus e papéis. Nada disso existe ainda também. E em todas as versões que estamos esboçando vale a mesma regra do pipeline de entrada: uma sessão de agente veria exatamente o que a permissão de gravação de tela do host já permite que uma sessão humana veja, e nada além. Se essa permissão estiver desativada para uma tela, o agente não receberia nada dessa tela — como acontece hoje com um cliente humano.

Toda sessão do Remio — de pessoa ou de agente — começaria do mesmo jeito: uma pessoa lendo um código de seis dígitos na tela do host e digitando-o no cliente. Não há nenhum desenho em consideração em que um agente crie a própria sessão, guarde um token que possa renovar em silêncio ou estenda o acesso além do momento em que a pessoa que o pareou decide encerrá-lo. A execução seguinte do agente exigiria que a pessoa pareasse de novo — um novo momento com humano no circuito, toda vez, por projeto.

Enquanto uma sessão de agente estiver ativa, tanto o host quanto o cliente mostrariam um indicador permanente e inconfundível — e um controle Parar que encerra a sessão imediatamente, ao alcance de quem estiver diante do teclado do host, e não apenas de quem a iniciou. Cada ação do agente seria gravada em um registro de auditoria que a pessoa pode revisar. Nada disso existe no código lançado hoje; é a barra que o projeto precisa superar.

A fronteira de permissões segue a mesma lógica das seções de entrada e tela acima: uma sessão de agente herdaria exatamente as permissões de nível de SO do host que uma sessão humana já respeita — Gravação de Tela, Acessibilidade — nada além. Ela não receberia uma concessão elevada própria e não teria caminho para ampliar o limite que a pessoa já definiu para o app Remio. Se um recurso que estamos projetando não couber dentro dessa fronteira, ele não é lançado.

A forma a que sempre chegamos é intencionalmente pequena: duas primitivas de entrada (um clique, uma tecla), duas de visão (um quadro estático, uma região) e uma de leitura estruturada da interface. Isso é o esboço, não uma especificação — nada foi lançado e a interface exata ainda está em aberto. O que prometemos agora é a forma, não a sintaxe.

Ser agnóstico quanto ao modelo é um requisito do projeto, não uma aspiração que deixaremos para depois. O que for lançado funcionaria da mesma maneira, seja o modelo que planeja o fluxo de trabalho o Claude, o GPT, o Gemini ou algo que você mesmo executa. Não estamos construindo isso em torno do formato de chamada de ferramentas de um único fornecedor, porque, no momento em que amarramos o runtime à interface de um modelo, fizemos o tipo errado de promessa.

O runtime da área de trabalho e o runtime do próprio agente são duas coisas diferentes, e pretendemos mantê-las assim. O Remio seria o que leva as ações de um agente a uma área de trabalho real; o modelo, o ciclo de planejamento e o lugar onde ele roda continuariam inteiramente por conta de quem constrói o agente. Não planejamos hospedar modelos, medir seu uso nem controlar o acesso a eles.

O Remio não foi feito para um agente que só precisa de um navegador — coletar dados de páginas, preencher formulários, ler painéis. Uma sessão inteira de área de trabalho remota é mais do que uma aba de navegador precisa, e o Remio não está tentando competir nessa categoria.

O Remio não foi feito para um agente que precisa de dezenas de ambientes descartáveis — um por tarefa, estado novo a cada vez, execução em paralelo. O Remio é construído em torno de uma sessão persistente pareada por uma pessoa, que é o formato oposto: pouca concorrência, muita continuidade, contexto real do usuário.

Se construirmos o Agent Runtime do jeito que esta página descreve, ele seria a resposta certa quando o agente precisa de uma área de trabalho de SO real com apps nativos, o software que o usuário realmente tem instalado, as contas e os arquivos reais do usuário e um limite de sessão com humano no circuito. Agentes de acessibilidade operando uma área de trabalho para um usuário com deficiência. Testes de QA assistidos por IA em apps reais do SO. Fluxos agênticos que precisam usar uma ferramenta nativa específica que o usuário já possui. Qualquer tarefa em que “use a minha máquina de verdade, com tudo o que há nela, enquanto eu supervisiono” seja o enquadramento natural. Para esses casos, quando for lançado, o Remio seria o runtime.