AstroForge AI Spacecraft Hands Solo Control, but Removes Mission Control’s Safety Net

AstroForge plans to put its AstroForge AI spacecraft under Solo’s control in 2027, without routine commands from Earth after launch vehicle separation. That decision turns a familiar spacecraft automation problem into a much harder test of machine judgment.

The company calls the mission Autonomy-1. Solo, a compact transformer-based system developed in-house, will coordinate spacecraft operations above an established layer of deterministic flight software. AstroForge says Autonomy-1 will transmit telemetry and science data to Earth while completing its mission without ground commands.

That is a much narrower claim than building a general-purpose artificial intelligence. It is also a more consequential one. Solo must interpret roughly 2,500 sensor inputs, diagnose off-nominal behavior, and choose actions while operating a physical vehicle beyond immediate human help.

AstroForge is making this bet after losing effective control of Odin, its first deep-space spacecraft, in 2025. Ground-station problems delayed contact during Odin’s most valuable communication window. The company never established the sustained command link needed to complete the asteroid mission.

The central contest is therefore not AI against another spacecraft company. It is onboard decision-making against the traditional model of Earth-centered mission control. One promises faster responses and lower operating costs. The other offers experienced people, extensive procedures, and the chance to intervene when software behaves unexpectedly.

The AstroForge AI Spacecraft Will Make Its Own Calls

Autonomy-1 is designed to complete its entire post-separation mission without receiving a command from Earth.

AstroForge announced Autonomy-1 on September 21, 2026. The mission is scheduled to fly in 2027 aboard the first launch of Stoke Space’s Nova Pathfinder vehicle.

Stoke confirmed the payload in its first-flight manifest. It said Autonomy-1 would demonstrate AstroForge’s Solo spacecraft intelligence system while supporting NASA Goddard’s COMPASS heliophysics payload.

The NASA instrument makes the mission more than an isolated software test. Solo will need to manage the spacecraft while coordinating the functions required for a working scientific payload. Autonomy must therefore preserve power, navigation, thermal conditions, and instrument operations across the mission.

AstroForge says telemetry and science data will still flow from the spacecraft to Earth. Engineers should be able to observe what Solo does and examine the reasoning trail reflected in mission data. However, the announced design removes the normal command path in the other direction.

CEO and co-founder Matt Gialich told TechCrunch that he did not plan to fly radios capable of receiving commands from Earth. He acknowledged that his engineering team might persuade him to change that decision before launch.

That caveat matters. A spacecraft that voluntarily ignores available commands differs from one physically unable to receive them. The first design preserves an emergency option. The second makes autonomy an irreversible condition once the vehicle separates.

AstroForge’s mission announcement describes Solo as an intelligence layer above conventional flight software. It does not replace the verified, physics-based algorithms that control individual systems.

That layered architecture is an important guardrail. Deterministic software continues handling functions whose expected behavior engineers can specify and test. Solo receives spacecraft state information, recognizes abnormal conditions, and decides what should happen next.

The model is transformer-based, meaning it uses an architecture designed to identify relationships across sequences of data. On a spacecraft, those sequences come from sensors and subsystem status rather than ordinary language prompts.

AstroForge says the model will process inputs from about 2,500 sensors. Specialized models trained on subsystem test data will support areas such as navigation and power generation. Solo will then coordinate decisions across those systems.

A representative problem begins with uncertainty about the spacecraft’s location. Solo might correlate that navigation error with abnormal power behavior from a star tracker. It could then attempt a targeted recovery, such as restarting the affected component.

That example sounds modest beside popular claims about autonomous agents. In spaceflight, however, correctly restarting one component can determine whether a vehicle remains controllable. The important capability is not conversation. It is selecting a safe action from limited, imperfect evidence.

Autonomy-1 will still be a demonstration mission. It will not mine an asteroid or prove that Solo can manage every deep-space scenario. Its immediate objective is to show that one spacecraft can complete a defined mission without post-separation commands.

Odin Turned Ground Communications Into the Main Opponent

AstroForge’s autonomy push follows a mission where communication infrastructure failed before human operators could gain reliable control.

Odin launched on February 26, 2025, as a secondary payload on Intuitive Machines’ IM-2 mission. AstroForge intended the spacecraft to fly past asteroid 2022 OB5 and capture images that would help evaluate it as a mining target.

The company received several early indications that Odin was alive. It never established the sustained two-way communications needed to command the vehicle, verify its state, or complete the planned encounter.

AstroForge’s Odin debrief identified failures across its hastily assembled ground network. One station transmitted with the wrong polarization. Another used incorrect pointing coordinates.

Those errors consumed the opening hours after separation, when Odin was closest to Earth and most likely to have adequate battery power. The company later used more sensitive equipment and additional antennas, but its chances diminished as the spacecraft traveled farther away.

Optical observations indicated that Odin continued along its expected path. That did not restore command authority. The mission became a sharp demonstration of how a functioning spacecraft can become operationally useless when communications fail.

AstroForge has not argued that Solo definitely would have saved Odin. Gialich told the original report that he did not know whether onboard intelligence could have recovered the vehicle.

His narrower point is stronger. Nothing aboard Odin was equipped to attempt a broad diagnosis once Earth lost control. An autonomous system might have inspected local data, identified a recoverable state, and acted before the ground team understood the problem.

Local information creates a genuine advantage. Deep-space communication links cannot continuously transmit every sensor reading at full detail. Engineers receive a reduced picture shaped by bandwidth, antenna access, distance, and spacecraft power.

Solo can inspect data at its source. It does not need to wait for a ground pass before correlating readings across navigation, power, communications, and thermal systems. That shorter decision loop becomes valuable when an anomaly is evolving by the minute.

The financial argument is equally important for AstroForge. The company says mission operations and Earth infrastructure account for nearly one-third of its overall mission costs. Gialich estimated that building a private global network of five dishes would cost around $200 million.

Those figures are company estimates, not independently verified industry benchmarks. They still explain AstroForge’s incentive. A startup planning multiple low-cost spacecraft cannot copy the labor and infrastructure model used by a major government mission.

TechCrunch reported that NASA’s OSIRIS-REx asteroid mission staffed about 100 operators during each eight-hour shift around its 2018 rendezvous. That approach brought experience, specialization, and redundancy. It also depended on resources that a venture-backed space company cannot easily reproduce.

AstroForge was founded in 2022 and has raised $56 million, according to the report. A proposed ground network costing several times that amount would conflict with its low-cost mission model.

Autonomy becomes an economic requirement under those conditions. Each additional spacecraft otherwise requires more controller time, more antenna access, and more operational coordination. Those costs rise with the fleet instead of falling through replication.

That does not mean software makes ground infrastructure irrelevant. Autonomy-1 still needs to return telemetry and scientific observations. AstroForge also needs tracking data to understand whether the mission reached its intended path.

Solo instead targets the command dependency. The company wants each spacecraft to continue operating when human instructions are delayed, unavailable, or too expensive to provide continuously.

The pressure extends beyond AstroForge. Small deep-space companies often pitch standardized vehicles, frequent launches, and lower mission costs. Those promises become harder to sustain if every new vehicle requires a bespoke operations organization.

If Solo works, competing platforms will face a choice. They can accept higher ground costs, develop comparable autonomy, or limit missions to narrower environments where established automation remains sufficient.

Solo Extends an Old Idea With a Less Predictable Model

Spacecraft autonomy has decades of history, but Solo adds a transformer decision layer to systems traditionally designed for predictable behavior.

NASA demonstrated onboard artificial intelligence long before the current transformer era. Its Deep Space 1 spacecraft ran the Remote Agent experiment in 1999.

Remote Agent planned activities from high-level goals, executed commands, monitored results, and responded to simulated failures. NASA’s experiment record says the system completed all planned objectives.

The experiment also encountered a software bug during its first run. Engineers diagnosed the problem and continued with a revised test. That episode remains relevant because early autonomy can expose failure modes inside the autonomy system itself.

NASA’s architecture used model-based reasoning, constraint-aware planning, and explicit fault-protection logic. Solo belongs to a different generation. Its transformer component learns relationships from training and test data rather than relying only on rules written in advance.

The difference is not that one system is intelligent and the other is not. Both operate within engineered boundaries. The difference concerns how each system represents patterns, interprets unfamiliar conditions, and selects a response.

Traditional control algorithms remain attractive because engineers can model their behavior under defined inputs. Verification teams can test requirements, inspect decision paths, and establish conditions where the software must enter a safe state.

Learned models complicate that process. Their behavior emerges partly from training data, model structure, and statistical relationships. A response that looks sensible across thousands of tests might still fail under a rare combination of sensor errors.

AstroForge is addressing that problem with a hybrid stack. Solo coordinates decisions, while established algorithms retain direct responsibility for physics-based control. This limits the model’s authority over the lowest-level vehicle behavior.

The distinction resembles a mission manager directing specialized controllers. Solo can decide that a component needs attention, but the underlying flight software governs how the spacecraft performs the relevant maneuver or system action.

That architecture should reduce some risks. It does not remove the need to validate Solo’s decisions. A correctly executed command remains harmful if the model chooses the wrong command, acts at the wrong time, or misreads corrupted data.

AstroForge is therefore planning an intermediate flight test. DeepSpace-2 will carry Solo in shadow mode before Autonomy-1 launches.

Shadow mode lets the model process real spacecraft data and produce decisions without controlling the vehicle. Engineers can compare those proposed actions with actual spacecraft behavior and the choices made by ground operators.

DeepSpace-2 is expected to launch with Intuitive Machines’ third lunar mission. Its broader objective is an asteroid rendezvous and imaging campaign, according to AstroForge.

The spacecraft weighs about 200 kilograms and is designed for missions lasting up to two years. AstroForge says it can operate at distances reaching 20 million kilometers from Earth.

Those conditions should provide more realistic data than laboratory simulations. Space hardware experiences radiation, thermal cycling, noisy sensors, communication gaps, and interacting faults that are difficult to reproduce completely on Earth.

Shadow mode also has limits. The vehicle does not experience the consequences of Solo’s proposed commands. A decision may look correct in recorded telemetry while producing unexpected effects when applied to real hardware.

Engineers can model those consequences through hardware-in-the-loop testing, which connects flight software to physical components or representative simulators. Yet the full closed loop only appears when the model’s decisions change the spacecraft’s next state.

That gap makes DeepSpace-2 essential but not conclusive. It can identify obvious errors, measure false alarms, and reveal whether Solo recognizes real anomalies. It cannot prove that every action sequence will remain stable in flight.

AstroForge will also need a clear policy for disagreement. If deterministic fault protection recommends a safe mode while Solo recommends continued operations, the architecture needs a predictable authority hierarchy.

The company has not publicly disclosed enough technical detail to evaluate that hierarchy. It has not published model size, compute hardware, power consumption, training procedures, or formal verification results.

That absence is understandable before a demonstration mission. It also means the strongest claims remain assertions by AstroForge. Readers should distinguish the announced architecture from demonstrated performance.

Removing Ground Commands Raises the Standard of Proof

Autonomy-1 succeeds only if Solo handles uncertainty without turning one recoverable software error into a permanent mission loss.

Spacecraft already perform critical operations autonomously when communication delays make real-time control impossible. NASA’s OSIRIS-REx mission used Natural Feature Tracking during its descent to asteroid Bennu.

The system compared onboard images with mapped surface features. It could cancel the descent if it predicted an unsafe touchdown. NASA’s navigation account described it as completely autonomous.

That autonomy was bounded by a specific mission phase and an extensively prepared environment. Engineers built hazard maps and defined the conditions that should trigger a retreat. Human teams remained responsible for the wider mission.

Solo aims to assume a broader operational role. It will monitor multiple systems, identify off-nominal states, and coordinate responses throughout Autonomy-1. That increased scope creates more opportunities for useful adaptation and harmful interaction.

A transformer can detect patterns across many sensor streams. It can also assign confidence incorrectly when inputs fall outside its training distribution. Space missions generate exactly those unusual combinations that are hardest to collect beforehand.

Sensor failures present another challenge. A model may receive internally consistent data that does not reflect physical reality. If several readings share a common fault, correlation alone might reinforce the wrong diagnosis.

Engineers normally manage this problem through redundancy, independent measurements, plausibility checks, and conservative fault trees. Solo’s value depends on using those protections without overriding them through an unjustified interpretation.

Compute constraints also matter. Space-qualified processors typically trail data-center hardware in performance. They must operate within tight power and thermal limits while tolerating radiation.

AstroForge describes Solo as a small model, which makes onboard operation more credible. However, model size alone does not establish reliable latency, energy use, memory requirements, or radiation resilience.

Cybersecurity deserves attention as well. A receiving radio creates an attack surface, but removing it does not eliminate software risk. Training pipelines, development tools, model updates, and flight code can all introduce vulnerabilities before launch.

The no-command design further removes a response option. Ground teams cannot upload a patch, change a threshold, or disable a faulty decision layer after separation if the spacecraft truly lacks a receiver.

That constraint might improve discipline before launch. Engineers must decide which behaviors are permitted and which states require deterministic fallback. They cannot depend on a future command to repair an incomplete design.

It may also turn a minor model defect into a permanent one. NASA’s Deep Space 1 experiment benefited from staged testing and continued human involvement. Autonomy-1’s public premise offers less room for that intervention.

The strongest version of AstroForge’s demonstration would include transparent success criteria. Completing the mission is one measure, but it does not show how often Solo intervened or whether those interventions improved outcomes.

Useful evidence would include the number of detected anomalies, false positives, rejected recommendations, recovery attempts, and transitions into safe modes. Engineers also need to know whether deterministic safeguards blocked any unsafe Solo actions.

Shadow-mode results from DeepSpace-2 could provide a baseline. AstroForge could compare Solo’s recommendations against flight-controller decisions and later evaluate which choice matched the spacecraft’s actual state.

The company has not committed publicly to releasing that level of detail. Commercial sensitivity and safety concerns may limit disclosure. Without such evidence, outsiders will struggle to separate autonomous performance from an uneventful mission.

Mission duration will shape the result too. A short flight with few anomalies tests nominal planning more than resilience. A longer mission creates more opportunities for degradation, navigation uncertainty, and subsystem interaction.

Autonomy-1 also carries a real scientific payload, which raises the cost of mistaken decisions. Solo must protect the spacecraft while giving COMPASS the power, pointing, and operational support needed to collect useful data.

This is why the mission should not be framed as AI replacing aerospace engineering. Solo depends on deterministic controllers, verified spacecraft systems, sensor redundancy, mission constraints, and extensive ground testing.

The actual proposition is narrower. AstroForge believes a learned coordination layer can reduce dependence on continuous human operations without surrendering the reliability supplied by conventional flight software.

That tradeoff has not been resolved by the announcement. It will be resolved through flight data, disclosed failure handling, and the spacecraft’s behavior when conditions stop matching the plan.

What the 2027 Mission Must Prove Next

Three milestones will determine whether Solo becomes a credible spacecraft operator or remains an ambitious demonstration.

The first signal is DeepSpace-2’s shadow-mode record. That mission should show whether Solo can interpret real sensor data before it receives command authority.

The most valuable result would not be perfect agreement with ground controllers. An autonomy system earns its place by identifying conditions humans miss, reacting faster, or proposing a safe response from richer local data.

Disagreement still needs careful analysis. Engineers must establish whether Solo found a legitimate alternative, misunderstood the spacecraft, or generated an action that deterministic safeguards would reject.

Frequent false alarms would weaken AstroForge’s case. They could consume power, interrupt science, and create unnecessary mode changes once Solo gains control.

The second signal is Autonomy-1’s final communications architecture. AstroForge currently describes a one-way link that sends telemetry and science data to Earth without accepting commands.

If the spacecraft launches with a dormant or emergency command receiver, the demonstration can remain autonomous while preserving a last-resort safety channel. That choice would reduce the purity of the experiment but improve recoverability.

If AstroForge removes the receiver entirely, Autonomy-1 becomes a stronger test of operational independence. It also becomes less forgiving of errors discovered after launch.

Neither choice automatically proves courage or caution. The important issue is whether AstroForge publishes the authority rules, fallback behavior, and conditions that define successful autonomy.

The third signal is mission evidence after separation. A vehicle that follows a nominal script without encountering meaningful anomalies will validate basic execution. It will not fully validate Solo’s diagnostic claims.

A stronger result would document an unexpected condition, the evidence Solo used, the action it selected, and the spacecraft’s state afterward. That chain would show whether the system can do more than replay a prepared plan.

Telemetry can also expose silent failures. Solo might complete the mission while wasting energy, missing science opportunities, or repeatedly approaching unsafe limits. Final mission status alone would hide those weaknesses.

AstroForge should therefore report operational quality alongside survival. The most useful measures include command decisions, anomaly classifications, recovery duration, resource margins, and blocked actions.

NASA and commercial partners will also watch COMPASS performance. Reliable scientific output would show that Solo can balance payload objectives with spacecraft health rather than merely keeping the vehicle alive.

A successful flight would pressure other small-spacecraft builders to reconsider their operations models. The immediate opportunity is not autonomous asteroid mining. It is reducing the staff and ground access required for each additional deep-space vehicle.

That shift would affect software teams as much as mission controllers. Engineers would need better records of system behavior, anomaly histories, test results, and decision constraints. A searchable knowledge base can help teams connect that evidence before it becomes training or validation material.

However, no knowledge system can substitute for flight qualification. Solo’s credibility will come from how it behaves when sensors disagree, communications disappear, and recovery procedures compete for limited power.

The AstroForge AI spacecraft is compelling because its central constraint is real. Deep-space operations cannot scale indefinitely through larger control rooms and scarce antenna time.

Its proposed answer also carries real risk. Moving intelligence onboard shortens the decision loop, but it transfers more responsibility to software that Earth may be unable to correct.

Watch DeepSpace-2’s shadow results, the final command-link design, and Autonomy-1’s post-flight decision record. Together, those signals will show whether Solo actually reduces dependence on Earth or simply removes the safest path home.