Robots, edge devices, and your own systems
The real-time half of an AI system lives on robots, edge devices, and the systems a team already runs. E31 Network is being designed to sit beside them, not replace them.
· 4 min read
IN SHORT
Robots, edge devices, and a team's own systems are where real-time work runs, and E31 Network is being designed to leave them alone. The network takes the batch jobs that surround that work: training the models those devices run, processing the data they collect, and evaluating changes before they ship. Nothing on a robot would ever depend on the network.
A team that builds machines already owns a lot of compute, even if it does not think of it that way. There is the processor on each robot. There are the edge devices bolted to walls and conveyors. There are the servers in the back room that run the operator consoles, the logging, and the safety interlocks. All of that is real-time infrastructure, and all of it stays exactly where it is when the team starts renting compute from E31 Network.
This article is about that boundary: what lives on robots, edge devices, and a team's own systems, and what the network is being designed to do beside them.
What lives on the robot
A robot carries the models it needs to act. Perception that identifies what is in front of it, planning that decides where to move, and the control loop that turns decisions into motor commands all run on hardware the robot carries or on a local system a short cable away. They have to. The deadlines are measured in moments and the cost of a late answer is physical.
None of that is a network job, and the network is not being built to change it. A robot would not connect to E31 Network as part of its operating loop. What the robot produces, though, is a great deal of data: camera footage, sensor logs, records of what it did and what happened next. That data is where the network enters, later, as the input to batch jobs the team decides to run.
What lives on edge devices
Edge devices are the fixed cousins of robots: cameras with on-board inference, controllers on a line, gateways that aggregate sensors. Many carry a small GPU so they can answer locally without waiting on anything. That is the right design for the work they do, and it is precisely the work the network excludes.
An edge GPU is sized for a steady stream of small, immediate answers. It is the wrong size for the occasional heavy job: retraining the model it runs on a season of collected footage, evaluating a candidate model across every recorded edge case, or processing the full archive to label what the device missed. Those jobs can wait for a queue. The design intent is that they go to the network, and that the output comes back to the team, which decides when and how to put a new model on the device.
What lives on your own systems
Beyond the machines, a team runs systems of its own: operator tooling, dashboards people watch during a shift, safety functions, data collection, and whatever interactive assistants the staff rely on while they work. These share the real-time property. A person or a process is waiting on them right now, and they must keep working when a link to the outside is down.
The network is being designed to stay out of that path too. It is not a facility control plane and not a serving system for a floor. If a team wants more AI compute inside its own walls for live work, Element 31's sibling product, Czar, is a sealed appliance built for that. The network is for the jobs that do not need to own compute, and the two are meant to sit side by side rather than compete.
Where the network fits around all of this
Lay the three layers out and the shape of the network's role is clear. Robots act. Edge devices answer. Local systems run the shift. All of them generate data and all of them run models somebody has to train, evaluate, and eventually retrain.
That surrounding work is batch work. A model to retrain this week. Forty hours of warehouse camera footage that nobody has processed. A sweep of ten thousand simulations before a policy change is trusted on the floor. Each can be described as a job with its work, its data, its request, and its output, submitted when the team is ready and run while the team does other things. The compute is held for the job, the output is returned, and the compute is released. Nothing on the robot, the edge device, or the local system has to know the job ran.
That is the boundary, and the network is being built to respect it. The workloads page lists the batch side in detail; the examples page shows what the footage job in particular would look like.
Questions this raises
- Would a robot ever connect to E31 Network directly?
- The design intent is no. A robot's real-time path runs on hardware it carries or on local systems next to it. Data the robot collected could later be staged for a batch job by the team, and a model the network trained could later be deployed to the robot by the team, but the robot itself is not part of the loop.
- What about edge devices that already have a GPU on board?
- They keep doing what they do. An on-board GPU exists to answer locally and immediately, which is exactly the work the network does not take. The network would handle the heavy, occasional jobs that an edge GPU is the wrong size for, such as retraining on a season of collected data.
- Does using the network mean replacing systems a team already owns?
- No. The network is for the jobs that do not need to own compute. Systems a team already runs for real-time work, data collection, or operations stay in place, and the network adds rented hourly compute for the batch jobs beside them.
KEEP READING