When a robot fails partway through a task, the fix has always been the same: a human steps in and demonstrates the correct motion again. This paper proposes a different route. A robot that has already finished its basic training raises its own performance — without any additional human correction demonstrations.
Here is the core idea. When one robot gets stuck in the middle of a task, it treats that moment as a clue. Then it digs through the records of other robots doing the same job and finds a moment that looked similar — one where things went right. It learns from the motion that robot used back then as its model to copy. No human needs to give a fresh demonstration, because the example is already sitting inside the fleet (the group of robots that split the same job among themselves).
Across five real-world manual tasks, this approach reached success rates of 93.3–99.2% at the largest fleet size. The paper is a joint effort from Tsinghua University, AgiBot, and Infinigence AI.
A robot foundation model (a large, broadly pre-trained base model meant to serve many tasks) turns what it sees and the instructions it hears into actual movement. That gives a robot an initial ability to at least attempt a task. But this initial ability does not translate straight into reliable execution. The properties of objects, the conditions at the point of contact, and the small individual differences from one robot to the next keep prying the gap open. In a task made of several chained steps, those tiny errors pile up. For a task like picking up a phone, plugging it into a charging port, and then placing it back in a box, a single wobble at one step spreads into a total failure.
The surest way to close this gap has been human correction. A teleoperator (a person who moves the robot on its behalf) watches the execution, and the moment the policy (the rule by which a robot looks at a situation and decides its next move) fails, takes over control and demonstrates the correct motion. The effectiveness is proven. The catch: as robots grow in number, so must people. At a scale of tens or hundreds, the workforce needed to watch every robot and supply corrections becomes the bottleneck itself.
Think of it as a store. If you have one store, a seasoned manager can stand behind a new hire and take their hand every time they slip. But if the chain grows to 100 stores nationwide, do you have to hire 100 new managers too? This paper's answer is no. Instead of adding managers, you collect the cases that stores across the country have already pulled off, and show the new hire only the case that fits the exact spot where they got stuck. The place where robot learning used to keep demanding "another expert's demonstration" is filled instead by the record of successes the fleet has already accumulated.
The authors call this broad framework Collective Experience Learning (CEL). Robots working apart from one another pool the execution experience each of them gathers and use it to tune a single shared policy. The improved policy goes back out to the fleet and generates new experience. One robot's execution becomes the whole fleet's learning, and that learning in turn lifts every robot's execution. It is a loop that keeps going around.
Follow it through one scene. A robot doing phone packaging keeps slipping as it tries to line a phone up against the corner of a box — a failure. At this moment the robot splits its work in two. The slipped motion itself is not a model worth copying. Imitating a failed motion only hardens a wrong habit. So it discards the failed motion and keeps only "the situation just before it got stuck" as a clue. Carrying that clue, it goes to the shared warehouse of success records the fleet keeps. It finds a segment where, in a similar situation, a phone was fitted neatly into a box, and it focuses its learning on that motion alone.
The authors name this arrangement FERT (Failure-guided Experience Retrieval Fine-Tuning). Fine-tuning is the process of taking an already-trained model and polishing it a little further to fit a specific task. In one sentence: failure points to "where to learn," and success provides "what to copy." No extra expert demonstration enters the picture.
The whole flow has four stages.
Technical note — two "whys" Why freeze the comparison yardstick. The policy keeps changing as it learns. If the ruler that measures "are these situations similar?" also changed along with the policy, then yesterday's similarity and today's similarity would differ, and you could not trust the retrieval results. So the part that turns a situation into numbers (the vision tower of the VLA model) is copied and kept frozen, and the features it extracts are combined with the robot's joint state to form a "situation fingerprint." No matter how much the policy changes, the yardstick for this fingerprint stays fixed. Why it can match the same situation even when motion speeds differ. Robots differ from one another, and attempt to attempt, in how fast they work. The same motion is done quickly by one robot and slowly by another. Overlay them as-is to compare and they misalign. So the method uses DTW (Dynamic Time Warping), a classic technique that stretches and squeezes two time series of different speeds to align them. But it uses a constrained variant (S-DTW) that prevents the time order from flipping, so that a slow success and the moment just before a fast failure can still be matched as the same situation.
Supplement — the system that keeps experience flowing without a break (FATS) If the algorithm handles "how to turn experience into policy improvement," then FATS (Fault-tolerant Asynchronous Training System) handles "how to gather and distribute that experience without a break." A fleet always has some fraction stopped for resets, maintenance, or recovery, and collection, inference, and optimization each run on their own schedules. The data layer SwarmLink gathers inference results and trajectories and sends them to training, while the control layer HotSwarm restarts a broken robot in place while letting the healthy robots keep collecting experience. Even if one robot stops, the rest of the fleet's learning loop keeps turning.
FERT does not start from bare ground. The initial policy requires human demonstrations. First comes supervised fine-tuning (SFT) that learns from human demonstrations, and then a multi-robot HG-DAgger that mixes in human intervention, to establish a base policy. FERT starts from that policy. In short, there are two phases. Expert supervision lays the foundation, and from there on the fleet's own motions do the teaching. What FERT eliminates is "the burden of having to keep supplying expert corrections even after deployment" — not the initial expert data itself.
So during the execution phase, the humans' work comes down to two things: tagging each attempt's outcome as success or failure, and returning the environment to its original state. Every motion used in learning comes out of the robots' own execution. The authors note that this outcome tagging could be done by a learned reward model in place of a human, but the experiments in this paper used human-assigned tags and human-performed resets.
The evaluation targets are five real-world manual tasks: Flower Arrangement, Clothes Folding, Phone Charging, Stool Assembly, and Phone Packaging. Together they cover deformable objects, precise alignment, tool use, and multi-step execution.
The results read most cleanly when split into two questions.
How much did it improve? At the largest fleet size, the policies for the five tasks recorded success rates of 93.3–99.2%. Phone Packaging, where the steps run one after another, stands out in particular. Trained with 96 robots, its 79.2% at the start of FERT rose to 98.3%. The more steps chained together, the more sharply the effect of collective experience showed.
Is it thanks to the retrieval? There is a difference between just using all of the success records and selecting only the successes that fit the spot the failure points to. To see this difference, the authors ran the same Phone Packaging with 16 robots and removed only the failure-elicited retrieval. The success rate dropped from 86.7% to 64.2% — a gap of more than 20 percentage points. That means the key is selecting the "right" thing to use, not gathering a lot.
| What's measured | Fleet size | Comparison | Success rate |
|---|---|---|---|
| Learning effect | 96 robots | Before → after FERT | 79.2% → 98.3% (Phone Packaging) |
| Contribution of retrieval | 16 robots | Retrieval on → off | 86.7% → 64.2% (Phone Packaging) |
| Overall endpoint | Largest size | — | 93.3–99.2% (five tasks) |
The two headline numbers come from different experiments. The 79.2%→98.3% measures before and after learning on 96 robots, while the 86.7%→64.2% toggles retrieval on and off on 16 robots. Since both the fleet size and the thing being compared differ, we do not merge them into a single result.
The evaluation conditions were applied in common across the five tasks. Each task was re-measured over 120 attempts, but those attempts were split evenly across 2 robots of the same platform that did not take part in training. This is to measure not whether a robot used in training repeats what it has already seen, but whether the fleet's experience carries over even to robots it is seeing for the first time. In the experiment that scales up the fleet size, the collection time per robot was fixed. This is to isolate whether the improvement comes from more robots accumulating experience in the same amount of time — not from simply running longer. RECAP and RLT were used as the comparison baselines (details in the appendix).
What the success rate measures is clear: the reliability with which a policy carries a task through to the end. That said, it is a value inside the bounds of a 120-attempt sample, 2 evaluation robots, and these particular five tasks. Generalization to other platforms or a wider range of tasks cannot be asserted from these numbers alone.
Why it works becomes clearer the more often failure occurs. If a robot keeps getting stuck in a certain situation, success segments similar to that situation get retrieved and folded into learning just that often. In other words, the weight of learning tilts toward the weak spots on its own. Because the structure fills the spots it gets wrong often more often, improvement drills into the weakest places first. (The theoretical analysis in Appendix B also shows that, under certain conditions, replaying success experience pulls the policy in the right direction, and retrieval weighting adds a plus on top of that.)
But this very structure is also the outline of its limits. The yardstick for retrieval is "is the scene and posture similar?" So does a similar scene and posture always mean the needed motion is the same? Usually, yes. But in a situation that looks alike on the surface while the motion actually required is different, it can pull up the wrong model. The retrieval criterion is this method's eyes, and the spot those eyes miss becomes its weakness.
There is a more fundamental limit too. FERT leans on the assumption that "a success case for that situation already exists somewhere in the fleet." If it is a failure that someone, at least once, succeeded at, that record can be pulled up to fill the gap. But for an entirely new type of failure that no one has ever succeeded at, there is no model to retrieve. In that case retrieval alone offers no path, and in the end new success experience has to be supplied from outside. The boundary between "failures that collective experience can fill" and "failures for which even the collective has no answer" defines the operating range of this method.
The scope of transfer is also more accurate to state outright. The evaluation confirmed transfer to other robots of the same platform. Whether it works for a different kind of robot or a different task distribution is outside the scope of this result. Also, settings such as query length, endpoint offset, downsampling ratio, and priority decay are entangled with the retrieval, so how much it costs to re-tune these values when moving to a new task is worth keeping an eye on.
One question also remains. Whether the fleet getting better as it grew is due to the "quantity" of experience or the "diversity" of situations that different robots encountered has not yet been teased apart.
The structure of this paper can be carried over to ONTLE's operations as a hypothesis. Everything below is an assumption. It is not something we have actually run, but a sketch of what might happen if we did.
Suppose ONTLE's AI project manager (PM) is deployed into several client companies and handles multi-step work like "issue a tax invoice → route for approval → reflect it in accounting." Now say there is a PM whose approval routing keeps tangling, specifically on a certain client's form. If a human operator has to hunt down each of those failures one by one and attach a correct handling example, then as the workload grows, the operator gets just as busy. This is exactly the point where the question stands: can you reduce repeated failures without spending more on labor?
Lay the paper's framework over this and it goes like so. Using the context of the moment that PM got stuck as the query, you retrieve past handling records that completed the same type of approval routing correctly. Rather than imitating the failed handling, you use only the success cases already accumulated as the model. Let's nail down the method of use to one thing: not referring to retrieved success cases on the fly mid-execution, but gathering them over a set period and re-training that PM's way of handling things (the same grain as the paper's fine-tuning).
That said, a robot platform and office work rest on different premises. Don't take it as a rule as-is; settle the three things below first, then validate it as a hypothesis.
The endpoint of validation is clear. Split it into before and after applying retrieval, and measure how much the re-failure rate and the number of human interventions on the same work dropped. If these two metrics fall meaningfully, it becomes the first evidence that a structure that worked in a robot fleet also works in office work.