Product Strategy

Our product strategy for EMOS operates on two levels: solving the hard technical problems that will enable standardization of intelligent automation behaviors (The Technology Play) and positioning EMOS as the indispensable infrastructure for the Physical AI era (The “Picks-and-Shovels” Play).

1. The Technology Play: The Missing Orchestration Layer

Building a true runtime for Physical AI is a deep engineering challenge that cannot be solved by simply wrapping model APIs. While the AI industry races to train larger foundation models, a critical vacuum exists in the infrastructure required to ground these models in the physical world. EMOS targets this “whitespace” We believe that this “orchestration layer”, is a frontier for massive technological innovation.

Build Adaptability Primitives

Component graphs emerge naturally in robotics applications. Historically, these graph definitions have been declarative and rigid (for example in ROS), because the robot performed a pre-defined task for its lifecycle. For general-purpose robots, the system needs to be dynamically configurable and have adaptability built into it.

With EMOS, we developed a beautiful, imperative API that allows the definition and launch of self-referential, adaptable (embodied-agentic) graphs where each component defines a functional unit and adaptability primitives Events, Actions and Fallbacks are fundamental building blocks. The simplicity of this API in EMOS is necessary for definition of automation behaviors as Recipes (Apps), where the recipe developer can trivially redefine the robots task and the adaptability required based on the task environment.

The Adaptability Imperative. Credit: AGI Comics by @dileeplearning.

Build Embodiment Primitives

Speaking more on the theme of enabling general-purpose robots to be general agents, one should note that embodiment adds certain obvious challenges which would not necessarily arise in digital agent frameworks.

For general-purpose robots to be general agents they require a sense of “self” and “history” that digital agents do not.

EMOS introduces Spatio-Temporal Semantic Memory, a referable, queryable world-state that persists across tasks. Current robots have logs, not memory. They merely record data for post-facto analysis. EMOS allows the robot to recall this data at runtime for task specific execution. This memory is currently implemented using vector DBs, which are clearly a first step towards, building hierarchial spatio-temporal representations and there is plenty of innovation potential for building better models (e.g. graphs inspired by hipocampal structure) for the general-purpose robots of the future.

Similarly, state management for long-running general-purpose agents is also an open problem which requires maintaining a complex state machine that the agent can argue over for adaptive its own behavior. EMOS provides these embodiment primitives so that more and more general behaviors can be automated in recipes.

Build the Utilization Layer

For automation behaviors to be truly regarded as “Apps” the barrier to interaction must be zero. Robotics software thus far has just been the “backend” (algorithms), leaving the “frontend” (HRI) to be custom-developed third party interfaces. This disconnect kills the “App” model; you cannot easily distribute automation logic if the user needs to fiddle on the terminal or require a separate application just to press “Start”.

EMOS solves this by treating the UI as a derivative function of the automation recipe. In EMOS, the recipe is the single source of truth. Defining a logic schema automatically generates the control interface. When a user deploys a “Parking Patrol” recipe, for example, they instantly receive a bespoke UI with video feeds, path configurations, and controls.

It is crucial to distinguish this from commercial visualization platforms like Foxglove or OSS tools like Rviz. While those tools excel at passive inspection and engineering debugging, EMOS generates active control surfaces designed for runtime interaction and meant for actually using the robot.

Demo Video

Check this demo to see how we can build a fully autonomous security patrol recipe and deploy it on a physical robot using EMOS in under 15 minutes

Solve “Solved” Problems

With a plethora of demos coming out for ML based manipulation, one might be tempted to believe that navigation is a solved problem. It isn’t.

Traditional stacks which work rather well in structured environments (e.g. autonomous driving) fail in the dynamic, unstructured environments where general-purpose robots will have to operate. In robotics, the most widely used navigation framework (Nav2) is a collection of control plugins which are CPU bound with limited adaptability defined in a behavior tree with a declarative API. This is why we built Kompass in EMOS; a highly adaptive navigation system on GPGPU primitives.

Kompass covers 4 modes of navigation of an agent, point-to-point navigation, following a path, following an object/person and intelligently resting in place. Similarly it covers all motion models for each navigation mode. One can easily see that traditionally a purpose built robot, usually employs one of these navigation modes and a general-purpose robot would have to employ all of them based on its task.

Kompass utilizes the discrete and integrated GPUs widely available on robotic platforms for orders of magnitude faster calculations (of course, without any vendor lock-in). And it does this while being purpose-built for adaptability allowing it to be highly configurable in response to stimuli (events) generated from ML model outputs or the robots internal state.

2. The “Picks-and-Shovels” Play: Infrastructure for the Physical AI Gold Rush

Another way to look at EMOS is as an automation building platform. This puts it in the same category as digital agent building frameworks and tools that utilize them. And while the spotlight has recently shifted from just training bigger models to the agentic infrastructure graphs required to orchestrate them, we have been architecting this solution since day one. However, unlike digital agent frameworks, EMOS provides the runtime primitives for building agents that can comprehend, navigate and manipulate the physical world while adapting their behavior at runtime.

While agent building software for the physical world is technically much more challenging than the digital one, one can can still draw certain strategic parallels. Therefore, our strategy is distinct from the many “AI Labs” currently raising capital. We are not trying to win the race for the best Robotic Foundation Model (a poorly defined concept as of yet, as most work is on manipulation). We are building the platform that any effective foundation model will need to function in the physical world.

Benefit from ML Innovation

There is plenty of interesting work utilizing LLMs and VLMs for high-level reasoning and planning. Whether the future of direct “robot action” belongs to next-token prediction models (e.g., Pi, Groot, SmolVLA) or latent-space trajectory forecasting (e.g., V-JEPA), EMOS is uniquely positioned to benefit. As these models evolve through scaling or architectural innovation, our platform provides the environment for application specific utilization of these models as part of a complete system.

Currently we believe that Task-Specific Models will dominate over General Purpose Action Models for the foreseeable future. Unlike the digital world, “Internet-scale” data for physical robot actions does not yet exist, making out-of-domain generalization and cross-embodiment a persistent hurdle. Furthermore, current training data assumes a (fairly) static environment for manipulation tasks, which is also why unstructured navigation is a harder problem to solve with ML.

Real-world robotic intelligence will likely not be a single monolithic model, but a symphony of specialized models and control algorithms orchestrated together. EMOS is the only platform built explicitly to orchestrate this symphony.

Capture the “Access Network”

EMOS is oriented towards end-user applications, which means that its design choices and development direction optimize for deployment in real-world scenarios. By focusing on software that end-users actually touch (Recipes and their UI), we capture the “access network” for robotics.

EMOS enables the utility of robots, establishing a sticky ecosystem suitable for general-purpose robots. This is why we are focused on getting EMOS to its intended end-users and finding an actual commercial model with which this can be done, as explained in the commercial terms and value chain sections.