SIFEI LIU / RESEARCH
01 / ASENACode as Policy + RSI

ASENA: Self-Evolving Agents
for Embodied Navigation

ASENA connects a coding model to embodied tools, execution feedback and a persistent workspace.

Presentation slides ↗
ASENA / SYSTEM DESIGN

The agent composes; the robot stack executes

ASENA connects a coding agent and persistent workspace to embodied tools. The agent can delegate navigation to a learned policy or construct motion proposals; execution authority stays with the platform.

Robot state

Observations

Camera · LiDAR
Pose · joints

Persistent workspaceCode · skills · experience
Inspect + revise
Decide + compose

Coding agent

Interpret the task
Choose the computation
Call and combine tools

Delegate a goal · optional

Learned VLN policy

Goal + recent RGB
→ Navigation waypoints

and / or
Construct a proposal

Programmed motion

Geometric waypoints
Upper-body joint targets

Execution boundary

Validate
+ approve

Independent checks
Operator approval

SONIC

Whole-body control
Balance + locomotion

G1 robot geometryG1
New observations · execution outcomes · operator feedback return to the agent
Navigation-policy results came from simulation; G1 demonstrated supervised execution. Adapted from Anjie Cheng’s slide 4.
ASENA / WORKSPACE RSICode and skills improve · model weights stay fixed

Parallel workers improve a shared workspace.

Sixteen simulation workers start from separate copies of a shared workspace, develop reusable skills and retain execution feedback. Between passes, their improvements are merged into the shared workspace for the next round. All model weights stay fixed.

Fixed coding agentCoding model serves independent worker contextsEach worker has its own task context.
Task allocation · private workspace per worker
01Worker
Private code + skills
↕
Simulator + policy instance
02Worker
Private code + skills
↕
Simulator + policy instance
…16Worker
Private code + skills
↕
Simulator + policy instance
Gather traces, local edits and task outcomes between passes
Fixed improver modelMerge, test and prune code and skills

Distribute the updated notes and skills to the next pass.

↶Wₖ₊₁ = Improve(Wₖ, traces, feedback)

Implemented in simulation: workers execute independently, inspect peer work and exchange tips through a shared bulletin. Between passes, consolidation merges, tests and prunes code and notes. This diagram shows logical instances, not a one-GPU-per-worker allocation.

Workspace-evolution protocol · paper §4.4 ↗

ASENA / EXECUTION AUTHORITY

Safety is enforced outside the coding agent

The deployment bounds the agent and its subprocesses. Motion passes through checks outside the agent, operator approval, and a controller that maintains balance.

Restricted process
+ every child process

Within the boundaryCoding agent+ scripts / subprocesses
Scoped resources
  • Python · NumPy · MuJoCo
  • Scratch files + reusable skills
  • Robot device API
  • Model API proxy
Unix identityProtected files + credentials
Network allowlistDevice + model proxy only
Inherited seccompBlocks direct kernel/device paths
No direct path
  • Raw CAN /
    packet sockets
  • Operator
    credentials
  • Platform writes /
    privilege escape
Checked execution path
  1. Motion proposalWaypoints / joint trajectory
  2. External validationBounds · joint limits
    Robot self-collision checks
  3. Operator approvalApprove or return a reason
  4. SONIC → G1Balance + locomotion
    Independent stop
Launch preflight verified the boundary.Reflection disabled motion.
MuJoCo gesture checks used the robot’s self model, not full environment physics. Supervision remained necessary. Slide 6.
How the workspace relates to agent trainingOptional comparison: workspace updates today; a proposed model-training extension

The existing workers execute programs through the simulation interface. The comparison below changes the update target from retained code and skills to the coding agent’s weights.

Fixed coding agentCoding model serves independent worker contextsEach worker has its own task context.
Task allocation · private workspace per worker
01Worker
Private code + skills
↕
Simulator + policy instance
02Worker
Private code + skills
↕
Simulator + policy instance
…16Worker
Private code + skills
↕
Simulator + policy instance
Gather traces, local edits and task outcomes between passes
Fixed improver modelMerge, test and prune code and skills

Distribute the updated notes and skills to the next pass.

↶Wₖ₊₁ = Improve(Wₖ, traces, feedback)

Implemented in simulation: workers execute independently, inspect peer work and exchange tips through a shared bulletin. Between passes, consolidation merges, tests and prunes code and notes. This diagram shows logical instances, not a one-GPU-per-worker allocation.

ASENA / POLICY & AGENTEvaluate the tool, then the combination

The navigation policy improves route geometry.

Reported monocular · 4B models

ASENA-VLN is the optional navigation tool the coding agent can call. Evaluated alone, it reaches closer to the goal on both benchmarks. Success improves on R2R; RxR shows a tradeoff between trajectory fidelity and successful completion.

R2R

MetricQwen-RobotNav
4B		ASENA-VLN
4B
Success ↑66.9%68.7%
Navigation error ↓4.22 m3.52 m
Path efficiency · SPL ↑60.564.2

+1.8 points in success−0.70 m navigation error

RxR

MetricQwen-RobotNav
4B		ASENA-VLN
4B
Success ↑71.3%70.2%
Navigation error ↓4.15 m3.90 m
Path efficiency · SPL ↑61.559.7
Trajectory fidelity · nDTW ↑68.673.1

−1.1 points in success+4.5 points in nDTW

Reported policy-only results: ASENA, Table 1 ↗ and Qwen-RobotNav v3, Table 1 ↗. Both use monocular observations; training recipes, data mixtures and evaluation filtering differ.

What changes when the coding agent calls the policy?

Agent + tool · fresh workspaces

Delegating navigation reduces tool calls for both coding agents. Success improves for Sonnet, while Astra trades some success for fewer interactions.

Claude Sonnet 5

Adding ASENA-VLN
MetricAgent onlyWith policy
Success50%61%
Tool calls / episode103.8338.91

+11 points in success62.5% fewer tool calls

GPT-6 Astra

Adding ASENA-VLN
MetricAgent onlyWith policy
Success93%86%
Tool calls / episode40.8019.98

−7 points in success51.0% fewer tool calls

RxR Agentic Split, 100 tasks per configuration, before workspace evolution. Sonnet improves from 50% to 61% success; Astra drops from 93% to 86%. Tool calls are agent–tool interactions, not physical steps or elapsed time. Paper §4.3 and Table 3 ↗

ASENA / WORKSPACE EVOLUTIONPrograms and experience accumulate · weights stay fixed

The workspace improved across repeated tasks.

Recorded experiment · 10 passes

Workers retained code, notes and tested skills between passes. Navigation success increased while the coding model, improver and policy weights stayed fixed.

Success rate (%)16 workers · 100 tasks per benchmark
Navigation success over ten passes with fixed model weights On the same recurring tasks, R2R success changes from 72 to 98 percent with the policy and from 60 to 97 percent for the agent alone. RxR changes from 65 to 89 percent with the policy and from 48 to 80 percent for the agent alone. Solid lines denote agent plus policy; dashed lines denote agent only. The vertical axis spans 40 to 100 percent. Exact values follow in the data table. 40 60 80 100 1 3 5 7 10
Pass over recurring task set
  • R2R + policy72 → 98%
  • R2R agent only60 → 97%
  • RxR + policy65 → 89%
  • RxR agent only48 → 80%
Protocol: 16 Claude Sonnet 5 workers at high effort; each pass repeats the same scenes, instructions and starting states. Traces are retained and replay is allowed, so these gains can include route and scene memory. The first pass belongs to this evolution campaign; it is separate from the fresh-workspace agent comparison above.

Source: ASENA, Fig. 4 and §4.4 ↗; recorded navigation series reproduced from An-Chieh Cheng’s slide 12. Download plotted values (CSV).

Inspect all ten passes
Success rate (%) · identical values to the plotted curves
PassR2R
+ policy		R2R
agent only		RxR
+ policy		RxR
agent only
172606548
279707057
386786861
491897068
590937070
693947874
795938077
898958379
998968680
1098978980
ASENA / RECORDED EXPERIENCEReal G1 recordings

Replay what the robot saw and did.

ASENA records camera observations, measured robot motion and agent events in MCAP. The replay aligns the camera, joint states and body pose on the same clock, so an execution can be inspected after the run.

One recorded 10-second window: the camera, joint trace and body replay share the same clock. The rendered G1 follows measured robot states. The camera was recorded at approximately 2 Hz; repeated frames preserve its original timing.

Inspect the saved events and measured motionAgent requests · operator feedback · a two-second motion example

Keep the decisions and feedback, too.

Additional event channels
Agent proposal · recorded example

What did the agent request?

upper_body(motion="yes_circle")

A motion request from the snack mission, linked to its task context and execution record.

Operator & outcome

What was permitted? What worked?

Approval fields
decision + reason
Recorded task verdict
completed

Approval authorizes execution. The task verdict is a separate outcome signal.

Speech input · field structure

What did the person say?

via: "voice"
user_content: "…"

Accepted ASR text enters the agent event stream. This recorder does not store raw microphone audio.

The proposal and task verdict are recorded examples from a separate snack mission. Approval and speech fields show the interface structure; these cards are not synchronized events from the clip above.

A measured motion example

What happened over two seconds

Take the preceding camera observation and robot state, then measure the motion over the next two seconds.

Recorded interval: 582.5–584.5 s
Measured local motion
Forward
0.466 m
Lateral
0.191 m
Yaw
0.369 rad

These values come from recorded odometry and describe the motion that actually followed the observation.

Recorded signals and provenance

The camera and measured-body replay come from deck-20260908-175129.mcap, bag time 579–589 s. The two-second motion example is a subset of that same recording. The separate snack-mission examples come from September 9; they are not labels for the walking clip.

The recorded channels include camera observations, robot state, control telemetry and agent events. Accepted voice text is logged in the event stream. The parallel simulation rollout pipeline is separate from this physical-robot recorder.

Paper §3.2 and Fig. 2 ↗ · Recorded-data walkthrough ↗ · Open the replay ↗

Possible reuse: curated real-robot recordings could later support SFT; an RL extension would use the simulation environment.

Next: Recova. Recova uses task and recovery experience to train manipulation policies that return to deployment. Explore the Recova tutorial ↗

03 / WATCH THE LOOPobservation → decision → code → action → feedback

The next action depends
on what just happened.

Follow a real recording one turn at a time. Pause on a decision, inspect the program, then see the feedback that changes the next turn.

Check whether the machine has my snack. Report back silently.
Recorded G1 demonstration
Desk → vending machine → person00:00
Code as PolicyTURN 01 / 07

OBSERVATION

DECISION

PROGRAMReadable pseudocode
Paused · advance at your own pace
State carried forward

Replay sources and timing

Open the complete demo clip ↗

The adjacent programs and decision summaries explain the control flow; they are not verbatim private reasoning or raw execution logs. Each turn plays its selected footage and holds briefly for reading. Step controls let you inspect it without speeding up the recording.

ASENA

Execute programs, inspect outcomes and retain useful skills.

Recova

Build the recovery loop that keeps embodied experience coming.