F · 01 · Map decay
Static maps become operational debt.
A pallet moves. A corridor narrows. A floor marker is repainted. By Friday afternoon the platform is acting on a fiction nobody updated.
Runtime infrastructure for Physical AI
Cognitive OS for intelligent robots
Most robotics programs do not die in the demo. They die between the second site and the twelfth Monday. RAI Swarms builds the runtime layer that survives that gap — memory, coordination, supervision, recovery, and deployment feedback as one operating system.
68%
of robotics pilots never reach a second site
8–14 wk
engineering per new floor · without a runtime
3×
override rate in the last hour of a shift
Field observation · cross-program · 2023–2025
Pilots land. Demos pass. Six weeks in, the engineer who tuned the platform is still on
site. The deployment does not collapse — it sustains, on heroics, until the engineer
leaves. Then exceptions accumulate, supervisors disable, and site two never starts.
01 — How robotics actually fails
The pilot survives only while a specialist babysits it.
Not framework problems. Not benchmark gaps. These are the conditions that show up on the floor every week and that quietly cost the program its second site.
F · 02 · Vendor conflict
Two vendors blame each other for every deadlock.
Mixed-fleet corridor. Vendor A logs say Vendor B was wrong. Vendor B logs say Vendor A was wrong. The floor lead resolves it by walking the lane.
F · 03 · Workflow drift
Operators adapt; the robot doesn’t.
A team-lead adds a hand-off step Monday morning. The robot is still operating against last week’s workflow on Tuesday. Override rate doubles.
F · 04 · Trust collapse
Three unexplained pauses, and the supervisor disables it.
Trust is binary on a floor. After three silent pauses the platform is off, and getting it back on takes weeks of operator-relations work, not engineering.
F · 05 · Drift
Performance degrades 0.3% per shift, then 0.5%.
No single event triggers alarm — the trend is the failure. By month two, the program is running at 78% of pilot, and nobody can say when it slipped.
F · 06 · Integration
Site two costs as much as site one.
WMS, MES, scheduling, gateways, identity — wired by hand on every floor. The runtime that was supposed to compound is rebuilt at every gate.
F · 07 · Cold start
A new unit ships not knowing yesterday.
What the fleet learned on Tuesday is not what the new unit knows on Friday. The customer paid for that lesson once already.
F · 08 · Heroics tax
A deployment that needs heroics does not scale.
The 5% the platform doesn’t handle becomes the 100% an engineer babysits. There is no second site; there is no second team that can babysit it.
Anomaly log · site · DC-NL-04 · last 12 h
06:42:18
WARN
Vendor-B fleet stalls in corridor 14. Vendor-A planner does not see Vendor-B intent. Deadlock.
+€312 · labour
07:01:55
CRIT
Floor lead resolves manually by walking the lane. Trust hit logged by supervisor.
+€140 · downtime
09:14:02
WARN
SKU mix change. Bin 8E re-shelved by picker. WMS state diverges from floor state.
+€88 · rework
11:38:47
INFO
Operator override on unit R-03. Reason free-text: “don’t know why it stopped.”
override · uncaptured
14:21:09
CRIT
Recovery latency on R-07 = 41s. Threshold = 15s. Cascade into adjacent task.
+€220 · throughput
17:55:30
OK
Runtime memory recognises bin 8E shift from morning. Auto-correct. Same incident, no recurrence.
−€88 · avoided
Representative · indicative numbers from real programs · names anonymised
02 — Runtime architecture
Models → Cognitive OS → Deployment → Fleet learning.
The Cognitive OS sits between intelligence and machinery. It is the layer that translates model output into operational behaviour and turns deployment feedback back into fleet intelligence.
01 · Input
Models & sensors
Foundation, perception, policy. RGB, depth, lidar, audio, force, IMU.
02 · Runtime
Cognitive OS
Memory · coordination · planning · supervision · recovery. The operating layer.
03 · Action
Deployment
Field operations, telemetry, intervention, recovery, audit.
04 · Feedback
Fleet learning
Site-to-fleet feedback. Memory updates. Policy refinement. Compounds.
Continuous loop — runtime is the load-bearing layer.
03 — Where it sits
The missing layer in Physical AI.
Seven layers from embodiment to deployment. Most of the industry has built the top and bottom. The Cognitive OS is the middle — the layer that makes everything else operate together.
07
Deployment
Field operations, telemetry, recovery, fleet rollout
06
Control
Motion, manipulation, low-level safety
05
Cognitive OS
Runtime · memory · coordination · supervision · recovery · deployment telemetry
RAI Swarms
Runtime kernel
Memory layer
Coordination
Task state
Safety gate
Operator interface
Telemetry
Fleet learning
04
Models
Foundation, perception, policy, language
03
Sensors
RGB, depth, lidar, audio, force, IMU
02
Hardware
Mobile bases, manipulators, humanoids, specialised platforms
04 — From the floor
Things that only happen after the demo.
Not benchmarks. Not promo videos. Operator transcripts and field observations from programs that have actually run a shift.
“After the third pause we just stopped using it on that aisle. Nobody had time to figure out why it kept hesitating.”Floor lead3PL · NL · Mo 06:14
Observation · cross-program
The pattern is repeatable. A platform passes pilot. By the second month, the
exception list outgrows the engineering response. Overrides accumulate
in free-text fields. Nothing is fed back into the policy. The deployment becomes a
maintenance line item.
“The vendor blamed our wiring. The integrator blamed the vendor. The CFO asked what we were paying for.”Programme leadLogistics · UK
Observation · site-to-site
Without a runtime, site one and site two share almost nothing — not the map, not
the operator interface, not the recovery policies. Engineering hours per new floor stay
flat across the program. The economic case for site three quietly disappears.
Three-minute shift overlap turns into 40 minutes of recovery.
Coordination, not throughput, is the bottleneck. The overtime line shows it before any dashboard does.
Overrides double in the last hour of every shift.
Not a platform problem. A supervision-schedule problem the platform never compensates for.
Week 3 · pick rate unchanged, idle time tripled.
The robot is fine. The map is wrong. Nobody re-mapped because nobody noticed in time.
Two vendors blame each other for every corridor deadlock.
Deadlocks resolve only when a human walks the floor. The ops team learns to plan around the platform, not with it.
Site two costs what site one cost. Site three never starts.
The economic case dies between the second and third floor. The runtime that was supposed to compound was reset at every gate.
Exception list grows faster than the platform learns it.
New SKUs ship weekly. Coverage is a moving target the engineering team is asked to chase, alone.
05 — Economics of a deployment that does not scale
Every override is labour. Every override is also memory you never captured.
The cost of robotics in deployment is not the robot. It is the engineering hours, the overtime labour, the operator retraining, and the program that quietly never starts site three.
Override · per event
€30–€120
Operator labour, downtime, recovery context. Multiplied across a shift.
Recovery · per minute past threshold
€18
Throughput loss + cascade into adjacent tasks. 41-second recovery = 7× the cost of 15s.
Engineering · per new site
8–14 wk
Without a runtime, integration is rebuilt every floor. The cost barely drops with experience.
Pilots that reach site two
~32%
The rest stall — usually because the engineer who tuned site one cannot also tune site two.
68%
of robotics programs never reach a second site with the same platform.
5%
of operating conditions consume more than half of all engineering hours.
06 — What compounds
The runtime is the layer that turns one deployment into the next deployment’s training data.
The economic case for a runtime is not what it does in week one. It is what it has absorbed by week fifty. Memory, recovery, supervision, and integration compound — quietly, in the background, while the platform keeps running.
Cost per new site
Operational intelligence · cumulative
Inflection · runtime pays for itself
01
Site memory.
map · workflow · exception graph
02
Recovery policy.
stated next-state per fault
03
Operator-corrected memory.
override → policy refinement
04
Coordination protocols.
intent · priority · arbitration
05
Integration surface.
WMS · MES · operator console
06
Audit trail.
defensible decision history
07
Fleet learning curves.
cross-unit, cross-generation
07 — Why static stacks break
Robotics stacks were not built for deployment.
Most robotics systems were architected around a single robot in a controlled cell. The assumptions that worked there do not survive a real shift across a fleet.
Without a cognitive runtime
Fragmented stacks. Stalled programs.
- —Perception lives in one team, planning in another, control in a third. They are integrated by hand on every site.
- —No persistent memory. Every shift, every unit, every site starts from a cold map.
- —No deployment learning. The 200th run on the floor is no smarter than the first.
- —No fleet cognition. Robots in the same corridor do not know about each other’s intent.
- —No runtime continuity. Restart on every fault, rebuild on every site, re-engineer on every new exception.
8–14
weeks · engineering per new site
With the Cognitive OS
A runtime that compounds across the fleet.
- +One operating layer between models, perception, control, and deployment. Modules speak the same protocol.
- +Memory across episodes, sites, and unit generations. New robots inherit what older robots have learned.
- +Deployment telemetry feeds the policy. The 200th run uses the knowledge of the first 199.
- +Fleet-aware planning. Coordination is a first-class signal, not a workaround.
- +Runtime continuity through interruption, override, and degraded sensors. The system bends instead of breaking.
1–2
weeks · once the runtime is in place
08 — What the Cognitive OS coordinates
Eight runtime functions, one operating loop.
A continuous operating loop across the cognitive state of every field-deployed unit and the fleet around it. Hardware-agnostic, model-agnostic, designed around uncertainty.
/ 01
Perception context
Structured situational state from raw multi-modal input.
/ 02
World model state
Live model of the environment, agents, objects, and constraints.
/ 03
Memory & task history
Episodic and persistent memory across shifts, sites, units.
/ 04
Multi-agent coordination
Negotiation across fleets, humans, and external systems.
/ 05
Action planning
Long-horizon planning, decomposition, replanning under change.
/ 06
Safety constraints
Hard limits, soft policies, safe degradation, override paths.
/ 07
Operator feedback
Human-in-the-loop signals, supervision, audit trail.
/ 08
Deployment telemetry
Site state, intervention rates, drift, fleet learning loops.
Why now · the transition is mid-flight
The robot stops being the product. The runtime becomes the product.
Humanoid platforms scale. Embodiment ships at supply-chain volume. Capability is no longer the constraint — coordination is. Memory is. Supervision is. The shape of the next robotics era is decided by who supplies that layer this year, and at what price.
2026humanoid fleets at site
+5×embodiment SKUs / yr
0commodity runtime · yet
2018
era · models
Deep learning hits robotics · capability era
Perception unlocks. The argument is what the model can do.
2022
era · policy
Foundation models go physical · policy era
Generalisation across tasks. The argument is what the policy can plan.
2024
era · embodiment
Embodiment wave · hardware floods in
Humanoids, AMRs, dexterous arms. Hardware starts to commoditise.
2026
era · runtime · now
Deployment is the bottleneck · runtime era
Models exist. Hardware exists. What is missing is the cognitive runtime that lets either survive a real shift.
2028
era · OS
Runtime becomes infrastructure · operating-system era
Memory, coordination, supervision become commodity layers. The companies that supplied them define the category.
2026 · embodiment
+5×
Humanoid SKUs shipping vs 2023. Hardware variety outruns the integration capacity to absorb it.
2026 · supervision
1 : 14
Operators per autonomous unit needed at scale. Today’s deployments staff for 1 : 1.
2026 · integration
0
Commodity runtime layers across robotics platforms. None ship as infrastructure today.
2026 · deployment
68%
Pilots that do not reach a second site. The economic case dies between site one and site two.
09 — Ecosystem
One coordinated ecosystem.
RAI Brain · RAI Swarms · Vera Kovaleva. Three roles, one architecture. Intelligence, infrastructure, and category framing — built together, deliberately.
Intelligence layer
Category framing
Physical AI category
Continuous data flow
/ Infrastructure
RAI Swarms
Cognitive runtime infrastructure — the operating layer between AI models and embodied systems. Memory, coordination, supervision, deployment telemetry.
/ Intelligence
RAI Brain
Research and intelligence hub mapping Physical AI — frameworks, market analysis, strategy. The map underneath the runtime.
/ Architecture
Vera Kovaleva
Category architect. Frames Physical AI as an infrastructure category — not a hardware race, not a humanoid race, a runtime category.
Operating layer for Physical AI
Hardware commoditises.
Models commoditise.
The runtime does not.