STELARIS
Orbital logistics · restricted
🔒 Provisional gate · full auth pending
TECH / technology & approach

How the swarm works.

The detail behind Stelaris — the coordination brain we're proving now, the servicer concept, and the operations console. ← Back to the overview

01 · Problem

Nothing up there can be moved.

The space economy is about to scale ten to a hundred times over. But everything we launch is built to fly once and stay put. Every object carries its own propulsion because there's no other way to move it — the equivalent of every shipping crate hauling its own engine. When the fuel runs dry, working hardware becomes junk it can't correct, dodge, or relocate. And nothing already in orbit can be moved, serviced, assembled, or brought home. An economy that can only launch and abandon isn't an economy. The bottleneck isn't getting to orbit — it's the ability to physically act on what's already there.

02 · Solution

Put the intelligence in the swarm, not the cargo.

Stelaris builds a shared, on-demand swarm that can grab, move, assemble, and place any object in orbit — of any mass or shape. A group converges on a target, takes hold, and repositions it: to a new orbit, off a collision course, into a service slot, or into a structure being built in place. Then it releases and moves to the next job. The object carries no propulsion and no autonomy of its own — the swarm brings both. And it isn't dedicated to any one payload: the same fleet works job after job across the whole sky, so hundreds of objects share one set of robots instead of each launching its own.

SEQ · how it works

Rendezvous, attach, move, release.

A swarm surrounds an object it has never seen, adheres to it, and repositions it with coordinated ion thrust — then lets go and moves to the next job. This is the loop the coordination algorithm is learning to run.

Single unitCollective transport
03 · Thesis

Launch is nearly solved. Thrust is a commodity. The moat is coordination.

Moving a real object in orbit means many autonomous units agreeing — in real time, from only what each one can sense locally, with no central controller — on how to grip, balance, and steer a shared mass none of them could move alone. That's the hard problem, and it unlocks everything above it: servicing, in-space assembly of large structures, debris removal, logistics between orbits. Whoever teaches a swarm to jointly manipulate the physical world owns the layer the entire space economy runs on. We're building that layer first.

04 · The system

The service needs three layers to come online. We're building the hardest and most defensible one first — without the coordination, the robots are just more debris.

Algorithms

The coordination brain: how a swarm agrees, grips, and maneuvers a shared object none of its robots could move alone. The core technical risk, and the moat.

● Building now
loading latest runs…

Hardware

The servicer itself — a flat bus with a gecko-adhesive capture face, twin canted ion thrusters aft, and deployable solar wings, built to dock and thrust in swarms. A first-cut concept grounded in real orbital-servicing hardware; the design follows the coordination.

Concept · SV-1
Concept · SV-1 rev A Swarm servicer unit

Control

The operations layer: one console tasking thousands of robots against thousands of objects — who moves what, when, and along which path. A concept for what the operator actually sees.

Concept preview
STELARIS MISSION CONTROL · ORBITAL OPS —— UTC
Tracked objects
no target selected
Designation
Regime
Altitude
Inclination
Period
Maneuver
Select a target to plan a maneuver.
Live · CelesTrak Objects tracked
05 · Status

We prove the hard part first.

The coordination has to work before anything else matters, so that's what we're building now — validated in high-fidelity simulation across a live cluster, every claim backed by an ablation. The counter above is that work, run by run.

06 · Founder

The coordination problem, from someone who's spent his career on it.

Joshua Bloom is the founder of Stelaris. He holds a PhD in Robotic Engineering from Worcester Polytechnic Institute, where his dissertation — Global State Prediction for Multi-Agent Reinforcement Learning — tackled the exact problem Stelaris is built on: getting many autonomous robots to coordinate and act on a shared goal from only what each one can sense locally. He ran WPI's NEST (Novel Engineering for Swarm Technologies) Lab and built the open-source GSP-RL library the research runs on.

Today he leads the Autonomy Behaviors & Agents team at Applied Intuition — one of the fastest-growing companies in autonomous systems — directing the engineers who build multi-agent autonomy deployed across surface, aerial, and ISR platforms. He architected maritime autonomy that ran across 12+ vehicles, drove a defense program to 5× growth, and designs the enterprise-scale reinforcement-learning infrastructure his teams train on. Earlier, at MIT Lincoln Laboratory, he engineered reinforcement-learning algorithms coordinating 300+ agents and pioneered decentralized multi-agent sensor networks.

His conviction: the hard part of moving things in space is coordination, not thrust — a control problem, not a hardware problem. He builds under a strict rule — a component earns credit only when an ablation proves it. Solve coordination honestly, and the hardware becomes an engineering exercise. That's the company he's building.

Full background on LinkedIn →

07 · Research