Por qué la memoria de trabajo de tu agente de IA falla en tareas largas

Cuando se le pide a un agente de IA que abra una hoja de cálculo, extraiga datos, actualice un gráfico y envíe el resultado por correo electrónico, el enfoque típico es alimentarlo con un registro creciente de capturas de pantalla, clics del mouse y respuestas del sistema. A medida que la tarea se extiende a lo largo de docenas de pasos, ese historial sin procesar se convierte en un pantano. La información crítica (una ruta de archivo, una edición verificada, una URL) queda enterrada bajo intentos fallidos y observaciones obsoletas.

Ese es el problema que los investigadores de UC San Diego y Aether AI Lab se propusieron resolver con StructAgent, un marco cuya idea central suena casi paradójica: para hacer que los agentes sean más confiables en tareas largas, dales menos contexto. Pero el contexto que conserva debe estar estructurado, verificado y vinculado causalmente con lo que realmente avanza en la tarea.

En experimentos reportados en un nuevo artículo, StructAgent mejoró la tasa de éxito de un modelo de 9 mil millones de parámetros del 27,0 % al 46,9 % en OSWorld-Verified, un punto de referencia para el uso de computadoras de horizonte largo. Con un núcleo más fuerte de 27 mil millones de parámetros, saltó del 31,6 % al 62,2 %. Usando el modelo MiniMax-M3, alcanzó el 78,9 %, un nuevo estado del arte para métodos de código abierto en ese punto de referencia.

Los autores citan a Edsger Dijkstra: “El propósito de la abstracción no es ser vago, sino crear un nuevo nivel semántico en el que se pueda ser absolutamente preciso”. El artículo se lee como un argumento extendido de ese principio aplicado al diseño de agentes.

El problema del historial sin procesar

Los agentes digitales actuales, ya sean impulsados por LLM o VLM, típicamente consumen el historial de interacción como una secuencia plana: capturas de pantalla, árboles de accesibilidad, resultados de acciones. A lo largo de muchos pasos, ese contexto crece para incluir ediciones intermedias, intentos fallidos y finalizaciones parciales. El agente no tiene una manera fundamentada de separar lo que importa de lo que no.

StructAgent reemplaza esto con un estado unificado que contiene tres componentes tipados: requisitos actuales, valores útiles (rutas de archivo, URL, datos extraídos) y evidencia verificada. En lugar de inferir el progreso de un registro creciente, cada módulo (planificador, actor, verificador) lee y escribe en este estado compartido. La regla crítica es que no se puede comprometer ningún progreso sin una decisión respaldada por el verificador.

Cómo funciona

El marco ejecuta un bucle. El planificador lee el estado actual y selecciona un subobjetivo. El actor intenta ese subobjetivo en el entorno. El verificador comprueba si se realizó un progreso válido. Solo si el verificador encuentra evidencia, se actualiza el estado. Esto es más estricto que los enfoques donde el actor se autodeclara completado, o donde un juez final verifica solo la captura de pantalla final.

El verificador utiliza un sondeo estructurado: puede verificar archivos en el disco, salidas de comandos, URL, árboles de accesibilidad, no solo la pantalla. En una tarea de múltiples aplicaciones, por ejemplo, el actor podría parecer exportar una imagen de un documento, pero el verificador puede verificar el sistema de archivos en busca del archivo exportado real. Si el archivo falta, el subobjetivo permanece pendiente, bloqueando una finalización falsa.

Esta disciplina permite varias capacidades: punto de control de progreso (el estado en sí mismo es un punto de reanudación), recuperación dirigida de fallos (el verificador diagnostica si un fallo fue causado por evidencia faltante, un requisito conflictivo o un bloqueador del entorno) y ejecución asistida por herramientas (procedimientos reutilizables que aún requieren confirmaciones respaldadas por el verificador).

Las cifras

Los experimentos controlados en OSWorld-Verified utilizan un presupuesto de 100 pasos y un pipeline de puntuación común. Los resultados muestran que StructAgent mejora cada núcleo probado, con las mayores ganancias en los modelos más débiles. La implicación es que el marco compensa la capacidad limitada de un modelo para extraer señales del historial sin procesar.

Las aplicaciones de oficina (hojas de cálculo, documentos) ven las mejoras más claras, probablemente porque estos entornos exponen estados intermedios duraderos como valores de celda y contenidos de archivos. Las tareas entre aplicaciones siguen siendo el entorno más difícil. Incluso con el núcleo más fuerte, el rendimiento en escenarios de múltiples aplicaciones va por detrás de los dominios más simples. La superficie de evidencia del verificador es menos confiable a través de los límites de las aplicaciones.

El marco se generaliza más allá de los entornos de escritorio. En Minecraft, StructAgent reemplazó las fuentes de evidencia de escritorio con comprobaciones basadas en el inventario. Logró una tasa de éxito promedio ponderada por tarea del 76 % en cinco niveles de herramientas, en comparación con el 59 % del punto de referencia Optimus-1 publicado. Las mayores ganancias se produjeron en los niveles Hierro y Dorado, donde las largas cadenas de dependencia hacen que el seguimiento verificado de subobjetivos sea especialmente útil.

Por qué es importante

StructAgent llega en un momento en que la industria de la IA está presionando fuertemente hacia sistemas agénticos, modelos que pueden actuar de forma autónoma durante períodos prolongados. Pero puntos de referencia como OSWorld-Verified muestran que incluso los mejores modelos fallan en tareas largas. El artículo plantea el problema como un problema de diseño de agentes, no solo de escalado de modelos. Su enfoque reformula la verificación de una puerta final a un mecanismo de compromiso continuo.

El análisis de fallos de las trayectorias con puntuación cero es revelador incluso sobre el propio StructAgent. Los fallos del actor representaron el 33 % de los casos, pero los fallos del planificador y del verificador representaron cada uno el 30 %. Ningún módulo por sí solo explica todos los fallos, lo que los autores argumentan que respalda la visión a nivel de sistemas: la confiabilidad de horizonte largo requiere un mejor diseño de evidencia, un entrenamiento más sólido del verificador y soporte de ejecución consciente del dominio.

El artículo también muestra que la verificación estructurada supera a la verificación solo visual. Cuando los verificadores estructurado y visual discreparon, en 100 casos intermedios revisados manualmente, el verificador estructurado fue correcto el 63 % de las veces, en comparación con el 31 % del verificador solo visual. La ventaja provino de la evidencia latente: archivos, salidas de comandos, URL que no son visibles de forma confiable en las capturas de pantalla.

Las preguntas abiertas

Las ganancias de StructAgent son mayores cuando los entornos exponen un estado comprobable: archivos, URL, estructuras de datos accesibles. En dominios puramente visuales, algunas tareas del navegador y aplicaciones con muchas imágenes, la ventaja se reduce. El artículo sugiere comprobaciones más ricas específicas de la aplicación y entrenamiento del verificador como los próximos cuellos de botella.

Otra pregunta abierta es cómo este enfoque escala a tareas aún más largas o a configuraciones de múltiples agentes. La abstracción de estado está diseñada para compartirse entre módulos, pero el artículo no prueba escenarios de múltiples agentes. Los autores señalan en su conclusión que el paradigma podría extenderse a agentes web, agentes encarnados y colaboración de múltiples agentes, pero dejan la implementación como trabajo futuro.

StructAgent tampoco escapa al costo de la verificación. Cada llamada al verificador agrega latencia y cómputo. Para el presupuesto de 100 pasos utilizado en los experimentos, esa sobrecarga es manejable, pero para tareas que ejecutan miles de pasos, el propio verificador se convierte en un cuello de botella.

Aún así, los resultados son difíciles de ignorar. Un marco que eleva un modelo de 9 mil millones de parámetros del 27 % al 47 % en un punto de referencia difícil, sin escalar el modelo, sugiere que la forma en que un agente rastrea su propio progreso puede ser tan importante como la capacidad bruta del modelo. El argumento central del artículo, de que la ejecución de horizonte largo necesita una estructura causal para el progreso, no solo una ventana de contexto más grande, es algo con lo que es probable que la industria tenga que lidiar a medida que las tareas agénticas se alarguen.

El código y la página del proyecto de StructAgent están disponibles públicamente. Los autores han indicado que el diseño centrado en el estado no se limita a las tareas de escritorio, sino que es un paradigma general para crear agentes que puedan rastrear honestamente lo que han y no han logrado.