La receta estándar para manipulación de robots de horizonte largo—congelar la VLA, dejar que un agente LLM planifique en lenguaje, usar primitivas analíticas para movimiento en espacio libre, invocar la VLA solo para segmentos ricos en contacto—falla a escala de dos formas. Un nuevo artículo, BATON (arXiv 2608.16889), publicado el 17 de agosto de 2026 por investigadores de USC, nombra ambas fallas precisamente y las corrige sin actualizar un solo peso del modelo.

La primera falla es combinatoria. Cuando la competencia proviene de exploración en tiempo de prueba de toda la tarea y cada etapa necesita T episodios para converger, una tarea de K etapas requiere aproximadamente T^K episodios totales. Una falla en cualquier lugar de la cadena no proporciona señal sobre qué etapa la causó. BATON replantea el problema: hacer de la subtarea la unidad de exploración. Cada subtarea se ejecuta en un régimen de horizonte corto barato y almacena su solución en memoria. La trayectoria de horizonte largo se ensambla a partir de soluciones almacenadas en lugar de ser descubierta de extremo a extremo. El costo colapsa de T^K a T×K—aditivo en lugar de multiplicativo en el número de etapas—y cada falla se asigna a una única subtarea.

La segunda falla es estructural. Una primitiva VLA lleva una condición de salida (finalización de la tarea) pero sin condición de entrada (cómo debe verse la escena antes de que la invocación sea segura). Una subtarea predecesora puede tener éxito de una forma que su sucesora no puede usar—objeto agarrado en el ángulo incorrecto, un recipiente dejado ligeramente abierto. BATON llama a esto contaminación de transición. Aborda el problema con una capa de memoria consciente de transiciones que abarca tres mecanismos. Dentro de una subtarea, un agente verificador retiene la VLA hasta que una imagen de vista de muñeca confirma que la escena está lista. Entre subtareas, una transición de entrega restaura activamente el estado de entrada que el predecesor perturbó. Una transición de lookahead selecciona entre estrategias candidatas simulando qué resultado la siguiente subtarea puede heredar.

En RoboMemArena—un benchmark de 26 tareas donde las trayectorias promedio exceden 1.000 pasos y el 68,9% de las subtareas dependen de memoria—BATON mejora el éxito de la tarea en 11,6% y el éxito acumulativo en 14,9% sobre el estado anterior del arte. No se actualizan parámetros. Las ganancias provienen puramente de reestructurar cuándo y cómo se invoca la VLA, no de la capacidad del modelo.

La arquitectura es deliberadamente modular. El planificador LLM, la primitiva VLA y el agente verificador son cada uno una invocación de modelo distinta. Esa separación hace que la contabilidad de costos sea manejable: las llamadas caras de VLA ocurren solo después de que el verificador despeja la escena, por lo que la computación se escala con estados verificados-listos en lugar de timesteps totales. La memoria de lenguaje que almacena soluciones de subtareas persiste entre sesiones, por lo que una etapa resuelta no vuelve a explorar cuando aparece la misma configuración de tarea nuevamente.

BATON no aborda una limitación: el verificador mismo puede fallar. La verificación de vista de muñeca es una llamada de VLM, y si malinterpreta una escena, la transición de entrega puede activarse en un estado contaminado. El artículo evalúa tareas de simulación de RoboMemArena; la brecha sim-a-real en el verificador de vista de muñeca sigue siendo una pregunta abierta. El mecanismo de lookahead también asume que las estrategias de subtarea son lo suficientemente enumerables para comparar, lo que puede no cumplirse para objetivos de manipulación altamente abiertos.

El patrón no es específico de la robótica. Cualquier pipeline de agente que encadene llamadas de modelos especializados—un modelo de recuperación, intérprete de código, clasificador de visión, paso generativo—enfrenta los mismos dos modos de falla: costo de exploración de cadena completa escalando exponencialmente con etapas, y condiciones de salida dejando estado que el siguiente modelo no puede consumir. La respuesta de BATON: descomponer la exploración al nivel de subtarea, establecer cada llamada de modelo cara detrás de un verificador barato, y hacer que las condiciones de entrada/salida sean explícitas en la memoria. El costo se vuelve lineal; los fallos se localizan.