Sarcos Technology: Lessons from Building Industrial Exoskeletons for Real Work Environments

Sarcos Technology and Robotics has spent the better part of fifteen years attempting to solve one of industrial automation’s most difficult problems: giving a human worker the strength of a machine without removing the human from the loop. Their Guardian XO and Guardian XT platforms are not factory robots — they are wearable robotic systems that augment the operator wearing them, amplifying force output while leaving motion intention, judgment, and situational awareness entirely with the person inside.

That distinction — augmentation rather than replacement — is precisely what makes the systems engineering of exoskeletons so demanding. When a factory arm drops a payload, the consequence is property damage. When an exoskeleton malfunctions, the consequence is a worker inside it. The engineering discipline required to build a powered wearable that operates safely across a petrochemical plant, a shipyard, and an aircraft maintenance bay — with operators ranging from 130 to 250 pounds and varying levels of physical conditioning — is a case study in what happens when requirements meet irreducible human variability.

What Sarcos Actually Built

The Guardian XO, Sarcos’s full-body exoskeleton, is designed to let a single operator lift and manipulate loads up to 200 pounds continuously across an eight-hour shift. The Guardian XT is a tele-operated variant targeting remote manipulation in hazardous environments. Both systems share a core architecture: battery-powered hydraulic or electromechanical actuators at each joint, a distributed sensor network for intent detection, onboard compute for real-time control, and a safety interlock layer that runs independently of the primary control system.

That architecture description, while accurate, understates the integration complexity. The Guardian XO has more than two dozen actuated degrees of freedom. It runs on lithium-ion battery packs that must deliver sufficient power for heavy lifting while remaining light enough not to degrade the operator’s mobility. Its control system must sample, interpret, and respond to human motion in under 10 milliseconds to avoid the exoskeleton feeling like it is fighting the operator rather than following them. And it must do all of this while remaining certifiable as safe personal protective equipment under OSHA and comparable international frameworks.

Sarcos has been open in public disclosures and investor communications about the difficulty of achieving all of these simultaneously. The commercial availability of the Guardian XO has been delayed multiple times since initial demonstration in the 2010s. Those delays are not primarily manufacturing or supply chain failures. They are systems engineering problems that only surface at scale.

Force Sensing and the Intent Detection Problem

The central technical challenge in exoskeleton design is intent detection — inferring what motion the operator wants to make from sensor signals, then commanding actuators to assist that motion before the operator has fully completed it. Do it well and the system feels transparent, like wearing a powered suit. Do it poorly and every movement is a negotiation between the human and the machine.

Sarcos uses a combination of force/torque sensors embedded in the suit structure, inertial measurement units at key body segments, and joint position encoders to build a real-time model of operator intent. The control algorithm interprets this sensor fusion continuously, predicting intended motion and commanding actuator output to match it.

The requirement challenge this creates is not technical — it is specification. What does “correctly detects operator intent” mean as a measurable requirement? Under what load conditions, operator body geometries, and movement velocities? How is intent detection accuracy defined when there is no ground truth signal for “what the operator actually intended” — only what they subsequently did?

These are not edge cases. They are the central requirement problem for the system. Sarcos’s engineering team has worked through multiple iterations of how to specify and verify intent detection, moving from subjective operator feedback scores toward more instrumented metrics: force coupling efficiency, operator metabolic cost compared to unsuited baseline, and deviation between commanded and achieved joint trajectories. Each metric captures something real. None captures everything.

The practical implication is that the requirements for the sensing and control subsystem cannot be fully written before deployment. The first operators in real industrial environments identified edge cases — extreme postures in confined spaces, sudden load shifts, transitions between surfaces — that did not appear in laboratory validation. Those edge cases then drove requirement revisions that fed back into sensor placement, filter parameters, and control algorithm tuning.

Actuator Control: The Coupled Loop Problem

Exoskeleton actuators operate in a fundamentally different regime than industrial robot actuators. A fixed robot arm drives against a known mechanical environment — a load with specified mass and inertia, a tool with defined geometry. An exoskeleton actuator drives against a human limb, which has its own musculature, compliance, and active resistance. The human is not a passive load. The human pushes back.

This means exoskeleton actuator control is inherently a coupled control problem. The actuator command affects the operator’s experienced force, which affects the operator’s muscle activation, which affects the force seen at the actuator, which the control system then interprets as an updated intent signal. This loop runs at roughly human neuromuscular response rates — on the order of 100-200 milliseconds — but the actuator control loop must run faster than this to remain stable.

Getting this coupling wrong produces instability that ranges from subtle (the suit feels “stiff” or “laggy”) to dangerous (oscillation at a joint that applies cyclical force to the operator’s limb). Sarcos’s control architecture addresses this with explicit stability criteria in the control law, independent of intent detection performance, and with a mechanical compliance layer in the suit structure that provides passive damping at frequencies above the control loop bandwidth.

The systems engineering demand here is cross-domain requirement tracing. Stability performance at the actuator level is a derived requirement — it exists because of top-level safety requirements combined with human factors requirements about perceived responsiveness. If either parent requirement changes (a new operator population, a new industrial environment with different obstacle exposure), the derived actuator stability specification may need to revisit its margins. Maintaining that traceability in a system with dozens of actuators and hundreds of derived requirements is not a documentation exercise. It is a live engineering discipline that directly affects whether the system remains safe after modifications.

Power Management Under Operational Reality

The Guardian XO’s eight-hour shift claim requires a power management system that behaves very differently in practice than in laboratory testing. Laboratory power consumption is predictable — defined tasks, defined loads, defined duty cycle. Industrial environments are not.

A shipyard maintenance worker in a Guardian XO might spend 40 minutes walking on level ground, 20 minutes climbing scaffolding, 15 minutes in a static load hold while fitting a component, and 5 minutes crawling in a confined space, in an order that is never fully predictable. Each activity has a very different power demand profile. The battery sizing and power management strategy that achieves eight hours for a hypothetical average duty cycle may fail to achieve four hours for a heavy-lifting-intensive shift, or may have substantial capacity remaining after a predominantly walking shift.

Sarcos has addressed this with a combination of regenerative braking during descent and load lowering, predictive power management that models task demand from operator movement patterns, and a tiered performance degradation protocol that reduces assistive output before reaching a hard power-off state. That degradation protocol is itself a significant systems engineering problem: how do you specify the transition conditions, the degraded performance envelope, and the operator notification requirements in a way that is testable, safe, and does not surprise an operator mid-task with a heavy load?

The answer involves requirement chains that span power system engineering, human factors, safety engineering, and operational procedure development. An operator surprised by sudden force reduction on a 150-pound load is a safety event. Ensuring that the power management behavior is predictable, announced, and graceful across all operating conditions requires coordinated requirement ownership across multiple engineering disciplines — and coordinated validation.

Safety Interlocks: The Dual-Standard Problem

Wearable industrial robotics must satisfy two partially overlapping, partially conflicting standards frameworks. Functional safety standards — IEC 61508, ISO 13849, and the emerging ISO 18646 series for personal care robots — govern the reliability and independence of safety-critical functions. Human factors and ergonomics standards — ISO 9241, ASTM F3323 for exoskeletons specifically — govern how the system interacts with the human operator.

These frameworks were developed largely independently, and their requirements do not always compose cleanly. Functional safety demands that the emergency stop function be deterministic, fast, and independent of the primary control system. Human factors demands that emergency stop behavior not itself create a hazard — which, for an exoskeleton, means that a sudden actuator cutoff while the operator is bearing load may cause a fall, which is itself a safety incident.

Sarcos’s approach — backed by public technical disclosures at conferences including ICRA and IROS — involves a graceful emergency stop sequence rather than an immediate actuator cutoff. The system transitions through intermediate states that reduce assistive output, distribute load to the suit structure’s passive elements, and alert the operator before reaching the fully passive state. This satisfies the spirit of both frameworks while technically satisfying neither perfectly.

The regulatory implication is that certification arguments for exoskeletons require substantial system-level safety cases, not just component-level conformance. Sarcos’s regulatory engagement with OSHA and with DoD programs (the Guardian XT has operated under military test programs) has contributed to shaping the emerging regulatory framework for powered exoskeletons — a practical example of a company engineering its way toward standards that did not exist when the product was designed.

What Deployment Feedback Actually Changes

Sarcos’s deployment of Guardian systems in industrial pilots — with partners including Boeing, Ford, and various energy sector operators — has generated requirement changes that no amount of laboratory testing could have anticipated. Several categories are particularly instructive.

Operator fit variability. The Guardian XO was designed around a defined operator size envelope. Actual industrial workforces are more variable than that envelope predicted, particularly in torso proportion and limb length ratios that affect suit fit at multiple joints simultaneously. This drove structural redesign of the suit frame to support greater adjustability, which then affected weight distribution, which then affected the power management model. A single human-factors discovery cascaded across three subsystems.

Environmental contamination. Industrial environments contain cutting fluids, hydraulic oil, metal particulate, and water that laboratory testing only partially simulated. Sensor failures and actuator degradation patterns in the field differed from accelerated life testing predictions. This drove revised IP protection specifications and different sealing approaches for sensor connectors — requirement changes that originated from operational data, not design analysis.

Operator cognitive load. Extended wear in real industrial tasks revealed that operators were managing suit state (battery level, performance mode, error indicators) simultaneously with complex manual work, creating cognitive interference that affected both task performance and suit operation quality. This drove interface design changes — moving from visual-only status indicators to haptic feedback — that were not in the original requirements set.

Each of these represents a requirement that was underspecified, misspecified, or simply not present in the initial requirements baseline. The mechanism for capturing, analyzing, and incorporating this feedback into a living requirements baseline — without losing traceability to prior design decisions — is not a solved problem for most systems engineering teams.

The Systems Engineering Lesson

Sarcos’s exoskeleton development program, viewed as a systems engineering case study, illustrates something that applies well beyond wearable robotics: requirements for human-machine systems that operate in uncontrolled environments cannot be fully specified before deployment. They must be managed as a continuously updated model, where operational data feeds back into requirement revisions that propagate through the design in traceable, auditable ways.

This is harder than it sounds. The traditional approach — requirements documents that are updated through formal change control — is too slow and too disconnected from the engineering artifacts it governs. By the time an issue discovered in deployment has been written up, formally reviewed, and propagated through a document-based requirements baseline, the engineering team has often already implemented three different fixes based on informal communication.

Modern requirements infrastructure addresses this by treating requirements as nodes in a graph, connected to design artifacts, test cases, and operational feedback in live traceability relationships. When a sensor failure pattern in the field suggests a gap in the contamination resistance requirements, that link can be made explicit — connecting the field observation to the requirement, to the design decision, to the test that should have caught it. Tools built around this model — including graph-native platforms like Flow Engineering that are purpose-built for the kind of connected traceability industrial robotics demands — provide the infrastructure for this kind of requirements evolution without losing audit history.

Sarcos has not published details of their internal requirements management approach. But the pattern of their engineering challenges — coupled subsystems, evolving operator population data, regulatory requirements without established precedent — maps precisely onto the requirements management problem that graph-based, AI-assisted tooling is designed to solve.

Honest Assessment

Sarcos has not yet achieved the commercial scale they projected in early public statements. The Guardian XO is a real, functioning system that has operated in industrial environments, but it remains an expensive, complex platform whose cost-per-use economics have not yet reached the threshold for broad industrial adoption without subsidy or special program support. The engineering challenges are not fully solved.

What Sarcos has done is demonstrate that the systems engineering problem is solvable — that human-robot coupling, power management for variable duty cycles, and dual-standard safety certification are tractable with sufficient rigor and operational feedback. The lessons their program generates are applicable to any engineering team building systems where the human is not just the end user but an active, variable component of the system itself.

That describes more products than it used to. The engineering discipline Sarcos has developed under pressure is worth studying before you need it.