Agentes de IA en un escritorio remoto real: el Agent Runtime, en desarrollo.

Un agente que vive solo dentro de un navegador sin interfaz no puede abrir Final Cut, no puede arrastrar un archivo de video del Finder a una herramienta creativa, no puede firmar un PDF en Vista Previa, no puede ejecutar un instalador .dmg o .exe, no puede darle a otra app permiso de grabación de pantalla, no puede elegir un archivo con el selector de archivos del sistema y no puede sobrevivir a un cuadro de diálogo inesperado del sistema operativo. Son los momentos en los que vive la mayoría de los flujos de trabajo reales, y donde el agente de navegador sin interfaz falla en silencio.

Los contenedores virtualizados (el patrón de «computadora del agente» de los grandes laboratorios) cierran algunas de esas brechas, pero traen las suyas. La imagen suele ser un escritorio Linux mínimo con un puñado de apps preinstaladas; todo lo que queda fuera de ese conjunto es inalcanzable. El contenedor no tiene continuidad con el trabajo real del usuario: sus apps instaladas, sus cuentas con sesión iniciada, sus archivos guardados, sus permisos concedidos. Cada ejecución del agente parte de una máquina en blanco que no es la máquina del usuario.

El diseño de Remio toma el otro camino. Un agente conectado a través del runtime que estamos construyendo obtendría el escritorio real del usuario (el Mac, la PC o el equipo Linux en el que trabaja) mediante la misma sesión de escritorio remoto que una persona ya usa hoy. Estaría cada app que el usuario tiene instalada. Estaría cada cuenta en la que el usuario ha iniciado sesión. Estaría cada archivo. El agente no sería un inquilino de un entorno sintético; sería un invitado en la estación de trabajo real del usuario, mientras el usuario lo deje entrar, y ni un momento más.

Lo que se publica hoy es la transmisión en vivo: la pantalla del host, capturada de forma continua, codificada por hardware y entregada por el mismo canal cifrado que ya usa un cliente humano. Un agent runtime reutilizaría esa misma canalización para sus propias capturas fijas (un solo fotograma a pedido, o solo la región que un modelo ya sabe que debe mirar) en lugar de montar una segunda ruta de captura aparte. Esa reutilización es una decisión de diseño que ya tomamos, no una afirmación sobre lo que existe hoy.

Para agentes que razonan mejor sobre texto que sobre píxeles, el diseño esboza un modo de transcripción: el texto en pantalla devuelto con cuadros delimitadores, generado con el propio OCR de la plataforma (el framework Vision en macOS, la API de OCR de Windows en Windows) en lugar de un modelo de visión en el circuito. No se ha construido nada de esto. Está en la lista porque permitiría a un agente convertir una coincidencia de texto en un clic preciso sin enviar nunca un fotograma a su modelo: una ganancia real de eficiencia, si lo construimos bien.

Para el acceso estructurado de mayor fidelidad, el diseño también esboza una lectura del árbol de accesibilidad del sistema operativo para la ventana en primer plano, el mismo árbol que recorre un lector de pantalla: una jerarquía etiquetada de botones, campos de texto, menús y roles. Tampoco existe nada de esto todavía. Y en todas las versiones que esbozamos se mantiene la misma regla de la canalización de entrada: una sesión de agente vería exactamente lo que el permiso de grabación de pantalla del host ya permite ver a una sesión humana, nada más. Si ese permiso está desactivado para una pantalla, el agente no recibiría nada de esa pantalla, igual que hoy un cliente humano.

Cada sesión de Remio, sea de una persona o de un agente, empezaría de la misma manera: una persona escanea en Remio el código QR, o escribe el Device ID y el PIN, que se muestran en la pantalla del host. No hay ningún diseño en consideración en el que un agente cree su propia sesión, tenga un token que pueda renovar en silencio o extienda el acceso más allá del momento en que la persona que lo emparejó decida terminarlo. La siguiente ejecución del agente requeriría que la persona vuelva a emparejar: un nuevo momento con humano en el circuito, siempre, por diseño.

Mientras una sesión de agente esté activa, tanto el host como el cliente mostrarían un indicador permanente e inconfundible, y un control de Detener que termina la sesión de inmediato, al alcance de quien esté sentado frente al teclado del host, no solo de la persona que la inició. Cada acción del agente quedaría registrada en un registro de auditoría que la persona puede revisar. Nada de esto existe hoy en el código publicado; es el listón que el diseño debe superar.

El límite de permisos sigue la misma lógica que las secciones de entrada y pantalla de arriba: una sesión de agente heredaría exactamente los permisos a nivel del sistema operativo del host que ya respeta una sesión humana (Grabación de pantalla, Accesibilidad), nada más amplio. No recibiría una concesión elevada propia ni tendría un camino para ampliar el margen que la persona ya definió para la app Remio. Si una capacidad que estamos diseñando no cabe dentro de ese límite, no se publica.

La forma a la que siempre llegamos es deliberadamente pequeña: un par de primitivas para la entrada (un clic, una tecla), un par para la visión (un fotograma fijo, una región) y una para una lectura estructurada de la interfaz. Eso es el boceto, no una especificación: nada se ha publicado y la interfaz exacta sigue abierta. Lo que nos comprometemos a mantener ahora es la forma, no la sintaxis.

Ser independiente del modelo es un requisito de diseño, no una aspiración para más adelante. Lo que se publique funcionaría igual si el modelo que planifica el flujo de trabajo es Claude, GPT, Gemini o algo que ejecutes tú mismo. No lo estamos construyendo en torno al formato de llamada a herramientas de un solo proveedor, porque en el momento en que atamos el runtime a la interfaz de un modelo, habríamos hecho el tipo equivocado de promesa.

El runtime del escritorio y el runtime propio del agente son dos cosas distintas, y pensamos mantenerlas así. Remio sería lo que lleva las acciones de un agente a un escritorio real; el modelo, el ciclo de planificación y dónde se ejecuta quedarían totalmente en manos de quien construya el agente. No planeamos alojar modelos, medir su uso ni controlar el acceso a ellos nosotros mismos.

Remio no está pensado para un agente que solo necesita un navegador web: extraer datos de páginas, llenar formularios, leer paneles. Una sesión completa de escritorio remoto es más de lo que necesita una pestaña del navegador, y Remio no intenta competir en esa categoría.

Remio no está pensado para un agente que necesita decenas de entornos desechables: uno por tarea, con estado nuevo cada vez, en ejecución paralela. Remio se construye en torno a una sesión persistente emparejada por una persona, que es la forma opuesta: poca concurrencia, mucha continuidad, contexto real del usuario.

Si construimos el Agent Runtime tal como lo describe esta página, sería la respuesta correcta cuando el agente necesita un escritorio de sistema operativo real con apps nativas, el software que el usuario realmente tiene instalado, las cuentas y archivos reales del usuario y un límite de sesión con humano en el circuito. Agentes de accesibilidad que manejan un escritorio para una persona con discapacidad. Control de calidad asistido por IA en apps reales del sistema operativo. Flujos de trabajo con agentes que tienen que usar una herramienta nativa específica que el usuario ya posee. Cualquier tarea en la que «usa mi máquina de verdad, con todo lo que tiene, mientras yo superviso» sea el planteamiento natural. Para esos casos, una vez publicado, Remio sería el runtime.