What thirty years of JPL autonomy actually proved

Thirty years is enough time to read the arc, not just the anecdotes. If you take the JPL autonomy programs that reached flight or ground-based mission use, Remote Agent on Deep Space 1, CASPER, AEGIS on the Mars rovers, AutoNav on comets and Mars, Terrain Relative Navigation on Mars 2020, and the Ingenuity helicopter, a pattern emerges that the field has not fully absorbed.

The programs that shipped and stayed shipped were hybrids. A specialized autonomy component did something narrow and well. A separate, smaller mechanism decided when its outputs would run. The programs that did not stay were not less clever; they were monolithic. Their intelligence and their authority were the same piece of software.

What follows is the arc, one program per section, in the shape of: what it solved, what it deliberately did not, and what it teaches about the trust boundary.

Remote Agent on Deep Space 1 (1999)

Remote Agent was the first onboard AI to command a spacecraft. It combined a planner (HSTS), an executive (EXEC), and a model-based diagnosis engine (Livingstone). For a few days in May 1999, it planned and re-planned Deep Space 1's activities on its own.

What it solved: an integrated demonstration that goal-directed onboard reasoning was possible in flight. What it deliberately did not: replace the ground command sequence for the mission at large. Remote Agent's authority was a scheduled window, not the mission. That windowing was the trust boundary, and it was drawn by the mission designers, not by the software.

The lesson the field remembers from Remote Agent is the deadlock bug. The lesson worth remembering is that the mission still worked because the authority envelope was scoped correctly. When the deadlock happened, the ground team took the vehicle back. Nothing catastrophic followed.

CASPER and ASPEN (2001 onward)

CASPER (Continuous Activity Scheduling Planning Execution and Replanning) was the first system to do continuous onboard replanning in flight, on EO-1. It ran a rolling planning horizon, integrated new information from onboard science algorithms, and rescheduled downlink and imaging activities.

What it solved: iterative repair-based planning that survived the compute constraints of a small research spacecraft. What it deliberately did not: control the trust envelope. CASPER's plans were bounded by rules and by the executive, and it did not attempt to reason about safety by itself. It generated candidates. Other mechanisms accepted or refused them.

CASPER is a load-bearing citation for anyone claiming that iterative repair is a real technique. It is also load-bearing evidence that iterative repair works because it does not carry the safety decision alone.

AEGIS on Opportunity and Curiosity (2010, 2016)

AEGIS gave the rovers onboard target selection: identify a scientifically interesting rock in an image, point an instrument at it, take the shot. This is closer to what people today imagine as "AI on a rover." It has been in operational use for over a decade.

What it solved: closing the loop between perception and instrument on the same sol, without waiting for the next uplink. What it deliberately did not: decide whether the observation was safe, whether power allowed it, whether the traverse to it was permitted, or whether the exposure was needed elsewhere.

Those decisions were made by other software, and behind that other software, by the ground team's plan. AEGIS was a bounded service. The trust boundary sat outside it. This is why AEGIS is quietly one of the most successful onboard science autonomy systems ever flown, and it is why the shape of that success generalizes.

AutoNav (Deep Impact, Stardust, Mars 2020)

Optical navigation on approach. AutoNav processed images of the target, a comet, a planet, to update the trajectory estimate and command the burn, on a timescale too short for round-trip communication.

What it solved: closed-loop terminal guidance in deep space, an operation that cannot be done from Earth. What it deliberately did not: choose what the mission would do. The mission's intent, "reach this point, at this time, with this dispersion", was set by the ground. AutoNav delivered on the intent. It did not modify it.

This is worth pausing on. AutoNav is often listed as an example of onboard AI. It is more accurately an example of well-scoped autonomy: extreme competence inside a narrow role, with a clear line separating "how" from "what." That line is the same line this essay keeps returning to.

Terrain Relative Navigation on Mars 2020

TRN gave Perseverance the ability to compare descent imagery against an onboard map and pick a landing point inside a much more constrained region than the mission would otherwise have committed to. It expanded the accessible landing site by orders of magnitude in usable area.

What it solved: precision landing that reduced mission risk without changing what "safe" meant. What it deliberately did not: relax the safety envelope. The vehicle had a map of hazards, drawn on the ground, and TRN chose within the safe region defined on that map. The map was the boundary. The learned perception was inside it.

If you want a single flight-heritage example of the architecture this essay argues for, TRN is it. The safety envelope was pre-computed, on the ground, by humans and physics. The onboard perception operated inside the envelope. The trust boundary was explicit.

Ingenuity helicopter (2021 onward)

Ingenuity flew autonomously on Mars, without joystick control, in an atmosphere that had never carried a powered aircraft. Its guidance, control, and flight-abort logic were onboard and made real-time decisions.

What it solved: autonomous flight in a domain where teleoperation is impossible. What it deliberately did not: choose flight plans in ways that could not be reviewed on the ground. Every flight was proposed, reviewed, and cleared before it launched, and the onboard software followed the plan with a small envelope of autonomous decision. When a scenario exceeded the envelope, Ingenuity aborted.

Ingenuity is remarkable, and it is remarkable in ways that reinforce the pattern: an intense amount of autonomy on a short leash, with a specific and enforced envelope of what may execute, and a fallback that always favored the vehicle's survival over completing the flight.

What the arc actually shows

Six programs, three decades, one pattern. Autonomy that shipped and stayed was autonomy that was bounded. The boundary was drawn by a smaller, simpler mechanism than the autonomy itself: a scheduled window, a set of prohibitions on the executive, a safety map, an abort condition. It was engineered, not learned, and it was independent of the component whose behavior it governed.

This is not a nostalgia for old software. It is a specification for the layer we are building. The pattern is not accidental. It is what makes autonomy certifiable, and it is what makes an accident survivable. A modern mission carries more autonomous components than any of the missions above. It deserves the same discipline applied to the layer that governs them, not to each one individually.

That layer is what the runtime is.

Barycenter Systems is building a mission autonomy runtime. If this problem is yours too, write to us.