A Team Brain for Heterogeneous Robot Teams

Most robot autonomy is scoped to a single machine: one body, one skill, one decision loop. That's the right scope for teaching a robot to walk or grip. It's the wrong scope for an emergency, which almost never involves exactly one robot with exactly the capability needed. SentiaCore is built around a different unit of command: the team.

The unit is the fleet, not the robot

When a tank, a legged robot, and a drone are all on the same incident, SentiaCore doesn't run three separate decision loops that happen to coordinate afterward. It treats them as one fleet with one mission. The open work on an incident — suppress this hotspot, check that room, hold position beside a victim — gets offered to the whole team, and each robot bids on what's in front of it based on what it alone can actually do and where it alone actually stands.

A tank close to a hotspot bids strongly on suppression. A drone positioned above a collapsed section bids strongly on reconnaissance nothing on the ground can get. A legged robot that can hold a stable position next to an unconfirmed victim bids on an escort task no wheeled robot could take. The fleet settles into a division of labor without a human manually routing each assignment — the market does the routing, and a commander reviews the outcome, not the mechanics.

Why bidding, not a fixed hierarchy

A fixed assignment hierarchy — "tanks always suppress, drones always observe" — breaks the moment the easy case ends. A tank that's out of position, low on supply, or physically blocked shouldn't win a bid it can't actually execute well; a drone that's lost line of sight shouldn't keep holding reconnaissance it can no longer perform. Letting robots bid based on their real, current state means the team's division of labor tracks reality instead of a plan made at the start of the mission.

Resilience that comes from the structure, not a patch

A robot going offline mid-mission is not a special case SentiaCore has to detect and route around — it's just a robot that stops bidding. The rest of the team re-settles on the open work automatically, because the mechanism that assigned work in the first place is exactly the mechanism that re-assigns it. Heterogeneity and resilience come from the same design decision, not from two separate systems bolted together.

What this doesn't remove

A team brain decides who does what among capable robots — it doesn't decide whether the mission's leading plan is a good idea, and it doesn't decide whether an action is safe to take. Those are the jobs of rehearsal and the safety gate, respectively, both of which sit downstream of this bidding process. The team brain's job is narrower and, we think, more durable for it: get the right body on the right task, every time the situation changes, without anyone having to hand-assign it.

Why this is the harder problem

Teaching a single robot a new skill is a well-posed, increasingly well-solved problem. Teaching a heterogeneous team to allocate itself sensibly, continuously, as conditions change mid-mission, is not — and it's the problem that actually determines whether a fleet of capable robots behaves like a team or like three independent machines that happen to share a building. That's the problem SentiaCore is built to solve.