If you are being asked to form a robotics strategy, the worst starting question is, “Should we buy a humanoid?” That turns a product decision into a hardware debate before you have defined the job, the acceptable failure rate, or the economics.

Start with a narrower question: which physical workflow could create enough value to justify a robot’s cost, supervision, risk, and operational complexity? The answer will tell you whether you need embodied AI, what kind of body it needs, and how much autonomy you should permit.

The product is a system, not a humanoid

A software agent can recover from many mistakes by undoing a change, retrying a tool call, or asking for approval. A physical agent acts through cameras, joints, hands, grippers, wheels, and legs. Its mistakes consume time, move material, damage equipment, or put people at risk. That changes the product standard.

Useful embodied AI must connect several capabilities: interpret a goal, perceive the environment, plan a sequence, convert that plan into movement, observe the result, and decide whether to continue, retry, recover, or stop. Treating all of this as one opaque model makes failures difficult to locate and permissions difficult to control.

The Gemini Robotics 2 family separates these responsibilities across three components:

• Gemini Robotics ER 2 interprets the goal, reasons about the environment, creates a multi-step plan, calls tools, and monitors progress.
• Gemini Robotics 2 is the vision-language-action model that translates visual context and instructions into physical actions, including whole-body movement and object manipulation.
• Gemini Robotics On-Device 2 runs action capabilities locally on robotic hardware, reducing dependence on a continuous cloud connection.

This separation is more than an engineering detail. Each layer has a different product owner, risk profile, evaluation method, and update cadence. The planner can be improved without automatically expanding the actions a robot is allowed to perform. A new skill can be tested within a bounded workspace before it enters production. A safety controller can reject an action even when the reasoning model wants to continue.

Whole-body coordination matters for the same reason. A robot that can grasp an object but cannot reposition, balance, crouch, or carry it through the workspace has a narrow operating envelope. In one Apptronik Apollo 2 demonstration, placing a watering can in a bin on a lower shelf required the robot to locate the can, walk to it, grasp it, cross the room, crouch, and place it correctly. The value lies in maintaining perception and control across the entire sequence, not in any single movement.

That still does not make the robot universally capable. In product terms, “generalist” should mean reusable across a portfolio of related workflows. It should not mean unbounded autonomy in any environment. The body may be general-purpose; every production workflow still needs a defined task contract, permission boundary, and acceptance test.

Choose the task envelope before the robot

A polished demonstration answers whether a system can complete a selected task under selected conditions. You need to know whether it can complete your task across the conditions that occur during normal operations.

Define the task envelope before evaluating a platform. The envelope includes the objects the robot may encounter, their valid starting positions, the workspace, expected human movement, acceptable end states, permitted recovery actions, and conditions that require a stop. If a vendor cannot test against that envelope, the evaluation is not yet connected to your business.

A promising first workflow usually has the following properties:

• A verifiable finish state. You can determine whether the object reached the correct location, the kit contains the required items, or the insertion was completed properly. “Looks about right” is a poor production metric.
• Repeated demand. The task occurs often enough for training, integration, maintenance, and supervision costs to be spread across meaningful volume.
• Bounded variability. The environment may vary, but you can describe the expected objects, layouts, obstacles, and exceptions instead of asking the robot to handle anything that appears.
• Recoverable failures. A missed grasp can be retried or handed to a person without damaging an expensive item or blocking the entire operation.
• Contained consequences. A failure does not immediately expose a person to injury, contaminate a process, or damage critical equipment.
• Measurable human effort. You can count setup, monitoring, intervention, reset, and exception-handling time rather than treating human support as free.
• Adjacent follow-on work. The same body, gripper, sensors, workspace, and integrations could support other valuable tasks after the first one is reliable.

Be cautious when the task depends on delicate multi-finger manipulation, unpredictable deformable materials, subjective judgment, or constant close interaction with people. These may eventually be viable, but they combine difficult perception and control with expensive failure modes. They are poor choices for proving the initial business case.

Generalist robotics becomes economically interesting through adjacency. A fixed automation system may justify itself through exceptional throughput on one stable operation. A general-purpose robot has a different thesis: accept lower specialization in exchange for reusing the hardware, model, skill library, and operating system across related jobs. Buy the body for a credible task portfolio, but authorize one bounded workflow at a time.

Reliability must pass feasibility, repeatability, and economics

“The robot completed the task” is a feasibility statement, not a launch criterion. Production value depends on how often it succeeds, how long accepted work takes, how much human help it consumes, and what happens after a failure.

The gap between possibility and dependable operation is visible in Google’s reported Gemini Robotics 2 task results:

Robot configuration	Task	Reported task success	Product implication
Franka Duo with standard grippers	General pick and place	74.2%	Basic manipulation is feasible, but feasibility alone does not support unattended operation.
Franka Duo with standard grippers	Tool kitting	78.9%	A clear task structure helps, while misses still need an operational recovery path.
Franka Duo with standard grippers	Precise insertion	89.6%	A strong benchmark result is still not a forecast for different parts, fixtures, or conditions.
Five-finger hand	Unscrewing a light bulb	92%	A task can perform well even when a closely related reverse operation does not.
Five-finger hand	Screwing in a light bulb	36%	Do not infer one skill from the apparent similarity of another.
Five-finger hand	Tying a trash bag	44%	Flexible materials introduce state and control challenges that a rigid-object demo can hide.
Five-finger hand	Sealing a ziplock bag	40%	Dexterity must be evaluated on the exact object and completion condition.
Five-finger hand	Dustpan task	32%	Coordinating tools, material, and contact can remain unreliable despite general model capability.

These are vendor-reported results from particular experimental configurations. Treat them as evidence that capabilities are advancing, not as a forecast for your objects, hardware, environment, or operating process. The contrast between unscrewing and screwing in a light bulb is especially instructive: two actions that sound like inverses can have radically different control requirements.

Feasibility: can it finish the real task?

Test the complete workflow from the state in which work actually arrives to the state your operation accepts. If an employee must arrange every object into a demonstration-friendly position, that preparation belongs in the workflow cost. If a person completes the last step, record the run as assisted rather than autonomous.

Your evaluation set should cover ordinary variation, not just spectacular edge cases: different valid object positions, expected clutter, lighting changes, routine obstructions, and permitted product variants. Keep the task definition fixed while comparing systems. Otherwise, teams unconsciously make the problem easier after each failure and report an inflated success rate.

Repeatability: can it fail in a controlled way?

A useful reliability scorecard separates outcomes that a single success percentage hides:

• Accepted completions without human assistance
• Completions after an autonomous retry or recovery
• Completions requiring human intervention
• Incorrect completions that initially appeared successful
• Safe stops triggered before an unsafe or invalid action
• Failures that require a manual reset, cleanup, or repair
• Median and tail cycle time for accepted work
• Time spent waiting for connectivity, inference, or unavailable hardware

Count intervention at the action level. Repositioning an object, clearing a gripper, confirming a plan, restarting a sequence, or finishing the task by hand all consume labor. Combining them under “minor assistance” prevents you from seeing whether autonomy is improving.

If failure could injure someone or damage critical equipment, a high average success rate is not enough. Keep the workflow supervised and physically constrained until independent safety controls can stop invalid movement. A model’s confidence score should never be the only barrier between uncertain reasoning and a harmful physical action.

Economics: does useful autonomy beat the current workflow?

The metric that matters is useful autonomy: accepted work completed without unplanned human help. It connects model performance to an operating outcome. A robot that succeeds after frequent prompting may be technically impressive while creating little labor leverage.

Calculate cost per accepted completion using the full system: amortized hardware, software, integration, site changes, maintenance, monitoring, supervision, downtime, resets, and the cost of failed work. Use the same acceptance criteria for the robotic and current workflows. Comparing a robot’s raw movement time with an employee’s end-to-end process time will give you a decision-quality problem, not a decision-quality answer.

Set the graduation criteria before the pilot begins. If you choose the acceptable success rate, intervention burden, or cost after seeing the results, the team can make almost any demonstration look like progress.

Architecture determines what you can trust and scale

Embodied AI architecture is a product strategy decision because it determines latency, availability, data movement, permission boundaries, and how safely the system can degrade.

Cloud reasoning can support complex planning and coordination. Time-sensitive motion near people or fragile objects cannot assume that every network round trip will be fast and reliable. Local execution therefore matters even when high-level reasoning remains cloud-based. Gemini Robotics On-Device 2 is designed for this role, and Google says it can be adapted to substantially different two-arm robot designs using a few hours of data and typically fewer than 200 examples. That is a promising vendor claim, not a guarantee that every body and task will adapt with the same effort.

Before selecting a platform, make the following boundaries explicit:

• Goal authority: which users and systems may assign work, change priority, or cancel a task?
• Planning authority: may the reasoning layer create a new sequence, or must it choose from approved skills?
• Action authority: which movements, tools, workspaces, objects, and operating modes are permitted?
• Safety authority: what independent mechanism can slow or stop motion when the model, network, or sensor state becomes unreliable?
• Recovery authority: which failures may be retried automatically, and which require a person?
• Data boundary: which images, sensor streams, commands, and operational records can leave the site?
• Update boundary: how are model, policy, skill, and hardware versions tested together before deployment?
• Audit boundary: can you reconstruct what the robot perceived, planned, attempted, and observed after an incident?

A safe stop is a product outcome, not an embarrassing failure. Your dashboards should distinguish a correct refusal from a control error. If the system encounters an object, person, or state outside its approved envelope, stopping and requesting help may be the best available behavior.

The build-versus-buy decision should also be made layer by layer. Buying a robot does not require outsourcing the workflow definition. Using a foundation model does not require surrendering your evaluation data. The durable internal assets are likely to be your task contracts, representative evaluation set, failure taxonomy, intervention data, skill acceptance tests, and integrations with operational systems.

Own the layers that encode your operating advantage. Buy commodity capability when a supplier can meet your interface, safety, support, and observability requirements. This avoids the two common extremes: building a robotics stack that has no proprietary reason to exist, or buying a black box that cannot be evaluated against the work that matters.

Run a pilot that produces a scale decision

A good robotics pilot is not optimized for an impressive visitor experience. It is designed to tell you whether to scale, change the task, switch the system, or stop. That requires preserving failure evidence instead of rehearsing it away.

1. Write the task contract. Define valid inputs, the accepted end state, permitted actions, operating boundaries, stop conditions, and who handles each exception.
2. Measure the existing workflow. Record end-to-end cycle time, labor involved, quality checks, rework, interruptions, and exception handling. This is the baseline the robotic system must improve.
3. Build a representative evaluation set. Include the normal range of objects, positions, layouts, and routine disturbances. Keep a separate set for final evaluation so the team cannot tune only to familiar cases.
4. Create a failure taxonomy. Separate perception, planning, grasping, locomotion, manipulation, connectivity, hardware, policy, and acceptance-check failures. A single “robot failed” label gives nobody an actionable backlog.
5. Begin with supervision and explicit intervention rules. Tell operators when to wait, retry, stop, reset, or take over. Otherwise, different operators will quietly compensate for the system in different ways.
6. Instrument every attempt. Preserve the instruction, relevant sensor context, plan, actions, outcome, intervention, reset effort, and version information. Review failure traces, not only aggregate dashboards.
7. Expand one dimension at a time. Add a new object class, starting position, workspace condition, or adjacent skill only after the current envelope meets its predefined criteria. Simultaneous expansion makes regressions difficult to diagnose.
8. Make the decision in operating terms. Scale only when accepted output, human effort, failure consequences, and full cost support the business case. A capability milestone without an operating advantage is a learning result, not a production launch.

Key takeaways

• Generalist robotics means reusable capability across bounded workflows, not unrestricted autonomy.
• Evaluate the task, body, model, safety controls, and human recovery process as one product system.
• Separate feasibility from repeatability and repeatability from economics.
• Measure useful autonomy and intervention burden, not demonstration success alone.
• Treat local execution, permission boundaries, safe stopping, version control, and auditability as product requirements.
• Own your task definitions, evaluation set, failure data, and operational integrations even when you buy the underlying models and hardware.

If you have budget for an embodied AI initiative, spend the first portion on task mapping, baseline measurement, and the evaluation harness before committing to a fleet. Choose a repeated workflow with a clear finish state, recoverable failures, and credible adjacent tasks. Prove useful autonomy there, then widen the envelope deliberately. That is how a robotics demonstration becomes a product platform.

References

• Think Tank AI – AI Just Left the Screen

---