Robots from different makers. One site mind.
Buildings are filling with robots from many makers. Each has its own app and its own rules, and none can hand work to another. Cereal OS is the layer above them: say what you need once, by phone, chat or out loud, and the right robots do it, taking turns when a job needs more than one. Who is who, every place by name, who may command what and a record of every action stay with the site, whichever robots it runs.
Four things a site should keep, not each robot.
Who is who.
Every robot is enrolled to the site as itself, and the site knows the people who may talk to it. A new robot is introduced, not trusted by default.
Today: our robots take commands only from their owner, and only people the owner allows can watch them live.
Every place by name.
Rooms, doors and stops are named once and kept by the site, not inside one robot, so the next robot does not start from zero.
Today: our robot learns rooms by the names you give them. A new body still needs its own mapping or localization first.
Who may command what.
The site decides who may ask for what, in which rooms, and which robot may do it. A job goes only to a robot whose body and tested skills support it.
Today: owner-only commands, owner-controlled live views, and rooms marked private keep the camera off.
A record of every action.
Requests, actions, refusals and hand-offs between robots land in one record the site owns, whichever maker built the robot.
Today: every visit lands on the operator's console.
One job, two makers, a real run.
Real footageIn Paul's workshop, one voice note to Cole ran a robot dog and robot arms from two different makers on one job, taking turns, at real speed.
Not yet: a customer site running robots from several makers. That comes next, at our first supervised site, with a second robot type joining through Cereal Connect.
Not another robot app. The layer above them.
Each maker's app
Runs that maker's robots well. The map, the rules and the history stay inside it, and it cannot hand a job to a robot from another maker.
Fleet dashboards
Show where robots are and send them missions. Cereal OS keeps the site's people, places, permissions and record, and takes requests in plain words by phone call or chat, not another app.
Robot foundation models
Teach one model to move many bodies. Cereal OS sits above them: it calls the skills a body has and keeps the site's context. Better models make that layer worth more.
A maker will never run a rival's robots. The site's people, permissions and record have to sit with a layer the site owns.
Hotels, then sorting hubs, then offices.
Supervised sites first, plus after-hours security rounds, with a person responsible and an agreed workflow. Pilots start in the US and Thailand from early 2027.
Questions, answered.
What is a mixed robot fleet?
A site that runs robots from more than one maker: a delivery robot from one, a cleaning robot from another, a four-legged robot for rounds from a third. Each usually arrives with its own app, its own map and its own rules, and none can hand work to another.
Can one system run robots from different makers?
That is what Cereal OS is for. In a real run in Paul's workshop, one Cole ran a robot dog and robot arms from two different makers on one job from one voice note, taking turns, at real speed. Each new robot still needs a supported adapter, mapping or localization and validation of the tasks it can safely do. No robot is ready to work the moment it arrives.
Is Cereal a fleet management system?
It does the part of fleet orchestration that belongs to the building: who is who, every place by name, who may command what, and a record of every action, across every robot on the site. People reach it where they already are, by phone call or chat. The operator console shows each visit.
Do you make the robots?
We ship Cereal robots end to end, on bodies we procure with our own compute, sensors and safety kit, and every one runs Cereal OS. Robots from other makers are meant to join the same site through Cereal Connect, under the same rules, after integration and testing.
What happens to the memory when we change robots?
Keeping the context with the site is the design: identity, memory, permissions and the record should survive a hardware change. A new body still needs a supported adapter, mapping or localization and validation of the tasks it can safely perform.
Where do you start, and what does it cost?
We start with supervised sites: hotels, then sorting hubs, then offices, plus after-hours security rounds. Founding-site pilots: $1,250 USD a month per robot in the US or ฿29,900 in Thailand, from early 2027. Joining the founding list is free.