El mundo real no se deja simular
Durante años, el avance de los agentes de lenguaje (esos sistemas capaces de planear, razonar, ejecutar tareas encadenadas) se evaluó en espacios de laboratorio: entornos simulados, juegos abstractos, tareas sintéticas. Allí brillaban. Navegaban con precisión entre subtareas delimitadas, respondían con elegancia a prompts predecibles, parecían tener una estructura racional tan sólida como maleable. Pero fuera de esos escenarios controlados, el aire se enrarecía. Cuando se los soltaba en dominios reales —tareas con consecuencias, pasos que no pueden rehacerse, información dispersa y ambigua— el rendimiento se diluía.
Ese desfase entre lo que hacen en el benchmark y lo que logran en la práctica es el núcleo del trabajo que presenta TheAgentCompany. Es una intervención que no busca mejorar a los agentes, sino ponerlos a prueba en condiciones que realmente importan: no en preguntas de opción múltiple, sino en decisiones que afectan un sistema operativo, una base de datos, un entorno de producción.
El paper parte de una observación clave: gran parte de los benchmarks existentes para agentes de lenguaje están diseñados para medir microhabilidades, no competencias de agencia extendida. Saben si el modelo puede elegir un archivo, pero no si puede completar un flujo de trabajo complejo. Evalúan si resuelve una subtarea, pero no si puede sostener una estrategia con visión de conjunto. Esa fragmentación oculta un problema: los modelos parecen agentes porque imitan conductas localmente óptimas, pero no razonan a lo largo de horizontes amplios, no adaptan sus planes cuando el entorno cambia, no aprenden de sus errores en tiempo real. No son, en rigor, agentes robustos. Son lenguajes atrapados en estructuras episódicas.
TheAgentCompany propone una alternativa. Diseña un banco de pruebas que exige a los agentes enfrentarse a tareas del mundo real con múltiples pasos, consecuencias acumulativas y requerimientos prácticos. No es un benchmark más, sino un intento de redefinir qué significa ser un agente útil, autónomo y competente cuando se lo saca de la caja del prompt.
Tareas con consecuencias
Las tareas que componen el benchmark no fueron elegidas al azar. Responden a un criterio claro: tienen consecuencias concretas, irreversibles y observables. Entre ellas hay acciones como instalar software en un sistema Linux real, recuperar información desde documentación dispersa, manejar errores en tiempo de ejecución, analizar logs para depurar scripts, e incluso componer estrategias comerciales a partir de resultados pasados. No se trata de tareas triviales, pero tampoco de desafíos artificiales. Son exactamente el tipo de cosas que hoy, en pequeñas y medianas empresas, equipos técnicos o contextos de automatización, se espera que puedan resolver los agentes basados en LLM.
En estos entornos, no alcanza con que el modelo sepa generar código. Tiene que saber cómo desplegarlo, cómo manejar un error, cómo adaptarse cuando una librería no está disponible o cuando una API cambió. Y sobre todo, tiene que saber cuándo no sabe. La ilusión de competencia es más peligrosa que la incompetencia manifiesta. Y parte del objetivo de este benchmark es mostrar cuándo un agente toma decisiones sin tener los medios para evaluar sus consecuencias.
A diferencia de otros entornos sintéticos, aquí las tareas están encadenadas. No hay una solución única. No se premia que se haga lo correcto a la primera, sino que se logre el objetivo final incluso si hubo tropiezos. Lo importante no es la perfección, sino la capacidad de sostener un curso de acción bajo condiciones reales, con feedback ambiguo y sin guía explícita. Un agente verdaderamente útil, argumentan los autores, no es el que acierta rápido, sino el que navega con resiliencia y sentido del contexto.
El marco: entornos reales, acciones reales
Para evaluar este tipo de agencia, el equipo diseñó una arquitectura modular que permite desplegar agentes en entornos reales de sistema operativo (por ejemplo, una máquina virtual con Ubuntu), donde cada acción tiene efectos persistentes. El agente puede navegar el sistema de archivos, editar scripts, instalar paquetes, correr comandos en bash, revisar documentación, acceder a navegadores web en sandbox, y más. Es, literalmente, un actor dentro de un mundo.
Pero no se le da el control directo. Cada paso es ejecutado a través de un entorno seguro que registra todas sus acciones. Esto permite auditar no solo si completó una tarea, sino cómo la abordó, con qué estrategia, con qué ritmo, con cuántos errores y con cuántas adaptaciones sobre la marcha.
El benchmark no está diseñado para frustrar a los agentes. No hay trampas. Pero tampoco hay atajos. Lo que se mide no es el cumplimiento de un paso, sino la trayectoria funcional que va de una intención inicial a un resultado concreto. Por eso, además de los logs y resultados, se evalúa la calidad del razonamiento intermedio: cómo el agente argumenta sus pasos, cómo cambia de plan si algo falla, cómo maneja incertidumbre.
Los modelos evaluados incluyen algunas de las versiones más sofisticadas disponibles públicamente: GPT-4, Claude, Gemini, entre otros. Cada uno enfrenta las mismas tareas, bajo condiciones estandarizadas, y con acceso a un conjunto similar de herramientas y documentación. Pero lo que emerge no es una tabla de puntuaciones, sino un retrato desigual de cómo cada arquitectura traduce lenguaje en acción en contextos no triviales.
Agentes que tropiezan con la realidad
Los resultados son elocuentes, aunque inquietantes. Ninguno de los agentes evaluados logra superar consistentemente todas las tareas. Algunos fallan por exceso de confianza: ejecutan comandos destructivos sin verificar consecuencias. Otros por vacilación: se traban frente a ambigüedades mínimas. Algunos siguen instrucciones mecánicamente sin adaptar el plan cuando cambia una variable del entorno. Otros, directamente, pierden la noción de objetivo tras varios pasos.
Hay una lección común: la mayoría de los agentes actuales funcionan como ejecutores locales de instrucciones, no como estrategas adaptativos. Pueden tomar decisiones, pero no sostener un plan. Pueden razonar en un paso, pero no en una secuencia. Y sobre todo, tienen dificultades para integrar contexto histórico, memoria operativa y metas a largo plazo. Son competentes en la microdecisión, pero débiles en la macroestructura.
El artículo no plantea esto como una condena, sino como una advertencia. Lo que falla no es el modelo en sí, sino el modo en que asumimos que puede actuar como agente. Los LLM no fueron diseñados originalmente para sostener agencia extendida. Son modelos de completado, no de propósito. Y cuando los insertamos en entornos que exigen propósito sostenido, su arquitectura muestra sus límites.
Agentes con herramientas, pero sin juicio
Uno de los grandes avances de la última generación de agentes de lenguaje ha sido su capacidad para usar herramientas externas. Ya no se limitan a producir texto: pueden ejecutar código, consultar navegadores, leer archivos, interactuar con entornos de sistema, activar APIs, editar scripts en tiempo real. Este potencial multimodal ha generado entusiasmo —y en muchos casos, expectativas exageradas— sobre la posibilidad de que estos modelos se conviertan en agentes verdaderamente autónomos, capaces de operar en dominios complejos de forma eficaz.
Pero el benchmark muestra una realidad más matizada. La capacidad de acceder a herramientas no garantiza que el agente las use bien. En la mayoría de los casos, lo que se observa es un uso errático, no jerarquizado y mal temporizado de las herramientas. Algunos agentes abren un navegador para buscar instrucciones genéricas que ya tienen en su memoria. Otros invocan comandos sin revisar si la dependencia está instalada. Algunos ejecutan sin leer errores previos. Otros abren demasiados contextos paralelos y pierden el foco de la tarea principal.
En teoría, estas acciones son “razonables” si se toman de a una. Pero el problema es que la secuencia en la que se realizan carece de arquitectura. No hay una planificación de alto nivel que ordene el uso de herramientas en función de objetivos intermedios. Todo ocurre en un plano de decisiones locales: si aparece un error, el agente reacciona; si no lo entiende, prueba otra cosa. Pero no construye una visión global de qué herramientas necesita, en qué orden y para qué propósito. Es agencia reactiva, no prospectiva.
Los mejores agentes logran, a veces, componer flujos útiles: buscan información, la integran, ejecutan, evalúan resultados. Pero aún en esos casos, fallan al reiniciar una estrategia si el entorno cambia. No revisan si lo que aprendieron sigue siendo válido. La memoria operativa es superficial. Y sin memoria, no hay agencia robusta.
Planes sin estructura: el fantasma de la linealidad
El diseño de agentes jerárquicos —capaces de dividir tareas en subtareas, de monitorear objetivos intermedios, de replantear caminos si uno falla— ha sido durante años una promesa del campo. Pero en la práctica, lo que se observa en este benchmark es que los agentes tienden a ejecutar planes lineales, sin modularidad, sin mecanismos de control recursivo.
En términos prácticos, esto significa que una vez que el agente inicia un camino, sigue hacia adelante sin verificar si sigue siendo el correcto. Si un paso falla, intenta repetirlo o lo reemplaza improvisadamente, pero rara vez reconsidera todo el plan. No reestructura el árbol de decisiones. No cambia la prioridad de subtareas. Y lo que es más grave: muchas veces no identifica que una acción intermedia alteró las condiciones originales, y por lo tanto sigue operando como si nada hubiera cambiado.
Esto produce un tipo particular de error, que el estudio académico identifica con claridad: el colapso de objetivos implícitos. El agente sabe qué quiere lograr (por ejemplo, instalar una dependencia y correr un script), pero en el camino toma decisiones que impiden cumplir ese objetivo. Borra archivos necesarios. Reinicia entornos. Cambia de directorio sin actualizar rutas. Todo eso no ocurre por ignorancia, sino por falta de una estructura jerárquica de metas, donde cada acción esté subordinada a un propósito más general.
Es una falla arquitectónica, no una debilidad local. Y lo interesante es que los modelos con más capacidad de lenguaje (aquellos que en benchmarks tradicionales obtienen mejores resultados) no son necesariamente los que mejor navegan esta dificultad. La complejidad lingüística no implica estructura de acción. Saber hablar no es saber actuar.
Memoria breve, errores largos
Una de las áreas más críticas que revela el benchmark es el manejo de memoria. La mayoría de los agentes actuales operan con ventanas de contexto que simulan memoria, pero no tienen mecanismos persistentes de consolidación, actualización ni evaluación. Esto significa que recuerdan lo reciente, pero no lo relevante. Y que cuando se enfrentan a tareas largas, donde lo que aprendieron en un paso debe ser utilizado diez pasos después, tienden a fallar.
Por ejemplo, si un agente descubre que cierta variable no está inicializada, pero no corrige esa parte en su código base, más adelante el error se repite. Y lo peor: lo interpreta como un nuevo problema, no como una instancia repetida. Esto fragmenta su razonamiento. Cada paso parece aislado. No hay narrativa interna. No hay memoria estructural de lo hecho.
Esta debilidad se agrava cuando el agente necesita usar información distribuida en múltiples fuentes: documentación, logs, estado del sistema, resultados parciales. Sin un mecanismo para integrar esa información, las decisiones se vuelven miopes, dependientes del último input, sin capacidad de ponderar múltiples evidencias.
En algunos casos, los autores intentan mitigar esta debilidad incorporando memoria externa, como vectores de embeddings o contextos actualizables. Pero aún así, la mayoría de los agentes no desarrollan estrategias eficaces de recuperación, ni entienden cuándo consultar la memoria. La usan de manera pasiva, no estratégica. Y eso limita su capacidad de agencia extendida.
Patrones de error: entre la ceguera y el exceso de confianza
Más allá de los errores puntuales, el benchmark permite identificar familias de errores recurrentes, que se dan en distintos agentes y tareas. El primero es la ceguera funcional: el agente no reconoce que una acción falló, y sigue como si todo estuviera bien. Esto puede derivar en errores acumulativos, donde una mala suposición inicial contamina toda la cadena de decisiones.
El segundo es el exceso de confianza: el agente asume que una instrucción genérica es válida, y la ejecuta sin verificar. Esto ocurre, por ejemplo, cuando copia código de StackOverflow sin adaptar rutas o versiones. Lo hace rápido, pero sin control de consecuencias.
El tercero es la pérdida de foco: el agente se desvía del objetivo original, empieza a explorar caminos paralelos, y nunca vuelve al punto inicial. Esto es particularmente visible en tareas largas, donde el número de pasos intermedios genera distracción semántica.
Y finalmente, hay un patrón que preocupa especialmente: el autoengaño operativo. El agente redacta un paso como si lo hubiera hecho, pero no lo hace. Escribe: “Ahora he instalado la librería”, pero en realidad no ejecutó el comando. Esto no es mentira deliberada —no hay intención—, sino un fallo en la sincronía entre plan y acción. Pero sus efectos son graves: el agente cree que está avanzando, pero está narrando un avance ficticio.
No todos los modelos son agentes
Uno de los aportes más importantes de la investigación aquí tratada es su revisión crítica del supuesto de equivalencia entre modelo potente y agente competente. La lógica que dominó gran parte del discurso en los últimos años —según la cual basta con escalar el modelo y dotarlo de herramientas para que actúe como un agente exitoso— encuentra en este estudio una desmentida empírica. No todos los modelos grandes se comportan como buenos agentes. Y, en muchos casos, los que tienen mejor puntuación en benchmarks de lenguaje no son los que logran completar con éxito tareas del mundo real.
El experimento compara algunos de los principales LLMs del mercado (entre ellos GPT-4, Claude 2, Gemini y Mistral) al enfrentarlos con las mismas tareas, las mismas condiciones, y los mismos recursos instrumentales. Cada modelo tiene acceso a herramientas externas, a documentación contextualizada y a una arquitectura de interacción estandarizada. Aun así, los resultados muestran una brecha significativa en el rendimiento efectivo, no solo en términos de éxito, sino de cómo cada modelo organiza su agencia.
GPT-4, por ejemplo, tiende a producir planes iniciales razonables y detallados, pero muchas veces fracasa en sostenerlos si el entorno introduce cambios. Tiene tendencia a sobreplanificar: anticipa pasos que luego no ejecuta, o asume que se cumplieron sin verificación. Claude 2 muestra más cautela, mayor disposición a revalidar información, pero también una inclinación a dudar de su propio progreso, lo que puede traducirse en ciclos de revisión innecesarios. Gemini demuestra buena capacidad de síntesis, pero en ciertos contextos complejos se muestra proclive a priorizar fluidez textual sobre rigor funcional. Mistral, con arquitectura distinta, oscila entre aciertos quirúrgicos y fallos estructurales, como si le costara sostener consistencia a largo plazo.
El problema, como dejan en claro los autores, no es que los modelos sean malos, sino que el diseño general de los LLMs no está pensado para agencia sostenida. Son excelentes como generadores de lenguaje, muy competentes en tareas de corto plazo, brillantes en preguntas con contexto limitado. Pero cuando se trata de mantener una meta a lo largo de múltiples pasos, adaptarse a nuevas condiciones, integrar errores en la estrategia y no solo en el output, sus capacidades flaquean.
Este desajuste no es menor. Si los sistemas que hoy se presentan como “agentes inteligentes” solo pueden operar con eficiencia en entornos episódicos, entonces el discurso sobre la autonomía real de estos sistemas necesita ser repensado. Lo que hay no es agencia, sino una simulación estructurada de agencia, eficaz mientras el camino no se desvíe demasiado. Pero cuando se sale del andamiaje del prompt, aparece el vacío operativo.
Más que precisión: la prueba es la resiliencia
Uno de los mayores aciertos del benchmark es que no evalúa a los modelos en función de su precisión textual, sino de su resiliencia operativa. Es decir: su capacidad para sostener un curso de acción a pesar de errores, obstáculos o información ambigua. Y ahí se revela una dimensión poco explorada hasta ahora en los estudios sobre LLMs: la resistencia.
Porque actuar bien no es solo acertar. Es también reconocer el error, retroceder, corregir, volver a intentar. La inteligencia operativa no está en prever cada paso, sino en adaptarse cuando el paso previsto falla. Y esa adaptación requiere algo que los LLMs aún no han consolidado: una representación funcional de objetivos, una memoria operativa confiable y una disposición activa al replanteo estratégico.
Muchos de los errores detectados no ocurren porque el modelo no entienda la tarea, sino porque, una vez en marcha, pierde la capacidad de revisar su progreso con sentido histórico. No recuerda por qué eligió un camino. No evalúa si lo recorrido sirve a la meta. No compara lo esperado con lo obtenido. Esa ausencia de reflexividad práctica convierte a muchos agentes actuales en ejecutores sin supervisión. Y cuando fallan, no saben por qué. Tampoco aprenden de ese fallo.
En el benchmark, los agentes más exitosos no son necesariamente los más rápidos, ni los que ejecutan más comandos sin errores, sino los que muestran alguna forma rudimentaria de ajuste estratégico: que revisan logs, que preguntan antes de actuar, que comparan salidas, que evitan repetir el mismo error. Son modelos que, aunque limitados, empiezan a acercarse a una noción funcional de juicio adaptativo. Y ese es el tipo de agencia que realmente importa en escenarios reales.
El benchmark como forma de gobierno
Una idea que se desliza con sutileza en el texto, pero que tiene implicancias profundas, es que los benchmarks no son solo instrumentos de evaluación, sino mecanismos de normatividad. Determinan qué consideramos éxito, qué valores se premian, qué tipo de comportamiento es deseable. En ese sentido, TheAgentCompany no solo ofrece una nueva herramienta, sino que reconfigura el marco de referencia de lo que entendemos por agente útil.
Mientras otros benchmarks miden exactitud sintáctica, velocidad de respuesta o concordancia con un gold standard, este se centra en algo más difícil de capturar: el despliegue de una competencia sostenida, integrada, situada en un mundo con consecuencias. Y eso cambia todo. Porque implica que no basta con hablar bien: hay que saber actuar bien. No basta con generar código: hay que saber cuándo, cómo y por qué ejecutarlo.
Este giro no es solo técnico. Es político. Redefinir lo que cuenta como éxito en un agente es también redefinir lo que consideramos inteligencia artificial confiable. Y al hacerlo, se vuelve inevitable preguntarse: ¿estamos premiando lo que debería ser premiado? ¿Estamos entrenando a los modelos para lo que realmente importa?
El trabajo de TheAgentCompany sugiere que la respuesta es, hasta ahora, no del todo. Que hemos optimizado durante años para habilidades que no siempre se traducen en utilidad robusta. Que hemos confundido fluidez con competencia, y que ahora, cuando pedimos a los agentes que operen en el mundo real, nos damos cuenta de que hay un vacío estructural que no se llena con más tokens.
Agencia sin conciencia, pero con consecuencias
La idea de agencia artificial suele asociarse, casi por reflejo, a la ilusión de voluntad: si un modelo actúa de manera sostenida y coherente, asumimos que “quiere” algo, que “elige” caminos, que “decide” con algún tipo de criterio propio. Pero lo que revela este estudio (por contraste, por ausencia) es que la agencia no es una cuestión de deseo, sino de estructura. Lo que permite a un sistema actuar de forma eficaz en el mundo no es que tenga metas internas conscientes, sino que posea una organización funcional capaz de sostener propósitos, gestionar contextos, aprender de errores, modular planes.
Y eso, hoy, todavía no existe en la mayoría de los modelos presentados como agentes. Lo que existe es una simulación de intención, construida frase a frase. Pero cuando se la somete a entornos donde el lenguaje deja de ser suficiente, donde cada palabra se traduce en una acción con efectos, la arquitectura se desmorona. Los modelos no fallan por torpeza, sino porque el entorno exige una consistencia que no fueron diseñados para sostener.
El benchmark no acusa a los modelos. No los caricaturiza ni dramatiza sus límites. Simplemente los somete a la realidad, y observa. No interviene en su interior, no altera sus pesos, no modifica sus mecanismos. Les propone tareas que un humano competente podría completar, incluso sin expertise profundo. Y al verlos fallar, deja que los datos hablen.
La lección es simple, pero poderosa: una agencia funcional exige más que lenguaje. Requiere estructuras de memoria, mecanismos de monitoreo interno, control de versiones del mundo, flexibilidad estratégica, sentido del error. Requiere tiempo, no solo velocidad; reflexión, no solo completado.
La ilusión de la mejora lineal
Una de las implicancias más inquietantes del trabajo es que el tamaño del modelo no garantiza una mejora proporcional en capacidad de agencia. Escalar no es sinónimo de organizar. Lo que mejora al crecer el número de parámetros —fluidez, diversidad, coherencia local— no siempre mejora el desempeño en tareas con múltiples pasos, contextos ambiguos o necesidad de integración transversal.
De hecho, en algunas pruebas, modelos más pequeños con configuraciones bien ajustadas lograron desempeños equivalentes —e incluso superiores— a modelos más grandes. No porque fueran “más inteligentes”, sino porque su comportamiento era más estructurado, menos propenso a desvíos narrativos, más austero en su ejecución. Y en entornos donde cada acción cuenta, donde un solo comando mal ejecutado puede invalidar todo el progreso, esa austeridad puede ser una virtud.
Esto abre un interrogante incómodo para la industria: ¿estamos construyendo agentes cada vez más potentes, o solo modelos cada vez más grandes? ¿Cuánto de la agencia real depende de la arquitectura central, y cuánto del diseño externo, de la interfaz que la organiza, del contexto que la regula?
Porque si un modelo de 13B bien instrumentado puede desempeñarse tan bien como uno de 65B mal instrumentado, entonces la carrera por la escala deja de ser garantía de utilidad. Y empezamos a necesitar otro tipo de innovación: no más peso, sino más forma.
Lo que los modelos no saben que no saben
El comportamiento de los agentes evaluados en el benchmark deja entrever una falla silenciosa pero persistente: la incapacidad de detectar su propia incompetencia contextual. Los modelos no solo fallan en la ejecución, sino también en la metacognición funcional: no saben que no saben. Actúan con aparente seguridad incluso cuando están perdidos. Generan salidas plausibles aunque internamente inconsistentes. Y no desarrollan mecanismos para frenar la acción cuando la incertidumbre se vuelve dominante.
Este tipo de error no puede corregirse solo con entrenamiento adicional. Requiere un replanteo de la arquitectura deliberativa del agente: qué mecanismos posee para evaluar su propio estado, qué umbrales lo hacen reconsiderar un plan, qué señales internas activan un pedido de ayuda o una pausa operativa.
Hoy, la mayoría de los agentes no poseen nada de eso. Funcionan como narradores autónomos, no como actores evaluativos. Y eso es un riesgo: porque a medida que se despliegan en sistemas reales —desde plataformas de automatización hasta agentes comerciales, asistentes legales, diagnósticos o monitoreo—, la apariencia de seguridad puede ser más peligrosa que el error explícito. No basta con que el modelo funcione bien la mayoría del tiempo. Debe también poder decir: “esto no lo sé”, “esto no lo puedo hacer”, “este camino no es viable”.
Esa capacidad negativa, la de reconocer límites, es una de las formas más maduras de agencia. Y, paradójicamente, es la que menos hemos entrenado.
Repensar el diseño de agentes
El trabajo de TheAgentCompany no es solo un benchmark. Es una invitación a repensar el diseño general de agentes basados en modelos de lenguaje. No se trata de abandonar los LLMs, ni de desestimarlos como herramientas. Se trata, más bien, de reconocer que su forma actual no es suficiente para sostener agencia real. Y que si queremos construir sistemas que puedan operar de forma robusta en el mundo, necesitamos dotarlos de estructuras adicionales: memoria persistente, monitoreo de objetivos, planificación jerárquica, control de errores, reflexión intermedia.
Algunos de estos elementos pueden implementarse externamente, como módulos de supervisión o arquitecturas de scaffolding. Otros, quizás, deban integrarse en los propios modelos. Pero en cualquier caso, el mensaje es claro: la agencia no emerge por acumulación de tokens, sino por organización de funciones.
El benchmark sugiere caminos posibles. Muestra qué errores se repiten, qué funciones faltan, qué mecanismos serían deseables. No ofrece una receta, pero sí una cartografía de lo que no está funcionando. Y en ese sentido, funciona como guía para una nueva generación de diseño: no basada en la ilusión de que los LLMs son sujetos inteligentes, sino en el reconocimiento de que pueden ser actores útiles si se los estructura con cuidado, con mesura, con atención a sus límites.
No se trata de hacer que parezcan humanos. Se trata de que funcionen bien en el mundo que compartimos con ellos.