Embodied Intelligence Enters the “Era of Definition”

General-Purpose Foundation Models Are Squeezing the Niche of Embodied-Native Models

In the RoboDojo evaluation report released in September 2026, Astra achieved an average success rate of 22.48% across 42 simulated tasks and 2,100 trials without task-specific fine-tuning, outperforming the 40 publicly available policies compared at the time. It brought language, vision, reasoning, and coding capabilities accumulated through general-purpose pretraining into robotics tasks.[1]

In the past, instruction understanding, in-context learning, and error correction could each constitute a research direction for an embodied intelligence team. Today, these capabilities are beginning to enter robotic systems through general-purpose pretraining, and capabilities that once required independent R&D are gradually becoming a foundation that can be reused directly. The simulated tactile manipulation and learning from real-robot demonstrations discussed at Mini3DV also showed the potential for this kind of transfer, with specific outcomes depending on the task and execution method.[2][3]

The real-world Franka pouring experiment in the presentation showed both progress in capability and the constraints of actual use. The arm poured water outside the cup on its first attempt, then adjusted and poured into the cup on its second. But when the water flow was interrupted, its response was again a beat too slow. The model could detect a problem and correct its actions; practical use also requires it to make that correction at the right time.[1]

I think this is where the squeeze on the niche is happening: as general-purpose foundation models continue to expand their coverage of capabilities, the capability differences that embodied-native teams once relied on may shrink. This pushes the starting point of competition back to definition: which use cases still contain problems worth solving, what advantages a team’s accumulated expertise can bring, and how long those advantages can last.

Definition: First Find the Intersection of Team Strengths and Use Cases

Definition comes before technology selection. A team needs to explain clearly who has this need, what the task’s key constraints are, which parts its accumulated expertise can address, and how much improvement is needed to make using a robot worthwhile. These judgments form two levels of alignment, which I also see as the basis of future core competitiveness.

The first level is defining team strengths and aligning them with use cases. A team needs to specify which key constraints its strengths in physical interaction, accumulated data, or understanding of a use case can actually address. Choosing a use case requires considering both whether the demand is real and whether the team can keep doing better through its accumulated expertise. The more specifically strengths are defined, the easier it is to find suitable use cases.

The second level is aligning the technical strategy with the use case. Once the use case is clear, the team can decide which capabilities to obtain from general-purpose foundation models, which are worth developing in-house, and how much to invest in research, data, evaluation, and systems. Model objectives, data collection, and evaluation metrics all need to target the same set of requirements, so that every investment serves the capability, efficiency, and cost requirements of the use case.

Take mixed-item picking as an example. A team skilled at rapid adaptation can prioritize use cases where new item types appear frequently, focusing R&D on generalization, data efficiency, and adaptation costs. A team skilled in tactile sensing and contact control can focus on reliably grasping slippery or deformable objects, organizing its technical investment around success rate, cycle time, and item damage. The more consistent a team’s strengths, choice of use cases, and technical strategy are, the greater its opportunity to become competitive.

Definition determines where to invest; alignment determines how to organize that investment. The next step is to translate these judgments into the generality, efficiency, and division of technical responsibilities required by the use case.

Alignment: Let the Use Case Determine the Trade-Off Between Generality and Efficiency

Once a use case is clearly defined, alignment has a concrete basis: how much variation the task needs to accommodate, and what speed and cost are acceptable. A general-purpose model may cost more per inference, yet reduce data collection and adaptation for new tasks. A specialized model may be faster on familiar tasks, but frequent retraining also adds cost. Generality and efficiency often involve a trade-off, and the definition of the use case determines the criteria for that trade-off.

Even for the same action of picking up a cup, a home robot may need to understand instructions from different people and handle entirely new objects tomorrow. At a fixed workstation, objects and workflows are relatively stable, making operating speed and running costs more important. Mixed-item picking falls between the two: it needs to adapt to change while controlling the time and cost of each operation.

I draw this relationship as two axes. On the left are use-case requirements, and on the right are model capabilities. Higher positions place more emphasis on generality; lower positions place more emphasis on efficiency. When selecting a solution, connect the capabilities the use case actually requires with the capabilities the solution can provide.

Open-ended tasks can rely more on general-purpose models, stable tasks can use rules or lightweight policies, and use cases in between leave room for models optimized for the use case. As general-purpose foundation models continue to improve in capability and efficiency, these matches will also change, and the room left for specialized models will need to be reassessed. A niche must be built on accurately understanding requirements and maintaining an efficiency advantage in meeting them.

Efficiency: Turning Technical Investment into Value in a Use Case

Definition identifies problems worth investing in, and alignment establishes a technical path. The next step is to use efficiency to test whether that path is viable. Provided that the required capabilities and reliability are met, a team needs to prove that its solution can complete the task in less time or at a lower total cost. This is what turns a technical advantage into value that can be used on a sustained basis in the use case.

Once capabilities meet the task’s requirements, I place greater weight on two kinds of efficiency. Time efficiency includes the speed of completing the task and the speed of responding to changes in the environment. Economic efficiency concerns the total cost of successfully completing the task, including data, training, inference, hardware, retries after failure, and human intervention. Together, they affect whether a capability can remain in use in a given use case.

The technology choices discussed above need to be tested against these efficiency measures. A general-purpose model can handle understanding and planning, then invoke reusable skills; an embodied model can also generate actions directly from perception. The two approaches can be combined—for example, by letting a general-purpose model handle changes in the task and a specialized policy handle high-frequency execution.

The slow response during pouring needs to be analyzed within this division of responsibilities. A low-level controller can execute actions at high frequency, while responding to new changes also depends on how quickly higher-level decisions arrive. It is therefore necessary to compare the time taken for the entire task and the response speed. Current API latency affects technology selection, and comparisons need to be revisited as models and deployment methods change.

Costs likewise need to be calculated across the entire task. An individual inference may be cheap, but if grasps frequently fail and a person has to take over, the eventual cost of use may still be high.

Feedback from a use case needs to inform R&D trade-offs. A team that defines “rapid adaptation” as its strength should compare its in-house solution with a general-purpose solution that can be reused directly, in the same use case and under the same success-rate requirements: how much data, debugging time, and total cost does each require when a new item type is added? These gains must also cover the ongoing investment in in-house development to support long-term competitiveness. If the general-purpose solution has already caught up, the corresponding R&D resources need to be reallocated.

Jev: How Efficiency Creates a Niche

Jev, in the field of general-purpose models, offers a point of reference. TypeSafe AI positions it as a decision model for software automation that directly returns typed decisions, with low latency and low cost as its core selling points.[5]

Even today, when general-purpose models are already highly capable, Jev still has its own niche: when a use case requires frequent, well-defined judgments, faster responses and lower costs of use become reasons to choose it once its capabilities meet the requirements. The fact that a general-purpose model “can do it” does not mean it offers the best value in every use case. Time efficiency and economic efficiency are themselves sources of competitiveness.

The same holds for embodied intelligence teams. Even if a general-purpose foundation model can already perform a certain type of operation, a specialized solution may retain value in specific use cases through faster responses, shorter operating cycles, and lower adaptation and running costs. Definition needs to identify which requirements place the greatest value on these advantages; alignment needs to make the technical strategy serve those requirements; and efficiency needs to demonstrate why users keep choosing the team’s solution. This is how the two levels of alignment—team strengths with the use case, and the technical strategy with the use case—ultimately establish a niche.

Be an Adventist in Mindset and a Redemptionist in Action

From definition to alignment to efficiency, and then to a niche, this logic also explains the position I expressed at the end of Mini3DV. There, I borrowed three factions to summarize different expectations of the relationship between LLMs and embodied intelligence.

Adventists believe that large models will eventually be able to solve every problem, including embodied intelligence, and that scaling is the main path to that goal.

Redemptionists advocate using LLMs for semantic understanding, task planning, and failure attribution, while leaving low-level contact control to specialized policies, seeking a niche for embodied intelligence through this division between the two kinds of capability.

Survivalists emphasize learning from physical interaction, building an understanding of laws such as gravity and friction through their own world models, and remain skeptical about how much physical capability LLMs can bring.

Being an Adventist in mindset means taking seriously the possibility that “large models will eventually solve every problem,” and accounting for continued progress in general capabilities when making technical judgments. Being a Redemptionist in action means starting from the requirements of today’s use cases and working deeply on the physical-interaction and efficiency problems worth investing in.

The future core competitiveness of embodied intelligence teams lies in clearly defining their own strengths, aligning them with suitable use cases, keeping their technical strategy aligned with those use cases, and building an advantage through time efficiency and economic efficiency. General-purpose foundation models will continue to shift the boundaries of competition, while a team’s ability to retain its niche depends on whether these two levels of alignment can continue to translate into efficiency advantages in its use cases. This is what I mean by the “Era of Definition.”