Zetta-Embodiment: an online evolution harness that keeps the robot policy frozen

The problem Zetta-Embodiment targets: a frozen policy that cannot recover

A vision-language-action policy trained once tends to fail the same way twice. The robot reaches the same object, the same grasp slips, the same subgoal is abandoned, and the only fix available to the operator is another training run. Zetta-Embodiment takes the opposite position: keep the base policy frozen and let a separate, code-based layer evolve around it. The README describes the project as an efficient closed-loop embodied harness for self-evolving physical intelligence, and reports state-of-the-art success on LIBERO-Pro (90.8%) and RoboCasa (93.6%) with an 11.1x inference speedup. Those numbers come from the project's own claims; nothing in the repository layout lets an outside reader reproduce them without the simulator assets and model weights, which the README states remain outside Git. The intended user is an embodied-AI engineer who already has a working policy checkpoint and a simulator harness, and who wants failure recovery to improve between runs rather than between training jobs.

How the evolution loop works: rollouts, clusters, stages and gates

The README prints the protocol as a linear pipeline. It starts with 50 development rollouts and an explicit instruction never to use seeds 1 through 20. Failed trajectories are grouped into a failure cluster using synchronized video, bounded telemetry and failure segments. Stage 1 performs a causal diagnosis and explains one observable failure mechanism, but the role description states it cannot write or execute recovery actions. Stage 2 is the candidate writer, and it emits one frozen Critic-Recovery bundle whose parameters must satisfy the published tool schemas. Before anything reaches the robot, the candidate goes through shadow replay, then a paired same-seed gate, then held-out seeds 1 through 20. The loop either rejects the candidate and returns to Stage 2 or promotes it.

The role boundaries are the interesting part. Role1 accepts or rejects a Critic proposal and is described as the sole high-level decision authority during candidate execution. The Critic may only propose a recovery. The recovery actor executes only an accepted, bounded recovery program, and only the environment actor may write simulator actions. That is a deliberate split between proposing and acting, and it is what makes an online loop defensible: a generated recovery cannot reach the simulator without passing a gate and an authority check. A campaign root on disk reflects the same structure, with manifest.json, preregistration.json, task-contract.json, tool-catalog.json, state.json and separate directories for episodes, failure-clusters, diagnoses, proposals, shadow-replay, gates and promoted bundles.

Installing Zetta-Embodiment and running the simulator-free test environment

The README states that Python 3.10 through 3.12 is supported, and pyproject.toml confirms this with requires-python = ">=3.10,<3.13". The minimal test set is the only path that needs neither a simulator nor a model, which makes it the right first step before you commit to asset downloads.

python -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install -e ".[test]"

The editable install pulls the test extra, which pyproject.toml defines as pytest, pytest-asyncio, omegaconf, imageio-ffmpeg, scipy plus the runtime and geniesim-vla extras. After it completes, the two console entry points declared in pyproject.toml are available: zetta, which maps to zetta.cli.main:main, and zetta-evolve, which maps to zetta.evolution.cli:main. Run the tests directory next; the README describes it as unit and contract tests that need no simulator or model. That is the cheapest way to confirm the package imports and the tool schemas load before you touch a GPU.

Moving to a real policy means picking exactly one simulator track. The VLA runtime environment is built by a single script that takes a track flag, and the README warns that the tracks cannot share venv state because the robosuite versions are incompatible.

export REPO_ROOT=/abs/path/to/Zetta-Embodiment
export VENV_ROOT=/abs/path/to/venvs/vla-env
bash scripts/deployment/install_vla_env.sh --track libero-pro

The LIBERO-Pro track downloads its scene and object assets automatically, and the README gives a manual refresh command, "$VENV_ROOT/bin/liberopro-download-assets" --skip-existing, for when you want to re-fetch them. The RoboCasa track instead expects a source checkout containing robocasa/, robosuite/ and Isaac-GR00T/, plus the kitchen assets, which the README puts at roughly 10GB and points at the upstream RoboCasa installation guide to fetch.

Where Zetta-Embodiment gets expensive: venv isolation, asset weight and unfinished integrations

The clearest constraint is that one venv serves one track. LIBERO-Pro, RoboCasa, RoboTwin and Genie Sim each carry their own dependency stack, and the README states plainly that the tracks cannot share venv state. If you want to compare a policy across two simulators, you are maintaining two environments and two sets of assets. RoboCasa alone adds about 10GB of kitchen assets on top of the source checkout, and the Genie Sim path wants Isaac Sim 5.1 running as an isolated Python 3.11 simulator process, which is a second interpreter alongside the 3.10 to 3.12 range the package itself allows.

The integration list is also moving. The README's own TODO marks ManiSkill as native Panda/PickCube with model validation pending, and BEHAVIOR as not yet added. Genie Sim is documented with current single-task limits: the native geniesim backend supports the RoboColiseum g2op_if_pick_block_color task, and the geniesim_vla backend adds a G2 CoRobot WebSocket policy protocol. ManiSkill real VLA and campaign validation requires a matching native PickCube checkpoint and normalization stats, per the README. None of this is a defect in the design, but it means the harness is not a drop-in for an arbitrary robot and task today. It is a harness whose coverage is expanding at roughly one integration per week according to the TODO, and each new integration arrives with its own validation status.

Zetta-Embodiment compared with a plain reward-shaping or fine-tuning loop

The obvious alternative is to keep the policy as the thing that learns: collect failures, fine-tune or run offline RL on them, and redeploy. That approach changes the weights, so every improvement forces a new evaluation of the whole policy, and a regression in one task can silently damage another. Zetta-Embodiment changes only the critic and recovery code, which is why the README can describe the base policy as frozen and still claim gains. The trade is that the harness can only fix failures that a bounded recovery program can express. A failure that requires a different grasp representation, or a different action space, is outside what a runtime recovery actor can do, because the role description limits it to executing an accepted, bounded recovery program.

A second alternative is a hand-written error-recovery state machine in the robot client. That is simpler and fully auditable, and it does not need pydantic-ai, FastAPI, msgpack or the MCP dependency that pyproject.toml lists. What it lacks is the gate. Zetta-Embodiment's shadow replay and paired same-seed gate exist to stop a candidate that looks good on the development rollouts from being promoted on noise, and the held-out seeds 1 through 20 are withheld from development precisely so the gate has something clean to measure against. If you are not prepared to run that many rollouts per candidate, the gate stops being meaningful and the hand-written state machine starts looking like the better engineering choice.

Maintenance, release cadence and the missing licence file

The repository is not archived, and the last push was on 2026-09-16, one day before this review. The README's TODO shows a dated cadence through August and September 2026, with one integration per week described as ongoing and BEHAVIOR scheduled for 2026-09-20. There are no retrieved releases, so there is no versioned upgrade path to follow; pyproject.toml still declares version = "0.0.0" and classifies the project as Development Status :: 2 - Pre-Alpha. Expect to track the main branch.

The licence is the open question. pyproject.toml sets license = {file = "LICENSE"}, but LICENSE does not appear in the top-level repository entries, and no licence identifier was retrieved. THIRD_PARTY_NOTICES.md is present, which suggests the project is aware of its dependency obligations, but that file is not a substitute for the project's own terms. Until a LICENSE file exists and states the terms, treat the code as having no granted rights and ask the maintainers directly. That is a factual gap in the repository, not a legal opinion, and it should be resolved before anything derived from this code ships.

Editorial conclusion

Adopt Zetta-Embodiment if you already run a frozen VLA policy in LIBERO-Pro, RoboCasa, RoboTwin, Genie Sim or ManiSkill and want the critic and recovery layer to change without retraining the policy. Do not adopt it if you need a stable API, a published licence or a single venv that covers several simulators, because the repository states the tracks cannot share venv state and the pyproject file points at a LICENSE file that is not in the listing. Before committing, run the minimal test environment, read docs/geniesim-vla.md and docs/maniskill.md, and confirm the ManiSkill model validation and the BEHAVIOR integration, both of which the README still marks as unfinished.

Frequently asked questions

Official sources

1. air-embodied-brain/Zetta-Embodiment on GitHub
2. Issues
3. README