Shared autonomy is what happens between the two extremes people usually describe: a human driving every degree of freedom, or a policy running with no human in the loop at all. In between, a person and an autonomous policy both have a claim on the robot's next action, and the interesting engineering is in how that claim gets arbitrated.
The spectrum
| Mode | Who controls what | |
|---|---|---|
| Full teleoperation | Human | Every motion, continuously |
| Shared autonomy | Human + policy | Policy executes; human corrects at the point of failure, via handover or blending |
| Supervised (exception-only) autonomy | Policy, mostly | One human monitors a pool of robots, intervening only when summoned |
| Full autonomy | Policy | No human loop; used only where the policy is trusted end to end |
Teleoperation and shared autonomy aren't opposites — shared autonomy is the scaffolding that lets a task move from one to the other without a hard cutover, and it's usually where the highest-value training data in a mature program comes from.
Arbitration: switched vs. blended
There are two broad ways to combine human and policy input.
Switched (discrete handover). Control belongs entirely to the policy or entirely to the human at any instant, and a trigger flips which one. This is simpler to reason about and to log — an episode has an unambiguous "who was driving" field at every timestep — and it's the more common pattern in production fleets because it composes cleanly with a supervision queue.
Blended (continuous arbitration). Human and policy commands are combined continuously, typically weighted by a confidence estimate — the policy's output dominates when confidence is high, the human's input dominates or overrides when it's low. Blending can feel smoother to operate because there's no discrete jolt at the handover point, but it makes attribution harder: a resulting action was partly human, partly policy, which complicates using that action as a clean imitation-learning label later.
Detecting when to hand over
The trigger deciding when a human should take over (or when the system should hand control back) draws on the same signals used elsewhere in supervised autonomy:
- Policy confidence — action entropy or disagreement across an ensemble of checkpoints.
- Out-of-distribution detection on the current observation, flagging scenes that look unlike anything in training.
- Force-torque anomalies, which are often the earliest reliable signal for contact-rich manipulation, firing before a vision-based signal would.
- Task-level heuristics — stall detection, retry counters, geofence or workspace-boundary triggers.
No single signal is sufficient alone; production systems typically combine several into one calibrated intervention score rather than gating on any one threshold.
Why interventions are disproportionately valuable
Generic new demonstrations are spread across a task distribution the policy may already handle well. An intervention, by construction, occurs exactly where the deployed policy failed or was about to — so the corrective action is training signal concentrated on the current model's weak points, not the average case. This is the mechanism behind the DAgger (Dataset Aggregation) idea applied at fleet scale: policy runs, human corrects at the point of failure, correction re-enters training, and the next model closes precisely the gap that produced the intervention. Captured with the observation window before and after the trigger — not just the corrective action in isolation — an intervention becomes a labeled example that's worth substantially more per unit of operator time than an equivalent stretch of uneventful full teleoperation.
The economics: operator-to-robot ratio
Shared autonomy is what makes fleet economics work, because it inverts the ratio that dominates cost. A robot needing a dedicated operator for every minute of operation caps how many robots one person can run at 1:1. Under shared autonomy, the default mode is autonomous execution, and the human is a shared resource summoned by exception — so the ratio that determines cost isn't robots deployed, it's operator-hours per robot-hour, driven down as intervention rate falls with each retraining cycle. That compounding is the practical reason shared autonomy gets built before full autonomy is trusted: it's cheaper to run today, and it produces the exact data that makes full autonomy achievable tomorrow.
As intervention rate falls, the same operator pool covers more robots, and the queueing math starts to dominate the design more than the raw ratio does: when several robots request help at once, a scheduler has to decide who gets the operator next, usually weighing task value, how close a robot is to a safety limit, and how long a request has been waiting so low-priority robots don't starve behind a stream of higher-value ones. None of that shows up in a simple "operators per robot" headline number, but it's what determines whether the ratio holds up once a fleet is large enough that contention is routine rather than rare.
Safety implications beyond the handover gap
Handover latency is the sharpest safety risk, but not the only one. A blended arbitration scheme that lets a low-confidence policy output continue to influence the commanded action — rather than yielding outright — can produce a motion that's neither what the human intended nor what the policy would have done alone, which is harder to predict and harder to test for than a clean switch. Systems that default to a safe hold state (rather than continuing the policy's last trajectory) when a trigger fires and no human has taken control yet avoid the worst case: an unsupervised robot continuing to act on a plan it just flagged as unreliable. Whichever arbitration mode is used, the handover itself should be logged with enough detail — trigger, latency, resulting action — to audit after the fact, since the moments worth reviewing for safety are disproportionately the ones where control was changing hands.