Concepts
Mental models for building on the Menlo Platform — architecture layers, robots, simulator, and sessions.
The mental model you need before writing code. For exact message shapes and field lists, see the Wire format reference.
Architecture layers
System 2, 1, and 0 — the three timing contracts of robot software.
Robots
Virtual vs physical. Same API surface, different hardware.
Simulator
Digital Asimov — a browser-based digital twin.
Sessions & channels
How the browser, cloud, and robot stay connected in real time.
Architecture layers
Robot software is organized into three layers with different timing contracts. System 2 can take seconds to reason; System 0 must respond in microseconds. A well-designed robot moves work down the stack only as fast as the timing budget allows.
| Layer | Timing | Responsibility |
|---|---|---|
| System 2 | 100 ms – seconds | Goal reasoning, task planning, LLM queries |
| System 1 | 10 – 100 ms | Skill execution, behavior trees, reactive policies |
| System 0 | < 1 ms | Motor drivers, sensor reads, real-time control loop |
Robots
A robot is the core resource in the platform. Every robot — virtual or physical — exposes the same API surface, so code written against one deploys to the other without changes.
| Type | Description |
|---|---|
virtual | Simulated robot running in the browser via Digital Asimov. No hardware required. Access at try.menlo.ai — the simulator creates a robot automatically. |
physical | An Asimov humanoid robot. Controlled today via the Asimov API. Platform UI integration is coming soon. |
Physical robots additionally expose firmware modes (damp, stand, move) controlled through the Asimov API. Those modes aren't surfaced in the Platform UI today.
Simulator
Digital Asimov is a browser-based digital twin of the Asimov robot.
- Runs in the browser — no local install required. Access at try.menlo.ai.
- Uses actuator models measured from real hardware, not idealized physics.
- Streams telemetry over the same protobuf wire format as physical robots.
- FPV and third-person camera views, captured as a video track.
Agents validated in the simulator deploy directly to physical hardware without code changes. See Digital Asimov for the full guide.
Sessions & channels
A session is a live, bidirectional WebRTC connection to a running robot. The browser and the robot all join the same session and exchange messages over a fixed set of channels.
The channels have different reliability guarantees tuned to what they carry:
- Commands go out on a reliable, ordered channel — you don't want a "stop" to get dropped.
- Telemetry comes back on a lossy channel at ~10 Hz — if a packet drops, the next one is 100 ms away anyway.
- System events (boot progress, errors, mode changes) flow on a separate reliable channel so you can react to state transitions without polling telemetry.
- Video and audio are standard WebRTC media tracks.
Start a session with the Python SDK's connect() function. For the exact channel names, message shapes, and field lists, see the Wire format reference.
How is this guide?