From Atoms to BitsBuilding the Digital Development Loop for Physical Intelligence

What has to move into computation

A robot’s operating loop is to perceive, act, and observe the result. Its development loop is to change a model, test it, understand the result, and decide what to change next. Moving this second loop into a digital environment is the larger opportunity.

Training on a computer already gives us digital model updates. But if every meaningful comparison still requires new robot trials, the pace of development remains tied to physical experimentation. Evaluation is what lets us decide which digital changes are worth keeping. Without it, more generated data or simulated rollouts need not produce better robots.

A useful digital experiment therefore needs evidence from the world, a representation that preserves what matters for control, an environment in which alternative actions can be tested, and a process that evaluates the results. These requirements explain why data acquisition, perception, world modeling, and digital agents belong in the same research agenda.

Model-based learning has long connected real experience with simulated experience, as in Sutton’s Dyna architecture.¹ The ambition here extends across the development lifecycle: use computation to collect and process experience, build models, test revisions, and diagnose failures, while physical experiments establish where the digital conclusions can be trusted.

Why these four capabilities belong together

The dependencies matter. Observations alone cannot tell us what would happen under a different action. A useful representation still cannot execute an experiment. A simulator can produce outcomes without telling us whether a model improved. Four works from our collaborations address parts of this chain; integrating them into a reliable development system remains a research goal.

1. Acquire the experience the loop needs

Video in the wild offers interaction data without robot action labels: people grasp, push, place, and recover from mistakes. This can support learning before we collect task-specific robot demonstrations. But a recording shows what happened once. It may leave the causes of success unresolved.

IVE addresses the complementary problem of acquiring new experience. It uses semantic scene graphs and memory to propose configurations, checks their predicted feasibility, and executes them through action tools. The collected experience is evaluated for downstream learning.² Physical interaction remains necessary; an agent helps choose and organize it.

Within the proposed loop, acquisition would respond to a specific uncertainty. If two release strategies cannot be distinguished digitally, the system should collect an interaction that helps resolve that comparison. Connecting exploration to this evaluation need is a further step.

2. Preserve the information that changes an action

Experience is useful only if our models retain the relevant information. Recognizing a mug does not establish where to grasp it or whether it will remain supported after release. For control, geometry and motion matter alongside object identity.

DynaFLIP uses image–language–3D flow triplets from human and robot videos to train a visual representation. Motion provides supervision during pretraining; the resulting encoder takes images as input at deployment. The work evaluates these features in downstream manipulation.³

This connects data to the rest of the loop: representations should preserve distinctions that change predicted outcomes or policy performance. Information discarded here can limit both the controller and the world model built on it.

3. Turn physical experience into executable experiments

To evaluate a controller, we need an environment that responds to its actions and returns the observations used to choose its next action. Replaying a video cannot answer whether releasing the mug later would help.

μ₀ offers a foundation through 3D interaction traces: trajectories of salient points on objects, hands, and tools. TraceExtract obtains supervision from heterogeneous videos, and the pretrained trace model can support different robot embodiments through action experts.⁴ This supplies an inspectable motion representation. It does not yet constitute a general simulator for evaluating arbitrary policies.

A research direction is to combine learned dynamics with explicit objects, relations, and task conditions in a neural-symbolic world model. For the mug, predicted motion would be connected to a testable condition: does it remain supported after release? Such a model would still need to reproduce the effects of actions, relevant contact behavior, and the observations seen by the controller. Making the state explicit helps us inspect these assumptions; it does not make them correct.

4. Make experiments accessible to digital agents

A simulator alone leaves substantial work to the researcher: choose tests, run candidates, measure outcomes, investigate failures, and propose revisions. Automating this work would let us run more experiments without requiring a researcher to manage each one.

Guava studies how reasoning models use embodied tools through iterative perception–reasoning–action, semantic action abstractions, and multimodal observations.⁵ Its demonstrated setting is manipulation. I propose extending this interface principle to development: give digital agents tools for testing and improving physical agents.

The distinction is concrete. A manipulation agent selects how to place the mug. An evaluation agent compares the models that select those actions and gathers evidence for deciding which one to keep.

Build simulators that improve with evidence

For this loop to work, constructing the simulator must become part of development. Real observations provide initial estimates of the scene, robot dynamics, and observation process. Paired physical trials then expose mismatches, which guide corrections to the digital environment. Closing the real-to-sim gap becomes an ongoing experimental process.

The relevant fidelity depends on the decision. A simulator may be adequate for rejecting an infeasible approach yet too inaccurate to compare two release times. In the mug example, we need agreement on how release timing affects stability, including any visual differences that change the policy’s behavior. A convincing rendering alone cannot establish that agreement.

Video may not determine friction or compliance. The environment should retain plausible alternatives until additional sensing or physical interventions distinguish them. If the preferred controller changes across those alternatives, that uncertainty is a reason to run a physical test.

The simulator should accumulate a record of which comparisons have been checked, under which conditions. A new trial can then improve both the robot model and the environment used to evaluate future models. The aim is to expand the range of model changes we can evaluate reliably between physical checks.

Give digital agents the evaluation work

An evaluation agent could compare perception models, world models, or policies by selecting relevant scenarios, running controlled experiments, computing task metrics, and preserving the configurations and trajectories behind each result. It could then identify a likely failure mechanism and propose a revision or a physical check.

For the mug, it might compare release strategies from matched initial conditions, measure whether the mug remains supported for a specified duration, repeat trials to estimate variability, and test across plausible contact parameters. The success rule should be specified before the comparison and checked against recorded outcomes. A persuasive explanation from the agent is insufficient evidence.

The agent has two evaluation responsibilities: assess the candidate models, and assess whether the simulator supports that assessment. SIMPLER provides a precedent for comparing simulation evaluations with physical results, including agreement in policy rankings.⁶ A development system needs to maintain that agreement as models change.

This becomes harder under optimization. A policy could exploit a simulator that makes contact too forgiving, releasing earlier and improving its digital score while becoming worse on the robot. Agreement on yesterday’s policies does not guarantee agreement on a policy optimized against the simulator.

Selected physical checks must therefore continue across development rounds, with independent held-out tests for the final claims. When reality contradicts a digital result, the agent should investigate both the candidate model and the experimental environment. When evidence is insufficient, its useful output may be the next experiment to run.

Measure the development process

The strongest skeptical interpretation is that this adds an expensive simulator and an agent to a familiar model-based workflow. The proposal earns its value only if it improves the cost and reliability of developing real robots.

I would compare direct physical evaluation, an established simulation workflow, and the proposed calibrated, agent-operated loop over successive model revisions. Each would start with comparable data and the same physical interaction budget. Their selected policies would face common held-out physical tasks.

The decisive result would be better physical performance for that budget, with compute and human effort also reported. We should track whether digital comparisons remain predictive after optimization and whether the benefit persists across rounds. Removing simulator updates, accumulated tests, or agent automation would help identify which parts produce the gain.

What the next robot should inherit

The next robot may have a different gripper. It cannot assume that the old correction will prevent the mug from slipping. It can inherit the failure case, the competing explanations, the experiment that distinguishes them, and the conditions under which the digital result was verified.

I want future robot learning systems to improve their own ability to experiment. Each verified interaction would help establish which questions can be answered digitally and which still require the robot. A growing body of reusable tests and calibrated environments could support many model revisions between physical checks. The cost of exploring the next idea could then depend increasingly on computation.