Los agentes de uso informático están lejos de resolverse: el principal cuello de botella es la interfaz
Aunque los modelos de lenguaje avanzan a pasos agigantados en tareas de programación, su capacidad para manejar un ordenador como lo haría un ser humano sigue siendo extremadamente limitada. Los principales laboratorios de inteligencia artificial del mundo presentaron durante 2024 y 2025 prototipos de agentes capaces de operar interfaces gráficas, con resultados aparentemente espectaculares en pruebas como OSWorld, WebArena, AndroidWorld o WebVoyager, donde las tasas de acierto oscilaban entre el 60,76 % y el 97,4 %. Sin embargo, esos benchmarks presentaban entornos estáticos, representaciones textuales limpias y espacios de acción reducidos, muy alejados de la realidad.
Según Steelman Labs, en pruebas más exigentes como OSWorld-V2 el mejor modelo apenas alcanza un 20,6 % de finalización, mientras que en Agents' Last Exam la cifra apenas llega al 26,2 %. Esta brecha explica la frustración de numerosos usuarios, que esperan de estos sistemas un rendimiento parecido al de los chatbots y se encuentran, en cambio, con agentes poco fiables, lentos y costosos. En la práctica, continúa siendo más sencillo realizar la tarea uno mismo.
El análisis de Steelman Labs señala un problema de fondo: los agentes de uso informático suelen evitar la interfaz en lugar de utilizarla. En OSWorld-V2, los modelos más avanzados tienden a eludir el uso de la interfaz gráfica. Por ejemplo, en la tarea 052, dedicada a reservar una suite de hotel, GPT-5.5 inyectó JavaScript para leer el código fuente del sitio, localizar el endpoint interno de la API y enviar la reserva directamente mediante una petición POST. En la tarea 065, de compra de billetes de tren, tanto GPT-5.5 como Claude Opus omitieron la página web y realizaron la operación directamente sobre la API. Para combinar dos imágenes en GIMP, GPT-5.5 recurrió a un script en Python. En conjunto, la mayoría de las tareas no se resolvió mediante la interfaz como estaba previsto, sino sorteándola.
Este enfoque puede parecer ventajoso en algunos casos, ya que evita pasos intermedios, pero presenta serias limitaciones. Determinados trabajos solo pueden completarse a través de la interfaz, y utilizar la API por la espalda puede generar efectos colaterales imprevistos porque el software no fue diseñado para ese tipo de uso. Además, muchas tareas resultan mucho más sencillas mediante la propia interfaz: pulsar botones, rellenar formularios o navegar por un sitio web son acciones que una persona ejecuta sin pensar, mientras que revertir la API de un sitio, desensamblar su JavaScript o programar un compositor desde cero es significativamente más complejo que el clic al que sustituye.
Paradójicamente, los modelos de frontera no pueden permitirse esa sencillez. El benchmark WebGames lo demuestra: plantea tareas simples que requieren el tiempo de reacción y el control motor de un usuario medio, con una tasa de éxito humana superior al 95 %. Los modelos, en cambio, quedan muy por debajo, y esa brecha no se reduce por más parámetros o tokens que se les añada. Para tareas de horizonte largo, los modelos recurren a soluciones técnicamente complejas precisamente porque carecen de la capacidad de usar interfaces al nivel humano.
Esta limitación se traduce en una asignación de cómputo muy ineficiente. De acuerdo con la Figura 10 del paper de OSWorld 2.0, los agentes destinan la mayor parte de su presupuesto de acción a la percepción y la ejecución. El anclaje visual, la manipulación de bajo nivel y la sobrecarga de uso de herramientas dominan el cómputo, mientras que el razonamiento, la reflexión y la recuperación de errores reciben apenas los restos. Para Steelman Labs, esta es la cuestión central del uso informático agéntico: se están empleando modelos de razonamiento a escala de billones de parámetros para esquivar clics que una persona ejecuta de forma instintiva. Una manipulación adecuada permitiría a los agentes concentrar el esfuerzo en resolver la tarea, no en sortear las limitaciones de la interfaz, lo que se traduciría en mayor velocidad, menor consumo de tokens, más fiabilidad y mejor rendimiento en horizontes largos.
Hasta ahora, todas las soluciones se han construido sobre el bucle captura-herramienta: obtener una captura de pantalla y una representación textual del entorno, hacer que el modelo razone sobre ellas, generar una llamada a una herramienta como click(elemento[#enviar]) y repetir. Esta arquitectura, señalan desde Steelman Labs, es una extensión natural del bucle ReAct de los agentes de código, pero choca con una dificultad básica: las acciones triviales de interfaz siguen siendo complicadas para estos agentes porque recurren al mismo modelo grande para todo. El resultado es un agente demasiado dependiente del texto, incapaz de captar la información temporal y de reaccionar con la rapidez necesaria, un enfoque que contradice las propias suposiciones con las que las interfaces están diseñadas.
Añadir más parámetros y más tokens no resolverá el problema, y ni siquiera acelerar la ejecución de ese bucle serviría, porque solo lograría llenar más rápido el contexto del modelo. Para construir agentes de uso informático realmente útiles es preciso cuestionar las bases del diseño actual.
En esa dirección trabaja Steelman Labs, compañía que propone separar la planificación de la ejecución e introducir un Sistema 1 para los agentes: un manipulador dedicado al control motor, con un enfoque prioritariamente visual, que trate la pantalla como un entorno dinámico y aspire a tiempos de reacción comparables a los humanos. Su principio rector es claro: un agente de uso informático debe poder manejar cualquier interfaz que pueda manejar una persona. Hasta que esa condición no se cumpla, la promesa de los agentes capaces de presentar impuestos, corregir documentos o probar sitios web seguirá siendo, por ahora, una aspiración incompleta.