AstroForge announced on 21 September 2026 that its next deep-space vehicle will fly without receiving a single command from Earth. The mission is called Autonomy-1, the system flying it is called Solo, and the claim in the company’s own words is unambiguous: “after Autonomy-1 separates from its launch vehicle, we do not intend to send the spacecraft a single command.”
Telemetry and science data will still come down. Nothing will go up. That one-way arrangement is what makes this different from every autonomy demonstration flown before it, including the ones AstroForge cites as ancestors — NASA’s Remote Agent experiment on Deep Space 1 nearly three decades ago, and the autonomous descent OSIRIS-REx performed at Bennu.
The company is an asteroid-mining startup founded in 2022 with roughly $56 million raised, and it has not yet completed a mission. That combination — an unproven operator making the boldest autonomy claim in commercial spaceflight — is exactly why the engineering argument behind it deserves reading carefully rather than dismissing.
This article covers what Solo is, why AstroForge concluded that ground operations were the thing to remove, how the system will be tested before it is trusted, and where the argument is weakest.
Table of contents
- Why AstroForge Wants the Ground Out of the Loop
- What Solo Actually Is
- The Anomaly Case Solo Is Built For
- How the Spacecraft Knows Where It Is
- How AstroForge Is Testing Before It Trusts
- The Mission: Autonomy-1, Nova Pathfinder and a NASA Payload
- AstroForge’s Track Record Is the Elephant in the Room
- Where the AstroForge Argument Is Weakest
- What This Means Beyond AstroForge
- The Precedents AstroForge Is Measuring Itself Against
- Frequently Asked Questions About AstroForge Autonomy-1
- AstroForge Autonomy-1: The Verdict
- References
Why AstroForge Wants the Ground Out of the Loop
The motivation is not a philosophical preference for autonomy. It is a cost line and a physics problem, in that order.
One third of mission cost
AstroForge is blunt about the economics. Conventional mission operations “makes up a significant portion of our overall mission costs — nearly one-third — and just as critically, it does not scale.” For a company whose business model requires many cheap vehicles rather than a few expensive ones, a cost that rises linearly with fleet size is fatal.
The comparison that frames it
NASA’s OSIRIS-REx ran around 100 operators per shift. A startup cannot staff that, and the startup alternative — a small team watching a spacecraft through short communication windows — is not a lighter version of the same thing. It is a different and worse thing.
Light time and antenna scarcity
“The farther a spacecraft travels from Earth, the longer those operators must wait for data packets, and the more limited information they have to work with.” Deep-space communication also depends on a handful of antennas capable of reaching that far, which are shared, oversubscribed and scheduled months ahead.
The build-or-remove choice
Chief executive Matt Gialich has put the decision as a straight comparison: “Do I go build my own ground network, which is going to cost [around] $200 million to put up five dishes around the world and then do operations on it, or do I try to remove it with a model?” AstroForge chose the model.
| Approach | Up-front cost | Cost per additional vehicle | Limit |
|---|---|---|---|
| Rent deep-space antenna time | Low | Rises with fleet | Scheduling queue |
| Build a private ground network | About $200m for five dishes | Falls after build | Capital and siting |
| Staff a large operations team | Low | Rises with fleet | Headcount, shift cover |
| AstroForge onboard autonomy | Model development | Near zero | Trust in the model |
What Solo Actually Is
Solo is not a single neural network flying a spacecraft. It is a three-part stack, and the distinction matters for assessing the risk.
An intelligence layer, not a replacement
In AstroForge’s description, “Solo is an intelligence layer that sits above the spacecraft’s existing systems. It ingests information about the spacecraft and its current state, identifies if something is off-nominal, then determines what should happen next.” The deterministic, physics-based flight software underneath is not removed. The model sits on top of it.
The three layers
The stack combines conventional control algorithms, models trained on test data for individual subsystems such as power generation and navigation, and an overall intelligence layer trained on roughly 2,500 spacecraft sensors. Gialich has described the top layer modestly: “I’m making a constrained autonomy at a very low sensor input, following the basic training of a transformer model.”
What “constrained” is doing in that sentence
A transformer trained on 2,500 sensor channels is a small model by current standards, operating on a narrow, highly structured input space. It is closer to an anomaly classifier with an action policy than to a general reasoning system, and that is the point: the search space is small enough to test.
The advantage over a human operator
AstroForge’s claim is one of information access rather than intelligence: “Because Solo has access to much more data than any ground operator would, it will be able to make more informed decisions.” A ground team sees what fits in a telemetry downlink. The onboard system sees everything.
| Layer | Type | Job | Failure mode |
|---|---|---|---|
| Flight software | Deterministic, physics-based | Attitude, power, safe modes | Known and testable |
| Subsystem models | Trained on test-stand data | Predict per-subsystem behaviour | Out-of-distribution inputs |
| Solo intelligence layer | Transformer, about 2,500 sensors | Detect, correlate, decide | Confident wrong action |
The Anomaly Case Solo Is Built For
The scenario AstroForge keeps describing is a correlation problem, and it is a good illustration of why onboard beats ground for this class of fault.
The star tracker example
Imagine a vehicle that has lost track of where it is pointing. A ground team sees an attitude error. Solo is supposed to see the attitude error, notice a power anomaly in the same time window, connect the two to a star tracker fault, and act — all without waiting for a downlink, a shift handover and an uplink window.
Why correlation is the hard part
Individually, a small power fluctuation and a navigation drift each look like noise. The fault only becomes visible in the relationship between them, across a window of time, across subsystems that different engineers own. That is precisely the shape of problem a model trained on the whole sensor set can attack and a bandwidth-limited human cannot.
What it will not do
Solo is not being asked to invent mission objectives, redesign trajectories or negotiate with anyone. It is being asked to keep a vehicle alive and on task through faults, which is the job that consumes most of a real operations team’s time anyway.
How the Spacecraft Knows Where It Is
The star tracker keeps appearing in AstroForge’s examples because it sits at the junction of every hard problem in autonomous navigation.
What a star tracker does
It photographs a patch of sky and matches the pattern of stars against an onboard catalogue to derive the vehicle’s orientation. It is a computer vision problem solved on a power-constrained processor, and almost every other subsystem depends on its answer being right.
Why it is the interesting failure
A star tracker can fail loudly, by producing no solution, or quietly, by producing a wrong one. Loud failures are easy: the flight software falls into a safe mode and waits. Quiet failures propagate, because thrusters fire against a false attitude and the error compounds before anyone on the ground sees a symptom.
Where the model earns its place
Detecting a quiet star tracker fault means noticing that the attitude solution disagrees with what the gyroscopes, the solar array current and the thermal profile all imply. That is a cross-subsystem consistency check across noisy channels, and it is exactly the shape of inference a model trained on the whole sensor set can perform continuously while a ground team cannot.
The honest caveat
This is also the scenario in which a confidently wrong model does the most damage. A system that can override a star tracker it believes is lying can also override one that is telling the truth, and nothing in the announcement describes what arbitrates that disagreement.
How AstroForge Is Testing Before It Trusts
The strongest part of the announcement is not the model. It is the test programme wrapped around it.
The ground infrastructure
The company describes “a world-class testing operation around extensive in-house infrastructure, including full-scale thermal testing of the spacecraft, radio testing in a large anechoic chamber, thruster hot-fire, and hardware-in-the-loop testing.” Hardware-in-the-loop is the key item: it lets engineers inject synthetic faults into real avionics and watch what Solo does.
Shadow mode on DeepSpace-2
Before Autonomy-1, Solo flies without authority. “Our next mission, DeepSpace-2, will fly Solo in shadow mode. That means Solo will run onboard and process real spacecraft data, but its decisions will not be executed by the vehicle.” DeepSpace-2 is expected to launch with Intuitive Machines’ third lunar mission by the end of 2026.
What shadow mode proves and does not prove
It proves the model behaves sensibly on real flight data in real thermal and radiation conditions, and it produces a decision log to compare against what the ground team actually did. It does not prove the model recovers from a fault, because a shadow system never gets to try. AstroForge already reports DeepSpace-2 can “fly unguided by humans for up to a week at a time,” which is the intermediate step between the two.
The Mission: Autonomy-1, Nova Pathfinder and a NASA Payload
Autonomy-1 is not a free-flying technology demonstrator with nothing to do. It carries real science for a real customer.
The payload
Autonomy-1 carries COMPASS, a NASA Goddard heliophysics payload gathering data about the Sun. Solo must operate that instrument autonomously alongside keeping the vehicle healthy, which raises the bar considerably — a failed technology demonstration costs AstroForge its reputation, and a failed science payload costs a NASA team its data.
The ride
The spacecraft flies on the first flight of Stoke Space’s Nova Pathfinder vehicle, from Space Launch Complex 14 at Cape Canaveral, targeted for early 2027. Stoke has published the manifest: AstroForge’s Autonomy-1 and a Celestis payload called Infinite Flight.
The rocket risk
Nova Pathfinder Flight 1 is itself a first flight, testing a fully reusable architecture with Zenith full-flow staged combustion on the first stage and an actively cooled Andromeda second stage with a metallic re-entry heat shield. Stoke describes the flight as giving “the first integrated flight data on the hardest full reuse technologies.” First flights of new vehicles fail more often than they succeed.
The compounded probability
Autonomy-1 therefore stacks three independent risks: a maiden launch vehicle, a fourth-ever spacecraft from a company whose first three had anomalies, and an autonomy system with no prior in-command flight experience. None of those is unreasonable on its own; together they argue for reading the 2027 date as an ambition.
AstroForge's Track Record Is the Elephant in the Room
The company has flown three vehicles and completed none of their primary objectives, and that history is load-bearing for how this announcement should be read.
Brokkr-1 and the two prototypes
AstroForge’s first mission was intended to demonstrate refining technology in orbit. Communication problems prevented the demonstration. Two prototype spacecraft flew before Odin, and both suffered anomalies that stopped them completing their missions.
Odin
Odin launched on 27 February 2025 as a rideshare on the IM-2 lunar mission, heading for deep space. It was lost to a combination of ground-station and communication problems, with the primary Australian ground station experiencing significant technical issues that delayed the first contact attempt. Hope of recovering it faded within weeks.
Why that failure argues for Solo
It is worth being precise here: Odin did not fail because its onboard software was inadequate. It failed because the link to the ground did not work when it needed to. An autonomy system that removes dependence on that link is a direct, rational response to the company’s own most expensive lesson.
Why it also argues against
The counter-argument is equally direct. A company that has not yet demonstrated it can build a spacecraft that survives contact with space is proposing to remove the mechanism by which humans rescue spacecraft that do not survive contact with space. Both readings are fair, and the DeepSpace-2 shadow flight is the evidence that will settle which one is right.
| Mission | Date | Objective | Outcome |
|---|---|---|---|
| Brokkr-1 | 2023 | In-orbit refining demonstration | Communication problems, not demonstrated |
| Prototype vehicles | Before Odin | Flight qualification | Anomalies prevented success |
| Odin | 27 February 2025 | Deep-space asteroid flyby | Lost to ground and comms failure |
| DeepSpace-2 | End of 2026, planned | Solo in shadow mode | Pending |
| Autonomy-1 | Early 2027, planned | Full autonomy, COMPASS payload | Pending |
Where the AstroForge Argument Is Weakest
Four objections survive a sympathetic reading of the announcement.
Verification of a learned policy
Deterministic flight software can be exhaustively tested against a specification. A trained model can only be tested against the distribution it was trained on, and the faults that kill spacecraft are, by construction, the ones nobody anticipated. Hardware-in-the-loop testing narrows this gap; it does not close it.
Training data scarcity
There are not many deep-space anomalies to learn from, and the ones that exist are heterogeneous, poorly instrumented and owned by different organisations. Subsystem models trained on test-stand data partially address this, but test stands do not produce the correlated multi-subsystem failures Solo is meant to catch.
The no-uplink decision is stronger than it needs to be
Nothing about the cost argument requires refusing all commands. A system that acts autonomously by default while retaining a command path would capture nearly all the savings and keep the rescue option. AstroForge is choosing the stricter version as a demonstration, which is defensible as a test and would be indefensible as an operating norm.
Sensor integrity
A model reading 2,500 sensors is only as good as those sensors. A fault that corrupts the measurement chain rather than the subsystem — precisely the class that makes onboard diagnosis hardest — gives Solo a coherent but false picture with no ground team to notice the discrepancy.
What This Means Beyond AstroForge
The pattern here is not confined to spacecraft, and it is the reason the announcement is worth attention outside the space industry.
Autonomy as a cost argument, not a capability argument
AstroForge is not claiming the model is smarter than its engineers. It is claiming the model is present, and presence beats intelligence when the round trip costs hours. Every organisation deploying autonomous systems at the edge of a slow link — subsea, remote industrial, offshore energy — is running the same calculation.
The shadow-mode pattern generalises
Running a decision system alongside the humans it will eventually replace, logging what it would have done and comparing, is the most transferable idea in the announcement. It costs one deployment cycle and produces exactly the evidence a safety case needs. Any team building toward autonomous AI agents in a consequential process should structure the rollout the same way.
The instrumentation dividend
Solo is only possible because the vehicle carries 2,500 sensors and someone kept the data. The lesson for terrestrial operators is that the autonomy project starts with instrumentation and data retention years before any model is trained, which is a predictive analytics discipline long before it is an autonomy one.
The Precedents AstroForge Is Measuring Itself Against
The announcement names two ancestors, and both are instructive about how much of this is genuinely new.
Remote Agent on Deep Space 1
In 1999 NASA ran Remote Agent aboard Deep Space 1, an onboard planning and execution system that controlled the spacecraft for a short experimental period and handled simulated faults. It worked, it was celebrated, and it was not repeated at scale — the verification burden was considered too high for missions that could not be lost.
OSIRIS-REx at Bennu
The touch-and-go sample collection at Bennu had to be autonomous because light time made real-time control impossible. The vehicle navigated to the surface on its own using onboard imagery. That is genuine autonomy, but it was autonomy for a few minutes in a scenario rehearsed exhaustively in advance.
What AstroForge is adding
Both precedents are bounded: a defined window, a rehearsed scenario, a ground team ready to resume control. Autonomy-1 removes the boundary. The novelty is not that a spacecraft can decide things; it is that this one will have no one to hand back to for the whole mission.
Why 27 years of caution is not simply timidity
The reason Remote Agent did not become standard practice is that space agencies fly missions whose payloads cost more than their spacecraft, and an unverifiable decision-maker is an unacceptable risk against that. A startup with cheaper vehicles and a fleet strategy has a genuinely different risk appetite, and that difference — not a technical breakthrough — is what makes Autonomy-1 possible now.
Frequently Asked Questions About AstroForge Autonomy-1
Will Autonomy-1 really receive no commands at all?
That is the stated intent: no commands after separation from the launch vehicle. Telemetry and science data still flow down to Earth, so communication is one-way rather than absent.
What is Solo built on?
A transformer-based model developed in-house, sitting above conventional deterministic flight software and a set of subsystem-specific models. The intelligence layer is trained on roughly 2,500 spacecraft sensors.
When does it fly?
Autonomy-1 is targeted for early 2027 on the first flight of Stoke Space’s Nova Pathfinder from Cape Canaveral. Solo first flies in shadow mode on DeepSpace-2, expected with Intuitive Machines’ third lunar mission by the end of 2026.
Who else is involved?
The spacecraft carries COMPASS, a NASA Goddard heliophysics payload. Stoke Space provides the launch. Intuitive Machines provides the ride for the earlier DeepSpace-2 shadow flight.
Has AstroForge completed a mission before?
No. Three vehicles have flown and none completed its primary objective, most recently Odin in 2025, which was lost after ground-station and communication problems.
AstroForge Autonomy-1: The Verdict
The engineering argument is better than the company’s record. Removing mission control is a rational response to a cost that will not scale and a link that has already failed the company once, the three-layer stack is more conservative than the headline suggests, and the shadow-mode test on DeepSpace-2 is genuinely the right way to gather evidence before handing over authority.
The doubt is about sequencing rather than direction. Autonomy-1 stacks a maiden launch vehicle, an operator with three incomplete missions and an autonomy system with no in-command flight time, and the all-or-nothing no-uplink design removes the one recovery path that has saved spacecraft before. The result that matters arrives well before 2027: watch what Solo’s decision log on DeepSpace-2 says it would have done, and how closely that matches what the humans actually did. Readers interested in the broader shift toward machines that reason about their own hardware may also want our coverage of physical AI, where the hardware becomes the neural network.
References
More AI coverage: explore Progressive Robot's AI Models, Tools & Releases hub — hands-on reviews, setup guides and benchmarks in one place.
