Enact launch — post-training infrastructure that generates targeted recovery data for robotics VLAs

ListenThe Failure-Recovery Data Engine, As a Service8:54

Show notes

Enact launches as third-party post-training infrastructure for robotics VLAs: it finds where a deployed policy fails, generates targeted recovery demonstrations, and returns retrained checkpoints. We dig into their two anchor results — a packing task that jumps from ninety to ninety-nine out of a hundred with just fifty recovery demos, and a table-bussing long-tail failure that demanded an entirely new skill. Along the way: why happy-path data leaves a recovery gap, why this is just DAgger productized, and the load-bearing question the launch thread never answers. **Sources** - Enact launch — post-training infrastructure that generates targeted recovery data for robotics VLAs (James Stevens, Govind Chada)

Subscribe to the channel: https://podcast.lumalabs.link/27a25f51ea81d41a8253f46c6133a35e/feed.xml

TL;DR

Enact (James Stevens, Govind Chada; enact.company) launches as a robotics post-training service that identifies where a deployed policy fails and generates the targeted recovery demonstrations needed to fix those failures. The pitch is a simple DAgger loop framed as productized infrastructure: roll out the current policy, find the states it reaches after mistakes, collect matching recovery demos, aggregate them into the training set, retrain. Two controlled results anchor the launch — a single-item e-commerce packing task where 200 happy-path demos on π0.5 failed 10/100 rollouts and adding 50 targeted recovery demos took it to 99/100 — and a table-bussing task where the long-tail failure (knife wedged under bin) required learning an entirely new skill the original task never demanded. First filed instance of the failure-recovery data engine as a third-party service layer rather than an in-lab recipe.

Key claims

Robotics policies trained only on happy-path demonstrations receive no training signal for recovering from their own execution mistakes; on a single-item packing task, 200 successful-placement demos fine-tuning π0.5 produced 10/100 rollout failures with no learned recovery [tweet, posts 2–3].
Adding 50 targeted recovery demonstrations (collected at the states the policy actually reaches after failures like table drops) to the training set takes packing success from 90/100 to 99/100, recovering from every table drop in the eval [tweet, post 4].
The mechanism is standard Dataset Aggregation (DAgger): roll out current policy → collect recovery demos at reached failure states → aggregate → retrain [tweet, post 5].
Rare long-tail failures can demand new skills not required by the original task specification. In a table-bussing deployment, roughly 1 in 100 runs wedged the knife under the bin, and the only recovery required moving the bin itself — a behavior the base task never involved [tweet, posts 6–7].
Finding these long-tail states and generating the data to cover them is what Enact positions as production-critical infrastructure; the company is already serving customers by running the loop against real deployed-model failures [tweet, post 8].

Method

Enact’s public method is DAgger, positioned as post-training infrastructure rather than a research contribution. The launch thread does not disclose how failure states are discovered in customer deployments (whether via human review, VLM success detection, telemetry-triggered flags, or a mix), nor how recovery demonstrations are collected (teleop, scripted expert, kinesthetic). The controlled ablation on packing is standard: fine-tune π0.5 on happy-path demos only, roll out, count failures, collect 50 recovery demos at observed drop states, retrain, re-evaluate on the same 100-rollout protocol.

The table-bussing anecdote is the more interesting operational claim — that the loop must be able to extend the skill library (bin-moving) when a long-tail failure exposes a capability the policy was never trained to have, not just add examples of existing skills at OOD states. No detail on how the new-skill demonstrations are elicited or how the retrained model is verified to have learned the skill without regressing.

Results

Packing task: 200 happy-path demos → 10/100 rollout failures. + 50 targeted recovery demos → 99/100 consecutive successes, all table-drop failures recovered [posts 3–4].
Table-bussing: ~1/100 rollouts hit a novel long-tail state (knife-under-bin) requiring an entirely new skill (moving the bin) not in the original task specification [posts 6–7].
No numbers on customer deployments; company is “already serving [its] first customers” [post 8].

Why it’s interesting

Enact stakes out a third-party productized position on an axis this wiki tracks heavily: how to close the failure-recovery gap for VLA policies. The three existing recipes on file are (a) EgoRecovery: Acquiring Failure Recovery Ability Through Human Recovery Demonstration‘s egocentric-human capture as a >10× cheaper recovery-demo substrate; (b) FailSafe: Reasoning and Recovery from Failures in Vision-Language-Action Models‘s pure-simulator failure synthesis with executable-delta verification; and (c) OopsieData — a multi-lab dataset of real robot manipulation failures‘s OopsieData multi-lab federated real-robot-failure pooling. Enact is the service-layer counterpart — the customer runs their own policy, Enact runs the discovery + collection loop and returns retrained checkpoints. That’s structurally distinct from the offline curated datasets (OopsieData) and from the in-lab methods (EgoRecovery, FailSafe): the value proposition is running the DAgger loop against a specific deployed model in a specific customer environment on an ongoing basis.

The knife-under-bin anecdote is the sharpest concrete example on file of the observation The Physics of Multi-Turn Long-Horizon Planning: From Pre-training to Post-training via Single- and Multi-Teacher On-Policy Agentic Distillation and χ0 (Kai0): Resource-Aware Robust Manipulation via Taming Distributional Inconsistencies both approach from theory — that a policy’s own errors define the states it must be trained on, and those states can fall entirely outside the task’s original skill specification. It also sits alongside Assemble Bench and CG-DAgger — NIST small-parts assembly benchmark on Isaac Lab Arena + code-guided DAgger with zero teleop‘s CG-DAgger (zero-teleop code-guided scripted recovery for NIST assembly) as a second recent “productize the DAgger loop” datapoint, but with humans-in-the-collection-loop rather than scripted experts.

Open question the tweet doesn’t answer: whether the discovery step scales — finding the ~1/100 knife-under-bin state in a customer deployment requires some signal that a rollout was bad, and the launch thread doesn’t disclose whether that signal comes from human review, a success-detection VLM (Instance Labs — Verifying Robot Learning Episode Success is the closest filed comparable), or telemetry heuristics. This is the load-bearing gap between “DAgger works in principle” and “DAgger works as a service.”