Back to Investment Theses
May 5, 2026

The Two Jobs Every Robot Has to Do at Once

Following up on my last post on Physical AI and the next S-curve in autonomous systems...

I want to go one level deeper into something that I think is under appreciated: the core architectural tension that sits at the heart of deploying Physical AI at production scale.

It comes down to two jobs every robot has to do simultaneously - and the fact that those two jobs have fundamentally incompatible compute requirements.

Think about what a production-grade autonomous robot actually needs to do in the real world.

Job 1: Think.

The robot needs to understand its environment. Interpret visual input. Reason about what it's seeing. Plan a sequence of actions. Adapt when something unexpected happens.

This is high-level cognition. It's the kind of work that large AI models are extraordinarily good at - and getting better at fast. NVIDIA's GR00T N1 model, their foundation model for humanoid robots, handles exactly this: vision, language, reasoning, and action planning. It's the "brain" in the classic sense.

Job 2: Act.

While the robot is thinking, it also needs to be executing. Precisely. In real time. Motor control signals need to go out on a strict schedule - in some cases, with microsecond-level timing guarantees. Sensor data needs to be fused instantly. Safety loops need to monitor and respond to anomalies without any tolerance for delay or variance.

This is real-time control. And it has a completely different character from Job 1.

Why These Two Jobs Don't Coexist Easily

Here's the problem.

GPUs - the compute engine powering the AI revolution - are optimized for throughput. They're designed to process enormous amounts of data in parallel, which makes them exceptional for training models and running inference.

But throughput optimization is the opposite of what real-time deterministic control requires.

Real-time control needs guaranteed response times. Not fast on average. Guaranteed. Every time. With no exceptions.

A GPU operating in throughput mode doesn't provide that guarantee. It's architecturally designed for something different.

This isn't a critique of GPUs. It's a fundamental property of the compute problem. Cognition and control are different jobs that require different architectures operating in parallel.

NVIDIA themselves acknowledged this structure explicitly in the public design of GR00T N1. The model has two systems: one for high-level reasoning and planning, one for translating plans into motor actions. Two systems. Two different computational characters.

Where the Gap Is

The cognition side of this problem is being solved. Fast. GR00T N1. Jetson Thor. The VLA model ecosystem. Simulation platforms. These are maturing rapidly.

The control side - the real-time deterministic layer that handles what happens below the cognition level, where the rubber meets the road in a literal sense - is a different story.

Today, most robotics deployments handle this with separate embedded microcontrollers and real-time operating systems that run alongside the AI compute stack. They're not integrated. They're bridged by integration work rather than unified by design..

That works at small scale in controlled lab environments.

It creates significant challenges as you try to scale production deployments, improve coordination across increasingly complex robot bodies, and meet the functional safety certifications that regulated industries require.

This Is Not a Model Problem

I want to be precise about this, because the industry conversation tends to focus on models.

The gap between what Physical AI can do in a lab and what it can reliably do in production at scale is not primarily a model quality problem.

It's a systems architecture problem.

The models are good and getting better. The missing piece is the compute infrastructure that connects cognition to physical action in a way that is deterministic, reliable, safe, and scalable.

That infrastructure layer is where I'm paying close attention.

In my next post in this series, I'll name the architectural paradigm I think describes this challenge - and what solving it looks like.

Curious to hear from others working at this layer: robotics engineers, compute architects, and enterprise operators deploying autonomous systems in production environments.

Reach me at arif@faris-capital.com

This thesis was originally published on LinkedIn. Join the discussion, add your thoughts, and follow for regular updates.

View on LinkedIn