Repairing an agent failure requires more than finding a plausible replacement action: the deployed executor must be able to finish from that point. A second paper looks at the infrastructure behind training: how can a shared cluster create, preserve, and clean up sandboxes when many trajectories start together?
Repair selection: evaluate with the executor that will act
Original: Repairs for Whom? Evaluator-Executor Mismatch in Selecting Repairs for Failed LLM Agents
Authors: Yijun Liao, Fanwei Liang · First published: 2026-10-28
A stronger model, deterministic replay, or an environment planner may score candidate repairs. Yet an action’s value depends on how the deployed agent interprets the state, samples its next steps, and spends its remaining budget. An evaluator succeeding from a state does not guarantee that the executor will do the same.
The authors fix failed trajectories and candidate single-action replacements, let different evaluators select repairs, and independently measure the deployed policy’s net gain. This is the success rate after replacement minus the success rate when rerunning the original action; WebShop uses reward differences. The reference selects using the deployed executor’s own rollouts, with separate samples for selection and evaluation. The study distinguishes a change in evaluation target from simply using fewer samples.
On ALFWorld and WebShop failure pools not screened for repair value, greedy replay loses 0.08–0.13 in expected net success gain and 0.06–0.13 in net reward, respectively, relative to matched selection. Using 14B rollouts to select repairs for Qwen2.5-7B loses 0.25 and 0.07, respectively. These are selection losses in this experiment, not a general claim that stronger models are worse. Each unscreened pool contains 60 failed trajectories; the study replaces one action at a time and uses specified candidate sets and replayable environments.
For intervention design, the executor includes the model, prompt, history protocol, and decoding settings. Stronger agents may propose useful candidates, but their own success is not automatically a proxy for the deployed policy’s benefit. The experimental protocol is useful reading for anyone designing repair verification.
Sandman: bursty training sandboxes on a shared cluster
Original: Sandman: Building and Operating Sandboxes for Agentic Reinforcement Learning on Shared Kubernetes
Authors: Yiming Yan, Hongyang Wang, Wenbo Chen, Xuan Wang, Jingguo Liu, Xian Li, Chen Qi, Leo Fan, Siwei Li, Qianli Wu, Yichuan Li, Ruochen Wen, Qian Qu, Zheshen Wang, Benoit Dumoulin · First published: 2026-10-29
An agentic RL trajectory repeatedly calls tools, so files and processes must persist between calls. Training also requests environments in bursts: the authors report a peak of 132 creates in one second against a campaign average of 1.8 per second. Sizing for the mean can miss pressure on Kubernetes admission, scheduling, and network address allocation.
Sandman runs each sandbox as an ordinary pod with a small daemon mounted into the unmodified task image. The trainer acquires a sandbox and alternates model inference with tool calls; it extracts the patch and, by default, runs tests in a separate never-used grading pod. A provider creates, paces, spreads, and deletes pods; an optional pool prewarms common images. A key lifecycle detail is that cleanup still has an owner if a caller times out and abandons an acquisition.
Reading the diagram: the trainer acquires a rollout sandbox, alternates model and tool calls, and sends the patch to a separate grading sandbox; the provider manages pod lifecycles.
The authors held 11,858 tiny sandboxes in a scale test and report about 3.13 million creations across four internal SWE-bench Verified training campaigns. These are different workloads: the lightweight-pod test is not a capacity guarantee for real task images. Prewarming reduces acquisition latency but reserves idle resources; image pulls, address allocation, and cleanup after timeouts also matter. The evidence comes from one shared EKS cluster, and some mechanisms postdate the reported production campaigns. For AgentOps, the practical lesson is to consider tail acquisition latency, orphan reclamation, and grading integrity alongside tool execution speed.