A tool that reads a drone mission's flight path and profile, estimates connectivity risk along the route, and recommends the right 5G configuration: network slicing, URLLC vs. eMBB framing, handoff risk, plus a rough business case, in the language a telecom partnerships PM would need to make the call, before the drone takes off.
Drone operators in inspection, public safety, and live-event work all depend on "always on" connectivity, but the actual decision, does this specific mission need a premium, carrier-negotiated network slice, or is best-effort public 5G good enough, is a judgment call that mixes real radio-network mechanics with a real dollar figure. Most people either know the telecom half or the business half. This project is an attempt to make an AI agent reason across both, and then to test whether its reasoning actually holds up rather than just sounding plausible.
A mission's flight path is scored against cell tower density and distance data (OpenCelliD in production, a seeded synthetic generator for this offline showcase) to flag low-coverage and handoff-risk segments. Pure, deterministic code, no model involved.
Claude reasons over the mission profile and coverage data to recommend a use-case framing (eMBB vs. URLLC), whether dynamic slicing is worth the cost, and where handoff risk concentrates along the route.
A second, separately-scoped call turns the recommendation into a rough data-usage and cost estimate plus a concrete risk mitigation. Kept separate from pass 1 since a cost estimate and a network-engineering judgment are different jobs.
Everything renders as a one-page report a partnerships PM could actually bring into a carrier negotiation or an internal budget conversation, the same shape as the demo below.
These are precomputed outputs from the actual pipeline (illustrative coverage data for this offline demo), not live API calls, so this loads instantly and costs nothing to browse.
An LLM will produce a fluent, confident-sounding recommendation for almost any input, including bad input. Two layers exist specifically to catch that.
25 pytest cases with no LLM and no network call: coverage-scoring math against known boundary cases, handoff-risk logic, and schema validation that rejects bad input (out-of-range coordinates, duplicate waypoints, non-positive duration) before it ever reaches the model.
The reasoning step can't be unit tested the normal way, so each golden mission carries a known-good expectation, including a deliberate negative case: a routine inspection mission should not trigger a slicing recommendation. A second Claude call grades the written rationale against a rubric for whether it's actually grounded in the facts, so a correct label alone does not pass.
The 5G use-case profile built for guaranteed, near-instant delivery over raw throughput. This is what a drone's flight-control link needs, because a delayed command creates a genuine safety risk.
The 5G use-case profile built for high throughput, e.g. streaming live video. Bandwidth is the priority; split-second timing matters less.
A carrier partitions its physical network into isolated virtual networks, each with its own guaranteed performance, on shared infrastructure. "Dynamic" means a slice can be requested and resized in near real time rather than fixed in advance.
The network layer deciding which tower and frequency resources serve which device, including handover as a device moves between towers. A drone moves fast in three dimensions, which makes handover risk higher-stakes than for a phone.
The general term for what a network guarantees a given type of traffic: priority, minimum bandwidth, maximum latency. The business case step is really QoS translated into a dollar figure.
Built to demonstrate the specific overlap this kind of role actually needs: enough telecom fluency to reason about slicing and RRM correctly, and enough product judgment to know when the expensive feature is not worth it.