Robot Skills as the Next App Ecosystem

An app is only a useful analogy up to a point

A phone app usually owns a screen and a user session. A robot capability acts in a shared physical environment, may move mass, interact with people and must obey hardware and safety constraints. The more useful software unit is therefore not a screen-based app but a skill with a defined contract.

Skills turn embodiment into callable tools

A higher-level agent should not need to command joints or servo loops. It should reason in terms of capabilities exposed by the platform.

navigate(location)
inspect(asset)
pick(object)
place(object, location)
dock(charger)
handover(object, person)
report(exception)

A real skill requires trust metadata

Physical skills need declared hardware compatibility, confidence, failure modes, required sensing, operating envelope and safety conditions. A marketplace that distributes code without validating these boundaries would be far more dangerous than a conventional app store. Simulation evidence, runtime permissions and certification may become part of the platform itself.

This is where software reuse begins to compound

A reliable inspection or manipulation skill can potentially be reused across customers and compatible robot bodies. Reuse turns one-off integration work into software IP. The more that domain knowledge, telemetry and recovery logic are captured in the skill layer, the more difficult that layer becomes to commoditize.

The application economy begins when skills become portable

The decisive moment for Physical AI may not be when humanoids look impressive. It may be when a developer can build a useful physical workflow once and deploy it across multiple compatible machines. That is the point at which robotics starts behaving less like custom automation and more like a software platform economy.

Capability contracts strengthen even as general policies absorb more behavior

Confirmed evidence. Intrinsic Core exposes reusable control, motion-planning, grasp-planning, perception, simulation and calibration building blocks behind hardware-agnostic interfaces, which supports the idea that stable callable capabilities remain useful. At the same time, Google DeepMind reports one Gemini Robotics 2 checkpoint controlling multiple embodiments and rapid adaptation of Gemini Robotics On-Device 2 to new robot bodies. Skild reports that a policy based on S1 learned soccer through physical self-play using a single score objective, with behaviors such as dribbling, shielding, tackling and recovery emerging before transfer to a physical robot. Google and Skild results are first-party and do not establish industry-wide portability.

FlyPig interpretation. The evidence now points more clearly toward a hybrid architecture. Production systems still need external boundaries for permissions, safety, validation, orchestration and observability, but the behavior behind those boundaries can increasingly be generated by a general policy rather than installed as a separate hand-authored skill. The durable primitive may therefore be a permissioned capability or tool contract, not a marketplace of individually packaged robot behaviors.

FlyPig prediction. FlyPig prediction FP-PAI-004 remains weakening, with confidence falling from 0.56 to 0.53. Intrinsic provides meaningful counterweight because reusable capability interfaces are becoming concrete, but Gemini Robotics 2 and Skild strengthen the falsifier that end-to-end or general policies can make explicit behavior packages less necessary. The next decisive evidence is whether third-party ecosystems standardize capability contracts above these models.