Skip to main content

The console agent

The Constellation OS assistant is a copilot embedded directly in the console. It is not a chat window bolted onto a dashboard: it is a query and control surface over the same live scene the operator is looking at, and every number it reports is computed by a deterministic engine or a named production ML model, never by the language model itself.

One sentence version: the model decides what to run; deterministic tools decide what is true.

What it is​

  • A deterministic-tools copilot. The assistant answers by calling tools: scene controls, fleet statistics, orbital synthesis, network optimizers, beam planners, capacity engines, and production prediction backends. The tool executor runs in the console itself, against the scene state the operator is watching.
  • Embedded in the console. It selects assets, flies the camera, toggles constellations, mutates what-if scenarios, and renders charts and insight cards inline. Answers are visible on the globe, not just in text.
  • An analyst, not a narrator. Analytical answers follow a strict response contract: the requested metric first, deltas against a baseline, ranked alternatives, a deterministic confidence block, and the full audit trail (scope, method, exact calculation, sample sizes, exclusions). See Response contract.

The mental model: one scene graph, capability routing​

Everything on the globe lives in one asset registry. Operator-fleet satellites, gateways, external catalog constellations (Starlink, Kuiper, GPS, and others), uploaded files, chat imports, and synthetic what-if assets are all the same kind of thing: an asset with metadata. Assets differ only in metadata, never in kind.

Two pieces of metadata drive everything the agent does:

MetadataValuesWhat it controls
source (provenance)oneweb, gsaas, catalog, import, chat, syntheticLabeling and disclosure only. Provenance never changes what an asset is: a synthetic satellite is a satellite.
capabilitiestelemetry (live, recorded, none), links, predictions, orbital_elements, coverage_analysis, editable, syntheticWhich analyses exist. The agent routes analyses from capabilities, never from origin.

Capability routing in practice:

  • telemetry unlocks health and utilization statistics.
  • orbital_elements unlocks trajectories, passes, coverage, beam planning, and service availability.
  • links unlocks link budgets and link statistics.
  • predictions unlocks the production ML models.

When an analysis is unavailable, the agent names the missing capability ("this catalog object has no telemetry") instead of refusing generically. Synthetic and uploaded assets are first-class: they propagate through the same SGP4 worker pipeline, animate identically, and appear in search, selection, filtering, analytics, and every coverage, beam, and availability engine. The only difference is the provenance label, which the agent always discloses.

Scoping tools are visibility controls over this one graph, not different worlds: set_filter narrows the operator fleet by physical attributes, set_constellations toggles catalog groups, and reads (select_node, get_entity_detail, get_scene_state, get_fleet_summary) resolve any asset in the registry regardless of source.

The turn lifecycle​

Every turn follows the same loop:

  1. Context. The console assembles a fresh JSON context: the simulation clock, fleet nodes and links, the current selection, precomputed metric percentiles, predictions for the selected asset, and any assets the operator pinned for this turn (globe click or the @ menu).
  2. Model. The context, the bounded chat history, and the tool catalog go to the language model at temperature 0. The model resolves intent and plans tool calls; it does not compute anything.
  3. Tool calls. The model requests tools, singly or in batches, across up to 8 rounds per turn.
  4. Deterministic execution. The console executes each call against the live scene: selections apply, cameras fly, engines run. Results come back as structured JSON with audit fields (scope, sample sizes, exclusions, assumptions, calculations).
  5. Streamed step trace. Every planned action appears in the transcript as a running step before it executes, then resolves to done or error with a one-line outcome ("142/648 match", "3 picks, 214 access min", "n=296, 4 excluded"). The operator watches the chain of events in order.
  6. Synthesis. The model reads the structured results and writes the answer. Charts, forecast cards, and insight cards render below the message; substantial analyses also stream into a report document.

Where computation happens​

All numbers come from deterministic client-side engines and the fleet worker, or from the production prediction API:

  • Fleet statistics, trends, breakdowns: computed from the current snapshot or replay frames, honoring the active filter, operator scope, and sim clock.
  • Orbit and coverage math: SGP4 propagation plus elevation-mask geometry, executed off the main thread in the fleet playback worker for heavy analyses. Propagated tracks never cross the worker boundary; only the compact final result does.
  • Optimizers and planners: pure, deterministic engines for ground-network siting, beam planning, service availability, and network capacity.
  • ML predictions: five production model families (SNR, traffic, weather, jamming, conjunction) called through the prediction API at a plan-gated fidelity tier. See /api/predictions.

The language model is a router and a writer. It never produces a metric.

What the model may and may never do​

Allowed:

  • Resolve intent: the metric, the subject, the time window, and the right tool with the right objective.
  • Choose nominal defaults when parameters are unstated (a 700 km SSO, a 12 hour window) and state every choice as an assumption.
  • Chain tools freely: read the scene, act on it, read again to confirm, then answer.
  • Narrate what the console played on the globe and execute suggested camera moves.

Never allowed:

  • Inventing or estimating numbers. If a tool returns nothing, the answer says so with the reason. Empty scopes, zero matches, and unavailable data are reported plainly.
  • Substituting metrics. When the operator names a metric, the answer is that metric or an explicit statement that it is not computable. Demand-family questions (served or unserved demand, congestion) are refused by the statistics tools with a deterministic wrong_tool result that redirects to the capacity engine; throughput is never a stand-in for demand.
  • Hiding provenance. Synthetic assets are labeled SYNTHETIC, the demand surface is always called a synthetic population-weighted model, and modeled rain is always called a P.618 approximation.
  • Presenting a bare recommendation. Siting and optimization answers carry the ranked alternatives, the rejected candidates with reasons, and the candidate ledger, so no option disappears silently.

Where to go next​