Agentes que manejan el ordenador: patrones que funcionan
Actualizado: 2026-05-03
Cuando Anthropic lanzó computer use en octubre de 2024, muchos equipos lo probamos una tarde, nos sorprendió ver a Claude mover el ratón y escribir en una hoja de cálculo, y luego lo archivamos como curiosidad tecnológica. Año y medio después, con computer use estabilizado en Claude 4.5, con browser-use convertido en biblioteca estándar para automatizar navegadores y con OpenAI Operator y Gemini Control cubriendo el espacio, los agentes que manejan el ordenador se han convertido en herramienta real. No para todo, pero sí para una franja de casos donde sustituyen macros RPA frágiles o scrapers que se rompen cada semana.
Puntos clave
- Un agente bien prompteado sobre interfaz conocida acierta entre el 70% y el 90% de ejecuciones; los cambios de diseño y los modales inesperados reducen esa tasa.
- Un flujo de diez minutos con computer use cuesta entre 50 céntimos y dos euros según modelo y resolución.
- El anti-patrón más caro: usar agentes para decisiones críticas irreversibles sin supervisión humana.
- La arquitectura mínima viable incluye capa de verificación y capa de persistencia de evidencia.
- El punto de inflexión para preferir integración API propia suele estar en ejecuciones diarias o superiores con tareas estables.
Qué ha cambiado desde 2024
El cambio material respecto a las primeras versiones es que los modelos ahora entienden interfaces gráficas con suficiente precisión para tareas de varios minutos sin intervención. Computer use en Claude 4.5 resuelve flujos de diez a quince pasos con éxito razonable cuando la interfaz es estándar. Browser-use ha madurado hasta ser biblioteca de producción con manejadores para fallos habituales, persistencia de sesión entre pasos y captura estructurada del DOM que el modelo puede consultar sin repintar la pantalla completa.
La fiabilidad ha mejorado mucho pero no es perfecta. En cuanto aparecen avisos modales inesperados, cambios de diseño o pantallas con mucha densidad visual, la tasa cae. Esto obliga a diseñar los flujos con puntos de verificación claros, capturas guardadas como evidencia y reintentos con contexto explícito sobre qué falló antes.
Patrones que sobreviven en producción
El scraper de interfaz humana es el primer patrón con valor consistente. Aplicaciones empresariales antiguas sin API, paneles SaaS con exportación pobre o sistemas propietarios donde la única forma de extraer datos es hacer clic y copiar. Un agente con browser-use recorre el flujo una vez al día y deja los datos en CSV o base de datos. Frente a un scraper con Selenium y selectores frágiles, es más caro por ejecución pero sobrevive mejor a rediseños menores porque entiende el propósito de cada pantalla.
La automatización de tareas administrativas de bajo volumen es el segundo patrón: rellenar formularios en portales de proveedores, subir archivos a plataformas con interfaz cambiante, reservar recursos en sistemas internos antiguos. Donde una macro RPA requiere mantenimiento cada dos meses, un agente absorbe variaciones pequeñas y sigue funcionando. El límite es el volumen: si haces la tarea cien veces al día, el coste del agente se dispara y sale más rentable una integración API propia.
El asistente de pruebas exploratorias para QA es el tercer patrón. En lugar de escribir tests end-to-end que rompen cada vez que cambia el DOM, un agente recibe un objetivo funcional y recorre la aplicación verificando que el flujo se completa, con capturas y descripciones del comportamiento. No reemplaza tests estables automatizados, pero cubre bien las áreas donde el equipo no llega o donde la interfaz cambia demasiado.
Anti-patrones que pagas caros
Tres anti-patrones están suficientemente documentados en 2026 como para evitarlos:
- Tareas de alto volumen o baja latencia. Si necesitas procesar miles de operaciones en minutos, el agente es demasiado lento y caro. Construye la integración API correcta.
- Decisiones críticas sin supervisión. Pagos, configuraciones de producción o cualquier acción irreversible. Los agentes aciertan casi siempre pero no el 100%, y el 1% en decisiones irreversibles destruye el caso de negocio. Ver también el tratamiento de este punto en gobernanza de agentes en empresa.
- Pretender que el agente sustituye juicio humano. Un agente rellena bien formularios estructurados; no evalúa si un contrato tiene cláusulas problemáticas o si un diseño es bueno. Confundir automatización de clicks con sustitución de razonamiento lleva a despliegues caros que acaban abandonados.
Arquitectura típica en 2026
Un despliegue razonable de agente de computer use tiene varias piezas:
- Una capa de orquestación que dispara el flujo con calendario o evento.
- Una capa de agente con contexto empaquetado.
- Una capa de verificación que comprueba que el resultado tiene sentido.
- Una capa de persistencia de evidencia con capturas y trazas del razonamiento.
Los equipos que saltan las capas de verificación y evidencia descubren rápido que cuando algo va mal no pueden explicar por qué ni reproducir el fallo.
# Patrón típico browser-use 2026
from browser_use import Agent
from anthropic import Anthropic
agent = Agent(
task="Descarga el reporte mensual del panel proveedor",
llm=Anthropic(model="claude-4.5-sonnet"),
max_steps=15,
save_screenshots=True,
on_step=lambda s: log_step(s),
)
result = agent.run()
verify_and_persist(result)
En producción añades reintentos sobre pasos fallidos, notificaciones a canal cuando el agente pide ayuda humana y un presupuesto máximo por ejecución para que un bucle mal gestionado no se coma el cupo mensual. Esta arquitectura de capas es análoga a lo que se documenta en lecciones de agentes en producción en 2025.
Coste real y cuándo sale rentable
La aritmética es bastante simple. Si un humano dedica dos horas semanales a una tarea repetitiva de interfaz, el coste anual ronda los cuatro mil euros en equipos con sueldos medianos españoles. Si el agente cuesta veinte euros al mes en tokens y tres horas iniciales de desarrollo, el retorno es en meses, no años. Si la tarea solo consume media hora semanal, probablemente no merece la pena automatizarla salvo que sea propensa a errores caros.
El punto de inflexión donde la integración API propia supera al agente suele estar en ejecuciones diarias o superiores con tareas estables. Si el sistema tiene API, aunque sea privada, y el equipo puede dedicar una semana a construirla, la integración es más barata de operar y más fiable. Si el sistema no tiene API y nunca la tendrá, el agente es la mejor opción disponible.
Mi lectura
En 2026, los agentes que manejan el ordenador han encontrado su nicho pragmático: tareas de bajo o medio volumen sobre sistemas sin API, automatización exploratoria de pruebas y sustitución de scrapers frágiles. Donde antes había macros RPA caras de mantener o trabajo humano repetitivo sin solución, ahora hay una opción intermedia razonable.
La decisión de adoptar un agente se parece a la de adoptar cualquier herramienta: mide el coste actual del problema, el coste de construir una solución adecuada y el coste de mantenerla. Lo que no tiene sentido es ni ignorar la herramienta por prejuicio contra la hype de 2024, ni desplegarla en todas partes porque se puede. El camino del medio es donde está el valor real.
