Close Menu
Technology

A Step-by-Step Guide on How to Build General-Purpose Physical AI

General-purpose robotics needs a development process that connects learning and recovery to customer acceptance, reliable operation, and measurable cost.
By Updated:15 Mins Read
AI-generated illustration.

In September 2026, Figure sent its humanoid robot, running its new Helix 2.5 model, into 30 homes it had never seen. It tidied living rooms, folded towels and made beds. By Figure’s own count, it finished the whole job 56% of the time.

In April, the startup Generalist showed its GEN-1 model folding 86 shirts in a row. Generalist reports 99% average success, but only on tasks the model had been trained to do.

Those two results sum up physical AI in 2026. One system copes with places it has never seen, and the other does familiar work almost perfectly. No released system has yet shown both in one robot, and that combination is what general-purpose physical AI means.

This guide sets out how to build it in ten steps. Every part already exists somewhere, spread across different labs. The hard part is putting them together and proving the result works.

What counts as general-purpose

General-purpose physical AI is a robot system that can arrive at a workplace it has never seen and take ordinary requests. It does the work well enough that someone pays for it, and keeps that up for a whole shift without a person quietly stepping in.

The word that matters is accepted. Work counts only when it passes the buyer’s own quality check, and every request ends in one of five ways.

  1. Done alone and accepted.
  2. Done and accepted, but with human help, from a remote hint to a person resetting the scene.
  3. Safely refused or postponed, with a reason.
  4. Failed, with no harm done.
  5. An incident, meaning an injury, a serious near miss or damage.

Companies tend to report the first two together as success. Buyers, insurers and auditors need the first one on its own. A robot cannot score well by refusing hard jobs either, because every refusal is counted against it.

We set the bar at what we call Level D, for domain-general work. A frozen system, one that is not retrained during the test, must handle 50 or more kinds of task in one line of business. The test runs at 100 sites the system has never seen, with targets for quality, safety and cost, and an outside auditor checks the results. Level X comes after that, when the same model family passes separate audits in three or more different lines of work, such as kitting, commercial laundry and machine tending.

Two things never count. A video without trial counts does not, and nor does a remote operator who quietly finishes the hard parts.

Why it is hard, in three numbers

The first number is 13%. Picture a job made of 100 small steps, with the robot getting each one right 98% of the time. It finishes the whole job only 13% of the time, because one slip anywhere ends the task.

The second number is 97%. Give the same robot the ability to notice 99% of its slips and fix 99.5% of the ones it notices. Now it finishes the 100-step job 97% of the time, even though it makes exactly as many raw mistakes as before.

That is the most important idea in this guide. The robots that win will be the ones that notice their mistakes and recover. Effort spent on catching and fixing errors buys more reliability than the same effort spent on perfect first attempts.

The third number is 34,400. That is how many trials, without a single failure, it takes to prove 99% success across 50 kinds of task with proper statistical confidence. At ten minutes a trial, that is about 5,700 robot-hours of testing before anyone can honestly make the claim.

Safety is harder still. Showing that a robot causes fewer than one serious incident per million hours would take about three million incident-free hours. A fleet of 100 robots, each working 4,000 hours a year, would need seven and a half years to log them. So safety has to be designed and argued for, and testing can only ever be part of the case.

Detection and recovery lift a 100-step task from 13% to 97% success

Each line assumes a 2% chance of a slip at every step, with steps failing independently. It is a model, not a robot measurement.

The ten steps at a glance

The build runs in three phases, and each one ends at a gate that an outsider can check. The steps overlap where the work allows, and failures verified at paying customers flow back into the data engine.

Ten steps in three phases, each closed by a gate, ending in a Level D audit

Phase 1. Foundations

The first three steps take roughly four months. They decide what the robot will be judged on, before anyone trains a model.

Step 1. Choose the work and write the contract

Start with one line of work. Good first domains share four traits. Output is counted, mistakes cost minutes instead of injuries, the work repeats with variation, and labour is short. Kitting, tote handling, commercial laundry and machine tending all fit.

Then write acceptance criteria that a paying customer would sign for 50 or more families of tasks. Include what counts as damage and what counts as a safe refusal. Define every kind of human help, from a remote hint to a physical reset, so none of it can hide. If no buyer will sign the criteria at your target price, change the domain, not the criteria.

Step 2. Build the test before you chase scores

Today’s best results cannot be compared. Figure reports full-task success across homes, Generalist reports streaks on tasks it trained for, and Google DeepMind reports averages by skill. Each is honest on its own terms, and none lines up with the others.

So build the evaluation first. Keep test sites and objects out of training, freeze the whole system before each test, and log enough to replay any request. The person running evaluation should report outside the model team, so nobody marks their own homework. If the logs cannot explain a failure, stop adding tasks and fix the logging.

Step 3. Build a data engine that buys information

Raw data is no longer scarce. Figure says its Index dataset takes in about 35 minutes of human experience every second, roughly 18 million hours a year at that pace. Generalist trained GEN-1 on half a million hours recorded with wearables.

Volume alone misleads, though. The head of China’s largest humanoid training centre told The Standard that fewer than 5% of humanoids shipped there in the first half of 2026 could do practical production-line work. He blamed a shortage of good real-world data. What counts is failure coverage, the share of real failure types your data teaches the robot to avoid or recover from.

So sort failures by cause, such as a slip, a jam or the wrong object, and spend each new data budget where it removes the most failures per dollar. Collect recovery data on purpose, by nudging the robot off course and recording how it gets back. If training scores keep improving while real-world results stall, change the approach before buying more of the same data.

Phase 1 ends at a gate. An outside evaluator must be able to rebuild 1,000 requests from the logs, and targeted data must beat random collection of the same cost.

Phase 2. Capability

Steps 4 to 6 build the robot’s skills, roughly in months three to six. The goal is a robot that feels what it touches and catches its own mistakes.

Step 4. Give the robot a sense of touch where it counts

Dexterity is where learning from video is weakest. Google DeepMind’s Gemini Robotics 2, working a five-fingered robot hand, unscrewed a light bulb 92% of the time. It screwed one in only 36% of the time. Rodney Brooks argues that humanoids will not learn dexterity mainly from video, because video does not record what hands feel.

Touch helps where contact decides the outcome. In the T-Rex study from UC Berkeley, NVIDIA and others, 100 hours of touch data lifted average success on 12 contact-heavy tasks to 65%. The strongest baseline managed 35%.

Add touch sensors where your failure log shows contact errors, and nowhere by default. Then train the robot to sense a slip before it happens. Teach it to probe as well, with a small tug to test a grip or a press to check that a part is seated.

Step 5. Split control into slow and fast layers

No single network should plan an hour of work, seat a part and keep a robot balanced. Planning and checking run slowly, between once every ten seconds and twice a second. Learned movements run 5 to 50 times a second, and force and balance control 100 to 1,000 times a second. Each faster layer can stop the slower one above it.

Even advanced models are slow. NVIDIA’s DreamZero, which predicts video and actions together, runs its control loop about 7 times a second, too slow for contact on its own. Keep a task ledger outside the network, a running record of what is done, what was checked and what is left, so memory survives a restart. Pick the design that needs the fewest human interventions per hour, whatever the benchmark tables say.

Step 6. Teach the robot to catch, fix and ask

This is the step behind the jump from 13% to 97%. Train a detector for each kind of failure in your catalogue and measure how often it misses. Then build a recovery curriculum from the robot’s own mistakes, because a robot that only copies perfect demonstrations drifts into situations its teachers never showed it.

Recovery has limits. Dropping a fragile object and then putting it in the right bin is not a recovery.

The robot also needs to know when to ask for help. Princeton and Google DeepMind’s KnowNo research showed that a robot planner can ask only when it is unsure, with a statistical guarantee on task success. Silent failures, where nothing was noticed, are the most dangerous kind, so drive those towards zero first.

Phase 2 ends at a gate. Contact failures must halve on two different hands, and unresolved failures must fall tenfold.

Phase 3. Scale and proof

The last four steps start around month seven. They turn a capable robot into a product that earns money and survives an audit.

Step 7. Learn from experience, one careful release at a time

Fleets supply the rare failures that no dataset holds. Collecting 100 examples of a failure that happens once in 1,000 attempts takes 100,000 attempts. Physical Intelligence’s Recap method, which learns from demonstrations, corrections and the robot’s own practice, more than doubled throughput on some of its hardest tasks.

Learning from the field is also the quickest way to break what already works. Ship every update to a small canary fleet first, with automatic rollback if interventions rise. No task family may get worse to make another better. Learning switches off during the final audit, so the system that was tested is the one that ships.

Step 8. Build a body that keeps working

A robot brain is only as good as the hours its body delivers. Bank of America puts the bill of materials for a China-built humanoid at $35,000 in 2025, falling below $17,000 by 2030. Price matters less than uptime, though, because every lost hour raises the cost of each accepted task.

Choose the body by cost per accepted task, which may mean wheels or fixed arms instead of legs. Design hands and batteries so a technician can swap them in minutes, and publish how long hands and wrists last between failures. China produces about 70% of the world’s rare earths, so line up second suppliers for magnets and precision parts early.

Step 9. Deploy where someone pays, and prove the fleet learns

Only paying fleets produce real experience at the volume reliability needs, and only payment proves the work is worth doing. Ambi Robotics has gathered about 200,000 hours of real robot data while sorting 100 million packages. Agility’s Digit robots have logged more than 65,000 hours at customer sites.

Start small, with three customer sites over 90 days. Contract for acceptance criteria, data rights, uptime and intervention reporting, and report all five outcomes every week. Then compare robots that run the learning loop with robots that do not. A bigger fleet is only a bigger cost until it is shown to teach, so if the learning group fails to beat the control group, stop scaling.

Step 10. Pass an outside audit, then try a second domain

Freeze the full system, let an independent auditor pick 100 sites the robot has never seen, and publish the results, failures included. Build the safety case on existing standards, such as the draft ISO 25785-1 for dynamically stable industrial robots and ISO 13482 for personal care robots.

Phase 3 ends when the frozen system passes its contract at those 100 sites. Then comes the harder test. The same model family must pass separate audits in at least two more lines of work, with different objects, hazards and buyers. Any task family that fails gets published, fixed and re-tested under the same rules.

How to tell real progress from a good demo

Nearly every number in this field comes from the companies themselves, and the tests differ so much that results rarely line up. No developer yet publishes how often humans step in, per robot-hour, across many unseen sites. Six questions cut through most claims.

  • How many trials were run? Generalist’s 86 straight shirt folds are impressive, but on their own they prove success above about 96.6%, not 99%.
  • Were the sites and objects new to the robot?
  • Was the system frozen during the test, or tuned between runs?
  • How often did a person step in? For 95% of eight-hour shifts to need no help, a robot can call for help at most once every 156 robot-hours.
  • Are all five outcomes reported, including refusals and incidents?
  • What does an hour of accepted work cost?

The last question is where many business cases break. Agility has more than $300 million in committed orders for 1,000 Digit 5 robots over three years, according to its SEC filing. That works out to roughly $100,000 per robot-year, support included, or $25 an hour at 4,000 working hours a year.

A US hand labourer costs about $27 an hour once benefits and overhead are added to the $19.35 median wage. If the robot works at 70% of a person’s pace and shares a supervisor with nine other robots, an hour of human-equivalent work costs about $40. That is roughly one and a half times the cost of the person.

When it could arrive

Our forecast puts the odds of a commercial system passing a full Level D audit at 30% by the end of 2030 and 50% by the end of 2032. Structured work such as logistics and manufacturing comes first, because sites can be standardised and failures cost less. Homes come later, with even odds around 2038, because they vary more, failures cost more and buyers pay less.

Even odds of a commercial Level D pass by 2032, and of a domestic one by 2038

The case for speed is real. GEN-1 cut average failures about 36-fold compared with its predecessor in five months, though on tasks it was trained for. Against that, most evidence is self-reported, a full audit can take up to 100,000 trials, and service prices have to fall well below $100,000 a robot-year.

The odds rise if an independent benchmark confirms 80% success at unseen sites, if audited intervention rates fall quarter after quarter, or if service prices halve. They fall if success at new sites stalls while training scores keep improving, or if a serious injury leads regulators to pause deployments.

The breakthrough will arrive as a report, with a signed acceptance contract and outcomes anyone can inspect. Whoever produces that report first, in a market that pays, will set the terms for the next decade of physical AI.

Sources

Share.

Related Analysis