The Edge Autonomy Gap

Intelligence is leaving the safety of the data center — the conditioned air, the redundant power, the predictable order of the racks — and heading for the frontier: a robotic arm on a factory floor, a turbine spinning offshore, a shelf that counts its own inventory, a sensor strung along miles of pipeline.

Places where data is born and the physical world is within reach. The promise is faster decisions and operations that respond in the moment. The catch: out there, failure isn’t a graph on a dashboard — it’s a machine, a vehicle, or a place where the consequences are physical.

We surveyed 500 engineering, IT, operations, networking, and DevOps professionals directly involved in edge initiatives to understand whether the systems underneath that ambition are ready for it.

The answer is a widening mismatch. 86% say decision-making intelligence will continue to move closer to the edge. But only 20% report closed-loop remediation today, and just 13% of teams that experience connectivity challenges say their systems recover automatically when a connection is lost.¹

That mismatch is the edge autonomy gap: the edge is getting a brain before it has reflexes. Every decision that brain makes needs infrastructure that can execute it, verify it, and undo it when it’s wrong — often with no human nearby and no connection to fall back on. Today, that work still routes through people: a page, a truck roll, someone SSH-ing into a gateway at 2 a.m.

Adding edge AI will increase operational load before it reduces it.

The findings follow a clear progression:

• Today: edge deployments are fragmented, manual, and hard to secure.
• Tomorrow: intelligence and bidirectional control become table stakes.
• The gap: all brain, no reflexes — the edge sees almost everything and fixes almost nothing on its own.

This creates a distributed-systems problem more than a model problem — reflexes come from the infrastructure, not the model. The intelligence may be new. The hard questions are familiar: how do commands reach the right place, how does state remain consistent, what happens when a link disappears, and how can a system recover without losing control or evidence?

Edge computing is production infrastructure at most surveyed companies. But the operating layer beneath it is still a sprawl of extended cloud tools, partial standards, custom scripts, and disconnected products.

The sprawl is the norm

Only 15% of respondents say their company runs the edge on a unified management platform. The rest operate on adaptations — cloud-native tooling stretched to cover the edge, partial standardization, or homegrown systems stitched together over time.

Fragmentation is more than an architecture-diagram problem: it leaves teams without a dependable account of what is actually running. Tooling choice shows up directly here — teams on homegrown tooling are 2.2x more likely to lack a unified view than teams on a unified platform.

At the edge, those blind spots are distributed across locations, hardware generations, network conditions, and owners. A partial update or inconsistent configuration can look healthy from inside each individual system while the overall operation drifts.

The glue-code tax

Fragmentation has become the workload itself: 62% of teams spend more time maintaining glue code and integrations than supporting new products or capabilities. Tooling sets the ceiling here too — on homegrown and patchwork systems, three teams in four say so; on unified platforms, fewer than half.

The cost is also human. 61% say dealing with stitched-together tools demotivates them at work — a view held more widely on the front line (71% of senior individual contributors and first-line managers) than in the executive suite (56%). The people closest to the systems feel the drag most acutely.

This perception gap appears elsewhere, and the survey lets us measure it. Asked how adaptable their edge setup is when requirements change, 39% of executives chose “very adaptable.” Every group below the executive level landed between 13% and 17%. A platform can look flexible in a roadmap and still be brittle during an incident.

“My team had to manually SSH into unresponsive devices or walk local site staff through hard reboots over the phone. A simple software fix turned into a massive time sink.”

— Manufacturing, 1,000–4,999 employees

The quote captures the compounding effect of fragmented control: a software problem becomes a fleet problem, then a staffing problem, then a continuity problem.

Security leads everything

Security, risk, and compliance are the leading reasons organizations standardize or unify edge tooling, cited by 52% of respondents. Security is also the number-one device-lifecycle headache (40%), narrowly ahead of OTA updates and patch management. And when respondents ranked seven factors that influenced their edge platform decisions, cost came in last place in the aggregated results. 1 in 4 respondents ranked it dead last.

An edge platform, in other words, is a risk and operational-control purchase, not a cost-reduction one.

When teams scale up their fleets, security and compliance is the single biggest limitation they run into — ahead of drift, operational workload, and coordination.

For all the focus on security, the most basic control at the edge — how each device proves “who” it is — is still provisioned by hand, or missing, in more than a third of fleets:

Rotation is the other weak spot. Only 11% of teams can complete a fleet-wide credential rotation in minutes — for most respondents it takes days or longer. In a distributed deployment, that delay can strand devices between old and new trust states.

“A device went offline for maintenance and missed its rotation window. When it powered back on, its ID had expired and it couldn’t connect to the network to get a new one. It essentially locked itself out — which took down our entire local site.”

— Transportation and logistics, 250–499 employees

The security challenge, then, is less whether every device has a credential than whether identity, policy, and access can change safely across intermittent connections and mixed hardware generations without taking the application down.

The verdict on today’s edge

The accumulated strain shows up in a blunt result: two teams in three — 68% — would overhaul their current edge setup if they had the chance. The gap between “completely prepared” and “can’t keep up” is stark:

The asks are consistent: visibility, integration, resilience, control, security, and less manual work. Teams aren’t asking for one more tool — they’re asking for a system that can see every device, act on what it sees, and keep working when the connection drops.

The edge is becoming a place where decisions happen, not only a place where data is collected — and communication becomes a continuous control loop rather than a one-way telemetry path.

The edge becomes a place where decisions happen

The direction is not in dispute: 86% of practitioners agree that decision-making intelligence — more compute and more inference — will continue to move closer to where physical-world data is generated.

The consequential choice is the distributed system around the model, not which model runs at the edge. Models will be swapped and upgraded; the system that feeds them context, coordinates their work, reports their state, and preserves control when central infrastructure is unavailable is what determines whether their decisions can be trusted.

Teams are already acting on this shift: demand for AI capabilities is the second-most common reason organizations standardize their edge tooling (45%). The pull looks even stronger in hindsight — among executives whose organizations have already standardized, 57% say AI demand helped drive the move.

But adding intelligence to a fragmented deployment does not make that deployment autonomous. It increases the number and importance of decisions that the underlying system must distribute and govern.

And governance has not moved with the workloads. Asked who most influences edge decisions, respondents name central IT and the people who set cloud standards over the operations and field teams maintaining the devices — by more than four to one. It is the OT/IT divide restated for the edge: the equipment lives in operations, but the authority lives in IT. Intelligence is arriving at the edge faster than decision rights are.

Bidirectional becomes the baseline

Practitioners expect two-way communication to become the default: 84% agree bidirectional communication will be a baseline requirement for edge systems within five years. Agreement runs highest where the physical stakes are highest — 90% in energy, utilities, and transportation.

Telemetry is only the northbound half of the problem. Autonomous operations require a return path for commands, policy, configuration, coordination, and correction — with acknowledgements and state moving in both directions.

That return path must work across unreliable networks, constrained locations, multiple clouds, and devices that may be disconnected for long periods. It must preserve local continuity when a central service cannot be reached. And it must reconnect without creating duplicate actions, conflicting state, or silent gaps.

Why teams actually standardize

The survey lets us compare what teams expect will force standardization with what teams that have already standardized say actually prompted it. Teams flagged the headline triggers correctly. Security and AI demand top both the expected and actual lists.

What they misjudged is the ugly operational reality of sprawl, glue code, and patchwork systems.

The burden of running a patchwork system and the need for bidirectional communication are each named as triggers about half again as often in reality as in expectation. Command and control capabilities, not just telemetry, become a clear need once a team is operating at depth.

What teams overestimate are the dramatic triggers. 40% expect cost pressure to drive the decision; among teams that actually standardized, only 28% say it did — consistent with cost ranking last among selection factors. Outage or incident crises are overestimated nearly two to one: 19% expect a prolonged incident or outage to force the change, while 11% say one actually was a leading reason.

The edge can already produce enormous amounts of signal. The harder test is whether the system can turn that signal into safe action — and remain trustworthy when devices, networks, or clouds fail.

Stuck at observe

The survey asked practitioners for the most advanced edge-management capability their organization has in practice, not on a roadmap.

Nearly half are limited to observing or diagnosing, and another three in ten can anticipate likely problems but do not execute remediation automatically. Only 20% have reached closed-loop remediation, where systems can trigger device-side actions with audit and controls.

Prediction without safe execution is still a human queue. It may improve awareness, but it does not remove the handoff between detecting a problem and resolving it.

“A firmware update conflicted with older hardware sensors, causing silent data corruption. The automated health checks falsely reported it as ‘success.’”

— Manufacturing, 5,000–9,999 employees

This is why observability alone cannot close the gap. A system can report that every component is healthy while their combined behavior is wrong. Autonomy depends on coordinated state and verified outcomes, not more dashboards.

Resilience is the dividing line

Physical-world systems cannot assume perfect connectivity, and the data shows they do not get it: a third of respondents describe connectivity as frequently or extremely challenging. Connectivity and network instability lead the list of common causes, but the more useful finding is how flat the list is. Security events, failed updates, manual error, and hardware failure all land within a few points. No single failure mode dominates. The surface is broad, which is why point solutions aimed at any one of them do not close the gap.

When a connection drops, only one team in four says no data is lost. The rest lose something — usually non-critical telemetry or logs, but 28% report losing important operational or critical transactional data.

This is the line between an edge that merely extends centralized infrastructure and one that can sustain an operation. Resilience is the prerequisite for continuity, not a nice-to-have on the way to autonomy: it is what keeps useful work moving, preserves data, and regains a consistent state when the network returns.

The dependence on central infrastructure is still poorly understood. 41% are not confident they know what happens to their edge devices during a cloud outage — and tooling moves that number dramatically. Teams extending cloud-native tools to the edge, the largest cohort, are three times more likely to be unsure than teams on a unified platform.

“We had a major AWS outage. It was hard to resolve because it disconnected all of our devices, and we had to go one by one and manually reconnect and secure them.”

— Energy and utilities, 1,000–4,999 employees

An architecture designed for autonomy must treat disconnection as an expected operating condition, not an exceptional one.

Recovery still means a human

Among respondents who experience connectivity challenges, just 13% say their systems recover automatically. For everyone else, recovery still runs through a person: most systems usually come back but sometimes need manual intervention, and about one in six teams finds recovery difficult or sees disruption frequently cause an incident.

Configuration drift tells the same story. Three teams in five still manage it imperatively — engineers investigate and issue commands, or run scripts and playbooks — and another quarter have systems that detect drift and suggest an action, but the action still waits for a person. Only 12% define desired state and let the system reconcile devices automatically.

The consequences move beyond software operations:

“A large-scale data outage in a wind farm system was caused by an edge-gateway firmware failure. It could only be solved by a manual restart, but the engineers were located far from the wind farm.”

— Energy and utilities, 500–999 employees

“Interruptions to medical equipment directly impact clinical decision-making. This incident consumed all of our night-shift staff.”

— Healthcare and life sciences, 250–499 employees

And not every failure announces itself. Sometimes nothing breaks at all; the fleet is just quietly wrong:

“We ran into inconsistent solar data because different edge devices were running different firmware versions. Everything looked fine overall, and checking remote sites wasn’t very easy.”

— Energy and utilities, 1,000–4,999 employees

Across these environments, recovery is slow because the system cannot reliably answer three questions on its own: what state should each device be in, what state is it actually in, and what action will safely close the difference?

Autonomy is not a switch that flips. It is a ladder climbed one operating state at a time — and the survey shows where the 500 stand on it.

Four tiers, five dimensions

The tiers below describe operating states, not aspirations. Each cell is what a normal week looks like at that stage — recognizable from the work itself, not from a roadmap. Find the row that sounds like your fleet.

The five dimensions are the same five the survey measured, and the same five the interactive benchmark scores. A team rarely sits in one column across all five rows — most fleets are a tier ahead on one dimension and a tier behind on another.

Where the 500 sit

Scoring all 500 respondents against this model puts most of the industry in the middle of the ladder. The two middle tiers hold 70% of respondents: teams that can diagnose or even predict, but whose corrective work still runs through people.

Where to start

The dimension medians answer the natural next question. Across the 500, identity and resilience are the strongest foundations, while acting on problems and correcting drift score lowest — the reflexes, again, are what’s missing.

For most teams the next rung is not a moonshot. Moving one tier on the weakest dimension — from running playbooks by hand to letting the system suggest the fix, or from suggestion to governed execution — is a bounded engineering project, not a re-platforming.

When edge operations strain, the default answer is more sprawl — one more tool stitched in beside the rest. The autonomy gap closes when distributed infrastructure gains the properties required for safe action, not when another isolated layer is added to the stack.

What the mature minority does differently

The survey does not establish causation, but the associations are consistent. Teams using unified platforms report stronger operational outcomes than teams using homegrown or patchwork approaches.

These results do not mean a unified product automatically produces autonomy. More mature teams may also differ in architecture, staffing, investment, and operating practice. And the rows differ in strength: the two capability gaps clear the margin of error comfortably, while the operational-workload gap is directional rather than conclusive at these subgroup sizes. But the pattern challenges the assumption that maturity comes from adding more specialized tools. The mature minority is more likely to operate through a common system that can see, coordinate, and correct the deployment as a whole.

“A timing mismatch between edge controllers caused robots to be slightly out of sync. Nothing broke, but more defects started appearing. It was hard to spot because each system seemed fine on its own, and the problem only showed up when we compared their results.”

— Manufacturing, 1,000–4,999 employees

The pattern is not unique to manufacturing:

“There was a connection problem between edge systems and tracking platforms, causing shipment delays. It was hard to fix because both systems looked fine individually.”

— Transportation and logistics, 5,000–9,999 employees

These incidents reveal the core design problem. Distributed components can each appear healthy while the operation they form together is failing. The answer is infrastructure that can coordinate the system as a system, not just more local intelligence.

Five requirements emerge from the survey:

These five requirements are the five dimensions the interactive benchmark scores — the same model behind the autonomy ladder in section 04. A weak answer on any dimension points to the requirement that closes it.

Together, these requirements describe an operating foundation for autonomy. They allow teams to move from seeing a problem, to understanding it, to acting safely, to recovering when the world does not behave as expected.

The organizations that close this gap won’t get there by deploying more AI at the edge; they will get there by building distributed systems capable of carrying its decisions.

Benchmark your edge operations against the 500 practitioners in this study — and identify the systems capability most likely to limit your next stage of autonomy.

NATS is one secure, low-latency communication fabric across devices, sites, clouds, and vendors. Data moves in real time from sensor to cloud, applications can move and change without re-architecture, and security and operations stay consistent across every environment — without lock-in. Synadia is the company founded by the creators of NATS, providing the platform, expertise, and operational tooling teams use to run it in production.

Teams building this way today include Verrus, MachineMetrics, Eviny, PowerFlex, Calix, and Rivian.

The survey was designed to describe current edge operating practices, expectations, and outcomes. It does not measure AI readiness directly, and associations between tooling approaches and outcomes should not be interpreted as proof of causation.

Kelsey White / Rep Data conducted the research for Synadia from March 13–28, 2026. The study surveyed 500 engineering, IT, operations, networking, and DevOps professionals directly involved in edge initiatives across the United States, Canada, and Europe. Seventy percent of respondents were based in the United States.

The sample included organizations with at least 250 employees:

• 39% had 1,000–4,999 employees; 22% had 500–999; 15% had 5,000–9,999; 12% had 10,000 or more; and 12% had 250–499.
• 65% were department leadership or executives; 25% were team leads or first-line managers; and 10% were senior individual contributors.
• 72% were involved in strategic or budget decisions related to edge initiatives.
• The sample skewed toward IT operations and administration roles (71%) and technology/software companies (40%). Manufacturing represented 15% of respondents; other industries included healthcare, media, financial services, energy, transportation, retail, telecommunications, public sector, education, and agriculture.

Unless otherwise stated, percentages use the total respondent base of n=500. The automatic-recovery result uses the n=354 respondents who reported connectivity challenges. Percentages may not total 100 because of rounding or multi-select questions.

Respondent quotes were lightly edited for spelling and punctuation only. Meaning was not altered. Quotes are attributed only by industry and firm-size band to protect respondent anonymity.