Skip to main content

Worked examples

Fourteen real operator questions, each walked end to end: what is asked, the tool chain the agent plans and why, what the results carry (audit fields, confidence, visualization), and the caveats an honest answer must state. Together they exercise most of the tools reference and every rule in the response contract.

These are assistant workflows inside the console; for API-level integration examples, see API examples. For the chat surface itself, see the assistant in the console.

1. Compare a 48-satellite Walker against the current fleet​

"How would a 48-satellite Walker constellation at 550 km compare to my current network?"

What the agent runs

  1. get_scene_state to establish what is loaded and the sim clock; the comparison baseline must be stated, not assumed.
  2. analyze_network_capacity (focus unserved_demand) over the current scene: the fleet-only baseline in P50/P90/P95/P99 unserved Gbps.
  3. create_orbit_scenario with count 48, planes 8, orbit_type custom, altitude_km 550, inclination_deg 53, phasing walker, and a stated window (12 h, 60 s step, 10 degree mask). The Walker's own coverage figures come from this run: combined coverage percent, per-satellite coverage, the single-satellite baseline, and coverageDeltaPercent.
  4. analyze_network_capacity again, now over the augmented scene. Synthetic assets are first-class, so the engine scores fleet plus Walker identically, and the delta against step 2 is the comparison.
  5. reset_scenario (or save_scenario to keep the design), so the sandbox does not leak into later questions.

What comes back

The Walker run reports its assumptions (chosen plus derived elements, per-plane RAANs in planeRaansDeg, the inter-plane phase offset) and the exact calculation. The capacity runs carry percentiles, per-region cause attribution, and a confidence block that downgrades for synthetic demand. The answer leads with the requested comparison as before/after deltas, then the ranked evidence.

Caveats: the 48 satellites are SYNTHETIC and separate from live telemetry; 48 is the per-call cap; demand figures come from the synthetic population-weighted model; both evaluations are scene-scoped.

2. Place three ground stations for maximum contact time​

"Where should my next three gateways go to maximize contact time?"

What the agent runs

  1. optimize_ground_network with objective contact_time, picks 3, and use_existing_network_as_base true. The objective comes from the question: contact time means aggregate satellite-gateway access minutes, where simultaneous contacts count. Availability would be the wrong objective here.

What comes back

The answer opens by binding the objective (metric and units, window and step, elevation mask, fleet evaluated, candidate set), then leads with where: each pick's label, country, and lat/lon first. Each pick carries its marginal gain in access minutes and as a percent versus the baseline, plus uniqueSatelliteMinutesGain so overlap with the existing network is visible. The result also carries baselineMetrics versus finalMetrics, every rejected candidate with its reason, and the candidate ledger (pool by source, minus exclusions, equals evaluated, equals picked plus rejected), so no candidate disappears silently. If access availability was already 100 percent, a saturationNote explains why the picks still help; a zero-gain claim would require zeroGainProof.

On the globe, the candidate sweep plays automatically: candidates appear staggered, rejected ones dim, picks glow with rank and score, and the winner pulses. The agent narrates the sweep and flies the camera to the winner with set_camera.

Caveats: candidates are real sites (GSaaS catalog, OneWeb gateways, scene stations); grid sites appear only with include_grid and ignore land feasibility; cost, licensing, and backhaul are excluded factors; the evaluation is clear-sky unless rain was passed.

3. P99 unserved demand​

"What is the P99 unserved demand across the network?"

What the agent runs

  1. analyze_network_capacity with focus unserved_demand. This is the only tool that computes demand-family metrics. If the model tried query_fleet_statistics instead, the tool would refuse structurally with a wrong_tool result redirecting here: throughput is a different distribution and never a stand-in for unserved demand.

What comes back

P50/P90/P95/P99 unserved Gbps with per-region cause attribution (coverage-constrained versus gateway-constrained versus capacity-constrained), the serving model stated up front (coverage, then feasible gateway link, then capacity caps, demand assigned greedily), the evaluation window, and an insight card with the full audit trail. The confidence block is at most medium, with "demand figures come from the SYNTHETIC population-weighted model, not real traffic" as an explicit reason.

Caveats: synthetic demand, always disclosed; scene-scoped, so the number describes the loaded simulation, not the whole real-world network.

4. Gateway bottlenecks at peak​

"Which gateways bottleneck the network at peak?"

What the agent runs

  1. set_timeline_mode("replay") if the fleet is not already in replay; without it there are no links to analyze, and the agent says it is loading the replay rather than dead-ending on "no data".
  2. seek_time to the peak window the operator means, stating the resolved time.
  3. analyze_network_capacity with focus gateway_bottlenecks.

What comes back

The regions that are capacity-constrained by gateways rather than satellite coverage, with per-gateway utilization, cause attribution, and the assumptions block. On the globe, the hottest gateways pulse; the agent narrates the emphasis and can select the named gateways and frame their region with the camera.

Caveats: demand loading is synthetic; there is no geographic gateway filter, so the camera frames the region and named gateways are selected, which the answer states plainly.

5. Heavy rain over Europe, quantified​

"How much contact do we lose in heavy rain over Europe?"

What the agent runs

  1. The agent constructs a rain_regions descriptor: a lat/lon box with representative European bounds and a representative heavy-rain rate (about 25 mm/h), both stated as assumptions.
  2. The matching evaluation with that weather attached, for example compare_candidate_sites across the European gateways, or optimize_ground_network when the question is about network posture. Under weather, a sample only counts as contact when the Ka fronthaul link budget also closes under modeled rain attenuation at that sample's elevation.

What comes back

Both figures, always: clear-sky versus weather-degraded contact, plus samplesLostToWeather. Optimizer runs additionally report finalAvailabilityClearSkyPercent versus finalAccessAvailabilityPercent, showing which gateways need proactive rerouting. Low-elevation contacts are lost first, and the per-site results show it.

Caveats: the model is a deterministic P.618 approximation of rain attenuation, named as such, never presented as measured weather or a forecast; the rain field is exactly what was requested, and identical inputs reproduce identical results.

6. Mission readiness report via a workflow​

Run the "Launch readiness review" workflow for mission Pathfinder-2.

What the agent runs

The workflow template renders into a prompt (unset optional parameters become "choose a sensible default and state it") and drives a normal turn:

  1. list_scenarios, then load_scenario if a saved scenario exists for the mission; otherwise create_orbit_scenario from the planned injection orbit with every chosen element stated.
  2. Coverage scoring against the current ground network: coverage percent, first-contact opportunities after separation, longest gap in the first day.
  3. compare_candidate_sites for the primary and backup TT&C stations to confirm early-pass geometry.

What comes back

A go/no-go checklist: coverage and first-pass contact confirmed, link margins positive, ground stations committed, open risks with owners. Every number carries its window, step, and elevation mask; synthetic assets are marked synthetic. The turn's insight cards and charts land as an analysis artifact in the Reports workspace, ready to become the readiness document.

Caveats: the injection orbit run is synthetic and separate from live telemetry; readiness is scored against the loaded ground network, not stations that exist only on paper.

7. Satellites over Australia right now​

"Which satellites are over Australia right now?"

What the agent runs

  1. Resolve "now" to the current sim clock and say so; the scene has one authoritative time.
  2. set_camera with view region and an Australian bounding box, so the operator sees the subject.
  3. A deterministic read for the population: query_fleet_breakdown on a node metric grouped by region returns each group with its members and sample size, and get_scene_state reports per-source asset counts. select_node highlights the named satellites that participate.

What comes back

The count and the named satellites from the tool results, at the stated sim time, with the camera framing the region and the participating satellites selected. If the operator wants a constellation not currently displayed, the agent chains set_constellations first, then re-reads, and reports the real match counts.

Caveats: this is a snapshot at the sim clock, not a persistent regional filter; catalog constellations count only when their groups are enabled, and the answer says which sources were in scope.

8. Compare two architectures via saved scenarios​

"Compare a 24-satellite, 6-plane 700 km SSO design against an 18-satellite, 3-plane 1200 km polar design."

What the agent runs

  1. create_orbit_scenario for design A (count 24, planes 6, SSO at 700 km), recording combined coverage, per-satellite coverage, passes, and derived elements; then save_scenario as "design-a".
  2. reset_scenario so the runs stay independent.
  3. create_orbit_scenario for design B (count 18, planes 3, custom polar at 1200 km); save_scenario as "design-b".
  4. Both runs use the identical window, step, and elevation mask, stated once. The comparison is a side-by-side table plus a bar chart of the primary metric.

What comes back

Coverage percent, pass counts, mean pass duration, and stations used for each design; a recommendation with an explicit tiebreak rule; and a flag when the winner's advantage is within noise of the runner-up. Because both designs are saved with their epoch and evaluation config, anyone can load_scenario either one later, seek to the saved epoch, and reproduce the identical numbers: the engines are deterministic.

Caveats: both runs are synthetic and separate from live telemetry; the ranking can be sensitive to the elevation mask and window, and the answer says when it is. The "Coverage comparison" workflow template packages this whole flow.

"How many service hours per day can a customer in Nairobi expect?"

What the agent runs

  1. analyze_service_availability for Nairobi. The agent resolves representative coordinates for the named city and states them, along with the elevation mask, as assumptions.

What comes back

Service hours per day in bold, coverage percent, longest and mean gap, pass count, and per-hour forecast highlights: best and worst hour SNR and throughput, and outage windows. The result carries a confidence block and the standard excluded factors (cost, licensing, backhaul, and weather when the run is clear-sky).

Caveats: the answer describes the constellation currently loaded in the scene, whether operator fleet, uploaded, or synthetic, and the agent says so when the question implies the whole real-world network.

10. A synthetic SSO constellation​

"Create a 6-satellite sun-synchronous constellation at 700 km in 3 planes."

What the agent runs

  1. create_orbit_scenario with orbit_type sso, count 6, planes 3, and defaults stated (12 h window, 60 s step, 10 degree mask, walker phasing, raan_spread_deg 360, walker_f 1). The inclination is auto-derived from the sun-synchronous condition, about 98.2 degrees at 700 km, and reported with the mean motion.

What comes back

Six first-class synthetic satellites fade into the globe, click-selectable with detail panels, ground tracks, and fronthaul links. The result reports combined coverage in bold, the per-plane RAANs and inter-plane phase offset, per-satellite coverage against the single-satellite baseline with coverageDeltaPercent, pass intervals with stations and max elevations, and the exact calculation.

Caveats: SYNTHETIC label always; results are separate from live telemetry; the sandbox is cleaned with reset_scenario or kept with save_scenario.

11. Root-causing a throughput drop​

"Why did throughput drop between 12:10 and 12:25?"

What the agent runs

  1. set_timeline_mode("replay") if needed, so timeline frames exist.
  2. query_fleet_trend for throughput over the window: the series pinpoints onset, and summary.delta sizes the drop. If the requested window exceeds stored data, window.truncated is set and the answer states the real covered span.
  3. query_fleet_breakdown by ground station and by link type near the low point, to localize which segment carries the drop.
  4. seek_time to just before and just after onset, comparing the implicated asset's links and neighbors at both instants; get_entity_detail on the suspect gateway or satellite for its link budget and health.

What comes back

A timeline of evidence with the onset time, the localized segment (best and worst group with values and sample sizes), a line chart of the trend, and competing explanations with the ones the data eliminates. The answer states root-cause confidence and what telemetry would confirm or refute it, and never infers a cause the numbers do not support.

Caveats: the demo replay window is about one hour, so deep look-backs truncate; correlation across groups is evidence, not proof, and the answer says which explanations remain open.

12. A downloadable engineering report​

"Turn this analysis into a report I can send."

What the agent runs

Nothing new needs to run: every analytical turn already emitted an analysis artifact (summaries, charts with regeneration metadata, insight cards, tool names). The operator assembles or opens the report in the Reports workspace; the insight cards become the Findings and Method sections, so every figure is traceable to the producing tool call.

What comes back

A report document with posture, findings, charts, and a method section (tools, windows, assumptions, exclusions), exportable as PDF for customers, regulators, or leadership. Charts in the document can be regenerated later against the current scene via their regeneration metadata.

Caveats: reports live in the browser's IndexedDB, local to the device, as described in Memory and sessions; reproducing the numbers elsewhere means re-running the same deterministic tools with the same inputs, which the method section fully specifies.

13. Four-color versus seven-color frequency reuse​

"For this satellite's footprint, should we run 4-color or 7-color reuse?"

What the agent runs

  1. Anchor resolution: the named satellite or the current selection; an explicit lat/lon plus altitude also works.
  2. compare_frequency_reuse with colors_a 4 and colors_b 7, defaults stated (32 beams, 1250 MHz total spectrum).

What comes back

Both plans' total throughput, mean and worst co-channel C/I, edge-of-beam SNR, and per-beam bandwidth, with the tradeoff in one sentence: more colors buy carrier-to-interference isolation at the cost of per-beam spectrum. The result carries its assumptions and the exact calculation.

Caveats: the RF pattern math is an operational approximation (parabolic beam rolloff, DVB-S2X MODCOD efficiencies), disclosed in the answer; demand-coupled loading, when reported, comes from the synthetic population-weighted surface.

14. Beam hopping under peak demand​

"How should beam hopping be scheduled to maximize throughput during peak demand while minimizing service interruptions?"

What the agent runs

  1. plan_beam_hopping on the anchor satellite, defaults stated: 32 beams, simultaneous_beams of beam count over 4, 16 slots per frame. The scheduler apportions illumination slots by largest remainder, proportional to per-beam offered demand, and spreads occurrences to minimize revisit gaps.

What comes back

Per-beam dwell fraction and served Gbps, total served versus offered, the maximum revisit gap (the service-interruption metric), and starved beams reported plainly, never hidden. The two goals in the question are exactly the two reported axes, so the tradeoff is visible instead of averaged away.

Caveats: offered demand is the synthetic population-weighted model, always disclosed; the schedule is a deterministic plan over the current footprint, not a payload command.

Where to go next​