Keeping an Agent on Goal After It Finds the Target

An agent can find the right target and still fail to finish the job. If evaluation records only the final failure, builders may improve search when the problem is what happens after discovery.

In their October 6 preprint, Attacca, Gyusik Seo and Jaehong Yoon study this distinction in Minecraft. Each step in a task chain begins where the previous step ended, with the world changes, position and camera direction carried forward. The next target may initially be out of view.

Finding it was not the main problem

In one chain's diamond-mining stage, the fine-tuned ROCKET-2 baseline saw the target in 27 of the 28 episodes that reached that stage. It completed the stage in only four of those 27. Attacca completed the stage in 39 of its 42 stage-reaching episodes. These are different subsets of runs, but the baseline's repeated loss of the visible target gives a more useful diagnosis than a single completion score.

The authors also changed the reference image used to specify the target. A nearby view, a distant view and a view from another world all represented the same target class. ROCKET-2 performed substantially worse with the latter two; Attacca was more consistent. Selected trajectories suggest the baseline sometimes reproduced the reference viewpoint instead of approaching and interacting with the target.

Attacca trains on complete search, approach and interaction demonstrations. It pairs them with target images from other worlds, learns where the target appears in the current view, and predicts which of those three stages it is in. The combined system improved task-chain completion, although adding individual components did not consistently help.

The study covers Minecraft, with one fixed world per chain and one reported training seed. A scripted controller supplies goals and detects completion; helpers handle some inventory and interface work. It evaluates the action policy, not an integrated autonomous planner.

A sharper question for WTK

Consider a hypothetical logistics agent asked to find a delayed shipment, book an authorized replacement delivery and update the customer. It opens the correct shipment, then returns from the carrier's booking screen to a reordered shipment list. Does it continue with the same shipment and finish the booking, or repeatedly search again and leave the request unresolved?

That example turns the paper's diagnosis into a WTK review question: when evaluating a catalog package in its target runtime, can we distinguish failure to locate the intended record from failure to complete the permitted work after locating it? The resulting booking and customer update matter alongside the action history, as our note on evaluating actions and final state explains.

The useful detail is to preserve what earlier steps actually left behind rather than restart each step in an ideal setup. Under WTK's research method, changes to incidental context should leave the required outcome and permissions explicit. People define those boundaries and review exceptions; routine continuation should not require their intervention at every step.

Our takeaway: before improving an agent's search, establish whether it failed to find the target or failed to follow through once it did.