Agentes de computer use: cómo evaluar automatización desktop

Un agente de computer use puede leer una pantalla, ubicar controles y operar mouse y teclado. Esa capacidad abre sistemas legacy, aplicaciones internas y herramientas de escritorio que no exponen API, CLI ni integración MCP. También cambia la unidad de riesgo: una llamada estructurada suele declarar operación y parámetros; una interfaz gráfica obliga al agente a inferir el estado visible, elegir un control y comprobar si la pantalla posterior significa éxito. Un clic correcto sobre una pantalla equivocada sigue siendo un fallo.

GitHub anunció el 1 de octubre de 2026 la vista previa pública de computer use en GitHub Copilot CLI y la app de Copilot para macOS y Windows. Puede leer contenido accesible y contexto visual, hacer clic, escribir, desplazarse, arrastrar y recorrer workflows entre aplicaciones. La novedad llegó un día calendario antes de este artículo en Lima. Es una expansión importante de superficie, no evidencia de que cualquier proceso desktop ya sea confiable o deba ejecutarse sin supervisión.

El loop útil no es «mirar y hacer clic», sino observar un estado, proponer una acción acotada, ejecutarla y leer el estado resultante. La observación puede combinar el árbol de accesibilidad del sistema operativo con capturas cuando falta contexto visual. La acción puede ser un clic, una entrada de texto, una tecla, un scroll o un drag. Cada paso modifica la evidencia disponible: aparece un modal, cambia el foco, tarda una carga o una notificación cubre el botón esperado. Por eso el agente necesita revalidar sus precondiciones después de cada transición relevante.

La documentación de GitHub recomienda una frontera clara: si una API, un servidor MCP, un comando, una herramienta de archivos o un navegador dedicado puede resolver la tarea directamente, normalmente ofrece información más estructurada y resultados más predecibles. Computer use debería ser el adaptador de último tramo para la parte realmente visual, no la capa universal de integración. Una arquitectura híbrida puede consultar datos por API, usar la GUI solo para una operación no expuesta y volver a una verificación estructurada al final.

Antes del piloto, describe el proceso como un contrato verificable: estado inicial permitido, aplicaciones involucradas, datos de entrada, acciones autorizadas, estados terminales, timeout y condiciones que obligan a detenerse. Separa lectura, preparación y efecto. «Procesa esta factura» es ambiguo; «lee la factura, busca un proveedor exacto, crea un borrador y detente antes de enviar» fija una frontera. También declara qué información nunca debe aparecer en capturas o pasar entre aplicaciones, y qué roles pueden aprobar el siguiente tramo.

Mapea cada tramo al mecanismo menos frágil. Si el proveedor puede consultarse por API, no lo busques con veinte clics. Si el formulario final solo existe en una aplicación Windows, limita computer use a esa pantalla y entrega datos ya validados. La cobertura GUI no debe medirse por cantidad de pantallas automatizadas, sino por cuánto proceso inevitablemente visual queda bajo control. Esta decisión reduce exposición a cambios de layout, contexto sensible y estados que el agente debe interpretar.

Construye una máquina de estados observables para el workflow. En cada nodo define señales positivas, señales incompatibles y la acción permitida. Un botón con el texto esperado no basta si pertenece a otra ventana; combina título de aplicación, encabezado, entidad seleccionada, campos visibles y ausencia de modal bloqueante. Prefiere controles accesibles con nombre, rol y estado. Cuando el agente dependa de píxeles, añade variaciones de resolución, escala, tema, idioma y posición de ventana a la evaluación.

Prueba perturbaciones deliberadas: una sesión expirada, un banner superpuesto, datos ordenados de otra manera, un campo deshabilitado, un doble clic accidentalmente repetible y una carga lenta. GitHub advierte que cambios de versión, sistema operativo, estado de ventana y timing pueden llevar al control equivocado, repetir una acción o impedir la continuación. El resultado esperado en muchos casos no es «seguir intentando», sino identificar el estado desconocido, conservar evidencia y pedir intervención.

Clasifica acciones por impacto antes de decidir permisos. Navegar y abrir un registro suele ser lectura; editar un borrador modifica datos pero permite revisión; enviar un pago, publicar, borrar o comunicar a otra persona produce un efecto material. Los checkpoints deben ubicarse justo antes del efecto, mostrando objeto, destino y cambio propuesto, no al inicio de toda la sesión. Una aprobación antigua o genérica no debe cubrir una acción cuyo contexto cambió cinco pantallas después.

GitHub indica que computer use está desactivado por defecto, respeta la configuración de permisos de la superficie y permite negar, aprobar por sesión o guardar acceso por aplicación. Las reglas de denegación prevalecen sobre aprobaciones automáticas o guardadas, y una política administrada puede deshabilitar la función. Trata «Always allow» como una excepción para aplicaciones de bajo impacto: no como un atajo de UX para correo, finanzas, identidad o sistemas con datos de terceros. Documenta además cómo detener una operación activa.

Una interfaz rara vez entrega una semántica transaccional clara. Después de un timeout, el agente puede no saber si el botón produjo un registro o si la respuesta aún carga. Repetir por defecto duplica facturas, mensajes o solicitudes. Añade una clave externa, un identificador visible o una consulta estructurada que permita reconciliar el efecto antes de reintentar. Si no existe, define un estado «resultado incierto» que bloquee nuevas acciones hasta que una persona o un verificador independiente confirme qué ocurrió.

El ejemplo siguiente es hipotético. Un agente recibe una factura, extrae proveedor e importe con una herramienta estructurada, abre un ERP desktop y prepara un borrador. Antes de guardar, verifica proveedor, moneda, centro de costo y hash del documento; después de guardar, lee el ID asignado mediante una consulta de auditoría. Si aparece un modal desconocido o el ID no coincide, detiene el flujo y entrega captura, último estado válido y acción pendiente. Nunca pulsa «Pagar» porque ese paso pertenece a un aprobador humano separado.

Un eval serio necesita tres capas. Primero, aceptación del resultado: campos correctos, registro único y estado terminal esperado. Segundo, trayectoria: aplicaciones abiertas, controles usados, reintentos, tiempo, approvals y divergencias respecto del camino permitido. Tercero, seguridad: exposición de datos, intentos fuera de alcance y acciones materiales bloqueadas. El éxito no es llegar al final de una demo; es completar el caso correcto y detenerse correctamente en los casos que no deben continuar.

Crea un set versionado con tareas normales, bordes y ataques de contenido. Incluye instrucciones ambiguas, texto visible que intenta redirigir al agente, ventanas con información sensible, controles duplicados y datos que exigen rechazo. Ejecuta repeticiones porque el estado visual y el timing introducen variabilidad. Reporta tasa de aceptación completa, paradas seguras, falsas confirmaciones, acciones duplicadas, intervención humana y latencia por clase de caso. No combines todo en un promedio que oculte un solo efecto grave.

Las capturas y árboles de accesibilidad pueden incluir información de otras personas o aplicaciones. Usa una cuenta y un escritorio dedicados al piloto, datos sintéticos o enmascarados, lista explícita de aplicaciones y mínimos permisos de archivos, red y credenciales. No asumas que un sandbox de comandos limita también lo que una aplicación autorizada puede mostrar o hacer. GitHub describe el sandbox local como una política por proyecto para filesystem, red y credenciales, y aclara que puede ser más restrictiva bajo administración empresarial; computer use requiere además sus propios permisos.

Empieza en shadow mode: el agente propone estados y acciones sin ejecutarlas. Luego habilita lectura, después preparación reversible y finalmente un efecto acotado con aprobación. Revisa ejemplos de fallo, no solo métricas agregadas, y vuelve a certificar cuando cambien la aplicación, el sistema operativo, el modelo o las políticas. La condición de salida de la preview no es «funcionó varias veces», sino que puedes explicar qué observó, qué autorizó cada acción, cómo detectó el resultado y cómo falló sin ampliar el daño.

Computer use importa porque incorpora software sin integración al alcance de los agentes. Precisamente por eso conviene mantenerlo estrecho: elige procesos con valor claro, efectos reconciliables y estados observables; conserva API y herramientas estructuradas para el resto. Evita como primer caso pagos, borrado, credenciales, mensajería externa o workflows donde una captura expone datos que el agente no necesita. La interfaz visual es una capa de compatibilidad potente, no una garantía transaccional.

Los cinco gates —contrato, estados, impacto, recuperación y evaluación— convierten una demo visual en una decisión de ingeniería. Si el proceso no puede declarar su estado, confirmar su efecto o detenerse sin repetirlo, todavía no está listo para autonomía. Si necesitas diseñar un piloto con herramientas estructuradas, computer use acotado, permisos y trazas, el servicio de agentes a medida de Wasyra puede ayudar a construir esa capa. Es un servicio de implementación separado del producto disponible en agents.wasyra.com.