Digit 5 Safety Architecture: Reference Design for 2026

On September 15, 2026, Agility Robotics unveiled Digit 5, the fifth generation of its warehouse-and-manufacturing humanoid, and buried inside the launch announcement was a claim more consequential than any spec on the sheet: an earlier Digit had already passed an independent field evaluation against industrial safety standards administered by OSHA, on a live customer production line, before any humanoid-specific international safety standard existed to evaluate it against. That inversion is the real story here. The Digit 5 safety architecture — an independent safety controller running alongside, not inside, the main compute stack — is Agility’s answer to a regulatory gap that will not close before Digit 5 ships to customers. This piece treats that architecture as a reference design any plant engineer can evaluate on its own merits, and treats the still-drafting ISO 25785-1 and ANSI/A3 TR R15.108 as the risk variable procurement teams need to price into a purchase order today, not in 2027 when a standard might finally exist.

What this covers: the independent-safety-controller pattern as a generalizable reference architecture, why payload and runtime numbers are secondary to the safety gate in humanoid deployment decisions, where the emerging standards landscape actually stands versus how vendors describe it, and a practical checklist for vetting any humanoid vendor’s safety claims in the absence of a finished standard.

Context and Background

Humanoid robotics spent 2023 through 2025 arguing about dexterity: how many degrees of freedom a hand needs, whether a bipedal gait beats a wheeled base, how much a foundation model can generalize across tasks it never saw in training. Compute platforms like NVIDIA’s Jetson Thor architecture made real-time perception and motion planning cheap enough to put on a mobile power budget, which quietly resolved most of the capability argument. By 2026 the constraining factor on humanoid deployment was no longer “can it do the task” — it was “can it work three feet from a person on a night shift without a lawyer, an insurer, or OSHA shutting the line down.”

Agility Robotics is the company best positioned to answer that question with field data rather than marketing copy. Digit, the company’s warehouse humanoid, has logged more than 65,000 cumulative operational hours across customer sites as of the Digit 5 launch. At one GXO logistics site, Digit crossed a 100,000-tote handling milestone at roughly 98% accuracy — a duty-cycle track record that matters more to a plant safety committee than any demo video. Digit 5’s named customers include GXO, Schaeffler, Amazon, and Toyota Motor Manufacturing Canada, all companies whose safety departments do not sign off on robots casually, and all companies that operate under existing OSHA general-duty-clause obligations regardless of whether a humanoid-specific standard exists yet.

That last point is easy to lose in the standards debate, and it is exactly why the Digit 5 safety architecture matters as a case study: the absence of ISO 25785-1 does not mean humanoid deployments today operate in a regulatory vacuum. OSHA’s general duty clause already requires employers to maintain a workplace free of recognized hazards, and existing frameworks for industrial mobile robots and collaborative fixed robots — including the now-finalized ISO 10218-1:2025 for conventional industrial robot arms, discussed only as background contrast here since it does not cover legged humanoids — already shape how a safety committee reasons about a new class of machine on the floor. Digit 5’s field-evaluation claim matters precisely because it demonstrates a path to satisfying that existing obligation before a purpose-built humanoid standard exists, not because it operates outside regulation entirely.

The official framing, from Agility Robotics’ September 15, 2026 announcement, centers safety rather than raw capability: “Agility Unveils Digit 5 Humanoid Robot Built for Cooperatively Safe Work at Scale.” NVIDIA’s VP of Robotics and Edge AI, Deepu Talla, put the strategic logic plainly in the same release: “Safely operating around people and assets is what moves humanoid robots from pilots to industrial deployments at scale.” That sentence is the thesis of this article. Digit 5’s headline specs — a 40% payload increase, a 90-minute runtime, a 9-minute recharge — are real engineering advances, but they are not what is gating adoption. The safety architecture is the gate, and it is worth understanding in the same detail an engineer would apply to a control system, because it is effectively functioning as one before any external standard forces the issue.

Digit 5’s other headline numbers round out the picture without changing the argument. The platform stands 5’11” (1.81 m), weighs 284 lb (129 kg), and reaches up to 7.2 ft (2.2 m) — dimensions close enough to an adult worker’s envelope that proximity detection has to distinguish “person” from “another Digit” reliably, not just “obstacle” from “clear path.” Proprietary cycloidal leg actuators and swappable end-effectors with ISO-standard mounting flanges round out the mechanical story, but none of that mechanical sophistication substitutes for the safety claim this article is built around. A humanoid that can swap tools in seconds and carry more weight is a more useful machine; it is not, by virtue of those upgrades alone, a demonstrably safer one, and conflating the two is the most common mistake in how these launches get covered.

Inside the Digit 5 Safety Architecture: An Independent-Controller Reference Design

The Digit 5 safety architecture separates safety-critical decisions onto a controller independent from the main compute stack that runs perception, planning, and task execution, so a fault or overload in the task-level software cannot silently disable human-detection responses. That separation — not any single sensor or algorithm — is the reusable pattern any team designing or evaluating a cooperative humanoid deployment should extract from Digit 5.

Figure 1: Digit 5’s independent safety controller sits parallel to the main task-execution compute, consuming its own sensor fusion input and driving three categories of output — motion response, posture fallback, and human-facing intent signaling — without routing through the task stack.

The diagram above lays out the architecture at the level a systems integrator needs to reason about it. A dedicated safety controller receives fused input from proximity and vision sensors dedicated to human detection, runs its own classification of whether a person is in a zone that requires a response, and issues one of three outputs: a motion-avoidance command, a hard stop, or a transition to what Agility describes as an “assume safe posture” fallback — effectively a robotic equivalent of a fail-safe crouch or seated stance that removes the robot from an unstable configuration. In parallel, the controller drives visual and auditory cues that signal the robot’s motion intent to nearby workers, independent of whatever the task-level software is doing with its own status lights or speakers. The core design decision is that none of this depends on the main compute stack being healthy, responsive, or even powered — the safety controller is architected to keep supervising human-detection responses even if the task-execution path stalls, crashes, or is mid-way through an unrelated computation.

Why a Second, Independent Compute Path

The generalizable argument for a second, independent safety compute path is one every industrial-automation engineer already knows from fixed robotics: a safety function that shares a fault domain with the function it is supposed to override is not a safety function, it is a suggestion. A perception stack running large vision-language-action models — the kind compared across vendors in our VLA model comparison of GR00T, Gemini Robotics, and pi0 — is optimized for task generalization, not for guaranteed low-latency response under worst-case load. Task-level inference can legitimately stall for tens or hundreds of milliseconds while a model reasons about an ambiguous scene, and that is an acceptable cost for task quality but an unacceptable cost for a stop command. Digit 5’s architecture routes the stop decision around that stack entirely.

This is also where Digit 5’s public positioning diverges most visibly from competitors. Tesla’s Optimus program, detailed in our breakdown of the Optimus Gen 3 architecture, has emphasized end-to-end learned control and a unified compute approach optimized for manufacturing-line tasks inside Tesla’s own facilities — a context where the “public” in “public safety standard” is less immediately load-bearing than it is for a robot GXO or Amazon deploys inside a leased warehouse with a mixed workforce and an insurer reading the incident log. Agility’s decision to publicize an independent safety controller as a named architectural component, rather than treating safety as an emergent property of a capable enough task stack, is a bet that third-party deployability requires a safety story that can be audited separately from the task-execution intelligence. That bet is falsifiable and worth testing against whatever OSHA, ISO, or ANSI eventually publish.

The Three-Tier Response Ladder

The avoid/stop/assume-safe-posture sequence is worth reading as a ladder rather than three independent options, because the ordering encodes a real engineering trade-off. Avoidance — replanning a trajectory around a detected person — is the response that preserves the most task throughput, and it is the one most sites will encounter thousands of times per shift as workers walk normal routes near the robot. A hard stop is the next rung: faster to guarantee, but it discards in-progress motion and, for a bipedal machine, a stop command issued at the wrong moment in a gait cycle can itself be a stability risk. That is precisely why the third rung exists. “Assume safe posture” acknowledges that a legged humanoid cannot always be commanded to instantaneously freeze without risking a fall, so the safety controller has to have a pre-computed, dynamically-stable fallback configuration it can transition into instead of a naive full stop. Any plant engineer evaluating a competing humanoid should ask, specifically, whether that vendor’s safety architecture has an equivalent third rung, or whether “stop” is their only fallback — because for an actively-balanced biped, that gap is not a minor omission.

Intent Signaling as a Safety Control

The visual and auditory motion-intent cues are easy to read as a UX nicety and wrong to dismiss that way. In fixed-guarding industrial safety, the hazard is usually behind a barrier and the worker’s job is to stay out; in cooperative humanoid deployment, the hazard shares the floor, and the worker’s own situational judgment is part of the safety system whether the vendor designs for it or not. Signaling intent — which direction the robot is about to move, whether it has detected the approaching worker at all — reduces the number of scenarios where a worker’s reasonable assumption about robot behavior turns out to be wrong. Treating this as a safety-controller output, driven by the same independent path that drives the stop command, rather than as a cosmetic feature of the task stack, is the correct architectural choice, and it is one an evaluator should specifically confirm rather than assume from a marketing photo of blinking lights.

There is a legibility problem underneath this that no vendor has fully solved yet: warehouse and manufacturing workers do not receive standardized training on what a given robot’s lights or tones mean, and turnover in these roles is high enough that any site-specific signaling convention has to be re-taught constantly or it decays into background noise workers learn to ignore. A safety architecture that depends on intent signaling being noticed and correctly interpreted is only as strong as the site’s training program around it, which is a human-factors problem sitting just outside the robot’s own architecture diagram but squarely inside a plant safety manager’s job. Evaluators should ask not just whether Digit 5 signals intent, but what onboarding materials Agility provides to make those signals legible to a rotating workforce on day one.

Deeper Analysis: Capacity, Duty Cycle, and the Perception Stack Behind the Safety Gate

The 40% payload increase, 90-minute runtime, and 9-minute recharge are not separable from the safety story — they change how often and how closely humans and Digit 5 will actually share floor space, which is the exact variable the Digit 5 safety architecture exists to manage.

Figure 2: The human-detection response state machine cycles continuously between monitoring and classification, escalating to avoid, stop, or safe-posture only when a detected human enters a zone that the current task and proximity combination requires a response for, then returning to monitoring once the zone clears.

A 9-minute recharge against a 90-minute runtime is roughly a 10:1 run-to-charge ratio, which Agility states directly as a design target rather than an incidental figure. The practical effect is that Digit 5 spends a much smaller fraction of a shift parked at a charging dock than a robot with a slower charge cycle would, which means more of its operating time is spent in the exact mixed-traffic zones — aisles, staging areas, pick faces — where the safety controller’s detection and response logic is doing continuous work rather than idling. A robot that charges slowly effectively rate-limits its own exposure to humans by spending time offline; a robot engineered for a 10:1 ratio removes that incidental safety margin and has to earn it back explicitly in the controller. Figure 2 shows why the state machine is built to run continuously rather than being invoked reactively: at a high duty cycle, the cost of a slow or missed transition compounds across far more cycles per shift.

The 50-pound payload capacity, a 40% increase over Digit 4, raises the stakes on the same logic from a different angle: more mass in motion, and potentially heavier or more awkwardly shaped loads carried through the same aisles, means the kinetic energy involved in a mis-classified proximity event goes up, not down, generation over generation. This is the pattern every industrial safety engineer should recognize from conveyor and AGV history — capability upgrades that increase throughput routinely increase the consequence of a safety-system failure even when they don’t change its probability, and the correct response is to treat the safety subsystem’s validation burden as compounding across generations rather than static.

Figure 3: With ISO 25785-1 still at working-draft status and ANSI/A3 TR R15.108 self-described by Agility as vendor-led and in development, a buyer’s decision path in 2026 runs through vendor-supplied field-evaluation evidence and interim risk-assessment documentation rather than a finished external certificate.

Underneath the safety controller’s decision logic sits the perception stack doing human detection and scene classification, and this is where the choice of foundation model architecture becomes a safety-relevant engineering decision rather than a purely capability-relevant one. The kind of vision-language-action models compared in our GR00T, Gemini Robotics, and pi0 breakdown differ meaningfully in latency, failure mode under occlusion, and confidence calibration — properties that matter enormously for a task planner and matter just as much, arguably more, for a safety classifier deciding whether a partially occluded shape in a dim aisle is a person. Agility has not published which specific model family drives Digit 5’s human-detection classification, and that omission is itself worth noting: a vendor’s safety claims are only as auditable as the perception stack underneath them, and “independent safety controller” describes an architecture, not a guarantee about the model quality feeding it. A buyer’s evaluation should press on this specific gap rather than accepting the architecture diagram as sufficient evidence on its own.

Cost is the piece of this deeper analysis that rarely makes it into a launch article, and it belongs here because it explains why not every humanoid program builds an independent safety controller in the first place. A second, dedicated compute path with its own sensor suite is not free — it adds bill-of-materials cost, adds a component that itself has to be validated and maintained across the robot’s service life, and adds engineering headcount dedicated to a subsystem that generates no task throughput on its own. For a company selling a robot on a per-hour or per-unit basis into thin-margin logistics operations, that is a real cost to justify against a competitor shipping a single unified compute stack at a lower bill of materials. Agility’s bet, consistent with the 65,000-plus operational hours and the named enterprise customer list, is that the independent controller is what converts a pilot into a multi-year purchase order at a GXO or a Toyota — in other words, that the safety architecture pays for itself in deal size and deal velocity even before any external standard makes it mandatory. That is a defensible bet given the customer roster, but it is still a bet, and a competitor optimizing purely for unit cost could reasonably conclude the market will tolerate a thinner safety story for longer than Agility is assuming.

Trade-offs, Gotchas, and What Goes Wrong

The Digit 5 safety architecture is a genuine architectural improvement, but it is not a certification, and treating it as one is the single most common mistake a procurement team can make in 2026. Passing a field evaluation on one customer’s production line, under that site’s specific lighting, floor layout, and worker density, is evidence the architecture can work — it is not evidence it will transfer unchanged to a different plant with different hazards, and OSHA field evaluations of this kind are typically scoped to the deployment they were run against, not issued as a portable, site-agnostic clearance.

The standards gap itself is the second gotcha, and it cuts against the vendor rather than the buyer. ISO 25785-1, described in trade coverage as the first international safety standard aimed specifically at the humanoid category — industrial mobile robots with actively-controlled stability that fall over if powered off — remains, as best reported, at working-draft status; one trade estimate placed a draft international standard (DIS) milestone sometime in 2026 with final publication in late 2026 or 2027, but that timeline is a reported estimate, not something independently confirmed on iso.org, and standards timelines slip routinely. ANSI/A3 TR R15.108, the parallel US/Canada technical report for dynamically stable industrial mobile robots including humanoids, is described in Agility’s own materials as a document Agility itself is “a project leader and active contributor” on — which means the company shaping the reference architecture in this article is simultaneously helping write the rules it will eventually be measured against. That is not disqualifying, but it is a conflict worth naming plainly, and it means a buyer citing “compliance” with either document today is citing a moving, vendor-influenced target, not a fixed external bar.

A third failure mode is more mundane and more common in practice: response-ladder latency under real warehouse conditions rather than lab conditions. Avoidance replanning, stop commands, and safe-posture transitions all have to execute inside tight time budgets against sensor data that is noisier on a working floor — reflective packaging, dust, forklift traffic, seasonal headcount surges — than in a controlled demo. False negatives (missed detections) are the obvious risk, but false positives matter operationally too: a safety controller tuned conservatively enough to never miss a person will also trigger frequent unnecessary stops, and sites that experience that will face real pressure, official or informal, to loosen the tuning — which is exactly the wrong direction for a system whose entire value proposition is deliberately erring safe.

Figure 4: The four failure modes most relevant to an independent safety controller — sensor dropout, communication latency between controllers, actuator fault during a commanded stop, and software fault in the classification path — each require a distinct mitigation, and a buyer should ask which of these Digit 5’s public safety materials actually address versus merely imply.

Figure 4 is deliberately narrow: it covers failure modes inside the safety subsystem itself, not the much larger set of ways a warehouse deployment can go wrong operationally. Sensor dropout — a camera occluded by a pallet, a proximity sensor blinded by direct sunlight through a dock door — has to fail toward a conservative response (stop or safe posture), never toward silently continuing as if no human were present, and that fail-safe direction is a design choice a vendor should state explicitly rather than leave implicit. Communication latency between the safety controller and the actuators it commands is the second failure mode, and it is the one most sensitive to the mechanical realities of a bipedal platform: a delayed stop command arriving mid-stride is a different physical event than the same delay on a wheeled AGV, which is exactly why the safe-posture fallback exists as a hedge against exactly that timing risk. Actuator fault — a cycloidal leg actuator not responding to a commanded stop — and software fault in the classification path round out the set, and both require the kind of redundancy and watchdog logic that fixed-automation safety engineers have decades of practice specifying but that humanoid-specific guidance, absent a finished ISO 25785-1, has not yet standardized language for.

Finally, Digit 5’s business context is worth factoring in: Agility’s pending SPAC merger with Churchill Capital Corp XI, a $2.5 billion deal announced in early June 2026 and expected to close by the end of 2027, plus reported multi-year customer commitments exceeding $300 million, put commercial pressure on hitting the stated early-access (H1 2027) and general-availability (end of 2027) timelines. RoboFab, Agility’s production facility, is reported to be scaling toward capacity of up to 10,000 units per year — a volume ramp that will inevitably introduce manufacturing and component variance the field-evaluated pilot units did not have to contend with at smaller scale. None of that commercial pressure is evidence the safety architecture will be compromised, but it is a reason for buyers to ask about the safety validation schedule separately from the shipping and financing schedule rather than assuming the three move in lockstep, and to ask specifically whether safety-relevant testing scales with unit volume or lags behind it.

Practical Recommendations

Plant engineers evaluating the Digit 5 safety architecture, or any competing humanoid’s equivalent, before ISO 25785-1 or ANSI/A3 TR R15.108 reach final publication should treat vendor safety claims the way they would treat any pre-standard industrial equipment claim: verify the specific evidence, not the marketing category it’s filed under. The core discipline is separating architectural claims (there is an independent safety controller) from validation claims (it was tested, where, and against what) from certification claims (a named external body signed off, and on exactly what scope).

Evaluation checklist:

• Ask which specific field evaluation the vendor cites, who performed it, and whether the scope covers your site’s layout, lighting, and worker density — not just that an evaluation happened somewhere.
• Confirm the safety controller’s fault domain is genuinely independent of the task-execution stack, in writing, not just in a marketing diagram — ask what happens to human-detection response if the task compute crashes mid-cycle.
• Require documentation of all response tiers, specifically whether a legged platform has a dynamically-stable fallback posture distinct from a hard stop, and how that transition is validated.
• Get the perception stack’s human-detection model family, latency budget, and known failure modes (occlusion, low light, reflective surfaces) in writing rather than accepting an aggregate accuracy number.
• Ask directly which draft standard, if any, the vendor is designing to, and get their own acknowledgment of that standard’s current status rather than treating “ISO 25785-1 compliant” as a claim to accept at face value in 2026.
• Build your own site-specific incident and near-miss log from day one of pilot deployment — this becomes your evidence base for the next generation’s evaluation and for insurer conversations, independent of whatever the vendor publishes.
• Revisit the vendor relationship annually against the standards timeline rather than assuming a purchase-time safety story remains current through a multi-year deployment.
• Involve your insurer and workers’ compensation carrier in the pilot design before deployment, not after an incident, since their read on an unproven safety category will shape claims handling regardless of what the vendor’s documentation says.

None of this checklist requires waiting for ISO 25785-1 or ANSI/A3 TR R15.108 to finalize before deploying a humanoid responsibly. It requires treating the vendor’s safety documentation the way a plant engineer already treats any pre-standard equipment: as a set of specific, verifiable claims to test against your own site conditions, rather than a category label to trust because a well-known brand attached it to a well-specified robot.

Frequently Asked Questions

What is the Digit 5 safety architecture, in one sentence?

The Digit 5 safety architecture is an independent safety controller, physically and logically separate from Digit 5’s main task-execution compute, that runs its own sensor fusion for human detection and can independently issue avoidance, stop, or fallback-posture commands along with visual and auditory intent signals, so a fault in the task stack cannot disable the robot’s human-safety responses.

Has Digit actually passed an OSHA safety certification?

Not exactly, and the distinction matters. Agility’s own materials state that an earlier Digit became the first humanoid to pass an independent field evaluation against industrial safety standards administered by OSHA, on a specific customer production line. A field evaluation of a deployed system is meaningfully different from a formal product certification against a finished standard — the latter doesn’t yet exist for humanoids at all.

What is ISO 25785-1 and when will it be finished?

ISO 25785-1 is reported in trade coverage as the first international safety standard aimed at the humanoid robot category, covering industrial mobile robots whose stability is actively controlled and who would fall if powered off. It remains at working-draft status; one trade estimate puts a draft international standard milestone in 2026 and final publication in late 2026 or 2027, but treat that as an unconfirmed reported estimate, not a fixed date.

How is ANSI/A3 TR R15.108 different from ISO 25785-1?

ANSI/A3 TR R15.108 is a US/Canada-focused technical report, described in Agility’s own materials as covering dynamically stable industrial mobile robots including humanoids, with Agility named as a project leader and active contributor. It is a regional technical report under development rather than a finished international standard, and Agility’s role in authoring it is vendor-stated, not independently verified by a third party.

Why does the payload and runtime upgrade matter for safety specifically?

A 40% payload increase and a roughly 10:1 run-to-charge ratio both increase the amount of time and kinetic energy a Digit 5 spends actively working in mixed human traffic rather than idle at a charging dock. That raises the consequence of any single safety-controller failure and means each generation’s capability gains have to be matched by proportional safety validation, not just celebrated as throughput wins.

What should a buyer do differently because no humanoid safety standard exists yet?

Treat every vendor safety claim as evidence to independently verify rather than a certification to accept. Ask for the specific field-evaluation scope, the safety controller’s actual fault-independence, and the perception stack’s known failure modes, and build your own incident log from day one so your safety case doesn’t rest entirely on the vendor’s documentation once a real standard finally arrives.

Further Reading

• Tesla Optimus Gen 3 Humanoid Architecture (2026)
• NVIDIA Jetson Thor Humanoid Robot Architecture (2026)
• VLA Models Comparison: GR00T, Gemini Robotics, pi0 (2026)
• Agility Robotics: Agility Unveils Digit 5 Humanoid Robot Built for Cooperatively Safe Work at Scale
• Robotics and Automation News, September 17, 2026, coverage of Digit 5 customer order commitments and production timeline

By Riju — about