Humanoid Robots as a Service: What a 90-Day Pilot Must Prove

The short answer

A humanoid Robots-as-a-Service contract should be judged by the operating record it produces, not by the financing label or the robot demonstration that preceded it.

Agility Robotics has now published a concrete deployment method for Digit. Its Customer Acceleration Program, or CAP, has three stages:

define and validate a workflow in a controlled environment;
run a cordoned proof of concept at the customer site;
move onto the production line and measure 90 days of uptime, throughput, reliability, operational impact, and return on investment.

Agility says a customer can then move to an ongoing Robots-as-a-Service, or RaaS, model (Agility Robotics). This is meaningful process disclosure. It identifies the integration work that short robot videos omit, including simulation, physical workflow setup, facility mapping, network access, fleet software, employee training, deployment engineering, repairs, software updates, and cloud monitoring.

It is not a published 90-day customer result. The article does not provide a completed CAP dataset, price, uptime percentage, intervention rate, throughput per robot-hour, service-level agreement, support staffing, or ROI formula.

The useful conclusion is narrower: Agility has described how it intends to convert a use case into measured production operation. Buyers still need the resulting denominators and contract terms before they can compare value.

What Robots-as-a-Service changes

A purchase price asks what the machine costs. A service model asks what useful capability the customer receives over time and who carries the operating risk.

The public GXO agreement gives this model a real commercial reference. GXO announced a multi-year agreement in June 2024 after a 2023 proof of concept. It said Digit robots and Agility Arc would operate at a SPANX facility, moving totes from autonomous mobile robots to conveyors while integrating with existing automation (GXO).

That source establishes a named customer, workflow, site context, multi-year term, and RaaS structure. It does not disclose price, robot count, minimum output, uptime guarantee, termination rights, or how commercial risk is divided.

A service model can reduce the customer’s upfront capital burden. Agility calls its model “CapEx-light.” It can also bundle capabilities that are difficult to procure separately:

robot hardware and replacement capacity;
deployment engineering and workflow configuration;
facility maps and fleet orchestration;
monitoring, alerts, and troubleshooting;
software releases and security maintenance;
repairs, parts, and field support;
performance reporting and scaling support.

Those benefits are possible features of a service relationship, not proof that every contract contains them on favorable terms. The contract must state what is included, what triggers an additional charge, and who is responsible when the system is unavailable.

Agility’s three-stage evidence ladder

The CAP process is best read as an evidence ladder. Each stage answers a different question.

Stage	Public description	What it can establish	What it cannot establish alone
Solution setup	Define the win, map the workflow, reproduce conditions in simulation and at Agility, then generate physical workflow data	Task fit, object and layout requirements, early technical feasibility	Customer-site reliability, production throughput, commercial value
On-site validation	Deploy Digit in a cordoned customer area, connect networks and Arc, map the work area, assign the workflow, adjust for site details, and train staff	Integration feasibility in the actual facility, workflow-specific problems, deployment effort	Routine production performance or low support burden
Operational impact	Move Digit onto the production line and measure uptime, throughput, reliability, operational impact, and ROI over 90 days	Bounded operating evidence under production conditions	General-purpose autonomy, performance at another site, favorable contract economics
Ongoing RaaS	Continue service, support, software, monitoring, and possible scaling	A recurring commercial relationship when a customer signs and operates it	A public service level, renewal, profitability, or customer ROI without disclosed results

This separation protects against a common evidence error. A successful controlled setup does not make the site pilot a success. A site pilot does not establish production performance. A 90-day measurement plan does not establish a positive result. An ongoing contract does not reveal whether either party earns an acceptable return.

Our humanoid availability and deployment tracker uses the same distinction among announcement, demonstration, pilot, commercial access, and production deployment.

Stage 1: prove that the workflow fits the robot

Agility says its first customer conversations ask whether a humanoid is even the right tool. Repetitive work between “islands of automation” can be a plausible fit. A fixed arm or autonomous mobile robot may be better for other workflows.

That screening matters because humanoid form does not automatically create economic value. Legs and arms can help in facilities designed for people, but they add balance, power, safety, maintenance, and control requirements. A buyer should compare the proposed humanoid workflow with the simplest credible alternative.

The solution-setup stage should produce a written workflow definition:

input and output states;
objects, weights, dimensions, and acceptable placement error;
travel path, obstacles, stations, buttons, doors, and conveyors;
required rate and quality;
environmental constraints;
expected exceptions;
tasks kept with human workers;
acceptance criteria for moving to the customer site.

Agility says it recreates conditions in simulation and physically at its own site, then uses physical workflow data to refine execution. That is stronger than presenting a generic capability reel. It still does not show how the system performs in the customer’s live operation.

Stage 2: measure integration work, not only robot motion

The customer-site proof of concept is where deployment overhead becomes visible.

Agility describes deployment engineers uncrating robots, connecting them to the customer’s network, connecting Arc, building a facility map, specifying movement and manipulation points, assigning workflows, and adjusting the system for local conditions. It also describes employee communication, customer-team training, and on-site engineering support.

These are not side details. They are part of the cost and schedule. A useful proof-of-concept report should retain:

engineering hours by vendor and customer;
network, cybersecurity, and systems-integration work;
facility changes and new equipment;
training time by role;
software and workflow revisions;
robot and peripheral versions;
time from arrival to first valid task;
time from first task to a stable acceptance run;
blocked hours and their causes.

Agility explicitly says initial automation integration requires adjustments. That candor is valuable. The unanswered question is how much adjustment a typical site requires and whether the burden falls over time.

Stage 3: make the 90-day denominator inspectable

Agility says the production stage should produce 90 days of operating data. A calendar window alone is not enough. Ninety elapsed days could contain one robot on one short shift, several robots across continuous shifts, or long periods of inactivity.

A defensible 90-day report needs at least five denominators.

1. Fleet and schedule

Record robot count, hardware generation, software version, planned shifts, scheduled hours, and days the workflow was expected to run. Report configuration changes with dates.

2. Output and quality

Report attempted tasks, successful tasks, units moved, rejected or damaged units, retries, partial completions, and output accepted by the downstream process. Throughput should be normalized per active robot-hour as well as reported in total.

3. Human assistance

Report teleoperation minutes, interventions, resets, fault clearances, material corrections, manual task completions, and supervision hours. Separate remote vendor support from customer labor.

4. Reliability and maintenance

Report scheduled versus actual uptime, failure categories, mean time between incidents, mean time to recovery, planned maintenance, unplanned repair, component replacement, spare consumption, and software-related stoppages.

Agility Arc was introduced to expose robot status, uptime, throughput, mean time between incidents, alerts, troubleshooting, and support access (Agility Robotics). That establishes the intended measurement surface. It does not make customer data public or define how each metric is calculated.

5. Safety and operational impact

Report protective stops, near misses, incidents, damaged goods, blocked aisles, ergonomic changes, staffing changes, and effects on adjacent equipment. Preserve both positive and negative outcomes.

The robot safety standards guide explains why robot design, workcell controls, application integration, and site risk assessment must be evaluated together.

What the 100,000-tote milestone adds

Agility later reported that Digit moved more than 100,000 totes at GXO’s Flowery Branch facility. It describes two tote workflows and says its learning pipeline combines traditional control, teleoperated demonstrations, policy training, reinforcement learning, and simulation (Agility Robotics).

This is useful production evidence. A six-figure cumulative output is stronger than a short pilot video because it implies repeated operation over many cycles. GXO’s separate agreement confirms the customer and commercial setting.

The milestone still cannot answer several economic questions because the public sources do not provide:

number of Digit robots;
total scheduled and active robot-hours;
totes per robot-hour;
failed or rejected moves;
intervention and teleoperation time;
downtime and repair history;
customer and vendor staffing;
total service and integration cost;
comparison with the previous process.

This is why cumulative throughput and a 90-day CAP report would complement each other. Total output shows scale of activity. Fleet, time, assistance, quality, and cost denominators show the rate and burden behind it.

The wider physical AI production evidence comparison applies these fields across Digit, Figure 02, AGIBOT G2, and task-specific systems.

How to calculate ROI without hiding the baseline

Return on investment is not a property of the robot alone. It depends on the workflow, contract, integration, utilization, support, and alternative the customer would otherwise choose.

A transparent calculation should show:

Annual benefit

accepted incremental output;
avoided overtime or temporary labor;
reduced injury or ergonomic cost, when supported by site data;
lower error, damage, or rework;
capacity retained during staffing shortages;
avoided facility retrofit compared with the chosen alternative.

Annual and one-time cost

service fees and usage charges;
integration and facility changes;
customer IT, operations, safety, and training labor;
vendor and third-party support outside the base fee;
network and software dependencies;
human supervision and exception handling;
downtime and displaced production;
contract exit or restoration costs.

Baseline

The comparison must name the actual alternative: the current human process, a fixed robot cell, an AMR, conveyor changes, outsourced work, or no automation. Comparing a humanoid with an imaginary zero-cost process or an unrealistically perfect labor baseline can distort the result in either direction.

A 90-day pilot can estimate these terms. It cannot automatically establish a full-year result if seasonality, learning effects, maintenance cycles, shift mix, or product mix differ.

Contract questions buyers should settle before production

The following checklist is an editorial framework. It is not a description of confidential Agility or GXO terms.

Scope and acceptance

What exact workflow, objects, stations, rates, and exclusions are covered?
What test moves the project from setup to site validation and then to production?
What output counts as successful, rejected, retried, or customer-caused delay?

Service level and measurement

How are scheduled time, active time, uptime, throughput, and incidents defined?
Which systems supply the source data, and can the customer export raw event records?
Are planned maintenance, facility blockage, network failure, and upstream starvation excluded?
What service credits or remedies apply when targets are missed?

Human support

Who provides on-site supervision, remote monitoring, teleoperation, resets, and recovery?
Are support hours included, capped, or billed separately?
What response and repair times apply by shift and severity?

Hardware, software, and data

Who owns the robots, spares, maps, logs, workflow configurations, and generated task data?
Can software updates change measured behavior during the pilot, and how are versions recorded?
What cybersecurity, retention, access, and incident-notification terms apply?
What happens to customer data and site maps when the contract ends?

Safety and change control

Who owns the application risk assessment, workcell controls, employee training, and regulatory documentation?
Which changes require a new validation or safety review?
Who carries responsibility for damage, injury, production loss, and third-party equipment failure?

Economics, scale, and exit

Is pricing per robot, hour, shift, task, accepted unit, site, or performance tier?
Which integration, travel, parts, support, and software costs sit outside the recurring fee?
Can the customer scale down as well as up?
What are the renewal, price-change, termination, transition, and facility-restoration terms?

A CapEx-light contract can still create long obligations or variable operating cost. The economic question is not simply whether the hardware sits on the vendor’s balance sheet. It is whether the customer receives a measurable outcome at an acceptable total cost and risk.

Safety boundary: sectioned workcells today

Agility’s deployment article makes an important generation-specific disclosure. It says fourth-generation Digit remains in a sectioned workcell during CAP and full RaaS deployments. It also says workcells containing Digit have passed field inspections by an OSHA-recognized Nationally Recognized Testing Laboratory.

Those statements should not be broadened into a claim that Digit is cooperatively safe without barriers. Agility says its first cooperatively safe humanoid is scheduled for 2027. That is a roadmap statement, not a completed deployment, certification, or customer operating result.

The distinction affects economics. Barriers, access controls, material handoffs, workcell footprint, restart procedures, and interaction with adjacent workers can change facility design and utilization. These controls may be entirely appropriate. They still belong in the workflow and cost model.

Evidence verdict

Claim	Classification	Confidence	Evidence boundary
Agility uses a three-stage CAP deployment method	First-party process disclosure	High	The stages and intended activities are public, but customer-level CAP records are not
CAP should produce 90 days of operating and ROI data	Vendor-stated measurement plan	High for the stated plan	No completed 90-day dataset or calculation method is published in the source
GXO signed a multi-year Digit RaaS agreement	Customer-confirmed commercial agreement	High	Public terms omit price, robot count, service levels, and exit conditions
Digit moved more than 100,000 totes at GXO	Vendor-reported cumulative production output	Medium-high	GXO confirms the deployment, but fleet, hours, failures, interventions, and economics remain undisclosed
Arc measures operational KPIs and supports fleet operations	First-party product capability	High for documented product intent	Public customer KPI exports and metric definitions are unavailable
Fourth-generation Digit works cooperatively beside people without barriers	Not supported	High	Agility says current CAP and RaaS deployments use sectioned workcells
A cooperatively safe humanoid will be deployed in 2027	Company schedule	Medium	Future delivery, validation, standards alignment, and operating results remain to be shown

What to watch next

A completed CAP report with robot count, scheduled and active hours, output, failures, interventions, support, and cost.
Metric definitions for Arc, including uptime, throughput, and mean time between incidents.
Customer-side confirmation of the 100,000-tote operating denominator and workflow economics.
Public service-level categories for response, repair, replacement, software support, and data access.
Renewal or scaling evidence from an existing RaaS customer.
A comparison against the customer’s best non-humanoid alternative.
Safety evidence for the announced 2027 cooperatively safe generation, with application scope and customer operation kept separate from design claims.
Evidence showing whether integration and intervention burden falls, stays flat, or rises across later sites and workflows.

Bottom line

Agility’s deployment article is valuable because it replaces an abstract adoption claim with a sequence of work: screen the workflow, reproduce it, integrate at the site, train people, measure production, then decide whether to continue under RaaS.

The process is not the result. A buyer should not treat “90 days” as an evidence label without the fleet, time, output, assistance, reliability, safety, and cost denominators inside that period.

The strongest humanoid service contract will not merely provide access to a robot. It will define the work, expose the operating record, allocate support and safety responsibilities, and let the customer test value against a credible alternative.

Frequently asked questions

What is humanoid Robots-as-a-Service?

Humanoid Robots-as-a-Service is a commercial model in which a customer contracts for robot capability and continuing service rather than treating the robot only as a one-time capital purchase. The reviewed Agility and GXO sources connect Digit hardware, fleet software, deployment, troubleshooting, support, and continuing operation under a multi-year agreement, but do not publish pricing or service-level terms.

Does a 90-day humanoid pilot prove return on investment?

Not by itself. Agility says its Customer Acceleration Program is intended to produce 90 days of operating data and quantify return on investment. A defensible result still needs the robot count, scheduled and active hours, successful output, interventions, downtime, support labor, integration cost, baseline process, and calculation method.

What should a humanoid pilot measure?

At minimum, measure task attempts and successful outputs, active and scheduled hours, uptime, throughput, interventions, teleoperation, resets, failures, recovery time, maintenance, quality defects, safety events, staffing, and total cost against a defined baseline.

Is Agility's Customer Acceleration Program a production result?

No. It is a disclosed deployment method with three stages, controlled solution setup, a cordoned customer-site proof of concept, and production-line measurement. The method is useful evidence about integration, but customer-level results must be evaluated separately.

Is Digit working without safety barriers?

Agility says its fourth-generation Digit remains in a sectioned workcell during the Customer Acceleration Program and full Robots-as-a-Service deployments. The company says a cooperatively safe humanoid is scheduled for 2027. A schedule is not a completed deployment or certification result.

What contract terms matter most for humanoid Robots-as-a-Service?

Buyers should define the task and acceptance test, service levels, uptime calculation, human-support responsibilities, maintenance and repair, software changes, data rights, cybersecurity, safety responsibilities, pricing units, renewal, scaling, and exit terms. The reviewed public sources do not disclose Agility's actual customer contract language.