Continuum
All essays
Essay

The learning loop in physical AI

Why smarter household products create a second opportunity in the factories that build them.

October 2026

A household appliance should not need the household to become predictable before it can be useful. It should work around changing rooms, unfamiliar objects and people who do not follow instructions written for a machine.

We expect a new generation of consumer robots and appliances to move in that direction. The important change is not adding a conversational interface. It is making a product better at understanding conditions, choosing an action and checking whether that action worked.

That creates two connected opportunities: intelligence in the product and intelligence in the production process. A machine that adapts to its environment needs hardware that can be manufactured consistently, diagnosed in use and improved over successive versions. Our thesis is that physical AI creates value where those learning loops close, on either side of the factory gate.

Language is useful, but the world does not run on words

A language model can interpret a request, explain a failure and organize a plan. But a robot must also estimate where an object is, what will happen when it moves and whether its action remains within safe limits. Describing how to lift a cup does not establish that a machine can handle a slippery surface or a person entering its path.

World-model approaches address part of this problem by learning representations of how an environment changes. The goal is to predict relevant outcomes, potentially under candidate actions, rather than treat every physical problem as language generation.

The V-JEPA 2 research paper is one example. It studies prediction in learned visual representations and an action-conditioned extension used for robot-arm planning. Its experiments include picking and placing objects in laboratory settings. That is evidence of a promising approach, not a demonstration of general household autonomy.

We do not assume a single model family wins. Language models, predictive models, learned policies and conventional control systems may serve different parts of the same product. The commercial test is whether the combined system performs the task reliably within its physical and economic constraints.

The household tests the whole product

Homes are not standardized work cells. Layouts change, objects are partially hidden, and people and pets behave unexpectedly. The product must still justify its price and fit into an ordinary maintenance routine.

A narrow, valuable task is a stronger starting point than a broad claim of intelligence. We would rather see a product complete one recurring job with little intervention than perform many jobs only when an engineer prepares the room.

Adaptation need not require a humanoid form. An appliance might adjust its operation to measured conditions, detect a developing fault or recover from a bounded class of mistakes. These are hypothetical product directions, not claims that a particular vendor already delivers them. The value is reduced household effort, not resemblance to a person.

More capable hardware supports more tasks but adds parts, energy use and failure modes. Greater model complexity can improve perception while increasing latency and compute requirements. The right architecture is the least complicated one that delivers the promised outcome safely.

Local and cloud intelligence have different jobs

We expect many products to combine local computation with cloud services. Immediate sensing, bounded control and critical safety behavior should not depend on a remote model responding in time. Larger-scale analysis, training and some planning may benefit from cloud capacity.

This is a design judgment, not a claim that local inference automatically makes a product safe. A local model can still be wrong. A safety controller can still be badly designed. The split must be evaluated at the level of the complete machine.

Apple's technical work on on-device and server foundation models demonstrates a hybrid model architecture, including attention to memory and power constraints. It does not establish that those models solve robotics. The relevant lesson is that intelligence can be divided according to the task rather than treated as an all-local or all-cloud choice.

For physical products, that division affects latency, power, privacy and cost. A machine needs to know which work can wait when connectivity degrades, which must stop and which can continue under a simpler local policy. Those degraded modes are part of the product, not an edge case to postpone until after deployment.

Smarter products need more consistent manufacturing

A model can adapt to variation, but adaptation is not an excuse for inconsistent hardware. Sensor placement, mechanical tolerances and component behavior affect what a machine perceives and how it acts. Variation that is cheap to ignore in a passive product can become expensive in a machine expected to interpret its own state.

The manufacturing opportunity is therefore more specific than building more factories to meet demand for robots. It is linking the behavior promised by the product to the conditions under which that behavior is produced.

Consider a hypothetical household robot that repeatedly fails a gripping task. The cause could be the policy, lighting, calibration, wear or a component that behaves differently across production lots. Field data alone will not resolve that ambiguity. The company needs to connect the failure to the relevant hardware version, manufacturing history and operating conditions.

If a design change fixes the problem, it must reach production and inspection. If the problem is supplier variation, quality checks need to detect it. If the model is at fault, an update needs validation against current and older hardware. The useful loop runs from operation to diagnosis to an approved change and back to measured performance.

The digital thread needs a return path

Connecting design, manufacturing and product support is not a new idea. NIST's Digital Thread for Smart Manufacturing project, which concluded in 2018, described information gaps and the need for feedback from manufacturing and inspection into design. It is a historical foundation, not evidence of a newly solved market.

Our view is that adaptive products increase the value of making those connections usable. A part record, an inspection result and a field event become more useful when a system can establish how they relate to the same failure mode.

AI can help interpret those relationships. It cannot substitute for missing identifiers, unreliable measurements or undocumented changes. A persuasive explanation of a production problem can mislead engineers if it refers to the wrong product version.

The difficult work is organizational too. Design, quality, suppliers and factory operations must agree on what the data means and who may authorize a change. An automatically generated recommendation is not an automatically approved engineering change.

Where manufacturing AI becomes a product

We see potential in connecting field failures to quality investigations, translating approved design changes into production requirements and using inspection results to identify recurring variation. Each begins with a particular decision and a measurable outcome.

The startup must preserve version history, operate within permissions and show that its intervention reduced a real cost: scrap, rework, diagnosis time, warranty expense or delayed production. The metric depends on the workflow. A generic productivity claim is too easy to manufacture.

Deployment should also become easier. If every factory requires completely bespoke integration, the business may be valuable engineering services without the repeatability its software economics assume.

This is why "each deployment improves the next" needs a precise meaning. Reusable integrations, validated failure categories and better evaluation suites can transfer even when raw customer data cannot. Cross-customer model improvement requires appropriate rights and safeguards. Restricted operating data should not become an imagined common pool.

A good first product could own one costly handoff rather than the entire factory. It might help a quality engineer trace a recurring defect to the correct change history, then prove that the investigation took less time. The broader platform earns its way in through results, not a promise to connect everything.

The strongest objection: the world slows the loop

Software can be distributed quickly. Hardware changes face production schedules, inventory, qualification and installed products that cannot all be replaced. Better models do not remove those constraints.

Consumer demand may also be weaker than technical enthusiasm suggests. A device requiring frequent supervision or expensive service can lose to a simpler appliance. Household robotics could develop through narrow tasks rather than a rapid wave of general-purpose machines.

In manufacturing, incumbent engineering and industrial software providers have established records, integrations and buyer relationships. They may incorporate useful AI features before a startup builds operational depth. Field data may remain fragmented among manufacturers, service partners and customers.

We accept those risks. The manufacturing thesis does not require a near-term humanoid boom. Connected appliances and existing industrial products can create demand for better diagnosis and design feedback. But a consumer revolution does not guarantee that independent manufacturing AI companies capture its value.

What we look for

In consumer products, we look for a recurring job, a credible path to low intervention and an honest account of service and failure costs. What does the machine do without supervision? How does it fail? Does repeated use improve performance on the job people bought it to do?

In manufacturing software, we look for a loop across a costly information gap. Does field evidence reach the engineer who can act on it? Does the approved change reach the line? Does the next production run perform better? Does the next customer require less custom work?

We are less interested in chatbot interfaces for factory documents, disconnected anomaly dashboards or general autonomy claims that postpone the hardest parts to future hardware. Those can be useful features. They are not evidence of the loop.

This thesis weakens if intervention and service costs remain high, if lifecycle data cannot be linked, or if better diagnosis never produces measurable operating gains.

The opportunity is intelligence that learns from physical consequences. In the household, that means a product adapting to the work. In the factory, it means turning what happened in use into a better product and a more reliable process. The connection is not more robots leading to more factories. It is better evidence leading to better decisions in both places.

Sources

These sources establish technical approaches and historical manufacturing problems. Adoption, market structure and investment implications are Continuum's analysis; no market-size forecast is asserted.