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.
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.
El coste sigue siendo tema central. Un agente que hace clic en quince elementos de una interfaz web consume capturas de pantalla y tokens de razonamiento en cada paso. En 2026, un flujo de diez minutos con computer use cuesta entre cincuenta céntimos y dos euros según modelo y resolución. Esto descarta automatizar tareas de segundos que un script o macro resuelven mejor, pero lo hace competitivo para tareas de minutos donde mantener un scraper clásico cuesta horas humanas cada semana.
La fiabilidad ha mejorado mucho pero no es perfecta. Un agente bien prompteado sobre interfaz conocida acierta entre el setenta y el noventa por ciento de ejecuciones; 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 primer patrón que ha demostrado valor consistente es el scraper de interfaz humana. 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.
El segundo patrón es la automatización de tareas administrativas de bajo volumen: 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 tercer patrón es el asistente de pruebas exploratorias para QA. 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.
Anti-patrones que pagas caros
Hay tres anti-patrones que en 2026 ya están documentados suficiente como para evitarlos. El primero es usar agentes para tareas de alto volumen o baja latencia: si necesitas procesar miles de operaciones en minutos, el agente es demasiado lento y caro. El segundo es delegar decisiones críticas sin supervisión: pagos, configuraciones de producción o cualquier acción irreversible. Los agentes aciertan casi siempre pero no el cien por cien, y el uno por ciento en decisiones irreversibles destruye el caso de negocio.
El tercer anti-patrón es pretender que el agente sustituya juicio humano. Un agente rellena bien formularios estructurados; no evalúa si un contrato tiene cláusulas problemáticas, si un candidato encaja con la cultura 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 en 2026 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 y 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)Este esqueleto es el mínimo razonable. 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.
Coste real y cuándo sale rentable
La aritmética que hacemos hoy 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. El error común es asumir que el agente siempre es más barato; no lo es cuando el volumen sube.
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. Si el agente ahorra más de lo que cuesta operarlo, adelante con las capas de verificación y evidencia bien montadas. Si no, seguramente lo que necesitas es una integración API o aceptar que esa tarea se hace a mano. Lo que no tiene sentido en 2026 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.
