Robot computers are getting bigger, and for perception and large policies that makes sense. The decision layer, though, doesn't have to follow them. This piece argues for a compact, deterministic, CPU-first layer that learns skills, picks actions and checks them before they reach the motors, next to the GPU stack rather than in place of it.
On 22 October 2026, Agility Robotics announced that Digit 5, its next-generation humanoid, will standardize its onboard compute on NVIDIA IGX Thor modules, with NVIDIA as the exclusive onboard-compute provider for the general-availability version. Agility is also building NVIDIA Halos safety models into its safe human-detection system [1]. Agility's CTO described the move as giving Digit 5 "a common foundation" ahead of broad commercial deployment [1].
The reasoning is sound. When Agility first started working with Jetson Thor in 2025, it explained that whole-body control, manipulation and scene understanding all rely on deep learning, and that larger end-to-end policies and richer semantic perception need a lot of onboard computation [2]. If your robot runs big neural networks on camera streams, you need an accelerator.
But "the robot has a GPU" and "every part of the robot's intelligence should run on a GPU" are two different claims. The second one deserves a closer look.
A modern robot stack does two kinds of work that have very different computational profiles.
Turning pixels into objects, or language and images into candidate motions, means dense tensor arithmetic over large models. This is what GPUs and AI accelerators are built for, and it is where they clearly earn their power and cost.
Once the robot has a structured picture of the world (poses, loads, contact states, masses, constraints), a different set of questions comes up. Which skill applies? What grip force stays within the limits? Is the action the policy proposes allowed in this state? Can we prove afterwards why the robot did what it did? These questions involve rules, small learned models, optimization and verification. They need correctness, repeatability and traceability far more than they need throughput.
The decision layer is the one buyers, integrators and safety reviewers ask about most. It is also the layer that gets hardest to reason about when it lives inside the same large probabilistic model that does perception.
Mobile manipulators, quadrupeds and retrofitted industrial cells all have tight power, thermal, memory and cost limits. Every watt and megabyte spent on decision logic is taken away from perception, batteries or payload. A decision layer that fits comfortably next to the rest of the software, without needing its own accelerator, keeps those budgets for the work that really needs them.
A decision layer an engineer can replay is a decision layer an engineer can test and reason about. Holo Engine is built around that: every decision can be replayed and audited [4], constraints are explicit, and teams can examine inputs, state and execution traces to see how a decision was reached, then repeat runs against fixed inputs and state to investigate unexpected behavior [3]. That is the kind of material engineering and compliance teams need for a safety review [3].
If fitting a task model takes about a second instead of a training job, you can adjust a skill when the task, conditions or parameters change, without starting over and without booking cluster time [3].
CPUs are everywhere: in industrial PCs, controllers and laptops. A compact runtime that runs "from cloud to edge" [4] can be tested through an API and then deployed on-premises or at the edge, close to the devices and sensors it serves [4].
Claims about efficiency are only useful with their measurement context. The figures below come from HiHolo's robotics page and were measured in October 2026 on an Intel Core i9-9880H laptop CPU with 16 GB of system RAM [3].
What each number includes.
≈1 s: five separate Meta-World models, each fitted from 4,560–9,084 prepared state/action examples, took 0.8318–1.1641 s per model. Experience collection, perception and physics simulation are not included [3].
18 demonstrations: the Panda experiment used 18 scripted teacher demonstrations to learn two correction gains and a hold/increase readout. A task-specific adapter supplied geometry and physical execution. Collection plus fitting took about 7.1 minutes [3].
0 GPU: model fitting and control computation ran on CPU without GPU acceleration. Rendering and hardware-specific robot software are outside the measurement [3].
≈100 MB: peak process RSS of the Alphabet Lab runtime, remeasured on 28 October 2026 at 97.89, 104.67 and 104.85 MB. Each run recomputed 34,946 results and 32 RGB-D frames. The process covers Holo, the loaded models, HoloLanguage and RGB-D processing. The simulator, renderer, operating system and device drivers are excluded. 1 MB = 1,000,000 bytes [3].
Peak RAM per run
Fitting time range
For context, Holo Engine ships as a compact engine binary of roughly 15–25 MB depending on the platform. Learning, reasoning, optimization and verification run in that one engine instead of separate tools stitched together, which is a large part of why the footprint stays small [3][4].
Fitting a model once is useful. Updating it during operation matters more at the edge. In our latest OpenArm V2 experiment, run 3 in MuJoCo simulation, Holo Engine predicted the mass of each pour from the scoop before it happened, with a mean error of 0.73 g across 173 pours. It also learned online during the task: 173 online updates took 9.7 s of engine time in total, on an Intel Core i9-9880H laptop CPU with no GPU. From one run to the next, even spread was reached in 5 of 8 test conditions instead of 3, losses stayed within limits in 7 of 8 instead of 3, and the full task criterion was met for the first time [5].
CPU-first is not a claim that robots don't need GPUs. We think the opposite is often true:
The practical question is not CPU or GPU. It is which layer needs which kind of compute, and which layer needs to be explainable. A neural policy can propose an action; a compact, deterministic layer can check that proposal against explicit constraints before execution [3]. That is a different job, and it doesn't need the same hardware.
| Workload | Typical compute | What matters most |
|---|---|---|
| Pixel-level perception | GPU / accelerator | Throughput, latency per frame |
| VLA / neural policy | GPU / accelerator or cloud | Generalization across tasks |
| Skill selection, parameter fitting | CPU-first | Fast adaptation, small data |
| Action verification against constraints | CPU-first | Determinism, traceability, replay |
To be clear about what we are arguing: running on a CPU isn't a product on its own. Efficiency only matters when it comes with something buyers need: decisions that are repeatable, constraints that are explicit, and a trace that engineering and safety teams can inspect [3]. Holo Engine pairs the compact footprint with that verifiability. You can use it in three ways [3]:
Let the accelerator see and propose. Let a compact, deterministic layer decide, verify and explain.
Footprint, adaptation speed and verifiability are the questions we keep measuring. Our experiments confirm the approach; the next step is a pilot on a real robot with a robotics partner.
Every robot. A measurable outcome.
Tell us what your robot needs to do. Let's discuss a pilot.
hi@hiholo.ai