When we first shipped the Fleet Advisor, it was a Orchestrate-only feature: every 30 seconds, read live fleet telemetry, compute optimal relay parameters, validate through the Safety Gate, apply. It was the AI layer of Overwatch — but only for multi-drone patrol operations. Core missions ran without it.

That was a historical accident, not a design choice. The same decision engine, the same Safety Gate, the same cloud-failover chain (Anthropic → OpenAI → Gemini) — none of it was Orchestrate-specific. It just happened to be wired to Orchestrate's tick loop because that's where we built it first.

Today it runs on Core too. And because it runs on both products across every phase of a mission, the name is bigger than Fleet Advisor was. We call it Overwatch AI.

What changed

The first and most visible place Overwatch AI runs on Core is the Pre-Flight Health Panel. Before launch, the panel shows eight live health checks per drone: battery percentage, cell balance, GPS fix, compass health, failsafe configuration, geofence, telemetry heartbeat age, and Remote ID broadcast status. Each row is green, yellow, red, or marked as needing a manual tick from the paper checklist.

Overwatch AI reads all of those, plus the current wind and the 1-hour forecast gust, and produces a natural-language recommendation:

  • "Green light, proceed — all checks passing."
  • "Proceed with caution — Wind 7.2 m/s, conservative mission envelope."
  • "Hold launch — drone-2: Battery 22% — swap before launch; Forecast gust 11.3 m/s within 1h — abort risk."

The Launch button is disabled while the recommendation is red. Operators can type OVERRIDE to bypass — and that override is audit-logged with the failing check names, operator ID, and timestamp. The gate is designed to be bypassable (there are real situations where operators need to fly despite a yellow or red check), but never bypassable silently.

Why the rebrand matters

The "Fleet Advisor" name tied the capability to Orchestrate. For a prospect evaluating Core, seeing "Fleet Advisor (Orchestrate only)" in the product page made the AI feel like a separate product they'd have to buy into later. In reality, the same pipeline that tunes relay timing mid-mission is the same pipeline that now reviews pre-flight health across both products.

Calling it Overwatch AI — one name across pre-flight, in-flight, and (eventually) post-flight, across Core and Orchestrate, across AirSDK and MAVLink — matches how it actually works under the hood and how customers should think about it.

The architecture is deliberately unchanged

What didn't change when we rewired for Core: the pipeline. Every Overwatch AI decision goes through the same three-stage flow we've written about before.

  1. Local decision engine. Physics-based, offline, instant. Runs on every decision, always. Produces the baseline recommendation from live telemetry + weather + mission config.
  2. Optional cloud refinement. When internet is available and keys are configured: Anthropic Claude first, OpenAI GPT as fallback, Google Gemini as second fallback. First successful response wins. Adds contextual reasoning the local physics engine can't do alone (weather-forecast integration, pattern recognition across missions, natural-language explanations for the operator log).
  3. Safety Gate. Always runs last. Validates every decision against inviolable constraints: critical battery thresholds, wind abort limits, structural speed caps. No parameter that violates a hard safety bound ever reaches the mission.

What extended for the Core use case: the input schema now includes pre-flight health readings, and the output schema includes a status: green | yellow | red plus a natural-language recommendation, in addition to the parameter changes that Orchestrate still uses for relay tuning.

The UI source badge on every decision still tells you where the recommendation came from: LOCAL, CLAUDE, GPT, or GEMINI. The operator always knows which engine made a given call. Air-gapped deployments run exclusively on LOCAL.

Pre-flight is the right place for an operator's first AI interaction

There's a design judgement behind putting Overwatch AI on Core's pre-flight screen specifically, not (yet) on Core's in-flight monitoring. Pre-flight is a low-stakes environment for an AI recommendation. The drone is on the ground. The operator has time to read the reasoning, look at the checks, decide whether to proceed.

If the AI says "recommend delaying 1h — gust forecast 11 m/s in 25 min", the operator can agree, disagree, or override. Nothing bad happens during the disagreement. The operator builds trust (or distrust) with the AI's recommendations before the AI is ever asked to do something in the air.

That's deliberate. The sequence for expanding AI across the product is: pre-flight first (low stakes, low latency), post-flight debrief next (zero stakes, high value for training pipelines), then in-flight advisory (live, but still human-in-the-loop), then in-flight automation (cautiously, only after operators and procurement reviewers have watched the advisor enough to trust it). We're currently at step one on Core; step three has been shipping on Orchestrate for months.

What it means for operators

If you run Core missions, you now see the Pre-Flight Health Panel above every Launch button. Eight checks, an aggregated status, a weather strip, and an AI recommendation. Green means go. Yellow means proceed with explicit awareness of the caveats. Red means stop, fix, or explicitly override with a documented reason.

If you run Orchestrate patrols, the runtime Fleet Advisor you've been using is still there, tuning swap thresholds and transit speeds every 30 seconds. Now it's also reviewing your pre-flight checks before the first drone takes off.

If you run air-gapped, Overwatch AI runs on the local physics engine only — no external calls, same recommendation logic, same Safety Gate, same audit trail. The AIR-GAPPED badge in the top bar tells the operator they're in offline mode; decisions are sourced LOCAL.

If you're evaluating Overwatch, the AI layer is on by default in the demo. Try both products — Core's pre-flight panel in single-drone planning, Orchestrate's runtime advisor during the simulated 24-hour patrol — and you see the same engine across both.

What's next

Core in-flight advisory and post-flight debrief are the two big expansion points — both tracked in the public backlog. In-flight advisory on Core will likely land first on the MAVLink track, where we have live telemetry to feed it. Post-flight debrief is a natural Phase B item — take the mission replay data (also on the roadmap), run it through the advisor, and produce a natural-language after-action review.

One pipeline, one Safety Gate, one audit trail — running everywhere.