Controlling an edge robotics fleet from one place

A robotics company runs fleets of edge devices (autonomous floor vehicles, inspection robots, and their charging infrastructure) across customer sites. Each site is behind its own network, often air-gapped from the internet in practice if not in design. The team maintained them the way teams did a decade ago: SSH jump boxes, VPNs, and a lot of travel.

The problem: a fleet with no single operating surface

The robots were individually observable through vendor dashboards and local tooling, but there was no one place to see the whole fleet, and no governed way to push a change. When a firmware update or configuration change shipped, it was a manual, site-by-site operation with a spreadsheet as the coordination artifact.

Worse, the estate was split-brain. Cloud-side analytics ran in one vendor console, device health in another, and the edge configuration lived on the machines themselves. 'What changed, where, and is it still true?' was nearly impossible to answer.

The fleet wasn't hard to operate because it was big. It was hard to operate because nobody could see it.

The approach: outbound-only agents, hosted control plane

The pattern that worked: each site runs an on-prem agent pool that dials out to the hosted control plane. No inbound ports, no VPN, no firewall exceptions at customer sites. The agents report inventory, topology, and signals; the control plane holds the graph and the policy.

site A robots/chargers ──▶ on-prem agent (outbound)site B robots/chargers ──▶ on-prem agent (outbound)site C robots/chargers ──▶ on-prem agent (outbound)                │ outbound TLS, no inbound ports          hosted control plane (inventory, policy)                │   approvals → deploy waves → fleet-wide audit

Implementation steps

• Deployed outbound-only agents to three pilot sites; confirmed no inbound firewall changes were required.
• Enrolled the robots into the inventory with ownership, region, and operational state.
• Modeled dependencies (vehicle to charger to network) in the topology graph.
• Defined a policy that flags devices running out-of-band firmware.
• Pushed configuration through deployment waves so the fleet updates in reviewable batches.

Guardrails: humans approve, the platform applies

The assistant was used for investigation across the fleet: given an alert, it read the graph and proposed which sites were affected and what a safe next step might be. Applying that next step, especially firmware or configuration on physical robots, stayed a human-approved, policy-checked operation recorded in the audit trail.

Lessons learned

The outbound-only agent is the single most important decision. Customer sites rarely approve inbound connectivity, and the moment you need an exception, the deployment becomes political. Dialing out removes the conversation entirely.

Second, the fleet view is the product. Individual device dashboards exist; a governed fleet view does not. The topology graph, which device connects to which charger in which network, was what made change impact reviewable.

Third, wave-based rollout beats site-by-site heroics. Batching the fleet into waves with policy and approval built in made updates boring in the good way: repeatable, reviewable, and safe.