Two months ago we shipped CAE — the first API for orbital compute scheduling. You POST a satellite ID and a workload, you get back a physically-accurate execution plan. Contact windows, link budgets, placement decisions, transfer scheduling — all computed from real orbital mechanics.

But a plan without execution is a whiteboard.

Today we’re shipping the other half: the Operator Agent.

What it does

The Operator Agent is a Rust SDK that runs on a satellite (or in simulation) and executes workloads using a pull-based protocol:

  1. Poll — During contact windows, the agent checks Mission Control for pending workloads
  2. Execute — Steps run locally on satellite hardware, managed by the agent
  3. Report — Events stream back in real-time: step progress, transfers, checkpoints, completion

The event format is the same one CAE already uses for planning and simulation. This means the entire stack — from plan generation to simulated execution to real execution — speaks the same protocol.

Why Rust

This isn’t a web SDK. It runs on satellite flight computers — resource-constrained, radiation-hardened, with no room for garbage collectors or runtime overhead. Rust gives us:

  • No runtime — compile to a static binary, deploy anywhere
  • Memory safety — no segfaults, no buffer overflows, enforced at compile time
  • Small binaries — the agent compiles to a few MB
  • Async I/O — handle concurrent operations without threads via tokio

The crate exposes an Agent trait. Implement poll(), execute(), and report_event() for your satellite platform, and the protocol handles the rest.

Simulated execution

You don’t need a satellite to test. The SDK includes a SimulatedSatellite that replays CAE event streams with physics-accurate timing:

rotastellar-agent simulate \
  --plan plan.json \
  --speed 100 \
  --api-url https://console.rotastellar.com

In Mission Control, you can deploy any plan and watch the execution timeline unfold — step starts, transfer progress through ground station passes, checkpoint saves, completion. All derived from the same SGP4 propagation and link budget calculations that power CAE planning.

The simulation runs at configurable speed (1x for real-time, 100x for demos). When you swap in real hardware, the protocol is identical.

Deploy API

Mission Control now has a Deploy API and a Deployments page. The workflow:

  1. Create a mission and generate a CAE plan (existing flow)
  2. Deploy the plan — creates a deployment record and queues it
  3. Start simulation — the system generates the event stream and you watch it execute
  4. Track progress via the event timeline with real-time updates

Every deployment produces a full audit trail of typed events — the same events a real satellite agent would produce.

The execution gap, closed

With the Operator Agent, RotaStellar now covers the full lifecycle:

Layer Component Status
Plan CAE Scheduler Live
Operate Mission Control Live
Execute Operator Agent Live

We started with planning because that’s where the physics lives. We built Mission Control because operators need a control plane. And now we’re building execution because plans need to become reality.

What’s next

The simulated execution layer is live today. Real satellite integration requires partnership with satellite operators — if you’re building on-board compute systems and want to integrate the RotaStellar protocol, get in touch.

The Operator Agent SDK is available at github.com/rotastellar/rotastellar-agent. Deploy your first workload from Mission Control.