Why we are building a cloud for embodied AI
An embodied agent is not the same kind of thing as a chat agent: its output cannot be undone, and latency is a safety property rather than a comfort one. This is how we think about the four kinds of model on a robot, the single criterion we use to decide which of three layers each belongs to, and the two lines we will not cross — the control loop passes through no cloud, and local and remote stay one interface.
An embodied agent is not the same kind of thing as a chat agent
Almost every agent today outputs a piece of text or an API call. They share one luxury: they can be undone. A wrong answer can be restated, a wrong call rolled back, a few seconds of delay is merely a poor experience.
An embodied agent has no such luxury. Its output is physical motion — the arm has already reached out, the foot has already stepped.
Push that one difference down and you get four entirely different engineering premises:
- Actions cannot be undone. A wrong command does not surface as an error message. It surfaces as a knocked-over cup, or as someone being bumped into. "Refuse rather than guess when uncertain" is not fastidiousness here; it is the floor.
- Latency is a safety property, not a comfort property. Two seconds of delay in a chat is waiting. Two hundred milliseconds of delay while a robot is walking is another fifteen centimetres travelled.
- The input is a stream that never stops, not a question. It is listening, seeing and sensing its own posture at the same time. It is not invoked; it is awake.
- It occupies a space with other people in it. A script that misbehaves affects a dataset. A robot that misbehaves affects the people around it.
Four kinds of model, doing four different jobs
The industry lumps these together as "large models". On a robot they are four distinct roles, with different demands, different release cadences, and different answers to "does this still work with the network down":
| Kind | What it does | Example |
|---|---|---|
| Language model | Thinks — understands what you want, decides the steps | "Take me to hall three": navigate first, then explain |
| Perception model | Senses — hears, sees, reads text, recognises people | Catching what you said in a noisy exhibition hall |
| Action model | Moves — turns one sentence into the arm's position every millisecond | "Hand me the red cup" |
| World model | Rehearses — plays the action out internally before committing to it | Will reaching there knock something over |
Deploying all four as if they were one kind of thing is where a lot of embodied stacks get stuck today.
So we split it into three layers
Where a model belongs is decided by exactly one criterion: who is responsible for the contention.
Compute on the robot is fixed, and it is fought over — hearing wants it, vision wants it, the action model wants it. "Should these two gigabytes go to speech recognition or to grasping" is a trade-off only something that knows what the robot is doing right now can make. Those models stay on the robot.
Compute in the cloud is elastic, and its trade-offs are throughput, cost and autoscaling — a different discipline, with different metrics and a different person on call. Large action models and world models belong there.
Below all of it sits a layer that hardly counts as intelligence at all: balance, joint servo, emergency stop. Millisecond scale, never in the cloud.
Two lines we will not cross
The control loop does not pass through any cloud. Metering, billing and usage accounting all run out of band, asynchronously. If the cloud is down, the account is out of credit, or the network is cut — the robot may get dumber, but it must not stop mid-motion, and it certainly must not fall. That is not a disaster-recovery feature; it is the product definition.
Local and remote are the same interface. The card on your canvas does not need to know whether it is talking to a small model on the robot or a large one in a machine room; swapping them does not mean rewriting your solution. What was separated is who maintains it, where it deploys and what it is judged on — not the interface.
Where we want this to go
What one robot learns, every robot knows. The experience of a single robot is thin. The experience of a hundred robots in a hundred real settings is not. The real value of the cloud layer is not that it computes faster; it is that it is the only place that experience can converge.
Changing robots should not mean changing software. Switching vendors today usually means starting over. We want solutions to be portable: the same solution installed on a different robot, whose hands and feet have changed but whose repertoire has not.
Capability grows in the cloud; reflexes stay in the body. Like a phone — the cleverest part lives far away, but it never stops responding to your touch just because there is no signal. A robot should have the same shape: the cloud makes it smarter by the day, while whether it stays upright is always its own business.