You've played that board game where you build a Rube Goldberg machine — dominoes, ramps, catapults, each triggered by the last. Now imagine you have to debug it, but every time something fails you have to reset the entire contraption. You can't tell whether the marble missed the ramp or the catapult was mis-angled, because you only see the final ball not landing in the cup. That's the problem with long-horizon robot manipulation today: you chain five or six contact-rich skills together, and when the chain fails — and it always fails — you've burned T^K exploration episodes and learned nothing about which link broke. BATON's committed claim: decompose multi-stage robot manipulation into independently explorable subtasks with explicit transition contracts between them, reducing exploration cost from multiplicative (T^K) to additive (TK) and attributing every failure to a single stage. This is not a new robot policy. It's an orchestration architecture that wraps an existing frozen VLA model with an LLM agent, and the contribution is in how that agent manages exploration and inter-stage handoffs. No parameters are updated at any point. The architecture sits in the LLM-as-planner family that's been gaining traction since SayCan and Code-as-Policies. The recipe: freeze a pretrained vision-language-action model, let it handle contact-rich manipulation (grasping, insertion, pouring), and use an LLM agent for planning, free-space motion via analytic primitives, and memory. What prior work missed — and what BATON targets — are two failure modes specific to long horizons. First, whole-task exploration is combinatorially expensive. Second, there's no representation of transitions: a subtask can "succeed" in a state its successor can't use, like placing an object at the right location but in the wrong orientation. BATON introduces three transition types to fix the handoff problem. An invocation transition uses a verifier agent to check the wrist-camera view before calling the VLA — the scene must be ready, not just close enough. A handoff transition explicitly restores entry conditions that the previous subtask's residual motion may have disturbed. And a lookahead transition selects among multiple successful strategies by checking which output state the next subtask can actually inherit. This is the real contribution: transitions as first-class objects with entry and exit contracts. On the RoboMemArena benchmark — which is the community's current long-horizon manipulation testbed — BATON improves task success by 11.6% and cumulative success by 14.9% over the previous state of the art. These are meaningful but not earth-shattering numbers. The benchmark is simulation-based, and the paper does not report real-robot results. The T^K-to-TK complexity reduction is the theoretically clean result; the empirical gains validate that the theory translates into practice at current benchmark scale. The obvious experiment not run: real-robot deployment. Every long-horizon manipulation paper faces this gap, and BATON is no exception. Simulation success does not guarantee physical transfer — contact dynamics, sensor noise, and calibration errors are qualitatively different problems. My honest read is (a): real-robot experiments are expensive and slow, and the authors chose to establish the algorithmic contribution on a controlled benchmark first. This is defensible but means the core claim is still unvalidated in the domain that matters. The bigger field fight here is whether you should train end-to-end long-horizon policies or compose modular skills with an external orchestrator. End-to-end approaches (RT-2, Octo) bet that scale will eventually solve compounding errors. The modular camp — SayCan, Code-as-Policies, and now BATON — bets that decomposition plus explicit contracts between modules will always beat brute-force scaling for multi-stage tasks. BATON is the strongest articulation yet of why transitions, not just skills, are the bottleneck.
