One Operator, Many Drones: Inside Skydio's Autonomy Stack — Suchet Bargoti, Skydio

Suchet Bargoti of Skydio begins by flying. From a laptop, he launches a docked drone in San Mateo and uses his keyboard to look around. The important change comes when he switches away from that aircraft: he starts a second drone in Colorado while the first remains airborne. The Colorado dock opens and runs its prelaunch safety checks. One interface now coordinates work in two distant places.

The imagined Colorado task is an inspection after an incident on power lines. The actual engineering requirement is broader: neither aircraft can depend on the operator continuously attending to it. Everything runs over conference Wi-Fi, and Bargoti says safe operation must continue even if he closes the laptop. That requirement moves responsibility into the vehicle and the services behind the interface.

Back at the first drone, Bargoti selects a passing car to track and takes his hands off the controls. The autonomous system takes over following the vehicle, leaving him free to start a third drone at headquarters. This is the opening example of the stack's division of labor: a person chooses a task, the aircraft executes the ongoing movement, and the fleet interface allows attention to move elsewhere.

The dock changes how a drone becomes available. Bargoti describes a progression from hobby aircraft roughly 15 years earlier, to industrial tools roughly 10 years earlier, to installed infrastructure. A tool travels with someone in a truck; an installed drone can launch where the work is needed. He reports thousands of docked systems deployed with utilities, public safety organizations, and construction companies.

The interface could eventually become a high-level request from a Slack bot: an incident happens, and a drone responds without someone managing every flight action. That is a future direction, distinct from the certified pilot operating this demonstration. For now, Bargoti tells the fleet to pause and return to dock, then begins the presentation while the aircraft handle the return.

Two customer examples explain why availability matters:

• Utility patrols: A system installed near a power station on the northeastern US coast found a pole burning from the inside during a normal patrol. The concern was that it could fall and create a fire risk. A nearby drone makes inspection possible without first sending people to the site.
• Following a stolen car: In the SFPD example, a drone maintains observation while a person changes the vehicle's license plate and later prepares to tint its windows. Continued aerial observation gives police time to position themselves for an intervention. Bargoti presents this as a safer alternative to a high-speed chase; the example does not establish a measured reduction in pursuit risk.

Installed infrastructure also has to work across weather and geography. Bargoti names docks in Alaska's cold and Texas's extreme heat, and reports about 16 million people living within a two-mile radius of this infrastructure. He states a reliability requirement of 99.9999%, supported by simulation and testing work. The recording does not define the event or denominator for that percentage, so it should be read as a stated engineering requirement rather than a demonstrated fleet-wide success rate.

A skilled pilot assigned to each drone creates a staffing problem as calls and alerts increase. Fleet control aims to let an operator specify an objective without continuously worrying about flight. Yet the opening demonstration still required Bargoti to choose and launch each aircraft individually. Even for an experienced operator, that introduces cognitive load. The longer-term ambition is to issue objectives such as searching an area for a missing person or finding a particular type of car.

Before moving deeper into the architecture, Bargoti checks the fleet: all the drones have landed. He is still pleased when that works, even though it is supposed to happen every time. The moment connects the ambition to its prerequisite. Delegating more tasks only helps if launch, flight, tracking, and recovery remain dependable while attention moves away.

Skydio controls the hardware, software, cloud services, user interface, and autonomy together. That allows decisions about perception and flight behavior to account for altitude, speed, cloud, rain, unreliable urban GPS, and objects hidden by buildings. These conditions affect one another: a tracking task still needs navigation, and navigation still needs a usable understanding of the environment.

Flights also produce the evidence for improving those systems. Logs capture the difference between an instruction and what the drone did, or between an expected outcome and what happened. Those discrepancies feed retraining and evaluation, including reinforcement learning, before updated systems return to the field. Bargoti puts data handling inside this learning cycle: private information needs to be removed, and customers need to understand what they share.

Autonomy runs in two places. Immediate autonomous actions happen on the drone. Video and telemetry also pass through cloud servers, where GPUs and inference engines can support heavier computation and longer-term planning. The split lets the system use cloud resources without making every immediate action wait for a remote answer.

That division makes the uplink part of the intelligence system. Cloud reasoning depends on what information reaches the server, so Skydio invests in encoding video into smaller sizes and decoding it into clearer images under limited bandwidth. Bargoti describes better video quality under the same network conditions, without specifying a codec or compression method. The causal point is straightforward: more useful visual information gives remote inference a better view of the scene.

The first kind of model is a map. Local perception helps an aircraft respond to nearby obstacles, but a trip from one part of a city to another also needs global planning. Repeatedly discovering buildings along the way is a poor substitute for choosing a route with prior knowledge. Skydio combines prior information, building data, and vector data such as roads and power lines into a map the drone can use for planning and navigation. Those layers can also support different behavior in different areas.

A construction site provides a concrete example of how that model changes. Points representing the system's knowledge are rendered over a video feed, but some do not line up with the current scene: new construction has appeared that the map did not contain. Flying drones observe the changed area. After returning and supplying their data, those observations feed map synchronization. In the next iteration, the fleet can plan with the updated map.

How does one drone's observation become useful to other aircraft? The flow below follows the construction-site example from a stale map to a shared update. The important relationship is the return path: fleet operations consume the map, but also produce observations that improve the map for subsequent operations.

The next model understands and tracks objects. A target moving behind a building requires more than recognizing it in each visible frame. The system needs a representation of the hidden object and an expectation of where it might emerge. That expectation informs the drone's own movement: it can reposition to regain a view on the other side. Tracking therefore joins perception to action.

Learned approaches, including reinforcement learning, can help choose these movements without explicitly engineering every occlusion case. The operational challenge remains vision-based tracking across rain, snow, day, and night. Here too, computation divides between locations:

• On-device tracking: A minimal tracking capability runs on the aircraft.
• Cloud tracking and reasoning: Heavier models, including vision-language models, can consider the broader map and return guidance for larger movement decisions. Bargoti describes one-to-two-second feedback latency as usable for those broad decisions, rather than for the immediate response expected from faster tracking.

Infrastructure inspection adds semantic understanding: the drone must identify what is in the scene before deciding what action fits an instruction such as inspecting a faulty line. Skydio builds primitives and tools for understanding utility poles and acting around them. Those capabilities can be called from conventional code today and made available to an agent that needs to understand what the drone sees and what it can do next.

The agent example begins with a user asking the system to look for a white Jeep. A vision-language model (VLM) accesses a drone API to command a search trajectory. As the aircraft moves, visual inference examines the scene for the requested vehicle. Once it finds a candidate, the agent calls tools that let the drone track and follow it. The visible task changes from searching an area to following an identified target.

What connects a language request to physical following? The flow below separates the agent's choices from the tools that carry them out. Search movement produces new visual context; recognizing the requested vehicle leads to a different tool call. The agent composes existing capabilities rather than requiring a custom rule sequence for this particular request. This is an illustrated capability in the talk; its production deployment scope is not specified.

The longer-term learning ambition is to feed raw sensor data into a system that directly produces the right action: where to point, where to fly, or how to actuate the aircraft. Skydio is testing and training with reinforcement learning toward such behavior. The obstacle is the reliability required of a physical system. When a completely end-to-end system fails, diagnosing what went wrong and establishing reliability guarantees remain difficult.

That leaves a practical design decision: which parts should become learned behavior, and which parts benefit from an explicit representation of the world? Search and rescue illustrates the pressure to change. A manually written strategy can accumulate branches: inspect trees, look underneath, turn on thermal sensing, then search somewhere else if nothing appears. High-level tools give an agent ways to choose among those actions using the current context, reducing the need to encode every branching strategy in advance.

The closing direction extends beyond the demonstrated quadcopter. Skydio is applying similar thinking to a smaller quadcopter and beginning to explore fixed-wing aircraft within the infrastructure model. Basic interaction APIs would let cloud agents orchestrate these vehicles and make higher-level decisions. The aspiration to launch and recover from anywhere remains a direction of travel; the reusable mechanism is the same one shown in the Jeep example: expose useful vehicle capabilities, then let the cloud compose them into a task.