Can I run a robot from the network?

No. A robot has to answer now, and E31 Network is being built for work that can wait. Its control loop, its live perception, its safety functions, and the tooling an operator watches while the machine moves all stay where the robot is: on the robot itself, on edge devices beside it, or on the dedicated local infrastructure your team already runs. None of that is ever submitted to the network, and the design does not have a place for it.

This is not a limitation the program plans to remove later. It is the line that defines the product.

The test

The question to ask about any piece of work is whether it can wait for a queue. A job submitted to the network may sit in a queue until compute is free, then run unattended, then return its output. A control loop cannot sit in a queue. Live perception for a moving machine cannot wait for compute to be free. A safety function that answers late has not answered.

If the work must answer now, it stays with you. If it can run tonight, it can run here. The workloads page draws that split, and what if my job cannot wait goes further into the cases that sit near the line.

What a robotics team would send

Almost everything around the robot is batch work, and that is what the network is for.

Retraining. The perception model that runs on the robot was trained somewhere, and it will need retraining as the environment changes and new footage accumulates. "I need compute tonight to retrain my model" is one of the four illustrative requests on the examples page for exactly this reason. The training run is a job; the trained model is the output; the model goes back to the robot.

Footage. A fleet produces more video than anyone watches. "I have forty hours of warehouse camera footage that needs processing" is a processing pass: label it, index it, find the moments worth a human's attention. It does not matter whether that pass finishes at midnight or at dawn, which is what makes it a network job.

Simulation. Before a policy change reaches a physical machine, a team wants to run it many times in simulation. "I need to run ten thousand simulations" is a sweep with a clear beginning, a clear end, and a report at the finish. It can wait for a queue, and the meter would not run while it does.

Where the network sits

Picture the loop: the robot runs its model locally, footage and logs accumulate, a job retrains the model on the network, the new model is returned, and a human decides whether it goes back to the robot. The network appears in one step of that loop, the one that is heavy, occasional, and patient. It never appears in the step where the machine is moving.

That is why the program refuses the labels people sometimes reach for: not robot control infrastructure, not an autonomous-system runtime, not an edge control platform. It is on-demand GPU compute for the jobs around the robot, rented by the hour and released when they finish.