AstroForge plans to fly an onboard AI autonomy system called Solo on its DeepSpace-2 asteroid-mining spacecraft, which the company is targeting for launch in 2027. The transformer-based stack is intended to work alongside conventional spacecraft-control software, using subsystem data and telemetry from roughly 2,500 sensors to handle a defined set of operational decisions without constant ground intervention.[1]
The important development is not that artificial intelligence is about to replace mission control. It is that deep-space operations have unusually strong economic reasons to move bounded decisions onboard. Communication latency, limited contact windows and the cost of assembling specialists for every anomaly can make even modest autonomous diagnosis and response highly valuable. AstroForge still has to demonstrate that Solo can perform reliably in flight, however; a planned 2027 launch is a long way from flight-proven autonomous operations around an asteroid.
By the numbers
- 2027: Target launch year for DeepSpace-2.
- About 2,500: Sensors whose telemetry Solo is expected to draw on.
- One: Announced spacecraft platform for Solo’s initial planned deployment, DeepSpace-2.
What Solo is designed to do
AstroForge describes Solo as an onboard autonomy stack built around transformer models and conventional control algorithms. The stated objective is to reduce reliance on large ground-control teams by giving the spacecraft a system that can interpret broad streams of vehicle data and support operational decisions locally.[1]
That framing matters. “In command” can imply unrestricted AI control over a spacecraft, but the available description points to a hybrid architecture instead. In such a system, deterministic flight software remains responsible for known control loops, hard limits, command sequencing and safety responses. The AI component can be used where conventional rule sets become unwieldy: recognizing combinations of telemetry signals, detecting an anomalous pattern, prioritizing likely explanations and selecting from approved procedures.
For a spacecraft with thousands of sensor channels, the operational challenge is often not a lack of data but deciding which data matters. A power-system change may affect thermal conditions; a thermal shift can alter propulsion or communications performance; a navigation discrepancy may reflect a sensor problem rather than an actual trajectory issue. Transformer-based models are useful in principle because they can represent relationships across many inputs and across time, rather than relying only on a fixed threshold for each individual measurement.
The report does not establish that Solo will independently make irreversible mission decisions, conduct unbounded navigation, or execute mining operations without constraints. Those distinctions will be central to evaluating the system. Autonomous fault detection and suggested recovery actions are materially different from authority to fire thrusters, change a trajectory, disable a subsystem or alter a mission plan.
Why conventional control software remains essential
Spacecraft control is a poor fit for an all-or-nothing AI narrative. Flight software must behave predictably under conditions including radiation effects, sensor faults, degraded power, communications loss and hardware states that may be rare or absent from training data. Conventional algorithms and state machines are designed for this work because their logic can be specified, tested against known failure modes and bounded by explicit safety rules.
Solo’s practical value is likely to come from complementing that software rather than displacing it. A traditional control layer can enforce operating envelopes: do not exceed thermal, power, attitude or propulsion constraints; enter a safe state when critical conditions are met; and require ground authorization for selected actions. An AI layer can then operate inside those boundaries, helping determine whether telemetry represents a genuine fault, a transient condition or an interaction among subsystems that deserves attention.
This division also addresses a central issue with machine-learning systems in aerospace: explainability. Controllers need to understand why a system classified a condition as risky, especially before it acts on a costly or irreversible recommendation. The more consequential the action, the more valuable deterministic checks, independent monitors and human approval gates become. A capable autonomy stack is therefore likely to be layered, not monolithic.
The operational economics of deep-space autonomy
Deep-space missions cannot operate like low-latency terrestrial systems. Commands and telemetry take time to travel, and communications are not continuously available. Ground teams must plan around contact opportunities, while any off-nominal event can trigger work across propulsion, power, thermal, flight dynamics and software disciplines. That staffing model is expensive, particularly for a company pursuing repeated commercial missions rather than a single flagship science program.
Autonomy can change those economics even if it handles only routine monitoring and first-line fault management. If a spacecraft can assess its own health, preserve a safe configuration, consolidate relevant evidence and wait for operators with a useful diagnosis, a smaller team can supervise more effectively. The target is not fewer engineers for its own sake. It is to direct scarce expert time toward decisions that genuinely require judgment, mission tradeoffs and engineering intervention.
For asteroid-resource companies, the argument is especially direct. The business case depends not only on reaching a target, but on doing so with enough operational efficiency to make repeated missions conceivable. Every avoidable manual intervention, specialized review cycle or missed response window works against that model. Deep-space autonomy is therefore both a technical capability and a potential operating-cost lever.
From training data to flight confidence
The largest unanswered question is how AstroForge will validate Solo for conditions it has not encountered before. Models trained on spacecraft subsystem data can learn useful signatures from simulations, hardware testing and prior telemetry, but spaceflight produces sparse and expensive real-world data. Novel combinations of faults, environmental effects and sensor behavior are precisely the circumstances in which an autonomy system must be most conservative.
Validation will need to extend beyond demonstrating that a model can identify familiar patterns in a test set. It should include hardware-in-the-loop testing, simulated sensor corruption and dropouts, timing errors, conflicting signals, degraded computing resources and scenarios in which the model is uncertain. Operators will also need a clear way to inspect what the system saw, what action it recommended or took, and which safety controls constrained it.
Onboard computing introduces another tradeoff. Transformer models can be demanding relative to traditional flight software, while spacecraft processors operate under strict power, thermal, radiation-tolerance and reliability constraints. The key technical measure will not be whether Solo resembles a modern terrestrial AI system, but whether it can deliver dependable inference within the vehicle’s available compute budget and fail safely when data or hardware are compromised.
AstroForge’s 2027 target should consequently be viewed as an initial operational test of an architecture, not proof that autonomous asteroid-mining operations have arrived. A successful launch and healthy cruise phase would be meaningful milestones. Demonstrating useful behavior during anomalies, under communication constraints and without eroding safety margins would be the more consequential evidence.
Implications for commercial space
AstroForge is part of a broader commercial-space push to make missions more self-managing as spacecraft fleets grow and operations move farther from Earth. The industry already uses automation extensively, but machine-learning systems introduce a different proposition: software that can synthesize high-dimensional telemetry and adapt its assessment to patterns that would be difficult to encode manually.
If Solo works as intended, its most immediate industry impact may be on operations design rather than spacecraft control doctrine. Commercial operators could build mission teams around exception handling and supervisory control, with onboard systems performing more of the continuous health assessment. That could be relevant to lunar, cislunar and deep-space missions, where communication delays and intermittent links make continuous manual control impractical.
But commercial credibility will depend on transparent milestones. Investors, customers and regulators will want evidence of what functions are autonomous, what remains under conventional control, how permissions are structured and how the system behaves when confidence is low. The sector has little reason to accept black-box authority over high-consequence actions when a hybrid system can capture much of the benefit with more auditable safeguards.
What to watch before launch
- Control authority: Whether AstroForge defines which decisions Solo may execute independently and which remain subject to deterministic software or ground approval.
- Safety architecture: The fault-protection layers, fallback modes and independent checks that constrain model outputs.
- Compute and reliability: How the system performs on flight-qualified hardware under power, thermal and radiation limits.
- Flight evidence: Telemetry and operational results from DeepSpace-2, particularly during off-nominal events rather than nominal cruise.
- Human workflow: Whether Solo meaningfully reduces operational workload while preserving operators’ ability to understand and override its recommendations.
Editor’s Take
I think AstroForge is aiming at the right problem. The strongest near-term use of AI in spacecraft is not handing an opaque model the keys to propulsion; it is turning thousands of noisy signals into a timely, prioritized operational picture when the people on Earth cannot respond immediately. If Solo can reliably detect, contextualize and contain problems inside hard safety limits, it could save more mission value than a more dramatic claim of “AI command” suggests.
I would watch the interfaces, not the model label. The commercially meaningful proof will be a clear account of what Solo is allowed to do, how conventional protection software vetoes it, and whether it helps a lean operations team resolve real anomalies. A 2027 flight would be an important test, but autonomous asteroid operations should be judged after repeatable in-space performance, not after a launch announcement.
.jpg){kind=link}